Chapter

6 Requirements Modeling: Scenarios,


Information, and Analysis Classes

Slide Set to accompany

Software Engineering: A Practitionerʼs Approach,
7/e
by Roger S. Pressman
Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in
conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other
reproduction or use is prohibited without the express written permission of the
author.

All copyright information MUST appear if these slides are posted on a website
for student use.

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 1
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Requirements
Analysis
Requirements analysis

 specifies softwareʼs operational characteristics
 indicates software's interface with other system
elements
 establishes constraints that software must meet
 Requirements analysis allows the software
engineer (called an analyst or modeler in this
role) to:
 elaborate on basic requirements established
during earlier requirement engineering tasks
 build models that depict user scenarios, functional
activities, problem classes and their relationships,
system and class behavior, and the flow of data
as it is transformed.
These slides are designed to accompany Software Engineering: A Practitionerʼs
Approach, 7/e 2
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
 A
Bridge
system

descripti
on

anal
ysis
model

desi
gn
mod
el
These slides are designed to accompany Software Engineering: A Practitionerʼs
Approach, 7/e 3
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Rules of
Thumb
The model should focus on requirements that are

visible within the problem or business domain.
The level of abstraction should be relatively
high.
 Each element of the analysis model should add to an
overall understanding of software requirements and
provide insight into the information domain, function
and behavior of the system.
 Delay consideration of infrastructure and
other non- functional models until design.
 Minimize coupling throughout the system.
 Be certain that the analysis model provides
value to all stakeholders.
 Keep the model as simple as it can be.

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 4
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Domain
Analysis

Donald Firesmith

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 5
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Domain
Analysis
 Define the domain to be investigated.

 Collect a representative sample of

applications in the domain.
 Analyze each application in the sample.
 Develop an analysis model for the
objects.

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 6
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Elements of Requirements
Analysis

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 7
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Scenario-Based
Modeling

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 8
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
What to Write
About?
Inception and elicitation—provide you with

the information you’ll need to begin writing
use cases.
 Requirements gathering meetings, QFD, and
other requirements engineering
mechanisms are used to
 identify stakeholders
 define the scope of the problem
 specify overall operational goals
 establish priorities
 outline all known functional requirements, and
 describe the things (objects) that will be
manipulated by the system.
 To begin developing a set of use cases, list the
functions
These slides are or Software
designed to accompany activities
Engineering:performed
A Practitionerʼs by a specific
Approach, 7/e
actor.
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
9
How Much to Write
About?
 As further conversations with the
stakeholders progress, the
requirements gathering team develops
use cases for each of the functions
noted.
 In general, use cases are written first
in an informal narrative fashion.
 If more formality is required, the
same use case is rewritten using a
structured format similar to the one
proposed.
These slides are designed to accompany Software Engineering: A Practitionerʼs
Approach, 7/e 10
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Use-
Cases
 a scenario that describes a “thread of
usage” for a system
 actors represent roles people or devices
play as the system functions
 users can play a number of different roles
for a given scenario

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 11
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Developing a Use-
Case
What are the main tasks or functions that are

performed by the actor?
 What system information will the 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 slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 12
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Use-Case
Diagram SafeHome

Access camera
surveillance via camera
the Internet s

Configure
SafeHome
system
parameters
homeown
er

Set
alarm

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 13
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Activity
Diagram
Supplements enter
password
and user

the use case by ID

providing a valid
passwords/ID
invalid
passwords/ID

graphical select major prompt for

function

representation
other reentry
functions
may also be
selecte
d input tries

of the flow of
select remain
surveillance no input
tries
remain

interaction thumbnail select a specific

within a specific
views camera

select
select camera

scenario
specific
camera -
icon
thumbnails

view camera
output in
labelled window

prompt for
another
view

exit this see another

function camera

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 14
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Swimlane
Diagrams homeo
wn e r
c am e
ra
i n t e rf a
ce

enter
password
and user ID

