Software Engineering: A Practitioner’s Approach,

6/e

Chapter 7
Requirements Engineering
copyright © 1996, 2001, 2005
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.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
 Requirements Engineering-I
 Inception—ask a set of questions that establish …
 basic understanding of the problem
 the people who want a solution
 the nature of the solution that is desired, and
 the effectiveness of preliminary communication and collaboration
between the customer and the developer
 Elicitation—elicit requirements from all stakeholders
 Elaboration—create an analysis model that identifies data, function
and behavioral requirements
 Negotiation—agree on a deliverable system that is realistic for
developers and customers

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
 Requirements Engineering-II
 Specification—can be any one (or more) of the following:
 A written document
 A set of models
 A formal mathematical
 A collection of user scenarios (use-cases)
 A prototype
 Validation—a review mechanism that looks for
 errors in content or interpretation
 areas where clarification may be required
 missing information
 inconsistencies (a major problem when large products or systems are
engineered)
 conflicting or unrealistic (unachievable) requirements.
 Requirements management

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
 Inception
 Identify stakeholders
 “who else do you think I should talk to?”
 Recognize multiple points of view
 Work toward collaboration
 The first questions
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful solution
 Is there another source for the solution that you need?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
 Eliciting Requirements
 meetings are conducted and attended by both software engineers and
customers
 rules for preparation and participation are established
 an agenda is suggested
 a "facilitator" (can be a customer, a developer, or an outsider) controls the
meeting
 a "definition mechanism" (can be work sheets, flip charts, or wall stickers
or an electronic bulletin board, chat room or virtual forum) is used
 the goal is
 to identify the problem
 propose elements of the solution
 negotiate different approaches, and
 specify a preliminary set of solution requirements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
 Eliciting Requirements

Conduct FA ST
meetings

Make lists of
functions, classes

Make lists of
constraints, etc.

formal prioritization?
Elic it requirement s
yes no

Use QFD to informally define actors

prioritize prioritize
requirements requirements

draw use-case
write scenario
diagram

Create Use-cases
complete template

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
 Quality Function Deployment
 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, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
 Quality Function Deployment
 QFD : emphasizes an understanding of what is valuable
to customer & then deploys these values throughout
the engineering process.

3 types of requirements

 Normal requirements

 Expected requirements

 Exciting requirements
8
 QFD
 QFD techniques applicable to requirements elicitation.

 QFD uses customer interviews , surveys & examination of

historical data for requirement gathering activity.

 Data is then translated into a table of requirements called

customer Voice table.

 Voice table is reviewed by customer & stakeholders.

9
 Elicitation Work Products
 a statement of need and feasibility.
 a bounded statement of scope for the system or product.
 a list of customers, users, and other stakeholders who
participated in requirements elicitation
 a description of the system’s technical environment.
 a list of requirements (preferably organized by function)
and the domain constraints that apply to each.
 a set of usage scenarios that provide insight into the use of
the system or product under different operating
conditions.
 any prototypes developed to better define requirements.
requirements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
 Use-Cases
 A collection of user scenarios that describe the thread of usage of a system
 Each scenario is described from the point-of-view of an “actor”—a person or
device that interacts with the software in some way
 Each scenario answers the following questions:

 Who is the primary actor, the secondary actor (s)?

 What are the actor’s goals?
 What preconditions should exist before the story begins?
 What main tasks or functions are performed by the actor?
 What extensions might be considered as the story is described?
 What variations in the actor’s interaction are possible?
 What system information will the actor acquire, produce, or change?
 Will the actor have to inform the system about changes in the external
environment?
 What information does the actor desire from 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, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
 Use-Case Diagram

Arms/ disarms
system

Accesses system sensors

via Internet

homeowner

Responds to
alarm event

Encounters an
error condition

system Reconfigures sensors

administrator and related
system features
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
13
14
15
 Building the Requirement Model
 Elements of the requirement model
 Scenario-based elements
 Functional—processing narratives for software functions
 Use-case—descriptions of the interaction between an
“actor” and the system
 Class-based elements
 Implied by scenarios
 Behavioral elements
 State diagram
 Flow-oriented elements
 Data flow diagram

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16
 Analysis Classes
 External entities (e.g., other systems, devices, people) that produce or consume
information to be used by a computer-based system.

 Things (e.g, reports, displays, letters, signals) that are part of the information domain for
the problem.

 Occurrences or events (e.g., a property transfer or the completion of a series of robot

movements) that occur within the context of system operation.

 Roles (e.g., manager, engineer, salesperson) played by people who interact with the
system.

 Organizational units (e.g., division, group, team) that are relevant to an application.

 Places (e.g., manufacturing floor or loading dock) that establish the context of the
problem and the overall function of the system.

 Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of

objects or related classes of objects.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17
 Selecting Classes—Criteria

Retained information
Needed services
Multiple attributes
Common attributes
Common operations
Essential requirements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18
 Class Diagram
Class name
System
systemID
verificationPhoneNumber
systemStatus attributes
delayTime
telephoneNumber
masterPassword
temporaryPassword
numberTries

