REQUIREMENTS MODELING

REQUIREMENTS ANALYSIS

Requirements analysis results in the specification of software’s operational characteristics,

indicates software’s interface with other system elements, and establishes constraints that
software must meet. 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:
• 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
provides the developer and the customer with the means to assess quality once software is
built.
Throughout requirements modeling, 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?
 Fig : The requirements model as a bridge between the system description and the design model

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.
Analysis Rules of Thumb
Arlow and Neustadt suggest a 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.
• 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.
That is, a database may be required, but the classes necessary to implement it, the
functions required to access it, and the behavior that will be exhibited as it is used
should be considered only after problem domain analysis has been completed.

• Minimize coupling throughout the system. It is important to represent relationships

between classes and functions. However, if the level of “interconnectedness” is
extremely high, effort should be made to reduce it.
• Be certain that the requirements model provides value to all stakeholders. Each
 constituency has its own use for the model
• 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.

Requirements Modelling Principles

1. The information domain of a problem must be represented and understood.

2. The functions that the software performs must be defined.

3. The behavior of the software (as a consequence of external events) must be
represented.
4. The models that depict information, function, and behavior must be partitioned
in a manner that uncovers detail in a layered (or hierarchical) fashion.
5. The analysis task should move from essential information toward
implementation detail.

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.
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.
Each element of the requirements model is represented in following figure presents
the problem from a different point of view.
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.
 Fig : Elements of the analysis model

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
Scenario-based elements depict how the user interacts with the system and the
specific sequence of activities that occur as the software is used.
Creating a Preliminary Use Case
Alistair Cockburn characterizes a use case as a “contract for behavior”, the “contract”
defines the way in which an actor uses a computer-based system to accomplish some goal. In
essence, a use case captures the interactions that occur between producers and consumers of
information and the system itself.
A use case describes a specific usage scenario in straightforward language from the point of
view of a defined actor. These are the questions that must be answered if use cases are to
provide value as a requirements modeling tool.
(1) what to write about,
(2) how much to write about it,
(3) how detailed to make your description, and
(4) how to organize the description?
To begin developing a set of use cases, list the functions or activities performed by a
specific actor.
 Safe Home Example
Identifies the following functions 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.

SafeHome Example: ACS-DCV functions

 Access camera surveillance via the Internet – display camera views

 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.

 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.

Refining a Preliminary Use Case

Each step in the primary scenario is evaluated by asking the following questions:
• 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?

Answers to these questions result in the creation of a set of secondary scenarios that are
part of the original use case but represent alternative behavior.
SafeHome Example :
 Consider steps 6-7:
 6. The homeowner selects “pick a camera.”
 7. The system displays the floor plan of the house.
1) Can the actor take some other action at this point?
• The answer is “yes.” the actor may choose to view thumbnail snapshots of all cameras
simultaneously.
- One secondary scenario might be “View thumbnail snapshots for all cameras.”
2) Is it possible that the actor will encounter some error condition at this point?
 Any number of error conditions can occur as a computer- based system
operates.
 The answer is “yes.”
 A floor plan with camera icons may have never been configured.
 selecting “pick a camera” results in an error condition: “No floor plan
 configured for this house.”- a secondary scenario.
3) Is it possible that the actor will encounter some other behavior at this point?
 The answer is “yes.”
 the system may encounter an alarm condition.
 This would result in the system displaying a special alarm notification (type,
location, system action) and providing the actor with a number of options
relevant to the nature of the alarm.
 It will not become part of the ACS-DCV use case.
 Rather, a separate use case—Alarm condition encountered—would be
developed and referenced from other use cases as required.

Use-case exception
 Exception: Describes a situation (either a failure condition or an alternative chosen by
the actor) that causes the system to exhibit somewhat different behavior.

Cockburn recommends using a “brainstorming” session to derive a reasonably complete set

of exceptions for each use case. 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.

Writing a Formal Use Case

 The informal use cases presented are sometimes sufficient for requirements modeling.
 However, when a use case involves a critical activity or describes a complex set of steps
with a significant number of exceptions, a more formal approach may be desirable.
The typical outline for formal use cases can be in following manner
• 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”
• 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 headings may or may not be included and are reasonably self-explanatory.
Every modeling notation has limitations, and the use case is no exception. A use case focuses
on functional and behavioral requirements and is generally inappropriate for nonfunctional
requirements.
Simple Use Case Diagram

CLASS-BASED MODELLING

Class-based modeling represents 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. 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
We can begin to identify classes by examining the usage scenarios developed as
part of the requirements model and performing a “grammatical parse” on the use cases
developed for the system to be built.

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.
• 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.
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.
Defining Operations
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.

Fig : Class diagram for the system class

Associations and Dependencies

An association defines a relationship between classes. An association may be
further defined by indicating multiplicity. Multiplicity defines how many of one class
are related to how many of another class.

Fig : Multiplicity

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. Dependencies are defined by a stereotype. A stereotype is an
“extensibility mechanism” within UML that allows you to define a special modeling
element whose semantics are custom defined. In UML. Stereotypes are represented in
double angle brackets (e.g., <<stereotype>>).

Fig : Dependencies

Class-Responsibility-Collaborator (CRC) Modeling

Class-responsibility-collaborator (CRC) modeling provides a simple means for
identifying and organizing the classes that are relevant to system or product
requirements.
Ambler 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.
The CRC model may make use of actual or virtual index cards. The intent is to develop
an organized representation of classes. Responsibilities are the attributes and operations
that are relevant for the class. i.e., a responsibility is “anything the class knows or does”
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. A simple CRC index card is illustrated in
following figure.

