© 2004, IAS 04/21/23 1

Automated Specification of Automotive Automated Specification of Automotive Software Functions based on Expert InterviewsSoftware Functions based on Expert Interviews

By

Md. Shariful Islam

Supervisor: Prof. P. Göhner Advisors: J. Konnertz Dr. H. Omasreiter (DaimlerChrysler)

Master ThesisMaster Thesis

Universität StuttgartInstitut of Industrial Automation and Software Engineering

Prof. Dr.-Ing. Dr. h.c. P. Göhner

© 2004, IAS 2

Wants to create

specification

Influence the

process

Influence the

process $ 1

$ 5

$ 20

$ 50

$ 100

Requirements

Design

Coding

Testing

Maintenance

Boehm, B., Software Engineering Economics, Prentice-Hall, 1981

Errors which originate in requirements tend to be the most expensive and troublesome to eliminate later

The more you late, the more you pay

Complete and concise

specification should be elicited

Error free and correct

specification should be elicited

Motivation

Classical unsystematically process, Undefined

brainstorming, Personality effect, Time

consuming, Does not achieve the goal

© 2004, IAS 3

Outline of Presentation

Motivation

Behind the Concept - Basic

Developed Concept - Automated Specification

Prototype Design

Conclusion & Future Work

© 2004, IAS 4

Predetermined systematically expert interview process

Based on a sequence of intelligent questions and answers

Generates the use cases automatically

Basic

What is a Use Case (UC)?

Sequences of interactions between the system under discussion and its users, relating to a particular goal

Can be represented by text or by diagram

Serve as a means of communication from one person to another, often among people with no special training

Simple text embedded in a table is usually the best choice

Unstructured paragraphs of text are inherently

ambiguous and difficult to understand

Task

© 2004, IAS 5

Use Case Template

UC-ID

UC-Name

Short Description

Preconditions

Primary Path

Alternative Paths

Postconditions

sequence number (1 or 2 or 3...)

is described user/actor intentions i.e. goal <actor + goal>

the least summary of the scenario

conditions to invoke the UC, Critical situations as preconditions

states main success scenario in steps <Step # + Actor /System + Action (Active Verb) + Object>

<Step # + alphabetic seq. (if refer from pp) + Actor /System + Action + Object >

describe the state after successful completion of the single use case

A style guide to promote

consistency among

multiple people and

multiple UCs

Structured with

necessary information to

describe UC

Basic

© 2004, IAS 6

Outline of Presentation

Motivation

Behind the Concept - Basic

Developed Concept - Automated Specification

Prototype Design

Conclusion & Future Work

© 2004, IAS 7

Developed Concept

AS2F-EIAS2F-EI

Static Process (SP)

Dynamic Process (DP)

Plan for the Process Interview Process Post Process Work

Find the expert

Intention & Time

Appointment

Materials (e.g. PC, Tool)

Information given to

expert

Questions bank

Review Process

Automated Specification of Automotive Software Functions based on Expert Interviews

© 2004, IAS 8

Goal Driven Approach Context Driven Approach

Static Process (SP)

Static Process

What Search for different user goals plays a pivotal role

What Describe the behavior of contextual sub-functions

Support driver to control the doors

Check the doors

Open the doors

Close the doors

. . .

Car changing the lane

On coming vehicle in the same lane

Foggy weather

. . .

Maintain defined distance

Bus Doors Control Distronic Function

© 2004, IAS 9

yes

no

Completely filled?

UC speci-fication?

Fill the template

Questions sequence

What is the overall or top goal of the system?

Control the bus doors

Expert’s answers

Who achieves this goal?

The driver

Can you please give an overview of this use case?

What are the conditions to be true prior to drive this UC scenario?

The driver controls the bus doors

UC-Name:

Short Description

Preconditions

The driver controls and manages the the bus doors

The driver sits in the bus

Goal Driven Approach

Static Process - Goal Driven

. . . .....

© 2004, IAS 10

Context Driven Approach

yes

no

Completely filled?

UC speci-fication?

Expert’s answers Fill the

template

Questions sequence Use Case

Context Matrix

Use case context matrix to discover the critical situations systematically

Uses input and context variables and valuations of those

Use Case Context Matrix (UCCM)

Static Process - Context Driven

Distronic Function

