REQUIREMENTS MODELING: SCENARIOS,

INFORMATION, AND ANALYSIS CLASSES

MODULE-02-CH-6
 6.1 REQUIREMENTS ANALYSIS

• Requirements analysis allows you to elaborate on basic

requirements established during the inception, elicitation, and
negotiation tasks that are part of requirements engineering.

• The requirements modeling action results in one or more of the

following types of models:
• The requirements modeling action results in one or more of the following
types of models:
• 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 system
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”
• These models provide a software designer with information that can be
translated to architectural, interface, and component-level designs.

• Finally, the requirements model (and the software requirements

specification) provides the developer and the customer with the means
to assess quality once software is built.
• 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, and
• (3) to define a set of requirements that can be validated once the software
is built.

• The analysis model bridges the gap between a system-level description

that describes overall system or business functionality as it is achieved by
applying software, hardware, data, human, and other system elements and
a software design that describes the software’s application architecture,
user interface, and component-level structure.
• This relationship is illustrated in Figure 6.1.
 ANALYSIS RULES OF THUMB

Number of worthwhile rules of thumb that should

be followed when creating the analysis model:
• The model should focus on requirements that are visible
within the problem or business domain. The level of
abstraction should be relatively high.
• “Don’t get bogged down in details” that try to explain how
the system will work.

• • Each element of the requirements 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 nonfunctional models
until design.

• Minimize coupling throughout the system.

• It is important to represent relationships between classes and functions.
• Be certain that the requirements model provides value to all
stakeholders.
• Each constituency has its own use for the model. For example,
business stakeholders should use the model to validate requirements;
designers should use the model as a basis for design; QA people should
use the model to help plan acceptance tests.

• Keep the model as simple as it can be. Don’t create additional

diagrams when they add no new information. Don’t use complex
notational forms, when a simple list will do.
 DOMAIN ANALYSIS

• Domain analysis is the process of identifying, capturing domain

knowledge about the problem domain with the purpose of making it
reusable when creating new systems.

• Domain analysis involves examining and understanding a specific

subject area or field of interest in order to extract meaningful
insights or develop solutions within that domain.

.
 REQUIREMENTS MODELING APPROACHES

• One view of requirements modeling, called structured

analysis, considers data and 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.
• A second approach to analysis modeling, called object-
oriented analysis, 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.
• the requirements model combines features of both
approaches,
• Scenario-based elements depict how the user interacts with the system and the
specific sequence of activities that occur as the software is used.
• Class-based elements model the objects that the system will manipulate, the
operations that will be applied to the objects to effect the manipulation,
relationships between the objects, and the collaborations that occur between the
classes that are defined.
• Behavioral elements depict how external events change the state of the system or
the classes that reside within it.
• Finally, flow-oriented elements represent the system as an information transform,
depicting how data objects are transformed as they flow through various system
functions.
 SCENARIO-BASED MODELING

• Requirements modeling with UML begins with the creation

of scenarios in the form of
• use cases,
• activity diagrams, and
• swimlane diagrams.
 CREATING A PRELIMINARY USE CASE

Use case: Access camera surveillance via the Internet—display camera views (ACS-DCV)
Actor: homeowner
• 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.
CREATING A PRELIMINARY USE CASE
 UML MODELS THAT SUPPLEMENT THE USE CASE

• 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
 SWIMLANE DIAGRAMS

• The UML swimlane diagram is a useful variation of the activity

diagram and allows you to represent the flow of activities
described by the use case and at the same time indicate which or
analysis class has responsibility for the action described by an
activity rectangle.
• The activity diagram is rearranged so that activities associated
with a particular analysis class fall inside the swimlane for that
class.
 DATA MODELING CONCEPTS

• If software requirements include the need to create, extend, or

interface with a database or if complex data structures must be
constructed and manipulated, the software team may choose to
create a data model as part of overall requirements modeling.
• A software engineer or analyst defines all data objects that are
processed within the system, the relationships between the
data objects, and other information that is pertinent to the
relationships
 DATA OBJECTS

• A data object is a representation of composite information

that must be understood by software.
• By composite information,--that has a number of different
properties or attributes.
• Ex-- width (a single value) would not be a valid data object,
but dimensions (incorporating height, width, and depth)
could be defined as an object.
• A data object 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).
• For example, a person or a car can be viewed as a data object in the sense that
either can be defined in terms of a set of attributes.

• The description of the data object incorporates the data object and all of its
attributes
 DATA ATTRIBUTES

• Data attributes define the properties of a data object and take on one
of three different characteristics.
• They can be used to
• (1) name an instance of the data object,
• (2) describe the instance, or
• (3) make reference to another instance in another table.
• In addition, one or more of the attributes must be defined as an
identifier
 RELATIONSHIPS

• Data objects are connected to one another in different ways

 CLASS-BASED MODELING

• Class-based modeling represents the objects that the system will

manipulate, the operations (also called methods or services) that
will be applied to the objects to effect the manipulation,
relationships (some hierarchical) between the objects, and the
collaborations that occur between the classes that are defined.

