-
Notifications
You must be signed in to change notification settings - Fork 0
requirements_document
This document describes the technical requirements for Geonition. Geonition is a continuously evolving project and technology and so this document is a living document. When a change happens in this document the change should also be reflected to the technical architecture, design and service.
If this document becomes too big or the requirements too conflicting then a decision to separate the requirements might be in place. Also in this way Geonition product/services should increase
The business goals are to be able to maintain this on top of the cloud and sell licenses to users so that they will be able to collect and analyze geographical data. The service comes with consulting and manual analyzing work and expertise to as broad area as possible.
The service provides a way of save, store, update and delete geographical data tat is connected to a user or owner. The data can be presented in 2D, 3D or 4D as time being the fourth dimension. Analysis methods and calculation programs should be provided to the customer so that dumping the data out for analysis is possible.
| Concept | Description |
|---|---|
| geoJSON | Json format for describing geographical data |
| time dimension of data | The data is valid at some point in time and thus has a beginning time and an end time |
| User group | Description | Number of users | Importance of the group |
|---|---|---|---|
| SoftGIS developers | The developers are creating place based questionnaires for the needs of urban planning and research | 3 | Important |
| Id | Requirement | Importance for customer | Impact on architecture | Development effort | Status | Related test cases and code (commits) |
|---|---|---|---|---|---|---|
| 1 | The REST should provide a way to retrieve the data in CSV format | Important | Small | Small | Implemented | data_processing Django application offers this service |
| 2 | There should be a possibility to see the usage of the REST service. This makes it easier to find weird functionality of the services in an easy way instead of querying the database etc. | High | Small | High | Accepted | |
| 3 | There should be client side Javascript functions to support querying and retrieving information from the server. This lowers the amount of bugs and efficiency of the queries. Also it makes developing HTML Javascript user interfaces faster. | High | Medium | Small | Accepted |
| Id | Requirement | Importance for customer | Impact on architecture | Development effort | Related use case | Related test cases and code(commits) |
|---|---|---|---|---|---|---|
| 1 | The REST API should have a short response time | Important | High | Medium | ||
| 2 | The API should enable support many different kind of clients e.g. Javascript, AJAX, Python httplib. The requirement is that it should not be conflicting with any of the existing ways to connect over HTTP. | High | Small | Medium | ||
| 3 | The API should work side by side with other API:s as much as possible an minimize conflicts | High | High | Medium |
| Id | Idea | Importance for customer | Impact on architecture | Development effort | Source | Related requirement |
|---|
Try to minimize the constraints and get rid of them when they appear.
| Id | Constraint |
|---|