Introduction

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 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 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 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 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 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.

Operating Environment

Our web-application's back-end will be built in Java 17 and Maven and our front-end will be built in Angular 14.0 and Bootstrap 5.0. The application will run in Wildfly 25.0.0, which allows us to run the website locally. We will use Java Database Connection (JDBC) to establish a connection between our database and our web-application. We'll also use a Broker to establish a connection between the racecar's sensors and our application, which allows us to receive a constant stream of data. The broker will also send data to the database, so that past data can be seen as well.

Design and Implementation Constraints

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 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).

Product Functions

Summary of all the functions:

• The product must present data from the sensors of the racecar.
•  The user is 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.

Purpose of this document

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 accomplish this, the document has been divided into multiple sections: