Non-functional Requirements
<Describe non-functional requirements in this section. Please refer to existing software quality models like ISO_IEC_IEEE_25010 or FURPS+.>
Performance Efficiency
Code | Description |
|---|---|
| NFR1 | Responses to all user-initiated actions in the web-interface need to must be be rendered on our systems in less than 1 second3 seconds. |
Security
Code | Description |
|---|---|
| NFR2 | The application must be protected against SQL-injections and other safety hazards to ensure no user can hack themselves into the race's data and alter said data... |
...
| NFR3 | Passwords must be hashed before they are stored into the database to prevent no user account can be hacked by an outsider. |
Reliability
| Code | Description |
|---|---|
| NFR3 | Personal user information needs to remain confidential to all parties other than system administrators. |
| NFR4 | ... |
...
| NFR4 | All data sent by the race car must be accurate to the last decimal stored in the database or received from the broker. This way, the analysing race crew can work with actual accurate data instead of rounded numbers. |
| NFR5 | There must be no code smells such as feature envy, shotgun surgery and tradition breaker present in the code. This is to ensure the reliability of our application in the future. |
Documentation
| Code | Description |
|---|---|
| NFR6 | All documentation |
| must be made in English to allow other groups that will continue our work after us to understand why we made certain choices. | |
| NFR7 | The main color used for the web-application should be #148484( |
Supportability
| Code | Description |
|---|---|
| NFR8 | All systems made by smalltalk should have an A rating on SonarQube reliability, security and maintainability, so future groups can work with our code without having to rewrite all of our code. |
| NFR9 | Our code should be tested thoroughly, with at least 80% of the lines being tested by unit-tests. This way we know our code is working and does not contain any bugs or errors. |