...
Regterschot Racing has requested us to build an API where a member of the racecrew can view the data sent by a racecar in real-time. This data needs to be converted into charts that accurately represents the data in a clear way. This means that the data should be understood by the raceteam. All graphs are placed in a dashboard that is seen by crewmembers that are logged into the application. Viewers can also see a restricted set of data. Regterschot wants this API to be deployed in a web-application. The data that is retrieved from the broker, will eventually end up in a database. The web-application needs to have a constant connection to the database, to show past data. The present data is retrieved from a broker that the team at Regterschot Racing had already made. This broker will send data data to the application twenty times per second to the application. It is important that the communication with the database and broker provides a fast and reliable way to bring data to the website. The system needs to be easily expandable, so that it may be able to add new features in the future. Because Regterschot Racing wants this application to be expandable, we need to have a clear and informational instruction on how the code works. Our project will be followed up by multiple other groups that will build upon our code. These groups might be international groups and therefore everything needs to be documented in English, so that they may can understand how our code works.
User Classes and Characteristics
For this product, we'll realize two types of users. Firstly, there's the crewmembers, who are our main scope. A crewmember can view a race and retrieve all of its real-time and past data. Second, there's the viewers, who can only view the race with a restricted set of data that is updated real time. Viewers can not cannot select what kind of data they wish to see, all data that is visible for them will be visible at all time whilst watching the race.
These Both types of users can both log in into our web-application. A crewmember can see more options when logged in, as they can view back races and watch live races, whereas a viewer can only watch live races.
...
The product owner has not given a lot of constraints for this project. There are still a few technical limitations that limit our options. The car's data is being sent to the database twenty times per second. Because Regterschot Racing wants a constant stream of data to the application, it is required to use TCP as a communication protocol. This data has to must be converted into graphs because a clear overview of all data is demanded. We will have to use Google Charts because Google Charts runs in a web-application and can update the data twenty times per second (Lijden & Kooy, 2022).
...
- The product must present data from the sensors of the racecar.
- The user is has to be able to login to the site and choose how the data is presented.
- The product stores all the data from the sensor for future purposes.
- The crewmember is able to add, delete and update a tab.
- The crewmember can place charts in the tab that contains data from the chosen sensor.
- The viewer and crewmember can watch past and present races.
...
This document serves as a guideline for the multiple features and behaviors that our application will have. This document includes a list of elements that will attempt to define the intended functionality required by the customer to satisfy their different users. In addition to specifying how the system should behave, this document will also define what key performance parameters will need to be met by the system. In order to To accomplish this, the document has been divided into multiple sections:
...