• The elements of a class-based model include classes and objects,

attributes, operations, class responsibility- collaborator (CRC)
models, collaboration diagrams, and packages.
 IDENTIFYING 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 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.
 I D E N T I F Y I N G A N A LY S I S C L A S S E S

• 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.
• Coad and Yourdon suggest six selection characteristics that should be
used as you consider each potential class for inclusion in the analysis
model:
• 1. Retained information. The potential class will be useful during
analysis only if information about it must be remembered so that the
system can function.
• 2. Needed services. The potential class must have a set of identifiable
operations that can change the value of its attributes in some way.
• 3.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.

• 4. Common attributes. A set of attributes can be defined for the potential class and these
attributes apply to all instances of the class.

• 5. Common operations. A set of operations can be defined for the potential class and these
operations apply to all instances of the class.

• 6. 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
SPECIFYING ATTRIBUTES

• Attributes describe a class that has been selected for

inclusion in the requirements model.
• In essence, it is the attributes that define the class—
that clarify what is meant by the class in the context of
the problem space.
 D E F I N I N G O P E R AT I O N S

• Operations define the behavior of an object. Although many different types of

operations exist, they can generally 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 occurrence of a controlling event.
 CL AS S - R ES P O NS IBI LI TY - COLL A BOR ATOR ( CRC) M O D EL I NG

• Class-responsibility-collaborator (CRC) modeling provides a simple means

for identifying and organizing the classes that are relevant to system or
product requirements.
• A CRC model is really a collection of standard index cards that represent
classes
• Responsibilities are the attributes and operations that are relevant for the
class.
• Collaborators are those classes that are required to provide a class with the
information needed to complete a responsibility.
• 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.
• Classes.
• Entity classes, also called model or business classes, are
extracted directly from the statement of the problem.

• Boundary classes are used to create the interface

• Controller classes manage a “unit of work” from start to finish.

• That is, controller classes can be designed to manage
• (1) the creation or update of entity objects,
• (2) the instantiation of boundary objects as they obtain information from
entity objects,
• (3) complex communication between sets of objects,
• (4) validation of data communicated between objects or between the user
and the application.
• Responsibilities. five guidelines for allocating responsibilities to classes.

1. System intelligence should be distributed across classes to best address the

needs of the problem.
2. Each responsibility should be stated as generally as possible.
3. Information and the behavior related to it should reside within the same
class.
4. Information about one thing should be localized with a single class, not
distributed across multiple classes.
5. Responsibilities should be shared among related classes, when appropriate.
Collaborations. Classes fulfill their responsibilities in one of two
ways:
• (1) A class can use its own operations to manipulate its own
attributes, thereby fulfilling a particular responsibility, or

• (2) a class can collaborate with other classes.

• Collaborations are identified by determining whether a class can
fulfill each responsibility itself. If it cannot, then it needs to interact
with another class.
• In all cases, the collaborator class name is recorded on the CRC model index
card next to the responsibility that has spawned the collaboration. Therefore,
the index card contains a list of responsibilities and the corresponding
collaborations that enable the responsibilities to be fulfilled.
• When a complete CRC model has been developed, stakeholders can review the
model using the following approach.
• 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. For example, a use case for SafeHome contains the following narrative:
• The homeowner observes the SafeHome control panel to determine if the system is
ready for input. If the system is not ready, the homeowner must physically close
• that a sensor is open, i.e., that a door or window is open.] When the review leader comes to
“control panel,” in the use case narrative, the token is passed to the person holding the
ControlPanel index card. The phrase “implies that a sensor is open” requires that the index
card contains a responsibility that will validate this implication (the responsibility
determinesensor- status() accomplishes this). Next to the responsibility on the index card is the
collaborator Sensor. The token is then passed to the Sensor object.
• 4. When the token is passed, the holder of the Sensor 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.
• 5. 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.
 A S S O C IAT ION S A N D D E P E N D E N C I E S

• In many instances, two analysis classes are related to one another in some fashion,
much like two data objects may be related to one another.
• In UML these relationships are called associations. In some cases, an association may
be further defined by indicating multiplicity.
• Ex- Wall object is constructed from one or more WallSegment objects. In addition,
the Wall object may contain 0 or more Window objects and 0 or more Door objects.
• These multiplicity constraints are illustrated in Figure 6.13, where “one or more” is
represented using 1. .*, and “0 or more” by 0 . .*.
• In UML, the asterisk indicates an unlimited upper bound on the range.
• The relationship between these two objects is not a simple association, yet a dependency
association does exist. In a use case written for surveillance (not shown), you learn that a
special password must be provided in order to view specific camera locations. One way
to achieve this is to have Camera request a password and then grant permission to the
DisplayWindow to produce the video display. This can be represented as shown in
Figure 6.14 where <<access>> implies that the use of the camera output is controlled by a
special password.
 ANALYSIS PACKAGES

• An important part of analysis modeling is categorization.

• That is, various elements of the analysis model (e.g., use

cases, analysis classes) are categorized in a manner that
packages them as a grouping—called an analysis
package—that is given a representative name.
END OF CH-6 M2