The functional and non-functional requirements were developed late during the in-depth project, and has received little changes since then. They have all been assigned a priority (C=Critical, H=High, M=Medium, L=Low) in collaboration with the customer, Revolve. The requirements assigned critical priority are an absolute necessity to make the system work. High and medium priority require-ments represents mainly the desired functionality, while low priority requirerequire-ments are meant to be less important bonus features.
8.3.1 Functional requirements
In this section we will list the functional requirements with an ID that is used throughout the report. We will also list the priority that have been set on this requirement by Revolve.
8.3. SPECIFIC REQUIREMENTS 49
Table 8.1: The system requirements.
ID Description Priority
ID - Input data
ID1 The system shall be able to extract (parse) the logged data from a predefined data structure stored in a file
C
DC - Data channels
DC1 The system must support generation of channel reports that show the minimum, maximum and average values for the selected channel
H
DC2 Time and distance shall have their own data chan-nels, like e.g. throttle and RPM
M DC3 The system must support math channels with
logic and derivative functions. It should be able to save custom math channel configurations for later re-use
M
DC4 The system must support calibration of channel data (e.g. translating from voltage to tempera-ture) using a set of polynomials
H
DC5 The system must have the ability to smooth graphs
M DC6 The system must support lap segmentation
(cor-ners and other types of segmentation) to make it easier to compare the same segment in different laps (manual)
H
DC7 It must be possible to get the lap times without the use of external sensors/beacons, for instance by using GPS
L
DC8 The system must support channel and segment color coding for ease of comparing segments
H DC9 The system shall have be able automatically
seg-ment the race map into curves and straights
L
Continued on next page
Table 8.1 – continued from previous page
ID Description Priority
GUI - Graphical user interface
GUI1 The GUI shall provide an empty visualization lay-out interface where the user can place different visualizations (e.g. standard graphs or video)
H
GUI2 It should be possible to duplicate a visualization layout
L GUI3 The GUI shall have multiple tabs containing the
different visualization layouts
H
GUI4 Multiscreen support L
GUI5 The visualization layout interface should have a snap to grid functionality for easy layout configu-ration
L
GUI6 The system shall have a map view to help the user put data into context
H GUI7 The system shall be able to display video recorded
from the vehicle and synchronize it with the other data
M+
GUI8 The system shall be able to put synchronized over-lays on video, like speedometer and minimap
L GUI9 Own GUI panel for visualization options M GUI10 Synchronized zoom between visualizations M
GV - Standard graph view
GV1 It shall be possible to draw data as function of time
H GV2 It shall be possible to draw data as function of
distance
C GV3 The system shall support time slip visualization
with time gained or lost in different positions
M GV4 The system must have the ability to view more
than one data channel/lap/segment in the same view (color coded)
H
GV5 The standard graph visualizations shall support horizontal and vertical scaling and zoom
H GV6 The standard graph visualizations must have the
possibility to synchronize their cursor positions for improved understandability
GV7 The system must support autofitting of seg-ment/map/marked area to the current view
M Continued on next page
8.3. SPECIFIC REQUIREMENTS 51
Table 8.1 – continued from previous page
ID Description Priority
XY - Standard XY-graph view
XY1 The system must have the ability to draw XY-graphs, in which other data channels than time or distance are plotted against each other, e.g. speed versus RPM
M
XY2 The system must have the ability to view more than one lap/segment in the same view (color coded)
H
XY3 XY graphs shall support horizontal and vertical scaling and zoom
H XY4 The XY graph visualizations must have the
pos-sibility to synchronize their cursor positions for improved understandability
H
Other
O1 The system shall support a undo/rollback history (with at least 100 actions)
M O2 The system shall have customizable hotkeys L O3 The system should have the ability to store a work
session to continue working on it at a later time M O4 The system shall support autosave (e.g. auto store
work session every minute)
L O5 The user should be able to store notes in the work
sessions
M O6 The system shall be able to export visualizations
to a suitable format (e.g. PNG images or PDF documents)
L
Non-functional requirements
NF1 The system should be able to run on the hard-ware the laptop that Revolve will be using has, in other words Intel Core 2 Duo, 1GB RAM or more powerful
M
NF2 The program must run on the most common op-erating systems (Windows, Linux and MacOS)
L NF3 Start-up of the system should take less than 5
sec-onds
M Continued on next page
Table 8.1 – continued from previous page
ID Description Priority
NF4 The system should not stay in memory or as a background process once exited, and should not have memory leaks
H
NF5 The system has to come with a user guide H NF6 The code has to adhere to standard Java coding
conventions and be documented by JavaDocs
H NF7 The system shall be ready for testing early April
2012 when the car is scheduled to be finished
H
8.4 Changes
This section contains the changes done the requirements during the project lifetime.
The requirement ID2 has been removed. Revolve have not added technology ca-pable of transferring real-time from the their data loggers to a recipient.
The follow two requirements have been added:
GUI10: Synchronized zoom between visualizations. M
O5: The user should be able to write and store notes in the work sessions. M