Software Requirements Specification for Personal Data Acquisition Prototype

1. Overview

1.1 Problem Description

Personal data acquisition systems are systems that gather sport performance data on the way the athlete and the equipment they are using or operating is performing and provides feedback where improvements can be made. Today’s personal data acquisition systems largely fall into two categories. Category one is professional data acquisition systems, which provide the user high quality data to analyze. However, these systems are expensive, difficult to install, create a massive amount of data to transmit and store, and possibly require a high acumen with computer systems if something goes wrong. Category two is more cost-efficient Do It Yourself (DIY) systems. These systems solve the cost issue of professional systems and depending on the number and type of sensors, can reduce the amount of data that is transmitted and processed. The trade-off for the DIY systems is that the level of programming and computer systems expertise required grows exponentially.

In between these two categories, there is a void that leaves many people looking to improve their performance by accessing the power of data acquired while performing their sport.

1.2 Purpose and Vision

Our project will fill the void between the professional and DIY data acquisition systems that are available today. We will build a low cost modular data acquisition system that will be simple to install and use. We aim to create an easy-to-use, real time user interface that allows any user to install the system and use the data effortlessly, improving their performance without a significant background in computer systems. Our data acquisition system will have the capability to locally store and live stream the most important data for instant feedback.

1.3 Users and Stakeholders

Alex Ulbrich
Kirsten Winters
Chris Patton (Project Partner)
OSU Global Formula Racing club
Feipeng Yue (Winter 2025 TA)
ECE 44X Team
Group Members
- Bradley Tyler
- Colby Noah
- Garrett McMichael
- Joey Abruzzo
- Lisa Young
- Max Goldstein
- Morgan Padberg

Chris Patton is carrying out the role of project partner. He has stated that he will be able to provide us with previous years’ GitHub repositories, testing data for our prototype, and some amount of contact with the Global Formula Racing club at OSU. He has provided us with a basic framework for how our prototype should function, as well as constraints in the form of a preferred programming language (Rust). Chris Patton and the teaching team for this project (Alex Ulbrich, Kirsten Winters, and Casey) all have a stake in this project due to the time that they are investing in it. For the project partner, this investment may extend to a financial one.

We are using the OSU Global Formula Racing club as a proxy for our assumed user base. This means that when we perform user experience surveys, they will be our respondents. It is also possible that they will be able to make actual and significant use of our prototype if we are able to meet their needs.

We are working on this project alongside an ECE team. Since our product requires hardware that we will have to purchase, both teams have a financial stake in the outcome of this project. As a stretch goal we are also considering the possibility of turning the final prototype into a purchasable product, which will result in an even greater time and work investment. Moreover, our grades in the class depend partly on the successful implementation of the product.

2. Preliminary Context

2.1 Assumptions

The product we are developing is a prototype personal data logger for amateur F1 cars. The data logger will receive information from six sensors: accelerometer, yaw rate, GPS, force transducer, linear potentiometer, and string potentiometer. It will record data at 100Hz - 5,000Hz and live stream the information to a website on a remote device.

We will be using Rust for the majority of the coding, as requested by the project partner, along with choosing either egui or OpenGL, though wgpu, for the graphics.

2.2 Constraints

We may be limited by the fact that we are primarily using Rust since none of the team members have coded in Rust before. Moreover, previous teams for this project have stated that using Rust and egui for the frontend resulted in a primitive UI, and suggested that Rust and egui be avoided for frontend. This results in a tradeoff: if we use egui, we will have the expertise of our project partner but most likely have a lacking end result. On the other hand, if we use Rust and OpenGL, we may no longer be using a coding language and library that the project partner is familiar with, but could end up with a much more sophisticated UI. However, if that UI is limited in functionality, the project may fall short of these requirements.

Our prototype will be transmitting a large amount of data. This means that we will need to perform a significant amount of data compression to properly display the data in a timely and readable manner.

2.3 Dependencies

We need a database to hold the data from the data logger, user logins and user settings.

We are building off previous years work and will need to adapt to the current data logger being set up by the ECE team.

