SE 325/425
Principles and
Practices of Software
Engineering
Autumn 2006
James Nowotarski
3 October 2006
Today’s Agenda
Topic
Duration

Finish risk management
30 minutes

Requirements process
45 minutes
*** Break

Current event reports
30 minutes

Requirements process
60 minutes

Wrap-up
15 minutes
2
Risk management
“The basic problem of software development
is risk”
Beck, K. (2000). Extreme Programming Explained. Boston, MA: Addison-Wesley
3
Categories of software risk
Project
 Technical
 Business
 Legal

4
Risk management
“It is futile to try to eliminate risk”
-- Peter Drucker, management guru
5
Risk management process
Identify
Analyze
$$
Cost of protection
Plan
Control
$$
Cost of exposure
6
Risk management process:
artifacts
Identify
• List of risks
Analyze
• Probability
• Impact
• Cutoff
• Risk exposure
Plan
Control
• Mitigation plan
• Monitoring plan
• Contingency plan
7
Does SE Matter?

“Worrying about what might go wrong may
not be as glamorous a job as speculating
about the future, but it is a more essential
job right now.”
Carr, N. (2003, May). IT doesn’t matter. Harvard Business Review. Retrieved September 8,
2006 from EBSCO Host – Business Source Premier database.
8
Today’s Agenda
Topic
Duration

Finish risk management
30 minutes

Requirements process
45 minutes
*** Break

Current event reports
30 minutes

Requirements process
60 minutes

Wrap-up
15 minutes
9
Quote
“The hardest single part of building software is
deciding what to build” – Fred Brooks
10
Survey Results
[plus Jordan] [plus all DL]

Key issues/trends:
 Outsourcing
 Security
 Web 2.0
 Requirements
 Dispersed teams
 Speed of delivery
 Project mgmt
 Six sigma/Quality
 Agile methods
 Upgrades
 IT working with business units
 Commoditization of IT/SW
 Others
11
7
6
1/5
5
4
3/1
4/1
4
3
2
2
1
11
Areas of most disruptive
change
Software requirements
 Program design
- Winston W. Royce

12
Context
Planning & Managing
Communication
project initiation
requirements
Modeling
analysis
design
Construction
code
test
Deployment
delivery
support
13
Context
Planning & Managing
Communication
project initiation
requirements
elicitation
Modeling
analysis
design
Construction
code
test
Deployment
delivery
support
Requirements
engineering
tasks (Ch. 7-8)
14
Context
Planning & Managing
Communication
project initiation
requirements
elicitation
Modeling
analysis
design
elaboration
specification
Construction
code
test
Deployment
delivery
support
Requirements
engineering
tasks (Ch. 7-8)
Chapter 7
Chapter 8
15
Context
Planning & Managing
Communication
project initiation
requirements
elicitation
Modeling
analysis
design
Construction
code
test
elaboration
specification
analysis model
functional reqts
non-functional reqts software reqts spec
Deployment
delivery
support
Requirements
engineering
tasks (Ch. 7-8)
Primary
deliverables
16
What is a requirement?

A requirement can be defined simply as a
property of a system, or a constraint upon
the product or process by which the system is
to be created

