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
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1
Requirement Model
 The requirements model—actually a set of models—is the
first technical representation of a system
 Scenario-based models of requirements from the point of view of various
system “actors”
 Data models that depict the information domain for the problem
 Class-oriented models that represent object-oriented classes (attributes
and operations) and the manner in which classes collaborate to achieve
requirements
 Flow-oriented models that represent the functional elements of the system
and how they transform data as it moves through the system
 Behavioral models that depict how the software behaves as a consequence
of
external “events”

2
Requirements Analysis
leads to Req. Model
 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 (inception, elicitation, and
negotiation)
 build models: user scenarios, Data, Class, Flow,
Behavioral
 These models provide a software designer with information
that can be translated to architectural, interface, and
component-level designs

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 3
Requirement Modeling
 Throughout requirements modeling, your
primary focus is on what, not how.
 What user interaction occurs in a particular
circumstance?
 What objects does the system manipulate?
 What functions must the system perform?
 What behaviors does the system exhibit?
 What interfaces are defined?
 and what constraints apply?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 4
Requirement Modeling
 We know, complete specification of requirements may not
be possible at this stage.
 The customer may be unsure of precisely what is required
for certain aspects of the system.
 The developer may be unsure that a specific approach will
properly accomplish function and performance.

 These realities mitigate in favor of an iterative approach to

requirements analysis and modeling.
 The analyst should model what is known and use that
model as the basis for design of the software increment.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5
Requirement Modeling
 The requirements model must achieve three
primary objectives:
 (1) to describe what the customer requires
 (2) to establish a basis for the creation of a software
design
 (3) to define a set of requirements that can be
validated once the software is built

 Requirement Model or Analysis Model Bridges the

Gap between System Description and Design Model

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6
 A Bridge

system
description

analysis
model

design
model

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 7
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
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 8
Domain Analysis
 Analysis Patterns often reoccur across many
applications within a specific business domain
 Recognize and Apply these patterns to solve common
problems, the creation of the analysis model is
expedited
 More important, the likelihood of applying design
patterns and executable software components grows
dramatically
 This improves time-to-market and reduces
development costs.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 9
Domain Analysis
 But how are analysis patterns and classes recognized
in the first place?
 Who defines them, categorizes them, and readies them
for use on subsequent projects?
 The answers to these questions lie in domain analysis.
 Software domain analysis is the identification, analysis, and
specification of common requirements from a specific
application domain, typically for reuse on multiple projects
within that application domain

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

11
Requirement Modeling
Approaches
 Two Approaches: Structured vs O-O Approach
 Structure Approach
 considers data & the processes that transform the
data as separate entities.
 Data objects are modeled in a way that defines their
attributes and relationships.
 Processes that manipulate data objects are modeled
in a manner that shows how they transform data as
data objects flow through the system

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 12
Requirement Modeling
Approaches
 Object Oriented Approach
 Focuses on the definition of classes and the manner
in which they collaborate with one another to effect
customer requirements
 UML and the Unified Process are Predominantly
object oriented.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13
Requirement Modeling
Approaches
 Although the requirements model proposed in this book combines
features of both approaches, software teams often choose one approach
and exclude all representations from the other

 The question is not which is best, but rather, what combination of

representations will provide stakeholders with the best model of software
requirements and the most effective bridge to software design

 Each element of the requirements model presents the problem from a

different point of view

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 14
Elements of Requirements Analysis

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 15
Scenario-Based Modeling
Although the success of a computer-based system or product
is measured in many ways, BUT user satisfaction resides at
the top of the list. IF you understand how end users (and other
actors) want to interact with a system, your software team will
be better able to properly characterize requirements and build
meaningful analysis and design

“[Use-cases] are simply an aid to defining what exists

outside the system (actors) and what should be
performed by the system (use-cases).” Ivar Jacobson
(1) What should we write about?
(2) How much should we write about it?
(3) How detailed should we make our description?
(4) How should we organize the description? 16
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
or activities performed by a specific actor.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17
What to Write About?
 The SafeHome home surveillance already discussed
identifies the following functions (an abbreviated list)
that are performed by the
homeowner (actor):
• Select camera to view
• Request thumbnails from all cameras.
• Display camera views in a PC window.
• Control pan and zoom for a specific camera.
• Selectively record camera output.
• Replay camera output.
• Access camera surveillance via the Internet.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 18
What to Write About?
 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
 Example: Consider the function access camera
