Personal Software Process
Lecture 2
Requirements Engineering
Liubo Ouyang
ouyangliubo@126.com
http://ss.hnu.cn/oylb/psp/
Copyright, 2006 © L. Ouyang
Introduction
Software engineering vs.
system engineering
System engineering:
• information engineering
(a business enterprise)
• product engineering (a
production process)
L.Ouyang, PSP, Lecture 2
Computer-based systems
•
•
•
•
•
•
L.Ouyang, PSP, Lecture 2
Software
Hardware
People
Database
Documentation
Procedures
Restraining factors
•
•
•
•
•
L.Ouyang, PSP, Lecture 2
Assumptions
Simplifications
Limitations
Constraints
Preferences
A good SRS
•
•
•
•
•
•
•
Unambiguous (one interpretation)
Verifiable (one can check that req. are met)
Complete (responses to invalid input)
Consistent (no conflicts between req.)
Modifiable (changes are not a big problem)
Traceable (origin of each req. is clear)
Usable during the Operation and
Maintenance Phase
L.Ouyang, PSP, Lecture 2
Source Documents for Requirements
.doc
Manual
SRS
Ver. n
L.Ouyang, PSP, Lecture 2
SRS
Ver. n+1
Source Documents for Requirements
List of SD4Rs
# Type Title From Since Place Comments
1 Email SRS Nowak 9.11.99 SDS/
2
SD4R: Source document for requirements
Types of SD4R:
Email
Video
File
Audio
Hard(copy)
...
L.Ouyang, PSP, Lecture 2
Ambiguous
Advice:
Try to keep all the
SD4Rs as text files
Requirements document (1)
1. Introduction
1.1 Purpose of the document
1.2 Scope of the product
1.3 Definitions, acronyms and
abbreviations
1.4 References
1.5 Overview of the document
L.Ouyang, PSP, Lecture 2
Requirements document (2)
2. General description
2.1 Product perspective
2.2 Viewpoints
2.2.1 Stakeholders
2.2.2 Users
2.2.3 Domain
2.2.4 Components
2.3 System architecture and use cases in UML
2.4 General constraints
2.5 Assumptions and dependencies
L.Ouyang, PSP, Lecture 2
Requirements document (3)
3. Technical requirements
3.1 Functional requirements
3.1.1 Requirement 1
3.1.1.1 Introduction
Viewpoint and source(s)
Firmness and importance
Verifiability and clarity
3.1.1.2 Inputs
3.1.1.3 Processing
3.1.1.4 Outputs
L.Ouyang, PSP, Lecture 2
Requirements document (4)
3.1.2 Requirement 2
..
3.2 External interface requirements
3.2.1 User interfaces
3.2.2 Hardware interfaces
3.2.3 Software interfaces
3.2.4 Communication interfaces
3.3 Performance requirements
L.Ouyang, PSP, Lecture 2
Requirements document (5)
3.4 Design constraints
3.4.1 Standards compliance
3.4.2 Hardware limitations
...
3.5 Attributes
3.5.1 Security
3.5.2 Maintainability
...
L.Ouyang, PSP, Lecture 2
Requirements document (6)
3.6 Other requirements
3.6.1 Database
3.6.2 Operations
3.6.3 Site adaptation
3.6.4 Training
...
3.7 Non-technical requirements
Appendixes
Index
L.Ouyang, PSP, Lecture 2
FAST
FAST = Facilitated
Application
Specification
Technique
JAD (Joint Application
Development) is
another approach to
FAST
L.Ouyang, PSP, Lecture 2
FAST for SDS
Persons involved
Facilitator (student of class1) - runs the
meeting(s)
Recorder (student of class2) - takes
notes, serves tape recorder or video
recorder
Developers (student of class3) and
customer representatives (1 for each
view) - work on requirements
Supervisor - know about the meeting
date & time
L.Ouyang, PSP, Lecture 2
FAST for SDS
Input documents (1)
Product request ( Project Proposal, in
the customer’s language, HTML 3.0)
Information about FAST place
(Laboratory Centre?, 9:00 - 15:00) and
time (2 - 4 hours by 20.3.2007) should be agreed by 15.3.007
(customer, student of class1, and the
Laboratory centre director)
L.Ouyang, PSP, Lecture 2
FAST for SDS
The list of stakeholders and views
should be ready before the project
leaders start to organise the FAST
meeting.
Get from the customer the initial list of
requirements sources (manuals,
organisation charts, technical data, ..)
and read it before the FAST meeting.
If not feasible, the meeting can be
conducted via phone or e-mail.
L.Ouyang, PSP, Lecture 2
FAST for SDS
Input documents (2)
Worksheet to fill in:
Missing stakeholders
Missing requirements sources
Objects (devices, documents, etc.):
• external to the system
• produced by the system
• internal - used by the system
Services that manipulate the objects
Constraints (cost, size, time, accuracy, ..)
L.Ouyang, PSP, Lecture 2
FAST for SDS
A FAST meeting
Product justification (every one should
agree) ~ n x 1’
Presentation of the worksheets (one by
one, no critique) ~ n x 15’
Deciding (discussion) about:
• Stakeholders ~ n x 1’
• System architecture (objects) ~ n x 5’
• Services ~ n x 10’
• Constraints ~ n x 5’
• Lecture 2
Validation criteria ~ n x 5’
L.Ouyang, PSP,
FAST for SDS
Meeting outcomes
Direct:
• Meeting minutes
Indirect:
• Software Requirements Specification
(validation criteria!)
L.Ouyang, PSP, Lecture 2
Davis’ Principles for RE
• Understand the problem before you begin to
create the analysis model
• Develop prototypes showing how the humanmachine interaction will occur
• Record the origin of and the reason for every
requirement
• Use multiple views of requirements (data,
functional, and behavioural)
• Prioritise requirements
• Work to eliminate ambiguity
L.Ouyang, PSP, Lecture 2
Viewpoints negotiation
A viewpoint represents partial information
L.Ouyang, PSP, Lecture 2
An example of viewpoints
Viewpoint = perspective on a system
An example: traffic lights
Prospective stakeholders
(viewpoints):
• drivers
• cyclists
• pedestrians
• emergency services
• the highway authority
L.Ouyang, PSP, Lecture 2
Viewpoints in RE
Viewpoints: early stages of
requirements elicitation
Viewpoint-oriented methods:
• CORE (G. Mullery, 1979)
• SADT
• PREview (I. Sommerville, P.
Sawyer, 1997)
L.Ouyang, PSP, Lecture 2
Typical viewpoints
The system’s stakeholders (a human,
role, or organisation)
The system’s operating environment
(other system/component)
The system’s domain (phenomena
inherent in the application domain;
constraints on the system)
L.Ouyang, PSP, Lecture 2
Basic RE activities
<= 50 zł
Requirements elicitation
L.Ouyang, PSP, Lecture 2
Basic RE activities
for 50 zł ?
Requirements analysis
L.Ouyang, PSP, Lecture 2
Basic RE activities
There is a conflict between
your requirements ..
Requirements negotiation
L.Ouyang, PSP, Lecture 2
The PREview process
Requirements elicitation
Requirements analysis
Requirements negotiation
Requirements
definition
L.Ouyang, PSP, Lecture 2
Local vs. global requirements
Types of requirements
Local requirements
Global requirements
(specific to a particular
(likely to be most
viewpoint)
expensive to change)
Global requirements = external requirements
L.Ouyang, PSP, Lecture 2
Concerns
A concern = a top-level, overriding goal
Concerns:
• crucial to the success
• non-negotiable
• vaguely defined
• concepts rather than
concrete properties
• serve as constraints
• converted into external
requirements
L.Ouyang, PSP, Lecture 2
TCS: Train Control System
A human driver
Aim: to monitor & to
intervene when safety is
in danger
If a train goes too fast or
crosses a stopping
point, TCS will apply the
emergency breaks
Hardware System
Interface (HSI)
L.Ouyang, PSP, Lecture 2
TCS: Train Control System
TCS’ concerns:
• Safety (contribution to train
safety)
• Compatibility with the HSI
interface
Concern question for
compatibility: Is the
requirement consistent with
the interface provided by the
HSI module ?
L.Ouyang, PSP, Lecture 2
TCS: Train Control System
A request: calculate a minimum
breaking distance
Required parameters:
• speed,
• mass,
• line gradient,
• track surface conditions
Question: are those values
available through the HSI
interface ?
L.Ouyang, PSP, Lecture 2
Compatibility requirements
External requirements for the ‘compatibility’
concern:
ER4: The TCS software shall be executed in
the Ada environment
ER5: The TCS software shall execute within
the application cycle of the existing on-board
software
ER6: The TCS software shall react to the
change of state within 280 ms
ER7: The real-time performance of the existing
on-board software shall be maintained
L.Ouyang, PSP, Lecture 2
The safety concern
Hazards identification:
hazard analysis techniques
(fault-tree analysis, causeconsequence analysis, ..)
TCS’ hazards:
• excess speed,
• overshooting a stopping
point
L.Ouyang, PSP, Lecture 2
Safety requirements
ER1: The system shall detect the
occurrence of excess speed
ER2: The system shall detect the
occurrence of overshoot
ER3: The system shall apply emergency
breaking when either excess speed or
overshoot are detected
L.Ouyang, PSP, Lecture 2
Viewpoint identification
Model of organisational
Model of operational
environment
environment
Domain
expertise
Stakeholder
Component
User
Domain
viewpoints
viewpoints
viewpoints
viewpoints
L.Ouyang, PSP, Lecture 2
TCS viewpoints
Stakeholders:
• driver
• maintenance technician
• regulator (indirect)
• normal operation (indirect)
• safe state assurance (indirect)
• erroneous state recovery (ind)
Domain: braking characteristics
Operating environment: HSI
L.Ouyang, PSP, Lecture 2
Viewpoint structure
• Name
• Focus
• Concerns applicable to
the viewpoint
• Viewpoint sources
• Requirements
• History
L.Ouyang, PSP, Lecture 2
Safe state assurance viewpoint
Name: Safe state assurance
Focus: Detection of dangerous conditions
and application of emergency braking
Concerns: safety, compatibility
Source: customer procurement executive;
TCS preliminary hazard analysis
Requirements:
SS1: detection of excess speed
SS2: detection of overshooting
SS3: frequency of invocation
L.Ouyang, PSP, Lecture 2
Requirements discovery
Identifier: SS1 - detection of
excess speed
Description: If the speed of the
train is excessive, emergency
breaking shall be applied
Rationale: The train must be
forced to comply with the
speed limits in force on the
track
Change history: L.Ouyang, PSP, Lecture 2
Requirements elicitation
Concern identification
Concern elaboration
Viewpoint identification
Requirements discovery
L.Ouyang, PSP, Lecture 2
Compatibility
Safety
Requirements analysis
Safe state assurance
Do not effect
SS1 SS2 SS3
each other
ER1: 1
0
0
ER2: 0
1
0
ER3: 1
1
0
Mutually reinforcing
ER4: 0
0
0
ER5: 0
0 1000
ER6: 0
0 1000
Conflict
ER7: 0
0 1000
L.Ouyang, PSP, Lecture 2
Requirements definition activities
1. Identify the structure of the requirements
document. Divide it into sections.
2. Identify quality standards and prepare a checklist.
3. Allocate each external requirement into one of the
sections.
4. Repeat activity 3 for each viewpoint requirement.
5. Apply the checklist from activity 2 to each
requirement.
6. Review each section and eliminate redundancy.
L.Ouyang, PSP, Lecture 2
Further readings
IEEE Guide to Software
Requirements
specification, ANSI/IEEE
Standard 830-1984
I. Sommerville, P. Sawyer,
Requirements
Engineering, John Wiley &
Sons, Chichester, 1997
L.Ouyang, PSP, Lecture 2
Summary
At last!
• Requirements document
• The FAST method
• The PREview process:
elicitation, analysis,
negotiation
L.Ouyang, PSP, Lecture 2
Quality assessment
• What is your general
impression ? (1 - 6)
• Was it too slow or too fast ?
• Did you learn something
important to you ?
• What to improve and how ?
L.Ouyang, PSP, Lecture 2