IEEE Std 610.12-1990 defines a requirement
as
A condition or capability needed by a user to
solve a problem or achieve an objective.
A condition or capability that must be met or
possessed by a system or system component
to satisfy a contract, standard, specification, or
other formally imposed documents.
17
Functional vs. Non-Functional
A functional requirement (FR) describes what the
system needs to do.
Example: ‘The system shall display the current
customer balance’.
18
Functional vs. Non-Functional
A non-functional requirement (NFR) describes a
constraint upon the solution space.
Examples: Performance, flexibility, reliability, usability,
portability, maintainability, safety, and security.
Also called “quality” requirements, “ilities”, or even
“systemic” requirements.
Emergent Properties: An NFR that is realized through
the careful implementation of other requirements on
which it depends.
Example: “The query must return its results in less
than three seconds” is only realizable once the
architecture and much of the system functionality has
been implemented.
19
Quote
“It’s not enough to do good. It must be done
well” – St. Vincent de Paul
20
Management involvement and
governance
Senior management needs to be involved in
critical business/IT decisions
Educating management is a technique to help
users who “don’t know what they want”
High degree of involvement helps to improve the
strategic business value of information
technology
Example: What security and privacy risks will we
accept?
Senior management needs to lead the decision
making
21
The Requirements Process
Elicitation: Proactively working with stakeholders to
discover their needs, identify potential conflicts, and
establish a clear scope and boundaries for the project.
Elaboration (Analysis): Gaining a deeper understanding
of the product and its interactions.
Specification: Production of a series of documents that
capture the system and software requirements in order to
support their systematic review, evaluation, and approval.
Validation: Inspecting requirements to ensure their
correctness.
Management: Issues such as software configuration
management, traceability, impact analysis, and version
control.
22
Elicitation
Key Question:
What does the system need to do?
How well does it need to do it?
Steps
1. Review as-is system
2. Identify requirements of
to-be system
Roles
Deliverables
Functional requirements
Quality requirements
Techniques
Re-engineering
AHP
Interviewing
Prototyping
Observation
Surveys/Focus Groups
Joint Application Design (JAD)
Benchmarking
Estimating guidelines
Business analyst
23
Elicitation Techniques
Collaborative sessions are useful for
brainstorming and problem solving activities.
A Joint Application Design (JAD) can bring together
a small group of stakeholders to form initial goals
and requirements.
Helps to avoid ambiguity
Helps to reduce scope creep
24
Joint Application Design
(JAD)
25
Elicitation Techniques
Interviewing techniques are simple yet effective.
Structured around a specific set of questions
Closed ended
Open ended
Can be conducted in stages, so that responses
from the first round can be used to generate a
deeper set of more focused questions for the
second round.
Can be expensive
26
Elicitation Techniques
Observation involves observing the way users
interact with an existing system.
Useful when users are unable to fully articulate their
needs, or are too busy to attend other types of elicitation
meetings.
Observe how tasks are executed, problems, shortcuts,
& areas for improvement.
Sometimes referred to as “going to the gemba”
Especially good for uncovering unstated requirements
“Exciting requirements” – Exceed user’s initial
expectations
27
Elicitation Techniques
Prototyping – taking an early set of requirements and
using them to elicit further requirements.
Low fidelity models useful because for very little cost
you can obtain useful feedback from the user.
Higher fidelity prototypes enable the user to interact with
something closer to the finished product.
28
Elicitation Techniques
Analytic Hierarchy Process (AHP) – a
mathematically-based prioritization technique
Represents the elements of any problem hierarchically
Guides decision makers through a series of pairwise
comparisons
Results in quantitative assessment of relative strength
of requirements
Developed by Dr. Thomas Saaty of the University of
Pittsburgh
29
Elicitation Techniques: AHP
Develop Quality
Software
Performance
Usability
Goal
Flexibility
Quality
reqts
Architecture
Choice 1
Architecture
Choice 2
Alternatives
30
Elicitation Techniques: AHP
Develop Software
Performance
Usability
Goal
Flexibility
.64
.08
Architecture
Choice 1
.59
.28
Architecture
Choice 2
.41
Quality
reqts
Alternatives
31
Activity: AHP
32
Context Models
Determine the boundaries of the system.
What is the system?
What is the system’s environment?
Develop a context model that shows the context of
the system within its environment.
Branch
accounting
System
Branch
counter
System
Security
System
Account
Database
Auto-Teller
System
Usage
Database
Maintenance
System
33
Context Models
Understand the types of interaction the software
system has with its adjacent systems.
Some adjacent systems cooperate with your system
through two-way communication. Consider them
black-box components of your system.
Some adjacent systems
initiate events
and interact with your
system (i.e., people).
Trigger events that must
be specified.
Some adjacent systems
have one way communication
but otherwise work autonomously.
Incoming communication
may trigger an event to
be specified. Also don’t
34
forget TIMED events
Model these interactions as
Use Cases
Identify actors
Model their interactions with the system.
Through elicitation fully explore all the ways each
actor may interact with the system.
Banking Software Product
Withdraw Money
Customer
Teller
35
Requirement Qualities
Each individual requirement should be:

Concise

Correct

Non-ambiguous

Feasible

Verifiable

Traceable

Manageable
36
Concise


A requirement should describe a single property
of the desired system and should include no
information beyond that necessary to describe the
intended property.
It should be stated in clear, simple, and
understandable terms.
Emergency calls from the public shall be answered in the
order in which they are received.


Note the need to define terms such as
“Emergency calls” and “Public” in the
requirements definition document.
37
Correct

A requirement should accurately describe the
intended property of the intended system.

No information missing that is needed to
define or implement the system.

