Go back to publications

Accident Warnings During Edge Case Traffic Events: Requirements Specification

February 2020 H. Orlowski, M. Golombeck, M. Filusch, L. Müller Technical Report 10.13140/RG.2.2.14784.89609 University of Applied Sciences and Arts Dortmund English
#Requirements Engineering#IEEE 830#Automotive Systems#Interactive Mobility
PDFResearchGate

A car’s sensors see what is in front of the car. That is the limit of the model, and it is precisely the edge cases beyond that boundary, the hazard around the corner, the situation that has not developed yet, where a driver most needs warning.

This document specifies a traffic accident warning application designed for exactly those cases, going beyond what an automated in-car sensor-based system can provide. It follows the IEEE 830 recommended practice for software requirements specifications throughout.

Approach

Scope, vision and subsidiary goals are derived first. The perspective of a potential contracting authority is then adopted to define an overall project description, which keeps the requirements anchored to something a client could actually commission.

From those goals the specification yields 40 distinct requirements, each proposed, grouped, rated and prioritised rather than simply listed. The intent is to give a mobile application a foundation solid enough to build on: one that identifies hazardous situations in traffic and warns the driver, advancing interactive mobility and proactively improving the safety of driver and passengers.

Stakeholders and Interactions

A requirement is only as defensible as the party it answers to. Every stakeholder is therefore rated twice, once on influence over the project and once on attitude towards it, and the resulting matrix settles who must be managed closely and who merely watched. The competitors sitting alone in the lower left quadrant are the clearest case: hostile, but without the leverage to matter.

Stakeholder matrix plotting power and influence against attitude towards the project, with the executive board, project manager and software developer marked negative and investors, users, politicians and traffic providers marked positive.
Figure 2. Stakeholder-Matrix of the identified Stakeholders.

The use cases fall out of the same exercise, and they separate cleanly into what a driver asks of the application and what an administrator does to it. Almost half of the user-facing cases concern data: granting permission for it, retrieving it, deleting it.

Use case diagram with a user actor connected to cases such as receiving accident and congestion warnings, sending personalised sensor data and deleting stored data, and an administrator actor connected to updating the app and the prediction model.
Figure 3. Use Case Diagram of the primary desired interactions, that users shall experience with the app.

Interface Concepts

Two states carry the whole premise. In the default state the application reports without demanding anything: traffic density, speed and the driver’s reaction time over the past hour are rendered as unobtrusive gauges beneath the annotated camera feed. In the warning state every secondary detail is deliberately drowned out, and a single instruction is left standing. A warning colour and an audible signal arrive together.

Phone mockup showing an annotated dashcam view above gauges for traffic density, speed and reaction time, with a smiling face and the message that the driving style is great.
Figure 4. Vertical Default-View of the app, while monitoring the traffic data, camera-feed and the gyroscope.
The same phone mockup in its warning state, the entire screen washed in red with the word Warning displayed across it and the underlying gauges blurred out.
Figure 5. Vertical view of the warning state within the app. More detailed informations are blurred out and the attention of the driver is raised by the usage of warning colors. In conjunction with this visual signal, a warning signal shall occur.

Situations and Scenarios

Each hazardous situation is modelled twice over. A situation model states which entities hold which data and which operations they expose, and a sequence diagram states the order in which those entities speak. The pairing is what keeps a requirement testable: the first says what must exist, the second says what must happen.

The opening scenario is an unidentified incident ahead. The application monitors the environment, raises the warning, starts sound and vibration, and then keeps watching the driver so that both signals stop the moment the situation has been acknowledged. The feedback loop matters as much as the alert.

Sequence diagram between user, smartphone and app, showing the app monitoring the environment, issuing an accident warning, starting sound and vibration, monitoring the user reaction and then stopping both signals.
Figure 11. Sequence Diagram of the first scenario: “Incident ahead”.

The second scenario swaps perception for subscription. Congestion ahead does not need a camera, only a position and an external traffic data provider, which changes both the entity model and the urgency of the response: sound without vibration, a notice rather than an alarm.

Class diagram relating the app, which holds the video feed, gyroscope data and GPS signal, to the smartphone environment entity, a traffic data provider supplying congestion coordinates, and the user actor holding a GDPR permission flag.
Figure 12. Model of the information system for the second identified situation: “Traffic congestion ahead”.
Sequence diagram between user, smartphone, app and traffic data provider, showing the app polling for traffic jams, issuing a congestion warning with sound only, and monitoring the user reaction before and after the warning.
Figure 13. Sequence Diagram of the second scenario: “Traffic congestion ahead”.

Abstract

This requirements document specifies a new traffic accident warning app designed to handle accident warnings during edge case traffic events. The IEEE recommended practice for software requirements specifications (IEEE 830) is used throughout. The scope, vision and subsidiary goals are deduced accordingly. Furthermore, the standpoint of a potential contracting authority is used to define an overall project description. The goals then are further examined and yield 40 different requirements, which are proposed, grouped, rated and prioritized. The key is to deliver requirements as a foundation of a mobile application, that can identify hazardous situations in traffic and warn the driver beyond what an automated in-car sensor-based system would provide. This serves to further the interactive mobility and proactively increase the safety of driver and passengers.

Cite this work

@techreport{filusch2020accidentwarnings,
  author      = {Filusch, Michael and Golombeck, Marius and Orlowski, Henning
                 and Müller, Lisa},
  title       = {{Accident Warnings During Edge Case Traffic Events:
                 Requirements Specification}},
  institution = {University of Applied Sciences and Arts Dortmund},
  address     = {Dortmund, Germany},
  year        = {2020},
  month       = feb,
  language    = {english},
  doi         = {10.13140/RG.2.2.14784.89609},
  url         = {https://www.researchgate.net/publication/339596534}
}