Input: Control lever (Activated or Deactivated), Brake (Pressed or Not pressed)

Context: Traffic situation (Vehicle changing the lane), Weather (Dry or Foggy)

Critical Situation: The other vehicle changing the lane

© 2004, IAS 11

Variables Valuations Critical Situations (CS)

    CS1 CS2 CS3 ...

Input          

 

       

        

       

 

       

   

       

       

Context          

     

     

       

 

   

     

       

Control

lever

Brake

Acceleratorpedal

Traffic condition

Weather

Activated

Deactivated

Foggy

Pressed

Not pressed

Oncoming vehicle in the same lane

Vehicle changing the lane

Dry

x

x

x

x

x

x

x

x

x

x

x

x

x

What could be the possible inputs of

the system from user point of view?

What could be the context

variables of the system?

Creation of UCCM -- Interview

What could be the relevant values

of those inputs?

What could be the relevant values

of those?

The driver wants to maintain

defined distance in case of other

vehicle changing the lane

Static Process – Context Driven

Pressed

Not pressed

What could be the critical

situations that we could specify

the behavior of the system?

Distronic Function

© 2004, IAS 12

Static Process - Result

3 interviews for each approach of static process

Conduct both approaches to create a complete & concise user specification

Approach

Result-Criteria

Goal Driven Approach Context Driven Approach

Kinds of system

General functionality

Context-dependent functionality

Critical situations

Can easily be divided in

to sub-functions (+)

Highly context-dependent

(+)

Elicits (+)

Elicits (+)Misses (-)

Misses (-) Systematically figure

those out (+)

Misses (-)

© 2004, IAS 13

Paradigm of Dynamic Process (DP)

Dynamic Process

SW function domain

SW function domain

Selected SW function

Selected SW function

Retrieve UC from existing function

Retrieve UC from existing function Present the

UC to expert

Present the UC to expert

Questions

sequence

UC specification

UC specification

Questions

sequence

Explicit

Classification of

SW Function

Same functionality of software (SW) functions, developing day by day

Improvement of the quality and reliability as well as saving time and money

Main Aspect: Reuse of Requirements

Existing UCs

Why Reuse?

Collection of automotive vehicle systems

© 2004, IAS 14

Dynamic Process - Classification

Explicit Classification

Automotive vehicle

SW domain

Type of communication

Inside Outside

Assistance

systemsTelematic

systems

Cruise Control System

Distronic System

Electronic Stability Program, etc

Does driver act?yes

noOther functions

How would you classify the system? Is it communicating with inside car system or outside car system?

Does the system interfere with driver‘s action?

Who is the main user and what is the goal achieved by the main user?

The driver wants to maintain the

defined distance.

© 2004, IAS 15

UC

UC

Modifications

UC

UC

Retrieve UC

UC

UC

New UC

Reuse Technique

Which part of this UC can be used to

your system?

Which part of your system can be

added with this UC?

Are there other functionalities that

you can describe it with a new UC?

Dynamic Process - Reuse

Common

Variable

AddingUC

UC U

C

UC

Complete Specification

© 2004, IAS 16

Dynamic Process - Result

+ Less time

+ Increases correctness

+ Efficient

- Possibility to mislead

2 Interviews for dynamic approach

Selected function was speedtronic

More correct and error free user requirements specification

© 2004, IAS 17

Motivation

Behind the Concept - Basic

Developed Concept - Automated Specification

Prototype Design

Conclusion & Future Work

Outline of Presentation

© 2004, IAS 18

AS2F-EI GUI Prototype

A GUI- prototype has been designed for the interview process

Name: AS2F-EI RS Tool, RS stand for Requirements Specification

© 2004, IAS 19

Outline of Presentation

Motivation

Behind the Concept - Basic

Developed Concept - Automated Specification

Prototype Design

Conclusion & Future Work

© 2004, IAS 20

Conclusion & Future Work

Static process does work well for creating specification from scratch

Takes less time and creates more quality specification than workshop

Dynamic process does work well on reuse concern

It costs less time (approx 50%) than static process and an efficient process

Interviewing tool to facilitate the gathering of user requirements

Conclusion

Future Work

In dynamic process classification can be done for all kinds of system

More advanced tool can be developed (e.g. web based tool)

© 2004, IAS 21

Questions/Discussion