BCS501, SEPM

Chapter 3: Requirement Modeling Strategies

REQUIREMENT MODELING STRATEGIES

One view of requirements modeling, called structured analysis, considers data and the
processes that transform the data as separate entities. Data objects are mod eled 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 modeled, called object-oriented analysis, focuses on the definition
of classes and the manner in which they collaborate with one another to effect customer
requirements. Although the analysis model that we propose 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 com bination of
representations will provide stakeholders with the best model of software requirements and the
most effective bridge to software design.

Flow-Oriented Modeling

The DFD takes an input-process-output view of a system. That is, data objects flow into the
software, are transformed by processing elements, and resultant data objects flow out of the
software. Data objects are represented by labelled arrows, and transformations are represented
by circles (also called bubbles). The DFD is presented in a hierarchical fashion. That is, the
first data flow model (sometimes called a level 0 DFD or context diagram) represents the
system as a whole. Subsequent data flow diagrams refine the context diagram, providing
increasing detail with each subsequent level.

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 1

 BCS501, SEPM

Creating a Data Flow Model

The data flow diagram enables you to develop models of the information domain and functional
domain. As the DFD is refined into greater levels of detail, you perform an implicit functional
decomposition of the system. At the same time, the DFD refinement results in a corresponding
refinement of data as it moves through the processes that embody the application. A few simple
guidelines can aid immeasurably during the derivation of a data flow diagram: (1) the level 0
data flow diagram should depict the software/system as a single bubble; (2) primary input and
output should be carefully noted; (3) refinement should begin by isolating candidate processes,
data objects, and data stores to be represented at the next level; (4) all arrows and bubbles
should be labeled with meaningful names; (5) information flow continuity must be maintained
from level to level and (6) one bubble at a time should be refined.

To illustrate the use of the DFD and related notation, we again consider the SafeHome security
function. A level 0 DFD for the security function is shown in Figure 7.1. The primary external
entities (boxes) produce information for use by the system and consume information generated
by the system. The labeled arrows represent data objects or data object hierarchies. The level
0 DFD must now be expanded into a level 1 data flow model. You should apply a “grammatical
parse” to the use case narrative that describes the context-level bubble. That is, we isolate all
nouns and verbs in a SafeHome processing narrative derived during the first requirements
gathering meeting. Referring to the grammatical parse, verbs are SafeHome processes and can
be represented as bubbles in a subsequent DFD. Nouns are either external entities (boxes), data
or control objects (arrows), or data stores (double lines). The nouns and verbs can be associated
with one another. Therefore, by performing a grammatical parse on the processing narrative
for a bubble at any DFD level, you can generate much useful information about how to proceed
with the refinement to the next level. Using this information, a level 1 DFD is shown in Figure
7.2. The context level process shown in Figure 7.1 has been expanded into six processes
derived from an examination of the grammatical parse. Similarly, the information flow between
processes at level 1 has been derived from the parse. In addition, information flow continuity
is maintained between levels 0 and 1. The processes represented at DFD level 1 can be further
refined into lower levels. For example, the process monitor sensors can be refined into a level
2 DFD as shown in Figure 7.3. Note once again that information flow continuity has been
maintained between levels. The refinement of DFDs continues until each bubble performs a

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 2

 BCS501, SEPM
simple function. That is, until the process represented by the bubble performs a function that
would be easily implemented as a program component.

Creating a Control Flow Model

A large class of applications are “driven” by events rather than data, produce control
information rather than reports or displays, and process information with heavy concern for
time and performance. Such applications require the use of control flow modeling in addition

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 3

 BCS501, SEPM
to data flow modeling. I have already noted that an event or control item is implemented as a
Boolean value (e.g., true or false, on or off, 1 or 0) or a discrete list of conditions (e.g., empty,
jammed, full). To select potential candidate events, the following guidelines are suggested.

✓ List all sensors that are “read” by the software.

