Projets-2016-2017-GeoDiff/SRS: Difference between revisions

From air
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
{|class="wikitable alternance"
=Requirements=
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| 05/02/2017
| A. Alexandre, B. Hervé, B. Aymeric
| GeoDiff
| -
| -


|}
==Functional==


* Function: Compare two spatial data sets.
** Description: Computes a delta between two spatial data sets.
** Input: Two spatial data sets.
** Source: Imported by the user.
** Output: The delta.
** Destination: The memory.
** Action: The two sets are compared and a delta is produced.
** Requirement: Two geographical data sets.
** Pre-condition: They represent the same data (at two different instants).
** Post-condition: The delta represents all differences between the data sets.
** Side-effects: Delta written into memory.
<!-- Each element of each data set should be either uniquely identifiable -->


=1. Introduction=
==1.1 Purpose of the requirements document==


Generic goals:
* Function: Display the delta.
Facilitating reviews
** Description: Display the calculated delta on the screen.
Describing the scope of work
** Input: The delta previously calculated.
Providing a reference to software designers (i.e. navigation aids, document structure)
** Source: The memory.
Providing a framework for testing primary and secondary use cases
** Output: A visualization of the delta.
Including features to customer requirements
** Destination: The screen.
Providing a platform for ongoing refinement (via incomplete specs or questions)
** Action: The delta is shown to the user, highlighting the additions, deletions and modifications.
Reliability Availability Security Maintainability Portability.
** Requirement: The delta being computed in advance.
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).
** Pre-condition: None.
** Post-condition: The delta is shown on screen.
** Side-effects: None.


==1.2 Scope of the product==


Data are often tedious to look through and sometimes people are lost inside its abundance and complexity.
* Function: Criteria selection.
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.
** Description: Computes a delta between two spatial data sets.
** Input: The current list of criteria.
** Source: The memory.
** Output: The list of selected criteria.
** Destination: The memory.
** Action: The criteria list is updated.
** Requirement: None.
** Pre-condition: None.
** Post-condition: None.
** Side-effects: The new criteria list is written into memory.


==1.3 Definitions, acronyms and abbreviations==


Delta: differences between two data sets (additions, deletions and location properties changes)
==Non-Functional==
Criterion: constraint on what to display on the screen (filter)


==1.4 References==
* Speed: The delta computation should be fast

* <!-- 1 donnée dans les deux fichiers => même identifiant -->
http://air.imag.fr/mediawiki/index.php/Sign2Text
* Ease of use: User-friendly interface
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=

Revision as of 22:33, 5 February 2017

Document History
Version Date Authors Description Validator Validation Date
0.1.0 05/02/2017 A. Alexandre, B. Hervé, B. Aymeric GeoDiff - -


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

Retrieved from "https://air.imag.fr/index.php?title=Projets-2016-2017-GeoDiff/SRS&oldid=33351"