The following requirement is obviously (or at least
probably should be) incorrect:
When an ambulance crew is dispatched to pick-up a
patient more than 2 miles away, they shall wait three
minutes before departing in order to give the dispatch
operator the chance to locate a closer crew.

38
Non-ambiguous

A requirement should be stated clearly and
understandably, in order to avoid ambiguous
interpretations.

The following requirement is OBVIOUSLY ambiguous.
Why?
When a call is received the dispatcher assigns
the job to the best crew.


How could you fix it?
Shoes must
be worn!
Dogs must
be carried!
39
What is wrong with this
requirement?
“The same display shall also be able
to generate a visible or audible
caution/warning sign for the attention
of the ambulance driver or medic.”
40
Conjunctions are dangerous…
Disambiguate what the ‘and’ means…
The battery low warning lamp shall light up when the voltage
drops below 3.6 Volts, and the current workspace or input data
?? Go back
shall be saved.
to the
stakeholder

We can separate the requirement into multiple parts…
The battery low warning lamp shall light up when the voltage
drops below 3.6 Volts.
When the battery low warning lamp lights up the current
workspace shall be saved.
The battery low warning lamp shall remain lit until the voltage
rises above 3.7 Volts.
41
Conjunctions are dangerous…
Problems arise when readers try to puzzle out
which part applies.
The battery low warning lamp shall light up when the
voltage drops below 3.6 Volts, and the current
workspace shall be saved.

Or disambiguate…
The battery low warning lamp shall light up when the
voltage drops below 3.6 Volts, and then the current
workspace shall be saved.
42
Conjunctions are dangerous…
What about this requirement?
An aircraft that is non-friendly and has an unknown mission or
the potential to enter restricted airspace within 5 minutes shall
raise an alert.

Again – disambiguate and/or precedence. Two options:
An aircraft that is non-friendly and (has an unknown mission or
the potential to enter restricted airspace within 5 minutes) shall
raise an alert.
If [an aircraft is non-friendly] and [has an unknown mission or
the potential to enter restricted airspace within 5 minutes], the
system shall <raise> <an alert>.
43
Feasible

A requirement should be feasible from a technical,
financial, and managerial perspective.

The following requirement is INFEASIBLE except
possibly in a James Bond movie!
All patients shall be delivered to a hospital within 5
minutes of their pick-up.

This is just overly optimistic wishful thinking
because we didn’t specify anything about traffic
congestion, location of the patient, distance to the
hospital etc.
44
Verifiable

A requirement should be written in such a way as to
provide a clear and testable acceptance criterion.

For example, it is not sufficient to specify that:
The dispatcher must be able to quickly identify the closest
open emergency room.
Instead, the requirement should be written in a
verifiable form such as:
The dispatcher must be able to identify the closest open
emergency room within 1 second.
45
Traceable

A requirement is traceable if it has been
assigned a unique ID and if it is focused on
one property.

For example a requirement stating that:
A driver and medic shall be assigned to an ambulance
crew and the crew shall be assigned to an ambulance.
creates traceability problems because it
involves tracking the implementation of crew
allocations and ambulance allocations.
46

Never build in let-out or escape clauses
(if, when, but, except, unless, although)
The forward passenger doors shall open automatically when the
aircraft has halted, except when the rear ramp is deployed.
The fire alarm shall always be sounded when smoke is detected,
unless the alarm is being tested or the engineer has suppressed the
alarm.

Don’t ramble
Provided that the designated input signals from the specified devices
are received in the correct order where the system is able to
differentiate the designators, the output signal shall comply with the
required framework of section 3.1.5 to indicate the desired input state.

Refrain from designing the system
The antenna shall be capable of receiving FM signals, using a copper
core with nylon covering and a waterproof hardened rubber shield.

Avoid mixing different kinds of requirements

Do not speculate
Users normally require early indication of intrusion into the
system.

Do not play on ambiguous requirements
Always make requirements as clear as possible

Do not use vague undefinable terms
The print dialog shall be versatile and user-friendly

Do not express possibilities
The reception subsystem probably ought to be powerful
enough to receive a signal inside a steel-framed building.

Avoid wishful thinking
The gearbox shall be 100% safe in normal operation
The network shall handle all unexpected errors without
crashing.
Manageable

Attributes should be used to support requirements
management.

For example:
Date created
Date last edited
Priority (High, Mid, Low etc)
Status (Completed, Undergoing Change,
Scheduled, Unassigned).
49
Qualities of a Good Set of
Requirements

