Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e
copyright © 1996, 2001
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
This presentation, slides, or hardcopy may NOT be used for
short courses, industry seminars, or consulting purposes.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
1
Chapter 11
Analysis Concepts and Principles
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
2
What Are the Real Problems?
the customer has only a vague idea of what is
required
the developer is willing to proceed with the
"vague idea" on the assumption that "we'll fill in
the details as we go"
the customer keeps changing requirements
the developer is "racheted" by these changes,
making errors in specifications and development
and so it goes ...
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
3
Requirement Analysis
Bridges between system level requirement
engineering and software design
Result in:
 specification of software’s operational characteristics
(function, data, & behavior)
 software’s interface
 constraints
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
4
Requirement Analysis (2)
Areas of Effort
1.
2.
3.
4.
5.
++
Problem Recognition
Evaluation and Synthesis
Modeling
Specification, and
Review
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
5
Software Requirements Analysis
1. identify the “customer” and work
together to negotiate “product-level”
requirements
2. build an analysis model
 focus on data
 define function
 represent behavior
3. prototype areas of uncertainty
4. develop a specification that will
guide design
5. conduct formal technical reviews
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
6
Requirement Elicitation for Software
1. Initiating the process
 Communication by asking
 Context-free question (eg. Who requests…, what’s
benefit…)
 The perception from customer (eg. What is good
output…, system environment…)
 Meta-question for effectiveness of the meeting (eg. Are
your answer official, are my questions relevant…, am I
asking too much questions…)
2. Facilitated Application Specification Techniques
3. Quality Function Deployment
4. Use-Cases
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
7
Requirements Gathering
Facilitated Application Specification Techniques
Software
Engineering
Group
Customer
Group
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
8
About FAST…
Encourages the creation of a joint team of
customers and developers who work together
to
 identify problem,
 propose element of the solution
 Negotiate different approach, and
 Specify a preliminary set of solution requirements
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
9
FAST Guidelines
participants must attend entire
meeting
all participants are equal
preparation is as important as meeting
all pre-meeting documents are to be
viewed as “proposed”
off-site meeting location is preferred
set an agenda and maintain it
don’t get mired in technical detail
J. Wood & D. Silver
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
10
Quality Function Deployment
Intro
 A quality management technique that translates the
needs of the customer into technical requirements for
software
 Initially developed in Japan, QFD concentrates on
maximizing customer satisfaction
 Emphasizes an understanding of what is valuable to the
customer and then deploys these values throughout
engineering process
 Types of requirements:
 Normal (explicitly stated)
 Expected (implicit)
 Exciting (beyond expectation)
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
11
Quality Function Deployment
Concept overview…
Function deployment determines the “value”
(as perceived by the customer) of each
function required of the system
Information deployment identifies data
objects and events
Task deployment examines the behavior of
the system
Value analysis determines the relative priority
of requirements
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
12
Use-Cases
A collection of scenarios that describe the thread
of usage of a system
Each scenario is described from the point-ofview of an “actor”—a person or device that
interacts with the software in some way
Each scenario answers the following questions:
 What are the main tasks of functions performed by the actor?
 What system information will the actor acquire, produce or
change?
 Will the actor inform the system about environmental
changes?
 What information does the actor require of the system?
 Does the actor wish to be informed about unexpected
changes
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
13
The Analysis Process
build a
prototype
the problem
requirements
elicitation
develop
Specification
Review
create
analysis
models
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
14
Analysis Principle I
Model the Data Domain
define data objects
describe data attributes
establish data relationships
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
15
Analysis Principle II
Model Function
identify functions that transform data
objects
indicate how data flow through the system
represent producers and consumers of
data
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
16
Analysis Principle III
Model Behavior
indicate different states of the system
specify events that cause the system to
change state
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
17
Analysis Principle IV
Partition the Models
refine each model to represent lower
levels of abstraction
 refine data objects
 create a functional hierarchy
 represent behavior at different levels of detail
Horizontal & vertical partitioning
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
18
Analysis Principle V
Essence
begin by focusing on the essence of
the problem without regard to
implementation details
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
19
Davis’ Principles
 Understand the problem before you begin to create the
analysis model.
 Develop prototypes that enable a user to understand
how human-machine interaction will occur.
 Record the origin of and the reason for every
requirement.
 Use multiple views of requirements.
 Prioritize requirements.
 Work to eliminate ambiguity.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
20
The Analysis Model
Data Model
Functional
Model
Behavioral
Model
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
21