Fig : A CRC model index card

Classes: The taxonomy of class types can be extended by considering the following
categories:
• Entity classes, also called model or business classes, are extracted directly from
the statement of the problem. These classes typically represent things that are to
be stored in a database and persist throughout the duration of the application.

• Boundary classes are used to create the interface that the user sees and interacts
with as the software is used. Boundary classes are designed with the
responsibility of managing the way entity objects are represented to users.
• 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. In general, controller classes are not considered until the design
activity has begun.
Responsibilities: Wirfs-Brock and her colleagues suggest five guidelines for
allocating responsibilities to classes:
1. System intelligence should be distributed across classes to best address the
needs of the problem. Every application encompasses a certain degree of
intelligence; that is, what the system knows and what it can do.
2. Each responsibility should be stated as generally as possible. This
guideline implies that general responsibilities should reside high in the class
hierarchy
3. Information and the behavior related to it should reside within the same
class. This achieves the object-oriented principle called encapsulation. Data
 and the processes that manipulate the data should be packaged as a cohesive
unit.
4. Information about one thing should be localized with a single class, not
distributed across multiple classes. A single class should take on the
responsibility for storing and manipulating a specific type of information. This
responsibility should not, in general, be shared across a number of classes. If
information is distributed, software becomes more difficult to maintain and more
challenging to test.
5. Responsibilities should be shared among related classes, when appropriate.
There are many cases in which a variety of related objects must all exhibit the same
behavior at the same time.
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.
When a complete CRC model has been developed, stakeholders can review the
model using the following approach :
1. 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).
2. All use-case scenarios (and corresponding use-case diagrams) should be
organized into categories.
3. 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.
4. When the token is passed, the holder of the 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.
 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.

Functional Modelling
The functional model addresses two application processing elements, each
representing a different level of procedural abstraction:

 (1) user-observable functionality that is delivered by the app to end users, and
 (2) the operations contained within analysis classes that implement behaviors
associated with the class.

User-observable functionality encompasses any processing functions that are

initiated directly by the user. For example, a financial mobile app might
implement a variety of financial functions (e.g., computation of mortgage
payment).

A Procedural View

 UML activity diagram can be used to represent processing details.

 Activity diagram supplements the use case by providing a graphical
representation of the flow of interaction within a specific scenario.
 The 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, and solid horizontal lines to indicate that parallel
activities are occurring.
Swimlane Diagrams

Allows the modeler to represent the flow of activities described by the use-
case and at the same time indicate which actor (if there are multiple actors
involved in a specific use-case) or analysis class has responsibility for the
action described by an activity rectangle.
Three analysis classes—Homeowner, Camera, and Interface—have direct or
indirect responsibilities in the context of the activity diagram
 UML Sequence Diagrams

 UML sequence diagram can be used for behavioral modeling.

 Sequence diagrams can also be used to show how events cause transitions from
object to object.
 Once events have been identified by examining a use case, the modeler creates
a sequence diagram—a representation of how events cause flow from one
object to another as a function of time.
 Sequence diagram (partial) for the SafeHome security
function

 Each of the arrows represents an event (derived from a use case) and indicates
how the event channels behavior between SafeHome objects.
 Time is measured vertically (downward), and the narrow vertical rectangles
represent time spent in processing an activity. States may be shown along a
vertical time line.
 The first event, system ready, is derived from the external environment and
channels behavior to the Homeowner object.
 Once a complete sequence diagram has been developed, all the events that
cause transitions between system objects can be collated into a set of input
events and output events (from an object).
 Behavioral Modeling
 The behavioral model indicates how software will respond to internal or
external events .
 UML activity diagrams can be used to model how system elements
 respond to internal events. UML state diagrams can be used to model how
system elements respond to external events.
 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.

Identifying Events with the Use Case

 An event occurs whenever the system and an actor exchange information.
Consider the use case for a portion of the SafeHome security function.
The homeowner uses the keypad to key in a four-digit password.
The password is compared with the valid password stored in the system. If
the password is incorrect, the control panel will beep once and reset itself for
additional input. If the password is correct, the control panel awaits further
action.
The underlined portions of the use case scenario indicate events. An
actor should be identified for each event; the information that is exchanged
should be noted, and any conditions or constraints should be listed.
Once all events have been identified, they are allocated to the
objects involved. Objects can be responsible for generating events (e.g.,
Homeowner generates the password entered event) or recognizing events
that have occurred elsewhere (e.g.,ControlPanel recognizes the binary result
of the password compared event).

UML State Diagrams

 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:
 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.
 An event (sometimes called a trigger) must occur to force an object to
make a transition from one active state to another.

The States of a System

 state—a set of observable circum-stances 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

State Diagram for the ControlPanel Class

An action occurs concurrently with the state transition or because

of it and generally involves one or more operations
 (responsibilities) of the object.
For example, the action connected to the password entered
event is an operation named validatePassword() that accesses a
password object and performs a digit-by-digit comparison to
validate the entered password.

Behavioral Modeling

1. make a list of the different states of a system (How does the system behave?)
2. indicate how the system makes a transition from one state to another (How
does the system change state?)
a. indicate event
b. indicate action
3. draw a state diagram or a sequence diagram or activity diagram