program()
display()
reset()
query() operations
modify()
call()

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19
 Class Diagram
FloorPlan
type
name
outsideDimensions

determineType ( )
positionFloorplan
scale( )
change color( )

is placed within

is part of

Camera Wall

type type
ID wallDimensions
location
fieldV iew
panA ngle
ZoomSetting
determineType ( )
computeDimensions ( )
determineType ()
translateLocation ()
displayID()
displayV iew()
displayZoom()
is used to build is used to build

is used to build

WallSegment Window Door

type type type

startCoordinates startCoordinates startCoordinates
stopCoordinates stopCoordinates stopCoordinates
nextWallSement nextWindow nextDoor

determineType ( ) determineType ( ) determineType ( )

draw( ) draw( ) draw( )
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20
 CRC Modeling
(Class_Responsibility-Collaborator)

 Analysis classes have “responsibilities”

 Responsibilities are the attributes and operations encapsulated by
the class

 Analysis classes collaborate with one another

 Collaborators are those classes that are required to provide a
class with the information needed to complete a responsibility.
 In general, a collaboration implies either a request for
information or a request for some action.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21
 CRC
Modeling
Class:
Class:
Description:
Class:
Description:
Class:FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22
 Class Types
 Entity classes, also called model or business classes, are extracted
directly from the statement of the problem (e.g., FloorPlan and
Sensor).

 Boundary classes are used to create the interface (e.g., interactive

screen or printed reports) that the user sees and interacts with as
the software is used.

 Controller classes manage a “unit of work” [UML03] from start to

finish. That is, controller classes can be designed to manage
 the creation or update of entity objects;
 the instantiation of boundary objects as they obtain information from
entity objects;
 complex communication between sets of objects;
 validation of data communicated between objects or between the user
and the application.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23
 Responsibilities
(Attributes and methods relevant to the class)

 System intelligence should be distributed across classes

to best address the needs of the problem
 Each responsibility should be stated as generally as
possible
 Information and the behavior related to it should reside
within the same class
 Information about one thing should be localized with a
single class, not distributed across multiple classes.
 Responsibilities should be shared among related classes,
when appropriate.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24
 Collaborations
 Classes fulfill their responsibilities in one of two ways:
 A class can use its own operations to manipulate its own
attributes, thereby fulfilling a particular responsibility, or
 a class can collaborate with other classes.
 Collaborations identify relationships between classes
 Collaborations are identified by determining whether a class
can fulfill each responsibility itself
 Three different generic relationships between classes [WIR90]:
 the is-part-of relationship
 the has-knowledge-of relationship
 the depends-upon relationship

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25
 Composite Aggregate Class
Player

PlayerHead PlayerBody PlayerArms PlayerLegs

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26
 Reviewing the CRC Model
 All participants in the review (of the CRC model) are given a subset of the
CRC model index cards.
 Cards that collaborate should be separated (i.e., no reviewer should have two
cards that collaborate).
 All use-case scenarios (and corresponding use-case diagrams) should be
organized into categories.
 The review leader reads the use-case deliberately .
 As the review leader comes to a named object, she passes a token to the person
holding the corresponding class index card.
 When the token is passed, the holder of the class card is asked to describe the
responsibilities noted on the card.
 The group determines whether one (or more) of the responsibilities satisfies the
use-case requirement.
 If the responsibilities and collaborations noted on the index cards cannot
accommodate the use-case, modifications are made to the cards .
 This may include the definition of new classes (and corresponding CRC index
cards) or the specification of new or revised responsibilities or collaborations on
existing cards.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 27
 Associations and Dependencies
 Two analysis classes are often related to one another in