surveillance via the Internet— display camera views.
 Narrative of homeowner about interaction

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 19
 What to Write About?
 Use case: Access camera surveillance via
the Internet—display camera views
(ACS-DCV)
Actor: homeowner
If I’m at a remote location, I can use any PC with appropriate browser software to log
on to the SafeHome Products website. I enter my user ID and two levels of passwords and
once I’m validated, I have access to all functionality for my installed SafeHome system. To
access a specific camera view, I select “surveillance” from the major function buttons displayed.
I then select “pick a camera” and the floor plan of the house is displayed. I then select the
camera that I’m interested in. Alternatively, I can look at thumbnail snapshots from
all cameras simultaneously by selecting “all cameras” as my viewing choice. Once I choose
a camera, I select “view” and a one-frame-per-second view appears in a viewing window
that is identified by the camera ID. If I want to switch cameras, I select “pick a camera” and
the original viewing window disappears and the floor plan of the house is displayed again.
I then select the camera that I’m interested in. A new viewing window appears.

20
What to Write About?
 A variation of a narrative use case presents the
interaction as an ordered sequence
of user actions.
1. The homeowner logs onto the SafeHome Products website.
2. The homeowner enters his or her user ID.
3. The homeowner enters two passwords (each at least eight characters in
length).
4. The system displays all major function buttons.
5. The homeowner selects the “surveillance” from the major function buttons.
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house.
8. The homeowner selects a camera icon from the floor plan.
9. The homeowner selects the “view” button.
10. The system displays a viewing window that is identified by the camera ID.
11. The system displays video output within the viewing window at one frame
per second.
21
What to Write About?
 It is important to note that this sequential presentation does not consider any
alternative interactions (the narrative is more free-flowing and did represent a
few alternatives). Use cases of this type are sometimes referred to as primary
scenarios

 Refining a Preliminary Use Case

 A description of alternative interactions is essential for a complete

understanding of the function that is being described by a use case.
 Therefore, each step in the primary scenario is evaluated by asking the
following questions

22
What to Write About?
 Can the actor take some other action at this
point?
 Is it possible that the actor will encounter some
error condition at this point? If so, what might it
be?
 Is it possible that the actor will encounter some
other behavior at this point (e.g., behavior that is
invoked by some event outside the actor’s
control)? If so, what might it be?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 23
1. The homeowner logs onto the SafeHome Products website.
2. The homeowner enters his or her user ID.
3. The homeowner enters two passwords (each at least eight characters in
length).
4. The system displays all major function buttons.
5. The homeowner selects the “surveillance” from the major function buttons.
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house.
8. The homeowner selects a camera icon from the floor plan.
9. The homeowner selects the “view” button.
10. The system displays a viewing window that is identified by the camera ID.
11. The system displays video output within the viewing window at one frame
per second. Is it possible that the actor will encounter
Is it possible that the actor will encounter some
some error condition at this point? Any
Can the actor take some
other other action
behavior at this
at this point? Again
number of error conditions can occur as a
point? The answer isthe“yes.” Referring
answer to thetoquestion is “yes.” As steps 6
computer-based system operates. In this
the free-flowing narrative,
and 7the actorthe
occur, may choose
system may encounter
context, we consider only error conditions that
to view thumbnail snapshots
an alarmofcondition.
all This would result in the
are likely as a direct result of the action
cameras simultaneously.
systemHence, one secondary
displaying a special alarm notification
described in step 6 or step 7. Again the answer
scenario might be “View thumbnail
(type, location, system action) and providing the
to the question is “yes.” A floor
snapshots for all cameras.”
actor with a number of options relevant to the
plan with camera icons may have never been
nature of the alarm. Because this secondary
configured. Hence, selecting “pick a
scenario can occur
camera” results in an error condition: “No floor
at any time for virtually all interactions
plan configured for this house.” This
error condition becomes a secondary scenario. 24
What to Write About?
 Each of the situations described in the
preceding slide is characterized as
a use-case exception.

 An exception describes a situation (either a

failure condition or an alternative chosen by the
actor) that causes the system to exhibit
somewhat different behavior.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 25
What to Write About?
 In addition to the three generic questions suggested
