The Requirements Process for Software Systems

1
The Requirements Process for Software Systems

• Requirements Elicitation
• and
• Requirements Generation

2
Putting It Together

• Principles
• Rigor and Formality
• Separation of Concerns
• Modularity
• Abstraction
• Anticipation of Change
• Generality
• Incrementality
• Notion of Process

3
Standard Software Creation Process
Requirements Documents
Gather Requirements
Domain language
Design Documents
Generate Design
Models, technical language
Implementation
Test
Write Code
4
What Really Happens
Requirements Documents
Gather Requirements
Test
Generate Design
Prototypes
Design Documents
Implementation
Write Code
5
Gathering Requirements

• Clearly, it drives the whole process
• Either implicitly or explicitly, need some
  statement of problem
• this implies knowledge of domain
• AND knowledge of problem in domain
• Explicit or Implicit?
• So, early or late?

6
Cost to Repair by Phase
7
What is a Requirements Spec?

• Statement of problem in the language of the
  problem domain
• Includes
• external behavior of final system
• constraints on system
• constraints of domain

8
Simple Looking Problems Sometimes Arent

• Calendar system-
• Years, months, weeks, days

Is this right?
Solar Calendar
Years
Mon Tue Wed..
Months
1996 1997 1998 1999 2000
Weeks
Jan Feb Mar...
Days
9
Calendar Taxonomy
7-Day Calendar
Solar Calendar
Weeks dont fit in months or years. Really two
calendars.
Years
Containment solves boundary problem.
Weeks
Months
Days
10
Real-World Simple Problems

• Mutual Exclusion
• Limit access to resource to one simultaneous
  process at a time
• Solutions appear simple, but have deceptive
  loopholes
• See An Investigation of the Therac-25 Accidents
  Leveson and Turner to see what can happen.

11
Client View of Domain

• Clients cant be expected to have rigorous or
  formal view of domain
• Hence, cant be expected to completely be aware
  of domain-problem relationship
• Some knowledge is explicit
• Easier to get at
• Some knowledge is implicit
• Many constraints are implicit
• Hard to get at

12
Requirements Elicitation Process
Client
Us
System
SRS
Client Domain
Problem
13
Communication
This process
Client
Us
Requires a common language and common
vocabulary. It is up to us to make sure this
happens.
14
Communication Problems
Common Vocabulary and Dictionary is
Required but, not enough

• Ambiguity Sources
• Lack of implicit knowledge of domain
• Mismatch on meaning of terms (your vocabulary Vs.
  clients)

15
Escalator System Requirements
Two Signs on Escalator
Shoes Must Be Worn
Dogs Must Be Carried
Conclusions
You must have on shoes, and you must be carrying
a dog.
If you have a dog, you have to carry it, so you
have to wear all the shoes you carry.
If you dont have a dog, you dont need to carry
it, so you dont have to wear shoes unless you
are carrying some.
16
Start of Elicitation Process

• Definition of domain terms
• Identification of domain objects
• Not necessarily object-oriented programming
  objects
• Identification of domain functions
• Relationship between functions and objects

17
Two Kinds of Elicitation

• Client PUSH
• Teach the client the common language and terms
• Help her self-model the domain and problem
• Client PULL
• Extract the language and terms on the fly

18
Client Push

• Teach client to model domain
• Help them model domain and problem (still in
  domain terms)
• Communication is in model terms
• Or teach special ways of understanding domain
  e.g.. Senge .
• Really, this is teaching a thinking approach

19
Client Push Process
1
Modeling Process
Client
Us
Domain knowledge
2
3
4
3
SRS
Domain Model
Client Domain
Problem
20
Modeling Techniques

• Just for Real-time
• Finite State Machines
• Decision Tables
• Program Language Design
• StateCharts
• Petri Nets
• Specification and Description Language
• And so on.

21
Client Pull

• Use Client as information window to domain
• Exploratory exchange
• Interviews
• Prototypes
• Observation
• Skillfully fill unknown parts of domain and
  problem
• Requires Us to build domain model ourselves

22
Client Pull Process
1
Questions Observation
Client
Us
Domain knowledge
2
4
3
SRS
Domain/Problem Model
Client Domain
4
Problem
23
Reality

• Both Push and Pull
• Usually, more Pull than Push
• Unless customer is very technical, rigorous
  and/or formally oriented
• So, we need skills to build models ourselves
• Danger Do not prejudge the problem or domain too
  quickly!!

24
Perspective
A
B
C
B
C
A
Connect like letters without crossing lines or
leaving box.
25
Early Focus on Constraints

• A-A line seems to be constraint
• But, is it really?
• Need to examine domain and constraints more?
• What transforms or shifts would yield easier
  problem?

26
Change Perspective a Little
and transform A-A constraint
A
C
C
B
B
A
27
Change Perspective a Little
and transform A-A constraint
A
C
C
B
B
A
28
Just to Prove it.
A
B
C
B
C
A
29
Building Requirements Model(or Theory)

• Why?
• All other phases of process have step above to
  compare consistency -- Requirements phase does
  not.
• What?
• Formal definition of behavior expected from
  system.
• How?
• Attempt Challenges or putative theorems against
  model to see if behavior is reasonable

30
Describe Environment