We are building a web application and will need to design a prototype and get feedback from the Oregon State University GFR Team prior to coding the User Interface.

Getting realistic test data and access points to the data logger require us to be dependent on other stakeholders.

2.4 Market Assessment and Competition

Oregon State University’s Global Formula Racing team currently uses Vector for data collection
High cost (https://www.ebay.com/itm/324655452701)
Dragy GPS data logger popular with vehicle tuners
- Corresponding mobile app has a rating of 1.1 stars on the App Store, with users reporting that the performance report and other features do not load properly
- High cost
  - GPS and performance recorder is $229.00
  - Company promotes accessories that cost up to $39.50
JB Data Engineering
- $3350 entry point
- High technical knowledge required to install

2.5 Target Demographics

The ideal target demographic for this project would be hobbyist or low-level professionals who are less technically proficient or more time constrained. Existing products have a high capability ceiling that can be used by professionals or high-level hobbyists with enough time to dedicate to them, but have a high barrier to entry. Our project will have a lower capability ceiling, but lower barrier to entry since it should take significantly less time to get up and running and produce useful results. Examples include hobbyist and small club-level racers or mountain bikers. These users might be limited by budget or software knowledge, or might have limited time to spend on their sport. They need quick access to important data, but might not need all the advanced features offered by competing products.

3. System Requirements Specification

3.1 Functional Requirements

The user should be able to view real-time or historic data from any selection or subselection of sensors connected to the device.
The client should receive information in real-time from the device when a stable connection is available.
When a stable connection is available between the device and server or the device and client, the client should receive real-time data.
If the device loses connection with the database/web server, the user should be able to view all data captured during the disconnection period when the device reconnects.
After a connection interruption, the client should automatically resume real-time data streaming from the device.
The client should be able to manually or automatically synchronize databases with the device.
The user interface should be easy for new users to navigate.
The web interface should be able to handle both mobile and desktop screen sizes.
The user interface should provide multiple color-blindness accessibility modes.

3.2 Non-Functional Requirements

The UI should have user selectable light and dark themes.
The software should have encrypted user passwords and usernames both when at rest or being transmitted.
Device should record data at 100Hz - 5000Hz.
The live streaming data should refresh at least every 2-3 seconds.
The device should upload its local data to the remote server frequently to minimize latency.
The device should immediately delete data from local memory once successfully uploaded to conserve RAM and minimize wear to the device’s flash memory.

3.3 Data Requirements

Data should be collected from a variety of sensors and may include:
- Accelerometer
- Yaw Rate
- GPS
- Force transducer
- Linear potentiometer
- String potentiometer
Data should be stored locally, then transmitted wirelessly and stored in database
Data must be filtered in order to provide accurate information

Figure 1–Database Entity-Relationship Diagram

3.4 Integration Requirements

Rust will be used for the embedded software to capture the data and prepare it to be sent to the external database
- Data formatting
- Error handling
- Local data storage
A remote database will store the data collected by the tracker and also be used to retrieve the data as it is displayed on the user interface

3.5 User Interaction and Design

The UI should be visually appealing and simple to navigate
To reduce clutter sub-menus and pages can be used, but should be limited to reduce complexity
Accessibility options like light and dark mode and colorblind modes should be available
Graphs should be easily readable and make good use of colors
Icon use should be clear and easy to understand
Icons should be prioritized over text wherever possible
Pages on the website should load in under 2 seconds and provide smooth visual transitions
Interface should always be clear about what is happening, and the user should never be stuck on a blank page or infinite loading icon

3.6 Open Questions

What are the sensors the ECE team is creating measuring? Which sensor is measuring what data?

What is the speed at which the hardware will develop data for each sensor used?

3.7 Out of Scope

We will not be implementing a mobile specific application.

We are considering a subscription service as a form of revenue, but this is currently a stretch goal. Doing so would also require more maintenance past the scope of the class.

4. Project Timelines

4.1 Milestones

Due Date	Feature	Description	Dependencies
CS 461 Week 7	Tech Stack Design	Determine the technology stack to use and what resources are required to develop this project, so we can note this in our design document and have all resources available by the start of CS 462.
CS 461 Week 7	Version-Control Setup	Configure a version-control system repository to host project code on GitHub
CS 461 Week 7	Low-Fidelity Design	Create a flow or wireframe UI design to understand the broad layout of the application
CS 461 Week 8	High-Fidelity Design	Create a high-fidelity UI design for the frontend of the main web application for the design document, project partner, and demo assignment.	Low-Fidelity Design
CS 461 Week 8	Tech Stack Resources	Ensure all resources determined necessary in Tech Stack Design are requested/ordered.	Tech Stack Design
CS 461 Week 9	Local Development	Create a test database and webapp to ensure proper communication between the webapp and the DBMS.	Tech Stack Design
CS 461 Week 10	Development Server Configuration	Once the requested development server is available to the team, install software required in Tech Stack Design; grant access to team members as needed. Ensure that the webapp is accessible from the Internet.	Tech Stack Resources Local Development (partial)
CS 462 Week 1	Database Schema Implementation	Design and implement the schema for how the sensor data will be stored, both on the local device and on the remote server.
CS 462 Week 2	Mock Data Generation	Write code to generate data that would emulate a sensor; this is used to test Week 4 code.	Database Schema Implementation
CS 462 Week 4	Network Protocol Implementation	Design the protocol used to transmit sensor data from the local device and the remote server; implement code to connect the local database with the TCP client and to connect the TCP server to the remote database.	Mock Data Generation
CS 462 Week 6	Remote Recorded Sensor Data Table	Write code to make the web UI display a table of recorded (mock) sensor data.	Network Protocol Implementation
CS 462 Week 6	Sensor Implementation	Design the protocol for communicating between the Bluetooth-enabled sensors and the local device.	Database Schema Implementation ECE team’s sensor design
CS 462 Week 7	Remote Sensor Graph	Write code to add a graph of sensor data to the recorded data table page in the UI, and controls to configure the graph display.	Remote Recorded Sensor Data Table
CS 462 Week 7	Remote Live Sensor Readout	Write the code to make the web UI display a live readout of sensor data. Optionally, include a bar graph in addition to the numeric readout.	Network Protocol Implementation
CS 462 Week 9	Remote Live Sensor Graph	Add a dynamically updating graph to the live sensor readout page to show recently collected data of a selection of sensors.	Remote Sensor Graph
CS 462 Week 10 (and periodically after)	Configuration Page	Add a page on the web UI to manage the configuration of both the server and the device. As additional features are added, update this page with necessary controls to configure these features.
CS 463 Week 2	Data Management	Add a mechanism to the UI to export data to a standardized format (CSV, XLS(X), JSON, etc.); add mechanisms to select and delete data.	Remote Recorded Sensor Data Table
CS 463 Week 4	Out-of-Box Experience	Create an “initial setup” screen where a user can intuitively configure the device, sensors, and server at first run	Sensor Implementation Configuration Page
CS 463 Week 5(ongoing until then)	Documentation	Proofread documentation created throughout the project; create a table of contents or other method of searching documentation.	Completion of software
CS 463 Week 6 (due 2025-05-13 12:00)	Engineering Expo Poster	Create a poster showcasing the project’s features and design to present at the Engineering Expo.
CS 463 Week 6	User Testing	Complete final user experience surveys to gather any achievable goals within remaining time.	Completion of software
If time permits	Stretch Goals

Table 1–Weekly Project Milestones

4.2 Goals and Success Metrics

Goal	Metric	Baseline	Target	Tracking Method
Increase usability of product among people with low technical expertise	Percentage of survey participants that found the software easy to use	75%	90%	Usability study with OSU F1 team
Desired features, or equivalent alternatives, are present (compared to previous iterations)	Percentage of features included	75%	90%	Compare prototype features with desired features found in previous studies
Desired features, or equivalent alternatives, are present (compared to currently used product)	Percentage of features included	70%	80%	Compare prototype features with current OSU F1 software (Vector)

Table 2–Identifiable Project Goals and Tracking Metrics