earlier in this section, the following issues should also
be explored:
 Are there cases in which some “validation function” occurs during this use
case? This implies that validation function is invoked and a potential error
condition might occur.

 Are there cases in which a supporting function (or actor) will fail to respond
appropriately? For example, a user action awaits a response but the function
that is to respond times out.

 Can poor system performance result in unexpected or improper user actions?

For example, a Web-based interface responds too slowly, resulting in a user
making multiple selects on a processing button. These selects queue
inappropriately and ultimately generate an error condition.

26
What to Write About?
 The list of extensions developed as a
consequence of asking and answering these
questions should be “rationalized” using the
following criteria:
 an exception should be noted within the use case if the
software can detect the condition described and then
handle the condition once it has been detected.
 In some cases, an exception will precipitate the
development of another use case (to handle the condition
noted).

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 27
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
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 28
Writing a Formal Use-Case
 Important elements of a formal use-case
 The goal in context identifies the overall scope of the use
case.
 The precondition describes what is known to be true before
the use case is initiated.
 The trigger identifies the event or condition that “gets the use
case started” [Coc01b].
 The scenario lists the specific actions that are required by the
actor and the appropriate system responses.
 Exceptions identify the situations uncovered as the
preliminary use case is refined.
 Additional elements may or may not be included

29
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 30
Diagrammatic
Representation
 Ease of understanding in case of complexity

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 31
UML Model that Supplement
the Use-Case
 There are many requirements modeling situations in which a text-based
model— even one as simple as a use case—may not impart information in a
clear and concise manner
 In such cases, you can choose from a broad array of UML graphical models.
 Developing an Activity Diagram
 The UML activity diagram supplements the use case by providing a graphical
representation of the flow of interaction within a specific scenario. Similar to the flowchart,
an activity diagram uses rounded rectangles to imply a specific system function,
arrows to represent flow through the system, decision diamonds to depict a branching
decision (each arrow emanating from the diamond is labeled), and solid horizontal lines to
indicate that parallel activities are occurring.

32
 UML Model that Supplement
the Use-Case
 activity diagram for the
ACS-DCV use case

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 33
Swimlane Diagrams
home owne r c a m e ra i n t e rf a c e

Allows the modeler to

represent the flow of e nt e r pa s s word

activities described by the a nd us e r ID

use-case and at the same

time indicate which actor valid p as s wo r d s / ID
in valid

(if there are multiple s e le c t m a jor fu nc t ion

p as s wo r d s/ ID

actors involved in a o t h er f u n ct io n s prom pt fo r re e nt ry

m ay als o b e
specific use-case) or s elect ed

in p u t t r ies
analysis class has s e le c t s urve illa nc e r em ain

responsibility for the n o in p u t

t r ies r em ain

action described by an
activity rectangle t h u m b n ail views s elect a s p ecif ic cam er a

s e le c t s pe c ific
s e le c t c a m e ra ic on
c a m e ra - t h um b na ils

ge ne ra t e vide o
ou tpu t

vie w c a m e ra ou t put p rom p t for

in la be lle d wind ow a not he r vie w

exit t h is
f u n ct io n

see
an o t h er
cam er a

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 34
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
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 35
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 operations that act on the data.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 36
Data Objects and Attributes
A data object contains a set of attributes that
act as an aspect, quality, characteristic, or
descriptor of the object
object: automobile
attributes:
make
model
body type
price
options code

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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 38
ERD Notation
One common form:
(0, m)
object1 relationship object 2
(1, 1)

attribute
Another common form:

object1 relationship
object 2
(0, m) (1, 1)

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 39
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
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 40
The ERD: An Example
request
Customer places
for service
(1,1) (1,m)
(1,1)
standard (1,n) work
task table generates
order
(1,1) (1,1) (1,1)
selected work (1,w)
consists
from
(1,w) tasks of

(1,i)
materials lists

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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 42
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 the
nouns have been isolated?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 43
Manifestations of Analysis Classes
 what should we look for once all of the nouns have been isolated?
 Analysis classes manifest (obvious/ clear) 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 classes of objects

44
Manifestations of Analysis Classes
 In simple words it is categorization of classes
 Also called taxonomy of classes
 For instance following types of classes:
 producers (sources) and consumers (sinks) of data, data
