Setup Requirements

Target release

Epic

Document status DRAFT

Document owner Malte H

Designer

Developers

QA

Goals

Background and strategic fit

Assumptions

Requirements

# Title User Story Notes

1 Cross-platform Users want to install Inexor on their Desktop System

2 Cross-platform - Users want to install Inexor on their Windows System

Windows

3 Cross-platform - Users want to install Inexor on their OSX System

MacOSX

4 Cross-platform - Linux Users want to install Inexor on their Linux System

5 File Control Users want to keep their file system in control.

6 File Control - Overview Users want to know where the files of the installation
are located

7 File Control - Users want to modify where which files of Inexor get Paths for the complete installation, components, subcomponents...
Modification located.

8 File Control - Removal Users want to be able to remove files of Inexor to free complete installation, Components, Subcomponents...
up disk space.

9 Adaptability - High Level Users want to be able to install those components of Reason: People are interested in different stuff.
Inexor fitting their use case.

10 Adaptability - Low Level Users should be able to modify each part of Inexor

11 Adaptability - Low Level The effort to set up an Inexor Dev Environment Otherwise people won't start modifying
setup time should not overweight the estimated effects.

12 Adaptability - Iteration Users want to quickly see effects after modifying If it takes too long, they will get distracted and demotivated.
time Inexor

13 Adaptability - Distribution Users modifying Inexor should be able to distribute it

to other Inexorians

14 Adaptability - Users modifying Inexor should be able to work in a There must be some data exchange between different Users.
Collaboration team.
15 Adaptability - Users modifying Inexor parts should not be When different people modify different parts, it should be automatically
Collaboration - Minimize interrupted by users modifying other parts merged.
Collisions

16 Adaptability - Multiple Users modifying the same Inexor part should

Collaboration - Provide be able to resolve the different versions to get a
Collision Resolving common version

17 Adaptability - Users modifying specific parts of Inexor should be I.e. the iteration time and the distribution time need to fulfill soft real
Collaboration - able to concurrently work with others. time requirements
Cooperation

18 Communities Users want to connect with other people doing similar People should be able to join "interest groups" / communities
things in Inexor.

19 Communities - Rules Community should be able to specify community Rules == "Counter-Adaptability"

goals. Community Goals should be enforceable.
Reason: People want to organize themselves in communities in which
specific rules apply to provide them with safety.

20 Communities - The people playing should not get in non-constructive A peaceful atmosphere must be established. I.e. by steering game
Atmosphere fights. mechanics.

21 User Imprinting Users of the game should not have a negative The lessons from using Inexor should try to have a positive influence
influence from that usage. on the users mindset.

22 User Imprinting - Users should become self-confident

Confidence

23 User Imprinting - Users should reflect their thinking more often from
Reflection playing

24 User Imprinting - Users should be able to attack challenging problems

Resilience

25 User Imprinting - Users should be able to empathize with others.

Empathy

26 Installation Setup Users should be able to install Inexor

27 Installation Setup - Users without admin rights should be able to install

Preconditions - Inexor
Privileges

28 Installation Setup - Users should not be forced to do tedious tasks

Automation

29 Installation Setup - Users should be able to install Inexor with minimal

Automation - Installation effort

30 Installation Setup - Users should be able to update Inexor with minimal

Automation - Updating effort

31

32 Game Experience

33 World - Loading - The map should be loaded fast

Perfomance

34 World - Loading - Delay Users want to see the map as soon as it is "good Although this may mean that it is not fully loaded.
enough to play on"
This results in systems to keep a (/some) "spartanic version(s)" which
can be loaded before the real version (i.e. mipmapped version before
the real texture)

35 World - Loading - Users should not notice the world loading whenever More parts should get loaded in the background.
Background Task possible.

36 World - Unloading Since Users have limited hardware, unused parts of Lazy loading: only those parts in memory, the user is interested in/can
the world should get unloaded. interact with.

37 World - Distribution All Users should see changes on the map

38 World - Distribution - The distribution should happen fast enough to not This may mean hard realtime
Performance have influence on game results

39 Rendering - Level of
detail - Tessellation
User interaction and design

Questions
Below is a list of questions to be addressed as a result of this requirements document:

Question Outcome

Not Doing