Trodomètre/SRS

From air
Revision as of 13:55, 11 February 2013 by Jfbianco (talk | contribs)
Jump to navigation Jump to search

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

1.2 Scope of the product

The goal of the “Trodometre” project is to provide a system to make accurate measurements during a journey. This system is able to calculate both indoor and outdoor measurements. In fact, it doesn’t use a localization system for its position in real time. Moreover, GPS is not available indoor and consumes a lot of energy which reduces the battery life of a system. Information collected by the program can be exported in XML format and used in OpenStreetMap. We can trace an itinerary everywhere precisely on the map. So, every circuit can be shared with everybody. The system is separated into two parts. The first part is the hardware. It is made up of sensors, based on ANT + technology, and moving means (scooter). Then, there is a second part with software which is based on Android an adaptability on every smartphone and mobile system.

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

2.2 Product functions

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