✓ List all interrupt conditions.
✓ List all “switches” that are actuated by an operator.
✓ List all data conditions.
✓ Recalling the noun/verb parse that was applied to the processing narrative, review all
“control items” as possible control specification inputs/outputs.
✓ Describe the behavior of a system by identifying its states, identify how each state is
reached, and define the transitions between states.
✓ Focus on possible omissions—a very common error in specifying control.

Among the many events and control items that are part of SafeHome software are sensor event
(i.e., a sensor has been tripped), blink flag (a signal to blink the display), and start/stop switch
(a signal to turn the system on or off).

The Control Specification

A control specification (CSPEC) represents the behavior of the system (at the level from which
it has been referenced) in two different ways.3 The CSPEC contains a state diagram that is a
sequential specification of behavior. It can also contain a pro gram activation table—a
combinatorial specification of behavior. Figure 7.4 depicts a preliminary state diagram4 for the
level 1 control flow model for SafeHome. The diagram indicates how the system responds to
events as it trav erses the four states defined at this level. By reviewing the state diagram, you
can determine the behavior of the system and, more important, ascertain whether there are
“holes” in the specified behavior. For example, the state diagram (Figure 7.4) indicates that the
transitions from the Idle state can occur if the system is reset, activated, or powered off. If the
system is activated (i.e., alarm system is turned on), a transition to the Monitoring SystemStatus
state occurs, display messages are changed as shown, and the pro cess
monitorAndControlSystem is invoked. Two transitions occur out of the
MonitoringSystemStatusstate—(1) when the system is deactivated, a transition oc curs back to
the Idle state; (2) when a sensor is triggered into the ActingOnAlarm state. All transitions and
the content of all states are considered during the review. A somewhat different mode of
behavioral representation is the process activation table. The PAT represents information

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 4

 BCS501, SEPM
contained in the state diagram in the context of processes, not states. That is, the table indicates
which processes (bubbles) in the flow model will be invoked when an event occurs. The PAT
can be used as a guide for a de signer who must build an executive that controls the processes
represented at this level. A PAT for the level 1 flow model of SafeHome software is shown in
Figure 7.5. The CSPEC describes the behavior of the system, but it gives us no information
about the inner working of the processes that are activated as a result of this behavior.

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 5

 BCS501, SEPM

The Process Specification

The process specification (PSPEC) is used to describe all flow model processes that appear at
the final level of refinement. The content of the process specification can include narrative text,
a program design language (PDL) description5 of the process algorithm, mathematical
equations, tables, or UML activity diagrams. By providing PSPEC to accompany each bubble
in the flowmodel, you can create a “mini-spec” that serves as a guide for design of the software
component that will implement the bubble. To illustrate the use of the PSPEC, consider the
process password transform represented in the flow model for SafeHome (Figure 7.2). The
PSPEC for this function might take the form: PSPEC: process password (at control panel). The
process password transform performs password validation at the control panel for the
SafeHome security function. Process password receives a four-digit password from the interact
with user function. The password is first compared to the master password stored within the
system. If the master password matches, is passed to the message and status display function.
If the master password does not match, the four digits are compared to a table of secondary
passwords (these may be assigned to house guests and/or workers who require entry to the
home when the owner is not present). If the password matches an entry within the table, is
passed to the message and status display function. If there is no match, is passed to the message
and status display function. If additional algorithmic detail is desired at this stage, a program
design language representation may also be included as part of the PSPEC.

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 6

 BCS501, SEPM
Creating a Behavioral Model

The behavioral model indicates how software will respond to external events or stimuli. To
create the model, you should perform the following steps:

1. Evaluate all use cases to fully understand the sequence of interaction within the system.

2. Identify events that drive the interaction sequence and understand how these events relate
to specific objects.

3. Create a sequence for each use case.

4. Build a state diagram for the system.

5. Review the behavioral model to verify accuracy and consistency.

Identifying Events with the Use Case

