PSCMRCET, VIJAYAWADA IICSE- ISEM

UNIT-III
Chapter7: Requirements Modeling (Flow, Behavior, Patterns and WEBAPPS): Requirements
Modeling Strategies, Flow-Oriented Modeling, Creating a Behavioral Model, Patterns for
Requirements Modeling, Requirements Modeling for WebApps.
Text Book:
RogerS.Pressman,“SoftwareEngineering–APractitioner’sApproach”,TataMcgraw-Hill International
Edition, 7th Edition, 2010.

Requirements Modeling (Flow, Behavior, Patterns and WEBAPPS)

REQUIREMENTSMODELINGSTRATEGIES

One view of requirements modeling, called structured analysis,. 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 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.

4. FLOW-ORIENTEDMODELING

Flow-oriented modeling is perceived as an outdated technique by some software

engineers, it continues to be one of the most widely used requirements analysis notations in use
today. The data flow diagram (DFD) is the representation of Flow-oriented modeling. The
purpose of data flow diagrams is to provide a semantic bridge between users and systems
developers.”
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 labeled arrows, and transformations are represented by
circles (also called bubbles). The DFD is presented in a hierarchical fashion. That is, the first
dataflow model (sometimes called a level0DFDorcontextdiagram)represents the system as a
whole. Subsequent data flow diagrams refine the context diagram, providing increasing detail
with each subsequent level.

Software Engineering (R20) 1

PSCMRCET, VIJAYAWADA IICSE- ISEM

Fig: Context-level DFD for the Safe Home security function 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 level0dataflowdiagramshoulddepictthesoftware/systemasasinglebubble;
(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 meaning full names;
(5) Informationflowcontinuitymustbemaintainedfromleveltolevel,2and
(6) One bubble at a time should be refined. There is a natural tendency to overcomplicate
the data flow diagram.
A level 0 DFD for the security function is shown in above figure. 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 level0 DFD must now be expanded into a level1 data flow model. you should apply a
“grammatical parse” to the use case narrative that describes the context-level bubble. That is,
isolate all nouns (and noun phrases) and verbs (and verb phrases). The grammatical parse is not

Software Engineering (R20) 2

PSCMRCET, VIJAYAWADA IICSE- ISEM

Fool proof, but it can provide you with an excellent jump start, if you’re struggling to define
data objects and the transforms that operate on them.
The processes represented at DFD level 1 can be further refined into lower levels. The
refinement of DFDs continues until each bubble performs a simple function. That is, until the
process represented by the bubble performs a function that would be easily implemented as a
program component. a concept, Cohesion can be used to assess the processing focus of a given
function. i.e refine DFDs until each bubble is “single-minded.”

Fig: Level1 DFD for Safe Home security function

Software Engineering (R20) 3

PSCMRCET, VIJAYAWADA IICSE- ISEM

Fig:Level2DFDthatrefinesthemonitorsensorsprocess Creating a

Control Flow Model

The data model and the data flow diagram are all that is necessary to obtain meaningful
insight into software requirements. The following guidelines are suggested for creating a Control
Flow Model
• 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;

Software Engineering (R20) 4

PSCMRCET, VIJAYAWADA IICSE- ISEM

The Control Specification

A control specification (CSPEC) represents the behavior of the system in
two different ways. The CSPEC contains a state diagram that is a sequential
specification of behavior. It can also contain a program activation table—a
combinatorial specification of behavior. The following figure depicts a preliminary
state diagram for the level 1 control flow model for Safe Home. The diagram
indicates how the system responds to events as it traverses the four states defined at
this level. By reviewing the state diagram, we can determine the behavior of the
system and, more important, ascertain whether there are “holes” in the specified
behavior.
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.

Fig: State diagram for Safe Home security function 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)

Software Engineering (R20) 5

PSCMRCET, VIJAYAWADA IICSE- ISEM

Description of the process algorithm, mathematical equations, tables, or UML activity

diagrams. By providing a PSPEC to accompany each bubble in the flow model, you can
create a “mini-spec” that serves as a guide for design of the software component that will
implement the bubble.

4. CREATINGABEHAVIORALMODEL
The behavioral model indicates how soft ware 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 with in
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
The use case represents a sequence of activities that involves actors and the
system. In general, an event occurs whenever the system and an actor exchange
information. A use case is examined for points of information exchange. To illustrate,
we reconsider the use case for a portion of the Safe Home 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 .
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
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.

Software Engineering (R20) 6

PSCMRCET, VIJAYAWADA IICSE- ISEM
State diagrams for analysis classes. One component of a behavioral model is a UML state diagram that
represents active states for each class and the events (triggers) that cause changes between these active
states. The following figure illustrates a state diagram for the Control Panel object in the SafeHome
security function. Each arrow shown in figure 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

Fig: State diagram for the Control Panel class 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 shorthand version of
the use case. It represents key classes and the events that cause behavior to flow
from class to class.

Fig: Sequence diagram(partial) for the SafeHome security function

Software Engineering (R20) 7

PSCMRCET, VIJAYAWADA IICSE- ISEM
PATTERNSFORREQUIREMENTSMODELING