some fashion
 In UML these relationships are called associations
 Associations can be refined by indicating multiplicity (the term
cardinality is used in data modeling
 In many instances, a client-server relationship exists
between two analysis classes.
 In such cases, a client-class depends on the server-class in some
way and a dependency relationship is established

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 28
 Multiplicity
Wall

1 1 1

is used to build is used to build

1..* 0..* is used to build 0..*

WallSegment Window Door

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 29
 Dependencies

DisplayWindow Camera

<<access>>

{password}

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 30
 Analysis Packages
 Various elements of the analysis model (e.g., use-cases,
analysis classes) are categorized in a manner that
packages them as a grouping
 The plus sign preceding the analysis class name in each
package indicates that the classes have public visibility
and are therefore accessible from other packages.
 Other symbols can precede an element within a package.
A minus sign indicates that an element is hidden from
all other packages and a # symbol indicates that an
element is accessible only to packages contained within a
given package.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 31
 Analysis Packages
package name

Environment
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building RulesOfTheGame
+VisualEffect
+Scene +RulesOfMovement
+ConstraintsOnAction

Characters

+Player
+Protagonist
+Antagonist
+SupportingRole

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 32
 Behavioral Modeling
 The behavioral model indicates how software will respond to
external events or stimuli. To create the model, the analyst
must perform the following steps:
 Evaluate all use-cases to fully understand the sequence

of interaction within the system.

 Identify events that drive the interaction sequence and

understand how these events relate to specific objects.

 Create a sequence for each use-case.

 Build a state diagram for the system.

 Review the behavioral model to verify accuracy and

consistency.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 33
 State Representations
 In the context of behavioral modeling, two different
characterizations of states must be considered:
 the state of each class as the system performs its function and
 the state of the system as observed from the outside as the
system performs its function
 The state of a class takes on both passive and active
characteristics [CHA93].
 A passive state is simply the current status of all of an object’s
attributes.
 The active state of an object indicates the current status of the
object as it undergoes a continuing transformation or processing.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 34
State Diagram for the ControlPanel Class
t imer < lockedTime

t imer > lockedTime locked

password = incorrect
& numberOfTries < maxTries

reading comparing numberOfTries > maxTries

key hit
password
ent ered do: validatePassword
password = correct

select ing

act ivat ion successful

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 35
 The States of a System
 state—a set of observables that
characterizes the behavior of a system at
a given time
 state transition—the movement from one
state to another
 event—an occurrence that causes the
system to exhibit some predictable form
of behavior
 action—process that occurs as a
consequence of making a transition

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 36
 Behavioral Modeling

 Make a list of the different states of a system

(How does the system behave?)
 Indicate how the system makes a transition
from one state to another (How does the
system change state?)
 indicate event
 indicate action
 Draw a state diagram or a sequence
diagram

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 37
 Sequence Diagram
homeowner cont rol panel syst em sensors
sensors

syst em reading
A
ready
password ent ered

request lookup
comparing

result

password = correct
numberOfTries > maxTries request act ivat ion
locked

t imer > lockedTime

A

select ing

act ivat ion successful act ivat ion successful

Figure 8.27 Sequence diagram (partial) for SafeHome security function

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 38
 Writing the Software Specification
Everyone knew exactly
what had to be done
until someone wrote it
down!

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 39
 Class Diagram
From the SafeHome system …

Sensor

name/id
type
location
area
characteristics

identify()
enable()
disable()
reconfigure()

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 40
 State Diagram
Reading
Initialization
commands not jammed

turn copier subsystems

system status=“not ready” system status=“Ready” paper full
“on“ ready
display msg =“please wait” display msg =“enter cmd”
display status =blinking display status =steady

entry/ switch machine on entry/ subsystems ready

do: run diagnostics do: poll user input panel
do: initiate all subsystems do: read user input
do: interpret user input

turn copier “off”

start copies

Making copies load paper

copies complete
system status=“Copying”
system status=“load paper”
display msg=“copy count =”
display msg=“load paper”
display message=#copies paper tray empty display status=blinking
display status=steady

entry/ start copies paper jammed entry/ paper empty

do: manage copying do: lower paper tray
do: monitor paper tray do: monitor fill switch
do: monitor paper flow problem diagnosis do: raise paper tray

system status=“J ammed”

display msg=“paper jam”
display message=location
display status=blinking not jammed
entry/ paper jammed
do: determine location
do: provide correctivemsg.
do: interrupt making copies

Figure 7.6 Preliminary

These courseware materials are to be used in conjunction UML stateEngineering:
with Software diagram for a photocopier
A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 41
 Analysis Patterns
Pattern name: A descriptor that captures the essence of the pattern.
Intent: Describes what the pattern accomplishes or represents
Motivation: A scenario that illustrates how the pattern can be used to address the
problem.
Forces and context: A description of external issues (forces) that can affect how the
pattern is used and also the external issues that will be resolved when the pattern is
applied.
Solution: A description of how the pattern is applied to solve the problem with an
emphasis on structural and behavioral issues.
Consequences: Addresses what happens when the pattern is applied and what
trade-offs exist during its application.
Design: Discusses how the analysis pattern can be achieved through the use of
known design patterns.
Known uses: Examples of uses within actual systems.
Related patterns: On e or more analysis patterns that are related to the named
pattern because (1) it is commonly used with the named pattern; (2) it is structurally
similar to the named pattern; (3) it is a variation of the named pattern.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 42
 Negotiating Requirements
 Identify the key stakeholders
 These are the people who will be involved in the negotiation
 Determine each of the stakeholders “win conditions”
 Win conditions are not always obvious
 Negotiate
 Work toward a set of requirements that lead to “win-win”

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 43
 Validating Requirements-I
 Is each requirement consistent with the overall objective for the
system/product?
 Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
 Is the requirement really necessary or does it represent an add-on
feature that may not be essential to the objective of the system?
 Is each requirement bounded and unambiguous?
 Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?
 Do any requirements conflict with other requirements?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 44
 Validating Requirements-II
 Is each requirement achievable in the technical environment that will house
the system or product?
 Is each requirement testable, once implemented?
 Does the requirements model properly reflect the information, function and
behavior of the system to be built.
 Has the requirements model been “partitioned” in a way that exposes
progressively more detailed information about the system.
 Have requirements patterns been used to simplify the requirements model.
Have all patterns been properly validated? Are all patterns consistent with
customer requirements?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 45