Difference between revisions of "RICM4 2017 2018 - SeriousGame Polystar / SRS"

From air
Jump to navigation Jump to search
 
(15 intermediate revisions by 2 users not shown)
Line 63: Line 63:
   
 
==2.4 General constraints==
 
==2.4 General constraints==
  +
- Multi-Users
  +
  +
- Asymmetrical use of the product for the different types of user
  +
  +
- Web application
  +
 
==2.5 Assumptions and dependencies==
 
==2.5 Assumptions and dependencies==
  +
- Use of tactile tables (Digitales of Actualities)
  +
  +
- Use of the NUC
  +
 
=3.Specific requirements, covering functional, non-functional and interface requirements=
 
=3.Specific requirements, covering functional, non-functional and interface requirements=
 
* document external interfaces,
 
* document external interfaces,
Line 71: Line 81:
 
* emergent system properties and quality characteristics.
 
* emergent system properties and quality characteristics.
   
==3.1 Requirement X.Y.Z (in Structured Natural Language)==
+
==3.1 Requirement Modifying/adding/deleting a Card==
'''Function''':
+
'''Function''': Modify, add and delete card and units of the game.
   
  +
'''Description''': The teacher has the rights to change things in the game such as the cards used to play.
'''Description''':
 
   
 
'''Inputs''':
 
'''Inputs''':
  +
A person who is authenticated thanks to a password.
   
'''Source''':
+
'''Source''': /modifypage
   
 
'''Outputs''':
 
'''Outputs''':
  +
The person who has the rights has modified / added / deleted a card.
   
'''Destination''':
+
'''Destination''': /modifypage
   
 
'''Action''':
 
'''Action''':
* Natural language sentences (with MUST, MAY, SHALL)
 
* Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 
* Mathematical Notations
 
* Tabular notations for several (condition --> action) tuples
 
   
  +
#Log in
'''Non functional requirements''':
 
  +
#Select the option wanted (modify, add, delete)
  +
#Confirm
  +
  +
'''Non functional requirements''': Security
  +
  +
'''Pre-condition''': A teacher who wants to change cards of the game.
  +
  +
'''Post-condition''': A modified pack of cards.
  +
  +
'''Side-effects''': None
  +
  +
==3.2 Requirement Play a Game==
  +
'''Function''': Launch a game with several players
  +
  +
'''Description''': The game is played in its integrity or partially by the players
  +
  +
'''Inputs''': At least 2 teams and at most 4 (for now, may change in the future)
  +
  +
'''Source''': /
  +
  +
'''Outputs''': The game is played.
  +
  +
'''Destination''': /gamepage
  +
  +
'''Action''':
  +
  +
#Select the play option
  +
#Choose the unit(s) to play with
  +
#Select the number of teams playing
  +
#Confirm
  +
#Play the game until the end or until the game is quitted
  +
  +
'''Non functional requirements''': Respect the game rules
  +
  +
'''Pre-condition''': The players are present around the table to play the game
  +
  +
'''Post-condition''': The game is either ended or quitted early.
  +
  +
'''Side-effects''': None
  +
  +
==3.3 Requirement Game supervision==
  +
'''Function''': The teacher supervises the game progress
  +
  +
'''Description''': The game is supervised by the teacher.
  +
  +
'''Inputs''': A game is currently played and the Teacher is nearby the tables
  +
  +
'''Source''': None
  +
  +
'''Outputs''': The game is supervised
  +
  +
'''Destination''': None
  +
  +
'''Action''':
  +
  +
#The Teacher lets the game progress and intervenes if needed
  +
 
'''Non functional requirements''': None
   
'''Pre-condition''':
+
'''Pre-condition''': A game is currently played
   
'''Post-condition''':
+
'''Post-condition''': The game progress and the game experience is enhanced
   
'''Side-effects''':
+
'''Side-effects''': None
   
 
=4. Product evolution=
 
=4. Product evolution=

Latest revision as of 11:57, 6 March 2018

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.


Read first:

Document History
Version Date Authors Description Validator Validation Date
0.1.0 TBC TBC TBC TBC TBC


1. Introduction

1.1 Purpose of the requirements document

Polystar powerpoint’s aim is to give the rules of the game.

1.2 Scope of the product

This project will be an educative game for Polytech students, allowing them to improve their english level.

1.3 Definitions, acronyms and abbreviations

SeriousGame : It is a game designed for a purpose other than pure entertainment. Here, it is designed for education and studies. Meteor: JavaScript Web framework written using NodeJS. Meteor produces cross-platform code.

1.4 References

https://air.imag.fr/images/a/ad/Polystar.pdf

1.5 Overview of the remainder of the document

2. General description

2.1 Product perspective

In the future our product is designed to be adapted in other languages (spanish) and other difficulties (other than 3rd year English). The users will be able to add their own cards and units to the game.

2.2 Product functions

The main function of the product is making it easier to learn 3rd year english in Polytech by providing a learning game. This game contains several english question cards created by A-L. Finkel, the Polytech Grenoble headmaster english teacher. The students users are allowed to see the ladderboard and to choose which unit to play with. The teacher is allowed to create, modify and delete cards from the game.

2.3 User characteristics

2 types of users :

- Teacher

- Students / Players

The teacher can modify / add / delete the cards and the units of the game. Therefore, he needs a password to avoid students to access to this part.

The players / students will have the access to the ranking and the game.

2.4 General constraints

- Multi-Users

- Asymmetrical use of the product for the different types of user

- Web application

2.5 Assumptions and dependencies

- Use of tactile tables (Digitales of Actualities)

- Use of the NUC

3.Specific requirements, covering functional, non-functional and interface requirements

  • document external interfaces,
  • describe system functionality and performance
  • specify logical database requirements,
  • design constraints,
  • emergent system properties and quality characteristics.

3.1 Requirement Modifying/adding/deleting a Card

Function: Modify, add and delete card and units of the game.

Description: The teacher has the rights to change things in the game such as the cards used to play.

Inputs: A person who is authenticated thanks to a password.

Source: /modifypage

Outputs: The person who has the rights has modified / added / deleted a card.

Destination: /modifypage

Action:

  1. Log in
  2. Select the option wanted (modify, add, delete)
  3. Confirm

Non functional requirements: Security

Pre-condition: A teacher who wants to change cards of the game.

Post-condition: A modified pack of cards.

Side-effects: None

3.2 Requirement Play a Game

Function: Launch a game with several players

Description: The game is played in its integrity or partially by the players

Inputs: At least 2 teams and at most 4 (for now, may change in the future)

Source: /

Outputs: The game is played.

Destination: /gamepage

Action:

  1. Select the play option
  2. Choose the unit(s) to play with
  3. Select the number of teams playing
  4. Confirm
  5. Play the game until the end or until the game is quitted

Non functional requirements: Respect the game rules

Pre-condition: The players are present around the table to play the game

Post-condition: The game is either ended or quitted early.

Side-effects: None

3.3 Requirement Game supervision

Function: The teacher supervises the game progress

Description: The game is supervised by the teacher.

Inputs: A game is currently played and the Teacher is nearby the tables

Source: None

Outputs: The game is supervised

Destination: None

Action:

  1. The Teacher lets the game progress and intervenes if needed

Non functional requirements: None

Pre-condition: A game is currently played

Post-condition: The game progress and the game experience is enhanced

Side-effects: None

4. Product evolution

5. Appendices

6. Index