Software patterns are a mechanism for capturing domain knowledge in away that allows it to
be reapplied when a new problem is encountered. In some cases, the domain knowledge is applied
to a new problem within the same application domain. The domain knowledge captured by a
pattern can be applied by analogy to a completely different application domain.
The pattern can be reused when performing requirements modeling for an application within
a domain. Analysis patterns are stored in a repository so that members of the software team can use
search facilities to find and reuse them. Once an appropriate pattern is selected, it is integrated into
the requirements model by reference to the pattern name.
Discovering Analysis Patterns
The requirements model is comprised of a wide variety of elements: scenario-based (use
cases), data-oriented (the data model), class-based, flow- oriented, and behavioral. Each of
these elements examines the problem from a different perspective, and each provides an opportunity
to discover patterns that may occur throughout an application domain, or by analogy, across
different application domains.
The most basic element in the description of a requirements model is the use case. Use cases may
serve as the basis for discovering one or more analysis patterns.
A semantic analysis pattern (SAP) “is a pattern that describes a small set of coherent use
cases that together describe a basic generic application”

REQUIREMENTSMODELINGFORWEBAPPS

Requirements analysis does take time, but solving the wrong problem takes even more
time.
How Much Analysis Is Enough?
The degree to which requirements modeling for Web Apps is emphasized depends
on the following factors:
• Size and complexity of WebApp increment.
• Number of stake holders
• Size of the WebApp team.
• Degree to which members of the WebApp team have worked together
• Degree to which the organization’s success is directly dependent on the
success of the design of a specific part of the WebApp.
It only demands an analysis of those requirements that affect only that part
of the WebApp.
Requirements Modeling Input
The requirements model provides a detailed indication of the true structure
of the problem and provides insight into the shape of the solution. Requirements
analysis refines this understanding by providing additional interpretation. As the
problem structure is delineated as part of the requirements model.

Software Engineering (R20) 8

PSCMRCET, VIJAYAWADA IICSE- ISEM
Requirements Modeling Output
Requirements analysis provides a disciplined mechanism for representing and evaluating
WebApp content and function, the modes of interaction that users will encounter, and the
environment and infrastructure in which the WebApp resides. Each of these characteristics can be
represented as a set of models that allow the WebApp requirements to be analyzed in a structured
manner. While the specific models depend largely up on the nature of the WebApp,
there are five main classes of models:
• Content model—identifies the full spectrum of content to be provided by
the WebApp. Content includes text, graphics and images, video, and audio
data.
• Interaction model—describes the manner in which users interact with the
WebApp.
• Functional model—defines the operations that will be applied to WebApp
content and describes other processing functions that are independent of
content but necessary to the end user.
• Navigation model—defines the overall navigation strategy for the WebApp.
• Configuration model—describes the environment and infrastructure in
which the WebApp resides.

Content Model for WebApps

The content model contains structural elements that provide an important view of content
requirements for a WebApp. These structural elements encompass content objects and all analysis
classes, user-visible entities that are created or manipulated as a user interacts with the Content can
be developed prior to the implementation of the WebApp, while the WebApp is being built, or long
after the WebApp is operational.
A content object might be a textual description of a product, an article describing a news
event, an action photograph taken at a sporting event, a user’s response on a discussion forum, an
animated representation of a corporate logo, a short video of a speech, or an audio overlay for a
collection of presentation slides. The content objects might be stored as separate files, embedded
directly into Web pages, or obtained dynamically from a database. Content objects can be
determined directly from use cases by examining the scenario description for direct and indirect
references to content. The content model must be capable of describing the content object
Component.
Interaction Model for WebApps
Interaction model that can be composed of one or more of the following
elements:
(1) Use cases
(2) Sequence diagrams
(3) State diagrams
(4) User interface prototypes.

Software Engineering (R20) 9

PSCMRCET, VIJAYAWADA IICSE- ISEM
Functional Model for WebApps
The functional model addresses two processing elements of the WebApp, each
representing a different level of procedural abstraction:
(1) user-observable functionality that is delivered by the WebApp 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.
Configuration Models for WebApps
The configuration model is nothing more than a list of server-side and client- side
attributes. However, for more complex WebApps, a variety of configuration complexities may
have an impact on analysis and design. The UML deployment diagram can be used in situations
in which complex configuration architectures must be considered.
Navigation Modeling
Navigation modeling considers how each user category will navigate from one WebApp element
(e.g., content object)to another. The mechanics of navigation are defined as part of design. At this stage,
you should focus on overall navigation requirements. The following questions should be considered:

• Should certain elements be easier to reach than others? What is the priority for
presentation?

• Should certain elements be emphasized to force users to navigate in their

direction?
• How should navigation errors be handled?
• Should navigation to related groups of elements be given priority over navigation to a
specific element?
• Should navigation be accomplished via links, via search-based access, or
by some other means?
• Should certain elements be presented to users based on the context of previous navigation
actions?
• Should a navigation log be maintained for users?
• Should a full navigation map or menu be available at every point in a user’s
interaction?
• Should navigation design be driven by the most commonly expected user
behaviors or by the perceived importance of the defined WebApp
elements?
• Can a user “store” his previous navigation through the WebApp to
expedite future usage?
• For which user category should optimal navigation be designed?
• How should links external to the WebApp be handled? Overlaying the
existing browser window? As a new browser window? As a separate frame?

Software Engineering (R20) 10