Requirements Engineering for Google’s Self Driving Car

Progress in self driving car technology has been made for years by increasing the automation of cars; this includes cruise control, lane keeping, and parking assist. Self-driving cars are being increasingly advocated as a means for making commutes more productive and the roads safer. However, they are complex socio-technical systems that involve different subsystems for managing the various functions of the car.

For the following coursework I was required to determine the requirements for Google’s self driving cars, including non-functional requirements such as safety, usability and security. I used two requirements engineering methods to model a use case specification of how a passenger might use a self driving car. These identify several human and technical actors in the socio-technical system including the passenger, the self-drive system and the navigation system.

This I*Strategic Dependency Model, depicting the dependencies between actors for a self-driving car system, has been designed around a taxi model. This is based on the assumption that in order for a passenger’s journey to be completed safely and within an acceptable time, as specified in the design brief, the passenger must know they are in the correct and nearest self-drive car.  In the case of a taxi system a mutual identification system is required. The car is assumed not to be unique so the user will need an identification to distinguish his/her unique car. This identification is assumed to be on an external area of the car. It has been assumed that the passenger has downloaded and registered with the self-drive app, and therefore the app knows of the user’s identity. An Estimated Time of Arrival (ETA) has also been included which the passenger must observe and respond to (by either confirming or cancelling their journey as necessary; although in order to contain the scope of the project the cancel option has not been included in the diagram). For the sake of clarity, in this I* Strategic Dependency model ‘Passenger’s location’ refers to where the passenger is waiting for the self-drive car, ‘destination’ refers to where the passenger would like to go.

I* Strategic Dependency model

I* strategic dependency (SD) models model requirement related dependencies between actors (shown in yellow) in the future system. They distinguish between hard goals (light orange) which equate to functional requirements that are met or not met, and soft goals (dark orange) which equate to non-functional requirements that different solutions (tasks etc) can more or less contribute to. Task and resource dependencies (green and blue respectively) model what the actor must be able to carry out with an available entity.

It has been assumed that the on-board system is the central brain of the car and communicates with each respective component as well as the self-drive app. The on-board system and the self-drive app have a two way level of communication. This is so the user can be informed (via the self-drive app) of the car’s estimated time of arrival (ETA), they can confirm or cancel the pick-up request as, and the user can be notified when the car has arrived to pick them up. In a broader I* SD model the car’s ETA to end destination would also be included.  It has been assumed that the user knows the correct location.

It has also been assumed that the on-board system must receive certain information in order to proceed with the journey and therefore meet the non-functional requirements of safety, security, reliability and quick service delivery. This includes confirmation of the passenger’s wish to travel after the received ETA, the passenger’s identity, the passenger’s location and confirmation of the passenger fastening their seatbelt.  It has been assumed that when the journey request comes from the self-drive app, the on-board system also knows to send the ‘arrived at destination’ notification back to the app. However, when the journey request is inputted straight into the on-board screen, the ‘arrived at destination’ notification is emitted from the on-board system in the car. It has been assumed that the self-drive system can detect an available parking space in the vicinity of the destination.

Strategic Rationale model

Strategic Rationale (SR) models model rationale decompositions and contribution links between important goals of different system actors. SR models specify which actors (goals, tasks, resources and soft goals) accomplish themselves. A process element is only included if it’s considered important enough to affect the achievement of some goal. An SR model includes the SD model hence actors may be able to achieve some things by themselves or by depending on other actors.

After modelling the dependencies in I* SD and SR models  I was able to formalise the requirements in VOLERE shell format. This included unique identifiers, requirement types, descriptions and fit criterions.

non function req

func req

Leave a Reply

Your email address will not be published. Required fields are marked *