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

From air
Jump to navigation Jump to search
No edit summary
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
{|class="wikitable alternance"
=Software 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 Requirements==




=1. Introduction=
==Non-Fonctional Requirements==
==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 Requirements==

==3.1.1 Functional==


* '''Function:''' Compare two spatial data sets.
** '''Description:''' Compute 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 must be compared and a delta must be 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.


* '''Function:''' Display the delta.
** '''Description:''' Display the calculated delta on the screen.
** '''Input:''' The delta previously calculated.
** '''Source:''' The memory.
** '''Output:''' A visualization of the delta.
** '''Destination:''' The screen.
** '''Action:''' The delta must be shown to the user, highlighting the additions, deletions and modifications.
** '''Requirement:''' The delta being computed in advance.
** '''Pre-condition:''' None.
** '''Post-condition:''' The delta is shown on screen.
** '''Side-effects:''' None.


* '''Function:''' Criteria selection.
** '''Description:''' Filters which elements to show.
** '''Input:''' The current list of criteria.
** '''Source:''' The memory.
** '''Output:''' The list of selected criteria.
** '''Destination:''' The memory.
** '''Action:''' The criteria list must be updated.
** '''Requirement:''' None.
** '''Pre-condition:''' None.
** '''Post-condition:''' None.
** '''Side-effects:''' The new criteria list is written into memory.


* '''Function:''' Data saving.
** '''Description:''' Exports/saves the delta.
** '''Input:''' The delta.
** '''Source:''' The memory.
** '''Output:''' A geojson representing the delta.
** '''Destination:''' The user’s storage unit (disk drive, usb, etc.).
** '''Action:''' The delta shall be saved to the user’s storage unit.
** '''Requirement:''' The delta is calculated.
** '''Pre-condition:''' None.
** '''Post-condition:''' None.
** '''Side-effects:''' None.

==3.1.2 Non-Functional==

* '''Speed:''' The delta computation should be fast (first estimation 30 sec max )
* '''Ease of use:''' User-friendly interface (drawing will be added later and user should be able to use our product with less than 3 hours of training )

=4. Product evolution=

User account and data storage in a database

Different formats: xml...

More than two documents? (--> delta chaining)


If we decide to include this, we must think about the security and the efficiency of the database...

=5. Appendices=

The project diagrams can be found [[Projets-2016-2017-GeoDiff/UML|here]].

=6. Index=

Latest revision as of 08:46, 3 April 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

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 Requirements

3.1.1 Functional

  • Function: Compare two spatial data sets.
    • Description: Compute 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 must be compared and a delta must be 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.


  • Function: Display the delta.
    • Description: Display the calculated delta on the screen.
    • Input: The delta previously calculated.
    • Source: The memory.
    • Output: A visualization of the delta.
    • Destination: The screen.
    • Action: The delta must be shown to the user, highlighting the additions, deletions and modifications.
    • Requirement: The delta being computed in advance.
    • Pre-condition: None.
    • Post-condition: The delta is shown on screen.
    • Side-effects: None.


  • Function: Criteria selection.
    • Description: Filters which elements to show.
    • Input: The current list of criteria.
    • Source: The memory.
    • Output: The list of selected criteria.
    • Destination: The memory.
    • Action: The criteria list must be updated.
    • Requirement: None.
    • Pre-condition: None.
    • Post-condition: None.
    • Side-effects: The new criteria list is written into memory.


  • Function: Data saving.
    • Description: Exports/saves the delta.
    • Input: The delta.
    • Source: The memory.
    • Output: A geojson representing the delta.
    • Destination: The user’s storage unit (disk drive, usb, etc.).
    • Action: The delta shall be saved to the user’s storage unit.
    • Requirement: The delta is calculated.
    • Pre-condition: None.
    • Post-condition: None.
    • Side-effects: None.

3.1.2 Non-Functional

  • Speed: The delta computation should be fast (first estimation 30 sec max )
  • Ease of use: User-friendly interface (drawing will be added later and user should be able to use our product with less than 3 hours of training )

4. Product evolution

User account and data storage in a database

Different formats: xml...

More than two documents? (--> delta chaining)


If we decide to include this, we must think about the security and the efficiency of the database...

5. Appendices

The project diagrams can be found here.

6. Index