managers, view or observer classes, and
helper classes.
 Also important to note What is not a class
 Some times mistakes in analysis leads toward mistakes in
selection of classes
 For example: considering Function/Operation as Class

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 45
Identifying Classes through
Grammatical Parse

46
 Identifying Classes through
Grammatical Parse
The list would be continued until all nouns
in the processing narrative have been
considered.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 47
Selection Characteristics for
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 to the operation
of any solution for the system will almost always be defined as classes
in the requirements model.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 48
Selection Characteristics for
Potential Classes

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 49
Selection Characteristics for
Potential Classes

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 50
Selection Characteristics for
Potential Classes

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 51
Defining Attributes
 Attributes describe a class that has been selected for
inclusion in the analysis model.
 Same class may have different attributes for different systems
 To develop a meaningful set of attributes for an analysis class,
you should study each use case and select those “things” that
reasonably “belong” to the class
 In addition, the following question should be answered for each
class: “What data items
(composite and/or elementary) fully define this class in the
context of the problem
at hand?”

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 52
Defining Attributes

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 53
 Defining Operations
 Do a grammatical parse of a processing
narrative and look at the verbs
Operations define the behavior of an

 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) operations that monitor an object for the
object.

occurrence of a controlling event.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 54
Defining Operations
 These functions are accomplished by operating
on attributes and/or associations. Therefore, an
operation must have “knowledge” of the
nature of the class’ attributes and associations.

55
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 56
CRC Models

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 57
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
collaborators on the right.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 58
 CRC Modeling
Collaborators are
those classes that
are required to
Class: provide a class with
Class:
Description:
Class: the information
Description:
Class: FloorPlan
Description: needed to complete
Responsibilities are the Responsibility:
Description: Collaborator:
Responsibility: Collaborator: a responsibility.
attributes and Responsibility: Collaborator: In general, a
Responsibility: Collaborator:
operations that are collaboration
defines floor plan name/type
relevant for the class. implies either a
manages floor plan positioning
Stated simply, a request for
scales floor plan for display
responsibility is information or a
scales floor plan for display
“anything the class request for
knows or does” incorporates walls, doors and windows Wall
some action.
shows position of video cameras Camera

59
Class Types
 Basic guidelines for identifying classes and objects are already discussed.
Discussion about taxonomy of class types is also carried out, further extension by
considering the following categories:
 Entity classes, also called model or business classes, are extracted directly from
the statement of the problem/Entities are objects representing system data (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 : Controls are objects that mediate between boundaries and
entities. 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.

60
Responsibilities
 Basic guidelines for identifying responsibilities (attributes and operations)
have been already discussed. Wirfs-Brock and her colleagues [Wir90]
suggest five guidelines for allocating responsibilities to classes:

 System intelligence should be distributed across classes to best address

the needs of the problem (cohesion)
 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
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 61
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 or can't
 three different generic relationships between classes [WIR90]:
 the is-part-of relationship
 the has-knowledge-of relationship (When one class must acquire information
from another class)
 the depends-upon relationship (The depends-upon relationship implies that two
classes have a dependency that is not achieved by has-knowledge-of or is-part-
of)

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 62
Example: is-part-of/Aggregation
Player

PlayerHead PlayerBody PlayerArms PlayerLegs

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 63
Example: has-knowledge-of
 Seeking information from other classes

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 64
Example: depends-upon
For example, PlayerHead must
always be connected to PlayerBody (unless the
video game is particularly violent),
yet each object could exist without direct
knowledge of the other. An attribute of the
PlayerHead object called center-position is
determined from the center position of Player

PlayerBody. This information is obtained via a

third object, Player, that acquires it
from PlayerBody. Hence, PlayerHead
depends-upon PlayerBody. PlayerHead PlayerBody PlayerArms PlayerLegs

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 65
Associations
 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)
Wa ll

1 1 1

is used to build is used to build

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

Wa llSe g m e n t Win d o w Do o r

66
Dependencies
 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

DisplayWindow Camera

<<access>>

{password}

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

 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
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 68
Analysis Packages
p ackag e n ame

Environme nt
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building Rule s OfThe Gam e
+VisualEffect
+Scene +RulesOfMovement
+ConstraintsOnAction

Charact e rs

+Player
+Protagonist
+Antagonist
+SupportingRole

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