Realistic: The requirements should represent
realistic goals at both the product and project level.

Concise: The requirements as a whole should
concisely describe the system that is to be developed.
Long-winded requirements create greater opportunity
for ambiguity and errors.

Complete: The requirements should collectively
describe the entire system to be implemented with no
information missing.

Consistent: Inconsistencies between requirements
lead to conflicts that prohibit all of the requirements
being implemented successfully. Inconsistencies
should be identified and conflicts negotiated.
50
Begin with the end in mind - Sample SRS
Overview
Revision History
Table of Contents
1.0 Introduction
1.1 Purpose
1.2 Scope
1.3 References
1.4 Assumptions and
Dependencies
2.0 Use-Cases
3.0 Requirements
3.1 Functional Requirements
3.2 Non-Functional
Requirements
3.2.1
Usability
3.2.2
Reliability
3.2.3
Performance
3.2.4
Supportability
4.0
5.0
6.0
7.0
8.0
9.0
10.0
Index
Glossary
Online User Documentation
and Help System
Requirements
Design Constraints
Purchased Components
Interfaces
7.1
User Interfaces
7.2
Hardware
Interfaces
7.3
Software Interfaces
7.4
Communication
Interfaces
Licensing Requirements
Legal, Copyright, and Other
notices
Applicable Standards
Today’s Agenda
Topic
Duration

Finish risk management
30 minutes

Requirements process
45 minutes
*** Break

Current event reports
30 minutes

Requirements process
60 minutes

Wrap-up
15 minutes
52
For October 10

Read Pressman Chapters 13-14 (Testing)

Current Event Reports:
Fitzgerald
 Marose
 Mikael
 Nan

53
Extra slides
54
Testing
Acceptance
Test
Requirements
System
Test
Functional Design
Technical
Design
Integration
Test
Detailed
Design
Unit Test
Code
Legend:
Flow of Work
Validation
Verification
Testing: Test that the product implements
the specification
55
Change Control Process
Create
Changes to
Incorporate
Create Initial
Sections
Create
Review
Changes Needed
In Document
Review
Draft
(V&V)
Create/Modify
Draft
Revise
Review
...
Document
Approved
Review
Approved
Time
Document Under Development and
User Change Control
Document in Production and
Under Formal Change Control
56
Waterfall model
System
requirements
Software
requirements
Analysis
Program
design
Coding
Source: Royce, W. "Managing
the Development of Large
Software Systems."
Testing
Operations
57
RUP Artifacts by Phase and
Discipline
Discipline
Business Modeling
Requirements
Analysis & Design
Inception
Transition
Vision
Use Cases (20-80%)
Actors
Software Req Spec
Glossary
Software Arch Doc
Executable Architecture
User Interface Prototype
User Interface Design
Use Case Realization
Design Model
Database Design
Build Plan
Build
Test Results
Test Strategy
Deployment
Construction
Business Architecture
Implementation
Test
Elaboration
Test Plan
Test Script
Test Data
Test Results
Deployment Plan
Training Materials
Support Materials
Acceptance Test
Results
Change Requests
Product
58
RUP Artifacts by Phase and
Discipline
Discipline
Inception
Environment
Construction
Transition
CM Plan
CM Environment
Change Requests
Configuration and
Change Management
Project Management
Elaboration
Risk List
Risk Mgmt Plan
Business Case
QA Plan
Software Dev Plan
Dev Case (Process)
Tools
Guidelines
Templates
Support
59
Risk vs. Technology Maturity
Risk vs. Return
Impact of Technology Maturity
Risk
Early Adopter
Mid Adopter
Late Adopter
hands-on implementation experience
little exper / high risk
more exper / mid risk
much exper / low risk
vendor survival for project after shake-out
high risk
mid risk
low risk
sudden changes in direction of technology
high risk
mid risk
low risk
integrating technology with existing portfolio
high risk
mid risk
low risk
Period for Start of Payoff
Short term
Mid term
Long term
Size of Returns per period
Biggest
Bigger
Big
Benefits
60
Flow of Extension Activities
Describe
Use Case
Perform Use
Case Analysis
Model User
Experience
Identify Design
Elements
Design
Classes
Design Subsystems &
Components
Implement
Elements
Core Concepts
The focus of SE 425 is
the process component
of software engineering
Process
Technology
People
… for the delivery of
technology-enabled
business solutions
Process
People
Technology
62