In general, an event occurs whenever the system and an actor exchange information. An event
is not the information that has been exchanged, but rather the fact that information has been
exchanged. A use case is examined for points of information exchange. To illustrate, we
reconsider 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. As an example of a typical event, consider the underlined use case
phrase “home owner uses the keypad to key in a four-digit password.” In the context of the
requirements model, the object, Homeowner,7 transmits an event to the object ControlPanel.
The event might be called password entered. The information

transferred is the four digits that constitute the password, but this is not an essential part of the
behavioral model. It is important to note that some events have an explicit impact on the flow
of control of the use case, while others have no direct impact on the flow of control. For
example, the event password entered does not explicitly change the flow of control of the use
case, but the results of the event password compared (derived from the interaction “password
is compared with the valid password stored in the system”) will have an explicit impact on the
information and control flow of the SafeHome software. Once all events have been identified,

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 7

 BCS501, SEPM
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).

State Representations

In the context of behavioral modeling, two different characterizations of states must be

considered: (1) the state of each class as the system performs its function and (2) 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. For example, the passive state of the class
Player (in the video game application) would include the current position and orientation
attributes of Player as well as other features of Player that are relevant to the game (e.g., an
attribute that indicates magic wishes remaining). The active state of an object indicates the
current status of the object as it undergoes a continuing transformation or processing. The class
Player might have the following active states: moving, at rest, injured, being cured; trapped,
lost, and so forth. An event (sometimes called a trigger) must occur to force an object to make
a transition from one active state to another. Two different behavioral representations are
discussed in the paragraphs that follow. The first indicates how an individual class changes
state based on external events and the second shows the behavior of the software as a function
of time.

State diagrams for analysis classes

One component of a behavioral model is a UML state diagram9 that represents active states
for each class and the events (triggers) that cause changes between these active states. Figure
7.6 illustrates a state diagram for the ControlPanel object in the SafeHome security function.
Each arrow shown in Figure 7.6 represents a transition from one active state of an object to
another. The labels shown for each arrow represent the event that triggers the transition.
Although the active state model provides useful insight into the “life history” of an object, it is
possible to specify additional information to provide more depth in understanding the behavior
of an object. In addition to

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 8

 BCS501, SEPM
specifying the event that causes the transition to occur, you can specify a guard and an action.
A guard is a Boolean condition that must be satisfied in order for the transition to occur. For
example, the guard for the transition from the “reading” state to the “comparing” state in Figure
7.6 can be determined by examining the use case:

if (password input 4 digits) then compare to stored password

In general, the guard for a transition usually depends upon the value of one or more attributes
of an object. In other words, the guard depends on the passive state of the object. An action
occurs concurrently with the state transition or as a consequence of it and generally involves
one or more operations (responsibilities) of the object. For example, the action connected to
the password entered event (Figure 7.6) is an operation named validatePassword() that accesses
a password object and performs a digit-by-digit comparison to validate the entered password.

Sequence diagrams

The second type of behavioral representation, called a sequence diagram in UML, indicates
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. In essence, the sequence diagram
is a short hand version of the use case. It represents key classes and the events that cause

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 9

 BCS501, SEPM
behavior to flow from class to class. Figure 7.7illustrates a partial sequence diagram for the
SafeHomesecurity function. Each of the arrows represents an event (derived from a use case)
and indicates how the event channels behavior between SafeHomeobjects. Time is measured
vertically (downward), and the narrow vertical rectangles represent time spent in pro cessing
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. The homeowner enters a password. A request lookup event is passed
to System, which looks up the password in a simple database and returns a result (found or not
found) to ControlPanel (now in the comparing state). A valid password results in a
password=correct event to System, which activates Sensors with a request activation event.
Ultimately, control is passed back to the homeowner with the activation successful event.

Once a complete sequence diagram has been developed, all of the events that cause transitions
between system objects can be collated into a set of input events and output events (from an
object). This information is useful in the creation of an effective design for the system to be
built.

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 10