Projets-2016-2017-GeoDiff/SRS

=1.  Introduction=

1.1 Purpose of the requirements document
Generic goals: Facilitating reviews Describing the scope of work Providing a reference to software designers (i.e. navigation aids, document structure) Providing a framework for testing primary and secondary use cases Including features to customer requirements Providing a platform for ongoing refinement (via incomplete specs or questions) Reliability Availability Security Maintainability Portability. More precisely this document will be marked as an assignment and will be our guide or reference to our school project (it will be modified if needed because no one can think about everything before the beginning of a project).

1.2 Scope of the product
Data are often tedious to look through and sometimes people are lost inside its abundance and complexity. Our product will bring the beginning of a solution by giving only a resume of the differences between two sets of data in the context of spatial data.

1.3 Definitions, acronyms and abbreviations
Delta: differences between two data sets (additions, deletions and location properties changes) Criterion: constraint on what to display on the screen (filter)

1.4 References
http://air.imag.fr/mediawiki/index.php/Sign2Text http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx http://en.wikipedia.org/wiki/Software_requirements_specification IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

1.5 Overview of the remainder of the document
The rest of the document contains technical characteristics of the project’s development.

=2.  General description=

2.1 Product perspective
Goal: visualisation of the delta of spatial data, under some criteria.

2.2 Product functions
Function: Compare two spatial data sets (i.e. produce a delta) Function: Display the delta Function: Criteria selection Function: export / save the data

2.3 User characteristics
Users will represent any organisation which has geojson data and wants to see their evolution through time (territorial collectivities, safety and prevention of risks, city halls, etc.).

2.4 General constraints
Size of data: keep computing time as small as possible (less than thirty seconds)

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=