Requirements
The requirements are divided into different priorities, whose meaning should be clear from the following table:
| PRIORITY |
DESCRIPTION |
| + |
The requirement must be fulfilled in any case so that the product can be accepted. |
| 0 |
The fulfillment of the requirement is optional and therefore not necessarily a prerequisite for acceptance, but would have a very positive effect on the product. |
| - |
The fulfillment of the requirement is also optional and therefore not a prerequisite for the acceptance. |
Functional requirements
This section contains all requirements that specify the basic actions of the software system.
Game type
| ID |
FR1 |
| PRIORITY |
+ |
| DESCRIPTION |
QualityQuest shall be a 2D Visual-Novel-RPG. |
| EXPLANATION |
The PlayerAudience makes decisions over the PlayerCharacter in a fictional, high-fantasy world of a software engineer. The PlayerAudience plays the game only through StoryFlowDecisions, comparable to a Visual Novel in which the PlayerAudience can actively decide on certain parts of the story. |
Game presentation
| ID |
FR2 |
| PRIORITY |
+ |
| DESCRIPTION |
QualityQuest shall be a visual-based 2D RPG. |
| EXPLANATION |
This means that QualityQuest shall not be a purely text-based game, but text may be an element of the visual appearance of the game. |
NewTec branding
| ID |
FR3 |
| PRIORITY |
+ |
| DESCRIPTION |
QualityQuest shall display the NewTec logo clearly visible at any given time. |
| EXPLANATION |
- |
Game language
| ID |
FR4 |
| PRIORITY |
+ |
| DESCRIPTION |
The main language of QualityQuest shall be German. |
| EXPLANATION |
The majority of the to be used in-game language shall be german, but typical software engineering terms that are not german, but are commonly used in the german language, do not need to be translated. |
Game language options
| ID |
FR5 |
| PRIORITY |
0 |
| DESCRIPTION |
QualityQuest should support multiple languages. |
| EXPLANATION |
- |
Music
| ID |
FR6 |
| PRIORITY |
- |
| DESCRIPTION |
QualityQuest may be accompanied by a suitable musical background to enhance the player experience. |
| EXPLANATION |
- |
Sound effects
| ID |
FR7 |
| PRIORITY |
0 |
| DESCRIPTION |
QualityQuest should emphasize important events of the StoryFlow with sound effects. |
| EXPLANATION |
- |
Game content
| ID |
FR8 |
| PRIORITY |
+ |
| DESCRIPTION |
QualityQuest shall tell a story which mainly consists of typical elements of the software engineering profession. |
| EXPLANATION |
- |
StoryFlow
| ID |
FR9 |
| PRIORITY |
+ |
| DESCRIPTION |
The story of QualityQuest shall be non-linear. |
| EXPLANATION |
The story shall contain elements where the PlayerAudience needs to make a StoryFlowDecision. Depending on the decision, the StoryFlow shall continue in different StoryBranches. |
Influence on the StoryFlow by the player
| ID |
FR10 |
| PRIORITY |
+ |
| DESCRIPTION |
The PlayerAudience shall influence the selection of StoryBranches by means of StoryFlowDecisions. |
| EXPLANATION |
- |
Participation of a larger PlayerAudience
| ID |
FR11 |
| PRIORITY |
+ |
| DESCRIPTION |
QualityQuest shall have the option to let a larger audience participate in StoryFlowDecisions by means of online voting. |
| EXPLANATION |
The online voting feature is directly embedded into the game, together with an offline backup in case the server can't be used. |
Random element of StoryFlow control
| ID |
FR12 |
| PRIORITY |
+ |
| DESCRIPTION |
The selection of a StoryBranch after a StoryFlowDecision shall be generated randomly. |
| EXPLANATION |
Randomness can be either determined through ZeroRandomness or DiceRandomness. |
Visualizing the randomness
| ID |
FR13 |
| PRIORITY |
+ |
| DESCRIPTION |
If the selection of a StoryBranch after a StoryFlowDecision is generated with DiceRandomness, QualityQuest shall display a clear visualization of the randomization process. |
| EXPLANATION |
- |
Character status values
| ID |
FR14 |
| PRIORITY |
+ |
| DESCRIPTION |
The PlayerCharacter shall have all of the following PlayerCharacterStatusValue: Programming, Analytics, Communication, Partying. |
| EXPLANATION |
- |
Selecting a character
| ID |
FR15 |
| PRIORITY |
+ |
| DESCRIPTION |
At the start of the game the PlayerAudience shall choose a PlayerCharacter from a selection of 4 possible PlayerCharacters via online voting. |
| EXPLANATION |
- |
Presentation of character status values
| ID |
FR16 |
| PRIORITY |
+ |
| DESCRIPTION |
QualityQuest shall display a PlayerCharacterStatusBox with all PlayerCharacterStatusValues at all times. |
| EXPLANATION |
- |
Portrait of the PlayerCharacter
| ID |
FR17 |
| PRIORITY |
+ |
| DESCRIPTION |
QualityQuest shall display a portrait of the PlayerCharacter as part of the PlayerCharacterStatusBox all the time. |
| EXPLANATION |
- |
Character levelling
| ID |
FR18 |
| PRIORITY |
+ |
| DESCRIPTION |
The PayerCharacter shall level up and level down its PlayerCharacterStatusValues based on events or StoryFlowDecisions. |
| EXPLANATION |
- |
Visual presentation of PlayerCharacter status changes
| ID |
FR19 |
| PRIORITY |
+ |
| DESCRIPTION |
The change of PlayerCharacterStatusValues of the PlayerCharacter shall be highlighted visually. |
| EXPLANATION |
- |
Acoustic presentation of PlayerCharacter status changes
| ID |
FR20 |
| PRIORITY |
0 |
| DESCRIPTION |
The change of PlayerCharacterStatusValues of the PlayerCharacter should be highlighted acoustically. |
| EXPLANATION |
- |
Operating system
| ID |
FR21 |
| PRIORITY |
+ |
| DESCRIPTION |
QualityQuest shall run on Microsoft Windows 10 operating system. |
| EXPLANATION |
- |
Pause Game
| ID |
FR22 |
| PRIORITY |
+ |
| DESCRIPTION |
The moderator shall have the possibility to pause the game with the PauseButton. |
| EXPLANATION |
- |
| ID |
FR23 |
| PRIORITY |
+ |
| DESCRIPTION |
The PauseButton shall be around the upper right corner. |
| EXPLANATION |
- |
Moderator game control
| ID |
FR24 |
| PRIORITY |
+ |
| DESCRIPTION |
Once the Moderator-Client established the connection to the ServerLogic, the moderator shall have the option to start or interrupt the game at any time. |
| EXPLANATION |
- |
Connection Timeout
| ID |
FR25 |
| PRIORITY |
+ |
| DESCRIPTION |
If the Moderator-Client or ServerLogic does not react to each others messages, the connection shall be timed out by the WebSocket. |
| EXPLANATION |
This serves as a failsafe, in case of corrupted messages or connection loss. |
ServerLogic connection loss
| ID |
FR26 |
| PRIORITY |
+ |
| DESCRIPTION |
If a Moderator-Client or PlayerAudience-Client loses its connection to the ServerLogic, its GUID shall be stored in the ServerLogic. In this case, the respective client can reconnect to the ServerLogic to participate in the game again. |
| EXPLANATION |
- |
| ID |
FR27 |
| PRIORITY |
+ |
| DESCRIPTION |
The file format for data exchange between Moderator-Client and ServerLogic shall be JSON. |
| EXPLANATION |
- |
PlayerAudience-Client GUID
| ID |
FR28 |
| PRIORITY |
+ |
| DESCRIPTION |
Every PlayerAudience-Client shall be assigned a GUID in the form of a SignalR connectionId. |
| EXPLANATION |
This ensures the following points: - The SignalR-Hub can ensure a PlayerAudience-Client can't vote several times per vote.
- The ServerLogic can count the amount of PlayerAudience-Clients connected.
- The SignalR-Hub can keep exact track of every active PlayerAudience-Client.
|
Offline-Mode condition
| ID |
FR29 |
| PRIORITY |
+ |
| DESCRIPTION |
If any of the following conditions apply: - The server is not functional
- The network infrastructure slows down significantly
- The connection between Moderator-Client and Server is problematic
the Moderator shall continue the game offline. |
| EXPLANATION |
- |
Offline-Mode transition
| ID |
FR30 |
| PRIORITY |
+ |
| DESCRIPTION |
The Offline-Mode must ensure a smooth transition between online and offline and shall be able to step in at any time. |
| EXPLANATION |
- |
Network protocol violation
| ID |
FR31 |
| PRIORITY |
+ |
| DESCRIPTION |
If the Moderator-Client does not adhere to the network protocol 3 times in a row, the connection to the Moderator-Client shall be terminated. |
| EXPLANATION |
This ensures that it is not easily possible to tinker with the game through an altered client. |
Unique voting option identifier
| ID |
FR32 |
| PRIORITY |
+ |
| DESCRIPTION |
Every voting option shall be assigned a unique voting option identifier in form of a GUID. |
| EXPLANATION |
- |
Game-relevant ServerLogic logging
| ID |
FR33 |
| PRIORITY |
+ |
| DESCRIPTION |
Data that is needed for the general course of the game or for communication between clients and server shall be logged by the ServerLogic. |
| EXPLANATION |
Relevant data is: - The Moderator-Client GUID
- Online-Session key
|
General ServerLogic logging
| ID |
FR34 |
| PRIORITY |
+ |
| DESCRIPTION |
The most important and communication relevant operations of the ServerLogic shall be logged on the server side for debugging reasons. |
| EXPLANATION |
The general data logged by the ServerLogic is neither integral nor personal user data. |
ServerLogic log deletion
| ID |
FR35 |
| PRIORITY |
+ |
| DESCRIPTION |
Game-relevant logs shall be cleared under following circumstances: - No Moderator-Client has been connected to the ServerLogic in the last 30 minutes.
- A new Online-Session is being started.
- An ongoing Online-Session is being closed.
|
| EXPLANATION |
This ensures that no user-specific data is being saved on server side longer than it has to be. |
ServerLogic access-password
| ID |
FR36 |
| PRIORITY |
+ |
| DESCRIPTION |
The ServerLogic shall require a password to connect to it through a Moderator-Client. |
| EXPLANATION |
- |
Encryption of integral data
| ID |
FR37 |
| PRIORITY |
+ |
| DESCRIPTION |
Integral data shall be hashed and salted on the server side. |
| EXPLANATION |
An example for integral data is, but is not limited to being, the ServerLogic access-password. |
Online-Mode
| ID |
FR38 |
| PRIORITY |
+ |
| DESCRIPTION |
If the Moderator-Client is connected to a server, and the moderator is not currently playing in Offline-Mode, the game shall be in Online-Mode. |
| EXPLANATION |
- |
Offline-Mode
| ID |
FR39 |
| PRIORITY |
+ |
| DESCRIPTION |
If the Moderator-Client is not currently playing in Online-Mode, the game shall be in Offline-Mode. |
| EXPLANATION |
- |
Moderator-Client GUID
| ID |
FR40 |
| PRIORITY |
+ |
| DESCRIPTION |
The Moderator-Client shall be assigned a GUID by the ServerLogic. |
| EXPLANATION |
The GUID serves to identify as the Moderator-Client during on-going communication with the ServerLogic. |
PlayerAudience-Client count
| ID |
FR41 |
| PRIORITY |
0 |
| DESCRIPTION |
The ServerLogic should keep count of the number of PlayerAudience-Clients being connected to the ServerLogic. |
| EXPLANATION |
- |
PlayerAudience-Client count live update
| ID |
FR42 |
| PRIORITY |
0 |
| DESCRIPTION |
The ServerLogic should inform the Moderator-Client in 3 seconds intervals about the amount of PlayerAudience-Clients connected to the ServerLogic, as long as the game didn't start yet. |
| EXPLANATION |
- |
Online-Session permanence
| ID |
FR43 |
| PRIORITY |
+ |
| DESCRIPTION |
An Online-Session shall persist until one of the following conditions apply: - The Moderator-Client intentionally disconnects from the ServerLogic.
- A new Online-Session is started by the moderator.
- The Moderator-Client has not communicated with the ServerLogic in the last 30 minutes.
|
| EXPLANATION |
- |
Multiple Moderator-Clients
| ID |
FR44 |
| PRIORITY |
+ |
| DESCRIPTION |
If a Moderator-Client connects to the ServerLogic while another Moderator-Client is already connected to the ServerLogic, then a new, separate Online-Session shall be started and both Moderator-Clients shall stay connected. |
| EXPLANATION |
- |
Voting-Timer stop on pause
| ID |
FR45 |
| PRIORITY |
+ |
| DESCRIPTION |
The Voting-Timer shall pause when the Moderator-Client initializes a pause. |
| EXPLANATION |
- |
Communication during pauses
| ID |
FR46 |
| PRIORITY |
+ |
| DESCRIPTION |
Communication between Moderator-Client and ServerLogic, and between PlayerAudience-Clients and ServerLogic shall persist during the pause. |
| EXPLANATION |
- |
PlayerAudience connection method
| ID |
FR47 |
| PRIORITY |
+ |
| DESCRIPTION |
The PlayerAudience shall be able to join an Online-Session using a dynamically generated session key, provided by the ServerLogic. |
| EXPLANATION |
- |
PlayerAudience connection option
| ID |
FR48 |
| PRIORITY |
+ |
| DESCRIPTION |
The PlayerAudience shall be provided with an URL, at the start of the Online-Session, to be able to connect to the ServerLogic. |
| EXPLANATION |
- |
Additional PlayerAudience connection options
| ID |
FR49 |
| PRIORITY |
0 |
| DESCRIPTION |
The PlayerAudience should also be provided with a QR code, at the start of the Online-Session, to be able to connect to the ServerLogic. |
| EXPLANATION |
- |
| ID |
FR50 |
| PRIORITY |
+ |
| DESCRIPTION |
The pause menu shall pop-up after the PauseButton has been pressed. |
| EXPLANATION |
- |
| ID |
FR51 |
| PRIORITY |
0 |
| DESCRIPTION |
The pause menu should display the following elements: - A banner that reads "Pause"
- A button to unpause the game
- The PlayerAudience connection method
- All PlayerAudience connection options
|
| EXPLANATION |
- |
Vote indexing procedure
| ID |
FR52 |
| PRIORITY |
+ |
| DESCRIPTION |
The procedure used for indexing the different voting options shall be GUIDs. |
| EXPLANATION |
- |
Cryptographic hashing procedure
| ID |
FR53 |
| PRIORITY |
+ |
| DESCRIPTION |
The hashing procedure used for cryptographic purposes shall be SHA-256. |
| EXPLANATION |
- |
| ID |
FR54 |
| PRIORITY |
- |
| DESCRIPTION |
The SessionKey shall consist of six uppercase, alphanumerical characters. |
| EXPLANATION |
For example: F8G21Z or 8IB2P4
Key-Pattern: @"[A-Z0-9]{6}" |
PlayerAudience-Client count display
| ID |
FR55 |
| PRIORITY |
+ |
| DESCRIPTION |
The PlayerAudience-Client count shall be displayed in the Moderator-Client, as long as the PlayerAudience-Client count is transmitted to the Moderator-Client. |
| EXPLANATION |
For example: F8G21Z or 8IB2P4 |
Multi-Game support
| ID |
FR56 |
| PRIORITY |
- |
| DESCRIPTION |
The ServerLogic may support several Online-Sessions at the same time. |
| EXPLANATION |
- |
ServerLogic persistence
| ID |
FR57 |
| PRIORITY |
+ |
| DESCRIPTION |
The ServerLogic shall not crash or terminate a session upon receiving a faulty message or faulty data. |
| EXPLANATION |
- |
PlayerAudience-Client content
| ID |
FR58 |
| PRIORITY |
+ |
| DESCRIPTION |
The PlayerAudience-Client shall contain the following pages and links: - A landing page for cookies and Terms of Service.
- A main homepage that turns into the game.
- A link to the NewTec website.
- A link to the Github Repository.
- An about page.
- A Terms of Service page.
|
| EXPLANATION |
- |
PlayerAudience-Client cookies and Terms of Service
| ID |
FR59 |
| PRIORITY |
+ |
| DESCRIPTION |
The PlayerAudience-Client shall inform the user about cookies and Terms of Service. |
| EXPLANATION |
- |
PlayerAudience-Client landing page
| ID |
FR60 |
| PRIORITY |
+ |
| DESCRIPTION |
The PlayerAudience-Client shall display a cookies and Terms of Service pop-up which the user needs to consent to. |
| EXPLANATION |
- |
PlayerAudience-Client wrong SessionKey feedback
| ID |
FR61 |
| PRIORITY |
0 |
| DESCRIPTION |
The user should receive instant feedback upon entering a faulty SessionKey into the PlayerAudience-Client. |
| EXPLANATION |
- |
PlayerAudience-Client error logging
| ID |
FR62 |
| PRIORITY |
0 |
| DESCRIPTION |
Errors caused by faulty communication between PlayerAudience-Client and ServerLogic should be logged. |
| EXPLANATION |
- |
PlayerAudience-Client persistent connection
| ID |
FR63 |
| PRIORITY |
+ |
| DESCRIPTION |
The connection between PlayerAudience-Client and ServerLogic shall be persistent. |
| EXPLANATION |
- |
ASP.NET and SignalR
| ID |
FR64 |
| PRIORITY |
+ |
| DESCRIPTION |
The ServerLogic and PlayerAudience-Client shall use ASP.NET and SignalR for the implementation of the website and the persistent connection. |
| EXPLANATION |
- |
PlayerAudience-Client statistics display
| ID |
FR65 |
| PRIORITY |
- |
| DESCRIPTION |
The PlayerAudience-Client may display the voting results of the last poll. |
| EXPLANATION |
- |
PlayerAudience-Client language
| ID |
FR66 |
| PRIORITY |
+ |
| DESCRIPTION |
The main language of the PlayerAudience-Client shall be English. |
| EXPLANATION |
- |
Additional PlayerAudience-Client languages
| ID |
FR67 |
| PRIORITY |
- |
| DESCRIPTION |
The PlayerAudience-Client may support the german language. |
| EXPLANATION |
- |
Supported desktop browser
| ID |
FR68 |
| PRIORITY |
+ |
| DESCRIPTION |
The PlayerAudience-Client shall work on the following desktop browser: - Mozilla Firefox 85
- Google Chrome 88
- Safari 14
|
| EXPLANATION |
- |
Additional supported desktop browser
| ID |
FR69 |
| PRIORITY |
- |
| DESCRIPTION |
The PlayerAudience-Client may work on the following desktop browser: - Microsoft Edge 88
- Opera 72
- Internet Explorer 14
|
| EXPLANATION |
- |
Supported mobile browser
| ID |
FR70 |
| PRIORITY |
+ |
| DESCRIPTION |
The PlayerAudience-Client shall work on the following mobile browser: - Mozilla Firefox Mobile 81
- Google Chrome 88
- Safari 14
|
| EXPLANATION |
- |
Additional supported mobile browser
| ID |
FR71 |
| PRIORITY |
- |
| DESCRIPTION |
The PlayerAudience-Client may work on the following mobile browser: - Microsoft Edge: Web Browser 46
- Opera Mobile 61
|
| EXPLANATION |
- |
PlayerAudience-Client colour scheme
| ID |
FR72 |
| PRIORITY |
+ |
| DESCRIPTION |
The colour scheme of the PlayerAudience-Client shall roughly resemble the colour scheme of the NewTec website. |
| EXPLANATION |
- |
PlayerAudience-Client NewTec branding
| ID |
FR73 |
| PRIORITY |
+ |
| DESCRIPTION |
The NewTec logo shall be clearly visible on the homepage of the PlayerAudience-Client. |
| EXPLANATION |
- |
Webpage live updating
| ID |
FR74 |
| PRIORITY |
+ |
| DESCRIPTION |
The PlayerAudience-Client shall support the functionality to live update the HTML/CSS/JS of a webpage without reloading the site. |
| EXPLANATION |
- |
PlayerAudience-Client data filtration
| ID |
FR75 |
| PRIORITY |
+ |
| DESCRIPTION |
The backend of the PlayerAudience-Client shall filter incoming data from the PlayerAudience-Clients and discard anything out of order or format. |
| EXPLANATION |
- |
Moderator veto
| ID |
FR76 |
| PRIORITY |
- |
| DESCRIPTION |
The moderator may be able to veto the PlayerAudience. |
| EXPLANATION |
The moderator can use a special UI element of the Moderator-Client to veto the decision of the PlayerAudience. |
Moderator-Client statistics display
| ID |
FR77 |
| PRIORITY |
+ |
| DESCRIPTION |
The Moderator-Client shall display the voting results of the last poll in form of a bar graph. |
| EXPLANATION |
- |
Moderator-Client winning option display
| ID |
FR78 |
| PRIORITY |
+ |
| DESCRIPTION |
The Moderator-Client shall display the winning option of the last poll in a separate colour. |
| EXPLANATION |
- |
Moderator-Client error display
| ID |
FR79 |
| PRIORITY |
+ |
| DESCRIPTION |
Errors caused by faulty communication between Moderator-Client and ServerLogic shall be displayed by the Moderator-Client. |
| EXPLANATION |
- |
Tied winning options
| ID |
FR80 |
| PRIORITY |
+ |
| DESCRIPTION |
If two or more voting options receive the same number of votes, one of these options shall be randomly selected as the winning option. |
| EXPLANATION |
- |
Sound options
| ID |
FR81 |
| PRIORITY |
+ |
| DESCRIPTION |
The Moderator-Client shall support that one can set the audio options independently of each other. |
| EXPLANATION |
- |
SessionKey generator limit
| ID |
FR82 |
| PRIORITY |
+ |
| DESCRIPTION |
If the ServerLogic can't generate a new SessionKey, that is not currently used by another session, after 16 tries, the ServerLogic shall close all connections that use the last generated SessionKey and assign that SessionKey to the new session only. |
| EXPLANATION |
With 2.176.782.336 possible combinations for a SessionKey, the chance of this happening is close to 0 and only serves as a fail-save. |
Non-functional Requirements
This section specifies the non-functional requirements for the software system.
Documents to be delivered
| ID |
NFR1 |
| PRIORITY |
+ |
| DESCRIPTION |
A Technical Specification, which comprises use case diagrams, use case descriptions and a static view of the software architecture and Software Design Specification for each software component, which describes both the static and the dynamic view shall be delivered. |
| EXPLANATION |
- |
In-code documentation style
| ID |
NFR2 |
| PRIORITY |
+ |
| DESCRIPTION |
The source code shall be documented by means of XML comment documentation generation provided by Visual Studio 2019. |
| EXPLANATION |
- |
In-code documentation content
| ID |
NFR3 |
| PRIORITY |
+ |
| DESCRIPTION |
All of the following source code elements shall be documented: Constants, variables and defines. Classes and class members. Methods and method signatures, including return values. Functions and function signatures, including return values. |
| EXPLANATION |
- |
Documentation style for diagrams
| ID |
NFR4 |
| PRIORITY |
+ |
| DESCRIPTION |
All documentation diagrams shall follow the UML standard. |
| EXPLANATION |
- |
Delivery of UML diagrams
| ID |
NFR5 |
| PRIORITY |
+ |
| DESCRIPTION |
All UML diagrams shall be delivered in the form of a diagram and a PlantUML link. |
| EXPLANATION |
- |
Adherence to project Coding Styleguide
| ID |
NFR6 |
| PRIORITY |
0 |
| DESCRIPTION |
The software code should adhere to the code quality rules and .NET API usage rules Microsoft recommends. |
| EXPLANATION |
- |
Adherence to Clean Code Principles
| ID |
NFR7 |
| PRIORITY |
+ |
| DESCRIPTION |
The software code shall adhere to Grade 1 (Red) of the Clean Code Principles. |
| EXPLANATION |
- |
Target audience
| ID |
NFR8 |
| PRIORITY |
+ |
| DESCRIPTION |
QualityQuest shall address a target audience of university students with interest in a SW engineering career. |
| EXPLANATION |
- |
Playing time
| ID |
NFR9 |
| PRIORITY |
+ |
| DESCRIPTION |
The complete story of QualityQuest shall be playable in a time frame of 15 to 20 minutes. |
| EXPLANATION |
- |
Playing fun
| ID |
NFR10 |
| PRIORITY |
0 |
| DESCRIPTION |
The story of QualityQuest should be humorous. |
| EXPLANATION |
- |
Player motivation
| ID |
NFR11 |
| PRIORITY |
+ |
| DESCRIPTION |
The audience of QualityQuest shall be encouraged to follow the story by motivational elements. |
| EXPLANATION |
Motivational elements could be for example rewards, achievement & level upgrades. |
Deliverable artefacts
| ID |
NFR12 |
| PRIORITY |
+ |
| DESCRIPTION |
Documentation, Source Code and a running version of QualityQuest shall be delivered to NewTec. |
| EXPLANATION |
- |
Type of delivery
| ID |
NFR13 |
| PRIORITY |
+ |
| DESCRIPTION |
All deliverable artifacts shall be delivered digitally. |
| EXPLANATION |
The delivery can be by depositing the deliverable artefacts in a public version control system. Documents should be delivered in HTML/CSS. |
Deadline
| ID |
NFR14 |
| PRIORITY |
+ |
| DESCRIPTION |
The deadline for the final delivery is 2021-04-28. |
| EXPLANATION |
- |
Open source development
| ID |
NFR15 |
| PRIORITY |
- |
| DESCRIPTION |
The Source Code of QualityQuest may be published open source under CreativeCommons CC BY-NC 4.0 license terms. |
| EXPLANATION |
- |
Stand-alone game
| ID |
NFR16 |
| PRIORITY |
+ |
| DESCRIPTION |
QualityQuest shall be a stand-alone game. |
| EXPLANATION |
The final binaries shall include everything that is needed to run the game. Any possibly needed frameworks have to be included in the delivery. The installation of additional frameworks or libraries is not acceptable. |
Programming language
| ID |
NFR17 |
| PRIORITY |
+ |
| DESCRIPTION |
QualityQuest shall be programmed in C#. |
| EXPLANATION |
- |
Development environment
| ID |
NFR18 |
| PRIORITY |
+ |
| DESCRIPTION |
Both the source code and the build solution of QualityQuest shall be buildable in one of the following development environments: Microsoft Visual Studio 2019, Microsoft Visual Studio Code. |
| EXPLANATION |
- |
Usage of online voting solutions
| ID |
NFR19 |
| PRIORITY |
- |
| DESCRIPTION |
A self-made online voting solution shall be created by the team in order to implement the requirements of the tool and ensure the compatibility as optimal as possible. |
| EXPLANATION |
- |
Amount of supported connections
| ID |
NFR20 |
| PRIORITY |
+ |
| DESCRIPTION |
The Server shall allow up to 200 PlayerAudience-Clients to connect to the game via the network. |
| EXPLANATION |
- |
Non-exclusive Moderator-Client connection
| ID |
NFR21 |
| PRIORITY |
0 |
| DESCRIPTION |
The ServerLogic should allow a multitude of Moderator-Clients to connect to the ServerLogic at any given time. |
| EXPLANATION |
- |
Game Engine
| ID |
NFR22 |
| PRIORITY |
+ |
| DESCRIPTION |
As a game engine the project shall use Unity. |
| EXPLANATION |
The license conditions of the game engine allow the source code of QualityQuest to be open source. The license conditions of the game engine allow the usage of the game engine without license fees. The license conditions of the game engine allow the usage of QualityQuest as intended by NewTec without license fees. |
Communication security
| ID |
NFR23 |
| PRIORITY |
+ |
| DESCRIPTION |
The safe communication between Moderator-Client and the ServerLogic shall be guaranteed through WebSocket and HTTPS. |
| EXPLANATION |
- |
Postgame statistics
| ID |
NFR24 |
| PRIORITY |
0 |
| DESCRIPTION |
The Moderator-Client should display postgame statistics at the end of the Online-Session. |
| EXPLANATION |
- |
Postgame statistic contents
| ID |
NFR25 |
| PRIORITY |
0 |
| DESCRIPTION |
The postgame statistics should display which option was voted how often. |
| EXPLANATION |
- |
Unit test coverage
| ID |
NFR26 |
| PRIORITY |
+ |
| DESCRIPTION |
Moderator-Client, PlayerAudience-Client and ServerLogic shall have a 60% unit test coverage. |
| EXPLANATION |
- |
Integration test coverage
| ID |
NFR27 |
| PRIORITY |
+ |
| DESCRIPTION |
The Moderator-Client shall have a 60% integration test coverage. |
| EXPLANATION |
- |
Multiple endings
| ID |
NFR28 |
| PRIORITY |
0 |
| DESCRIPTION |
The Moderator-Client should have three different endings, depending on the performance of the PlayerAudience. |
| EXPLANATION |
- |