valid
passwords/ID invalid
passwords/I
select major D
function
other prompt for
may also
functions reentry
be
selected input
select tries
surveillance remain
no input
tries
remain

thumbnail select a specific

views camera

select
select camera
specific
camera - icon
thumbnails

generate
video
output
view camera prompt for
output in another
labelled window view

exit
this
functio
n

see
anothe
r
camer
a
These slides are designed to accompany Software Engineering: A Practitionerʼs
Approach, 7/e 15
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Data
Modeling
 examines data objects
independently of processing
 focuses attention on the data
domain
 creates a model at the customerʼs
level of abstraction
 indicates how data objects relate
to one another

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 16
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
What is a Data
Object?
a representation of almost any composite

information that must be understood by
software.
 composite information—something that has a
number of different properties or attributes
 can be an external entity (e.g., anything that
produces or consumes information), a thing
(e.g., a report or a display), an occurrence (e.g.,
a telephone call) or event (e.g., an alarm), a role
(e.g., salesperson), an organizational unit (e.g.,
accounting department), a place (e.g., a
warehouse), or a structure (e.g., a file).
 The description of the data object incorporates
the data object and all of its attributes.
 A data object encapsulates data only—there is
no reference within a data object to
Approach, 7/e
operations
These slides are that
designed to accompany act
Software on Athe
Engineering: data.
Practitionerʼs
17
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Data Objects and
Attributes

object: automobile
attributes:
make
model
body type
price
options
code

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 18
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
What is a
Relationship?
 Data objects are connected to one
another in different ways.
 A connection is established between person
and car
because the two objects are related.
• A person owns a car
• A person is insured to drive a car
 The relationships owns and insured to
drive define the relevant connections
between person and car.
 Several instances of a relationship can
exist
 Objects can be related in many
Approach, 7/e different ways
These slides are designed to accompany Software Engineering: A Practitionerʼs
19
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
ERD
Notation

(0, (1,
m) 1)

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 20
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Building an
ERD
 Level 1—model all data objects
(entities) and their “connections”
to one another
 Level 2—model all entities
and relationships
 Level 3—model all entities,
relationships, and the attributes that
provide further depth

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 21
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
The ERD: An
Example request
places
Customer (1,m) for service
(1,1)
(1,1)
standard (1,n) work
task generates
table order
(1,1) (1,1) (1,1)
selected work (1,w)
from consists
(1,w) of
tasks
(1,i)
materials lists

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 22
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Class-Based
Modeling
 Class-based modeling represents:
 objects that the system will manipulate
 operations (also called methods or services)
that will be applied to the objects to effect
the manipulation
 relationships (some hierarchical) between
the objects
 collaborations that occur between the classes
that are defined.
 The elements of a class-based model
include classes and objects, attributes,
operations, CRC models, collaboration
diagrams
These slides are and
designed to accompany packages.
Software Engineering: A Practitionerʼs
Approach, 7/e 23
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Identifying Analysis
Classes
 Examining the usage scenarios
developed as part of the requirements
model and perform a "grammatical
parse" [Abb83]
 Classes are determined by underlining each
noun or noun phrase and entering it into a
simple table.
 Synonyms should be noted.
 If the class (noun) is required to implement
a solution, then it is part of the solution
space; otherwise, if a class is necessary
only to describe a solution, it is part of the
problem space.
 But what should we look for once all
of
These slides are
Approach, 7/e
the
designed nouns
to accompany Softwarehave
Engineering: been
A Practitionerʼsisolated?
24
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Manifestations of Analysis
Classes
 Analysis classes manifest themselves in
one of the following ways:
• External entities (e.g., other systems, devices,
people) that produce or consume information
• 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
• Structures (e.g., sensors, four-wheeled vehicles, or
computers) that define a class of objects or related
These slides are designed toclasses
accompanyof objects
Software Engineering: A Practitionerʼs
Approach, 7/e 25
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Potential
Classes  Retained information. The potential class will be useful
during analysis only if information about it must be
remembered so that the system can function.
 Needed services. The potential class must have a set of
