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

From air
Jump to navigation Jump to search
Line 34: Line 34:
   
 
==1.2 Scope of the product==
 
==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==
 
==1.3 Definitions, acronyms and abbreviations==
 
==1.4 References==
 
==1.4 References==

Revision as of 13:16, 5 February 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

1.4 References

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.4 General constraints

2.5 Assumptions and dependencies

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 X.Y.Z (in Structured Natural Language)

Function:

Description:

Inputs:

Source:

Outputs:

Destination:

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

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

4. Product evolution

5. Appendices

6. Index