• Describe only environment - not system
• Why? Avoid implementation bias
• Describe Environment as-is. These constraints
  are called indicative
• Often called assumptions or constraints.
• Describe Environment as modified by the
  system. These are called optative
• Often called system requirements

31
Goals and Sub-GoalsSetting the Boundary
Invest?
Improve Payables
Different Business?
Maximize Cashflow
Recreation? Religion? Drugs?
Increase Profits
Happy Owner
32
Definitions

• All terms need precise definition
• Distinguish between Definition and Assertion

designation of student must already exist
Asserts being a student is the same as being
enrolled
Defines what a student is, but assumes enrolled
33
Actions

• Shared Both environment and system can observe
• Unshared Only environment can observe
• System controlled
• Environment controlled

There is no system controlled, unshared action
34
Cant Implement Around Unshared
full switch
Fuel line
Flow counter
flow
Fuel tank
unusable fuel
Determine when flow will stop (empty)
and signal with indicator. Unshared without
flow counter output.
35
Attempting Challenges
Book bk (name, phone number pairs)
(bill, 555-1212) (judy, 555-1234) (,
EMPTY)
Special empty designator
Operations to manipulate the book
Phone Book
AddPhone(bk, nm, pn)
(name,)
FindPhone(bk, nm, pn)

DelPhone(bk, nm)
(,EMPTY)
36
First Challenge
FindPhone(AddPhone(bk,Nm,),Nm)
Phone Book
Phone Book (Nm,)
AddPhone (Nm, )
FindPhone Nm

Should be the same
37
Second Challenge
DelPhone(AddPhone(bk, Nm, ), Nm) bk
Phone Book
Phone Book (Nm,)
Phone Book
AddPhone (Nm, )
DelPhone
Should be the same
But, is it?
38
Why This is Wrong
Suppose
(Tom, 555-1234)
Phone Book
Phone Book (nm,pn)
Phone Book
AddPhone (nm,pn)
DelPhone
(Tom,998-7878)
Tom is now missing The books are different
Needed
39
Using Automata for Constraints
Safety Nothing bad will happen
B
As are separated by Bs
A
Liveness Something good will happen
After A, there must eventually be a B
A
B
40
So, How Do We Actually Use This Stuff?
41
How to Gather Requirements

• Map out environment as-is
• Map out environment as required
• Decide on systems boundaries / goals
• List actions with types
• Define terms
• Construct model
• Challenge model
• Modify as required

42
Power Window Motor Controller

• Cust We need the window to go up and down in
  response to a 3-way switch
• RE So, were controlling a motor with a
  momentary contact switch?
• Cust But window stops at top and bottom.
• RE How do we know top and bottom?
• Cust Stall current, of course.
• Cust Also, releasing switch stops window.
• RE Switch is then in center?
• Cust Yes.

43
Definitions and Assertions
(EOT End Of Travel)
Assertions
44
Known Properties
A Safety Property
Optative property
Top
Down, Up
A Liveness Property
Down
Bottom
Up
Up, Down
Moving
Indicative properties
Center
Is this correct?
45
Better Liveness Spec
A Liveness Property
Up, Down
Moving
Center, EOT
What About End of Travel?
EOT constrained by indicative property
(assumption) that window reaches end of travel
46
Indicative Switch Properties
Down
Up
Center
Center
There is always an up or down between
centers and this is constrained by the
environment.
47
Window Subsystem Model
Motor Down
EOT
Down
At-Top Stop
EOT
At-Bot Stop
Motor Up
Up
Notice No up from here.
Center
Down
Up
Motor Stop
Center
48
Initial Challenges

• Sequence Down, Center, Down, Center, Up
• Seems OK
• Sequence Down, EOT
• Seems OK
• When at top, Up does nothing
• Down for 4 sec, center, window stops
• Seems OK
• When at bottom, Down does nothing

Cust Whoops! This isnt what I want!
49
Extended Requirements

• Cust I want express down.
• RE Define express down
• Cust User holds down gt 3 seconds
• RE Down only?
• Cust Yes.
• RE So, downgt3 sec center means window to
  bottom.
• Cust Yes.

50
Control With Express
Motor Down
EOT
Down
At-Top Stop
Motor Up
3 Sec
EOT
Motor Down Xpress
Center
EOT
Down
Up
At-Bot Stop
Motor Stop
Up
Center
51
More Challenges

• User should be able to stop express down. Can
  she?
• Sequence ltat-topgt, down, gt 3sec ends only with
  motor stop.
• Wrong!
• RE How does express down stop?
• Cust with up!
• So, need an up transition to stop motor.

52
Completed Window Subsystem
Motor Down
EOT
Down
At-Top Stop
3 Sec
Motor Up
EOT
Motor Down Xpress
Center
EOT
Down
Up
Up
At-Bot Stop
Motor Stop
Up
Center
53
Augment to Models

• Often, some kind of prototype is useful to verify
  requirements
• Can also be challenged (but more expensive than a
  model)
• Better Observe users use of prototype
• What they do is not what they say they do
• Sometimes they dont KNOW what they do

54
Comment On Prototypes
Expendable and Easy
Quick and Dirty
Dont try to put prototype into production!
Because
Aircraft simulators with wings
Wont Fly