identifiable operations that can change the value of its
attributes in some way.
 Multiple attributes. During requirement analysis, the focus
should be on "major" information; a class with a single
attribute may, in fact, be useful during design, but is
probably better represented as an attribute of another class
during the analysis activity.
 Common attributes. A set of attributes can be defined for
the potential class and these attributes apply to all
instances of the class.
 Common operations. A set of operations can be defined for
the potential class and these operations apply to all
instances of the class.
 Essential requirements. External entities that appear in the
problem space and produce or consume information
essential
These slides are
Approach, 7/e
to the operation
designed to accompany ofAany
Software Engineering: solution for the system will
Practitionerʼs
26
almost
(McGraw-Hill, 2009). Slides always be by
copyright 2009 defined as classes in the requirements
Roger Pressman.
Defining
Attributes
 Attributes describe a class that has
been selected for inclusion in the
analysis model.
 build two different classes for professional
baseball players
• For Playing Statistics software: name,
position, batting average, fielding percentage,
years played, and games played might be
relevant
• For Pension Fund software: average
salary, credit toward full vesting, pension
plan options chosen, mailing address, and
the like.

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 27
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Defining
Operations
 Do a grammatical parse of a
processing narrative and look at
the verbs
 Operations can be divided into four
broad categories:
 (1) operations that manipulate data in
some way (e.g., adding, deleting,
reformatting, selecting)
 (2) operations that perform a
computation
 (3) operations that inquire about the
state of an object, and
 (4)tooperations
These slides are designed that monitor
accompany Software Engineering: A Practitionerʼs an object
Approach, 7/e 28
for copyright
(McGraw-Hill, 2009). Slides the 2009occurrence
by Roger Pressman. of a controlling
CRC
Models
 Class-responsibility-collaborator (CRC)
modeling [Wir90] provides a simple
means for identifying and organizing
the classes that are relevant to system
or product requirements. Ambler
[Amb95] describes CRC modeling in
the following way:
 A CRC model is really a collection of
standard index cards that represent classes.
The cards are divided into three sections.
Along the top of the card you write the name
of the class. In the body of the card you list
the class responsibilities on the left and the
These slides are designed to accompany Software Engineering: A Practitionerʼs
Approach, 7/e collaborators on the right.
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
29
CRC
Modeling Clas
s:Clas
s:Class:
Descriptio
n:Descriptio
Class:
n: Descriptio
FloorPlan
n:
Responsibility: Collaborator:
Responsibility:
Description: Collaborator:
Responsibility:
Responsibilit Collaborator:
Collaborato
y:
defines floor plan r:
name/type manages floor
plan positioning
scales floor plan for
display scales
incorporates floordoors and
walls, Wall
plan for display
windows shows position of video Camer
cameras a

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 30
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
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 slides are designed to accompany Software Engineering: A Practitionerʼs
Approach, 7/e 31
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Responsibiliti
es 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 slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 32
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Collaboratio
ns 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 slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 33
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Composite Aggregate
Class Playe
r

PlayerHea PlayerBo PlayerAr PlayerLe

d dy ms gs

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 34
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
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 slides are designed to accompany Software Engineering: A Practitionerʼs
Approach, 7/e 35
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Multiplici
ty Wal
l

1 1
1
is used to is used to
build build
1..* 0..*
0..* is used to
build
WallSegme Windo Doo
nt w r

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 36
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Dependenci
es
DisplayWind Camer
ow a
<<access>>

{passwor
d}

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 37
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
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 slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 38
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Analysis
Packages Environment
package
name

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

Characters

+Player
+Protagonist
+Antagonist
+SupportingRole

These slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 39
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
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 slides are designed to accompany Software Engineering: A Practitionerʼs

Approach, 7/e 40
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.