This post describes the non-functional requirements of LeapIn.it.
1. Performance | |
---|---|
Performance is the speed at which content is delivered to users, and how responsive the system is. | |
1.1. Processing time | Interactions with the server which require processing, such as login and requesting thumbnails of images, should take less that three seconds. |
1.2. Response time | Over reasonably common internet connection speeds, the server should respond to client requests in less that one second. |
1.3. Querying time | Querying the database should take less that one second. |
2. Capacity and scalability | |
The capacity is the amount of resources made available to the system, and scalability is the ability of the system to make use of these resources. | |
2.1. Storage | The system must store data effectively and must anticipate the time remaining until all available storage is filled up. |
2.2. Growth requirement | As the system gets used more often, by more people, the storage available will need to increase. |
2.3. Throughput | The system should be cable of 1000 queries per minute, with the capability to increase with larger demand |
3. Availability | |
Availability is the proportion of time that the system is online. | |
3.1. Hours of operation | The system should be always available during the hours it is most popular. Any maintenance where the system needs to be taken offline should be done outside these times. |
3.2. Locations of operation | The geographic location of the server should not impede the availability of the system. This means a location with a good quality connection and with minimal network restriction should be chosen. |
4. Maintainability | |
Maintainability describes how well the system can be kept functional and how well it can be changed. | |
4.1. Architectural standards | Accepted standards and design patterns should be used in the construction of the base architecture |
4.2. Coding standards | The code should be build modularly, such that independent parts accomplish independent tasks. Common coding styles should be utilised. |
5. Recovery | |
Recovery is the ability for a system to prepare and respond to a disaster. | |
5.1. Backups | The system should be responsible to taking backups of data, such that it may be restored to a working state. |
5.2. Backup frequency | The system should backup data very frequently (e.g. every hour) to avoid any data loss. |
5.3. Backup time | The system should backup in a short period of time (e.g. one minute) with minimal disruption. |
5.4. Recovery time | In event of a disaster, the latest backup should be immediately restored, such that the system is offline for less that one hour |
6. Security and privacy | |
Due to potentially sensitive information being contained within the database, the system should facilitate security and privacy. | |
6.1. Authentication | Users must be logged in in order to see posts and people’s profiles. |
6.2. Authorisation | Users must be friends with a person in order to see their profile. Users must be a resident of a room in order to see posts within it. |
6.3. Withholding of sensitive information | Passwords must not be stored within the system or revealed to users. |
6.4. Privacy | Users must be able to choose how who can see their profile and posts. |
6.5. Encryption | The system should make use of encryption to ensure that data is stored securely. For example, passwords should be stored as SHA1 hashes. Connections should be encrypted to prevent unauthorised listening of communication. |
7. Mobility | |
Mobility describes the suitability of the system for different platforms. | |
7.1. Mobile devices | The system should be operational on a wide spectrum of operating conditions, such as different screen sizes, performance and internet connection speed. |
7.2. Input devices | The system should make effective use of input devices on the mobile device. For example, the camera should be used for photo and barcode scanning. |
Please comment with your real name using good manners.