© 2004, ias1/6/20161 automated specification of automotive software functions based on expert...
TRANSCRIPT
© 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