Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

NFR1Responses to all user-initiated actions in the web-interface must be be rendered on our systems in less than 1 second.NFR2Data from the racecar is sent towards the web-application twenty times per second. The application should thus update the data it is displaying twenty times a second3 seconds.

Security

Code

Description

NFR4NFR2The application must be protected against SQL-injection sand injections and other safety hazards to ensure no user can hack themselves into the race's data and alter said data.
NFR5NFR3Passwords must be hashed before they are stored into the database to ensure prevent no user account can be hacked by an outsider.

Reliability

Code

Description

NFR7NFR4All data sent by the racecar race car must be accurate to the last decimal stored in the database or received from the broker. This way, the analyzing racecrew analysing race crew can work with actual accurate data instead of rounded numbers.
NFR8NFR5There must be no code smells such as feature envy, shotgun surgery and tradition breaker present in the code. This is to ensure the expandability reliability of our application in the future.

Documentation

Data is stored in plain text
Code

Description

NFR9NFR6All documentation has to must be made in English to allow other groups that will continue our work after us to understand why we made certain choises, no matter their originchoices.
NFR10NFR7

The main color used for documetation the web-application should be #148484(). The secondary, complementary color to use in addition to the main color should be #81c8bd().

NFR11

.

Supportability

CodeDescription
NFR12NFR8All systems made by smalltalk should be sound and solidhave an A rating on SonarQube reliability, security and maintainability, so future groups can work with our code without having to rewire rewrite all of our code.
NFR13NFR9Our 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 annoying bugs or errors.