UNIT – 3

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

Overall Objectives and Philosophy: Throughout requirements modeling, your primary focus is on what,
not how. 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 This relationship is illustrated in Figure 6.1
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. “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. 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. 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: The analysis patterns often reoccur across many applications within a
specific business domain. If these patterns are defined and categorized in a manner that allows
you to recognize and apply them to solve common problems. This improves time-to- market
and reduces development costs.

Domain analysis doesn’t look at a specific application, but rather at the domain in which the
application resides. The intent is to identify common problem solving elements that are
applicable to all applications within the domain. Domain analysis may be viewed as an umbrella
activity for the software process. Figure 6.2 illustrates key inputs and outputs for the domain
analysis process. Sources of domain knowledge are surveyed in an attempt to identify objects
that can be reused across the 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. UML and the
Unified Process are predominantly object oriented.

Each element of the requirements model (Figure 6.3) 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. 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. Analysis modeling leads to the
derivation of each of these modeling elements. However, the specific content of each element
may differ from project to project.
3.2 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: A use case describes a specific usage scenario in
straightforward language from the point of view of a defined actor. But how do you know (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?

What to write about? The first two requirements engineering tasks—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. You can obtain these from a list of required system functions, through conversations with
stakeholders, or by an evaluation of activity diagrams developed as part of requirements
modeling.

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.
• 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 it be?
• Is it possible that the actor will encounter some other behavior at this point. If so, what 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.
Can the actor take some other action at this point? The answer is “yes.”
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.
Is it possible that the actor will encounter some other behavior at this point? Again the answer to
the question is “yes.”
In addition to the three generic questions suggested, 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?
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.

3.3 UML MODELS THAT SUPPLEMENT THE USE CASE

A broad array of UML graphical models are as follows

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
and solid horizontal lines to indicate that parallel activities are occurring. An activity diagram for
the ACS-DCV use case is shown in Figure 6.5.

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 actor or analysis class has responsibility for the action described by an activity
rectangle. Responsibilities are represented as parallel segments that divide the diagram vertically,
like the lanes in a swimming pool. Refer Figure 6.6.
 3.4 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. The entity-relationship
diagram (ERD) addresses these issues and represents all data objects that are entered, stored,
transformed, and produced within an application.
Data Objects: A data object is a representation of composite information that must be understood
by software. Therefore, 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). 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.

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—that is, the identifier attribute becomes
a “key” when we want to find an instance of the data object. In some cases, values for the
identifier(s) are unique, although this is not a requirement.

Relationships: Data objects are connected to one another in different ways. Consider the two data
objects, person and car. These objects can be represented using the simple notation illustrated in
Figure 6.8a. A connection is established between person and car because the two objects are
related. But what are the relationships? To determine the answer, you should understand the role
of people (owners, in this case) and cars within the context of the software to be built. You can
establish a set of object/relationship pairs that define the relevant relationships. For example,
• A person owns a car.
• A person is insured to drive a car.

The relationships own and insured to drive define the relevant connections between person and
car. Figure 6.8b illustrates these object-relationship pairs graphically. The arrows noted in Figure
6.8b provide important information about the directionality of the relationship and often reduce
ambiguity or misinterpretations.

3.5 CLASS-BASED MODELING

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

Classes are determined by underlining each noun or noun phrase and entering it into a simple
table. 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.
Analysis classes manifest themselves in one of the following ways:
• External entities 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.

specifying Attributes: Attributes are the set of data objects that fully define the class within the
context of the problem. 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. (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. 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.
As a first iteration at deriving a set of operations for an analysis class, you can again study a
processing narrative (or use case) and select those operations that reasonably belong to the
class. To accomplish this, the grammatical parse is again studied and verbs are isolated. Some
of these verbs will be legitimate operations and can be easily connected to a specific class.

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.

One purpose of CRC cards is to fail early, to fail often, and to fail inexpensively. It is a lot
cheaper to tear up a bunch of cards than it would be to reorganize a large amount of source
code.

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.

In reality, 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. Stated simply, 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, collaboration implies either a request for information or a request for some action.
A simple CRC index card for the Floor Plan class is illustrated in Figure 6.11. The list of
responsibilities shown on the CRC card is preliminary and subject to additions or modification.
The classes Wall and Camera are noted next to the responsibility that will require their
collaboration.

Classes. Basic guidelines for identifying classes and objects were presented earlier in this
chapter. The taxonomy of class types presented in Section 6.5.1 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 (e.g., interactive screen or printed reports)
that the user sees and interacts with as the software is used. Entity objects contain information
That is important to users, but they do not display themselves. 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. The 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. This intelligence can be distributed acrosss classes in a
umber of different ways. “Dumb” classes can be modeled to act as servants to a few “smart”
classes.
To determine whether system intelligence is properly distributed, the responsibilities noted on
each CRC model index card should be evaluated to determine if any class has an extraordinarily
long list of responsibilities. Example is aggregation of classes.
2. Each responsibility should be stated as generally as possible. This guideline implies that
general responsibilities (both attributes and operations) 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.
To help in the identification of collaborators, you can examine three different generic
relationships between classes (1) the is-part-of relationship, (2) the has-knowledge-of
relationship, and (3) the depends-upon relationship.

When a complete CRC model has been developed, stakeholders can review the model using
the following approach
1. All participants in the review are given a subset of the CRC model index cards. Cards that
collaborate should be separated
2. All use-case scenarios (corresponding use-case diagrams) should be organized into
categories.
3. The review leader reads the use case deliberately.
4. When the token is passed, the holder of the Sensor card is asked to describe the
responsibilities noted on the card.
5. If the responsibilities and collaborations noted on the index cards cannot accommodate the
use case, modifications are made to the cards.

This continues until the use case is finished. When all use cases have been reviewed,
requirements modeling continue.
 Associations and Dependencies: 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. Referring to
The 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.

Analysis Packages: An important part of analysis modeling is categorization. That is,

various elements of the analysis model are categorized in a manner that packages them as
a grouping—called an analysis package—that is given a representative name.

For example, Classes such as Tree, Landscape, Road, Wall, Bridge, Building, and VisualEffect
might fall within this category. Others focus on the characters within the game, describing their
physical features, actions, and constraints.
These classes can be grouped in analysis packages as shown in Figure 6.15. 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.
 Although they are not shown in the figure, other symbols can precede an element within a
package. 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.

3.6 Requirements Modeling

The requirements model has many different dimensions. Flow oriented models, behavioral
models, and the special requirements analysis considerations that come into play when WebApps
are developed. Each of these modeling representations supplements the use cases, data models,
and class based models.

3.7 FLOW-ORIENTED MODELING

Although the data flow diagram (DFD) and related diagrams and information are not a formal
part of UML, they can be used to complement UML diagrams and provide additional insight into
system requirements and flow.
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
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.
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.

A few simple guidelines 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,2 and
(6) One bubble at a time should be refined. There is a natural tendency to overcomplicate the
data flow diagram. This occurs when you attempt to show too much detail too early or represent
procedural aspects of the software in lieu of information flow.

Creating a Control Flow Model: For some types of applications, the data model and the data flow
diagram are all that is necessary to obtain meaningful insight into software requirements. However, 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 to data flow modeling.
 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

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.
Figure 7.4 depicts a preliminary state diagram for the level 1 control flow model for SafeHome.
The Process Specification: The PSPEC is a “minispecification” for each transform at the lowest refined
level of a DFD. 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) description of the process algorithm, mathematical equations,
tables, or UML activity diagrams.
 3.8 CREATING A BEHAVIORAL MODEL

We can represent the behavior of the system as a function of specific events and time.
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: 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.

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 or recognizing events that
have occurred elsewhere.
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. 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. Two different behavioral representations are discussed in the paragraphs that
follow.
1) The first indicates how an individual class changes state based on external events
2) 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 Control Panel object in the Safe Home 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.
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. Figure 7.7 illustrates a partial sequence
diagram for the Safe Home security function.
 3.9 PATTERNS FOR REQUIREMENTS MODELING

Software patterns are a mechanism for capturing domain knowledge in a way 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.

Once the pattern has been discovered, it is documented by describing “explicitly the general
problem to which the pattern is applicable, the prescribed solution, assumptions and constraints
of using the pattern in practice, and often some other information about the pattern, such as the
motivation and driving forces for using the pattern, discussion of the pattern’s advantages and
disadvantages, and references to some known examples of using that pattern in practical
applications”.

The pattern can be reused when performing requirements modeling for an application within a
domain. 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. A semantic
analysis pattern (SAP) “is a pattern that describes a small set of coherent use cases that
together describe a basic generic application”.

Consider the following preliminary use case for software required to control and
monitor a real-view camera and proximity sensor for an automobile:
Use case: Monitor reverse motion
Description: When the vehicle is placed in reverse gear, the control software enables a
video feed from a rear-placed video camera to the dashboard display.

This use case implies a variety of functionality that would be refined and elaborated during
requirements gathering and modeling.

A Requirements Pattern Example: Actuator-Sensor One of the requirements of the SafeHome security
function is the ability to monitory security sensors.
Pattern Name. Actuator-Sensor
Intent. Specify various kinds of sensors and actuators in an embedded system.
Motivation. Embedded systems usually have various kinds of sensors and actuators. These
sensors and actuators are all either directly or indirectly connected to a control unit.
Constraints
• Each passive sensor must have some method to read sensor input and attributes that
represent the sensor value.
• Each active sensor must have capabilities to broadcast update messages when its value
changes.
• Each active sensor should send a life tick, a status message issued within a specified time
frame, to detect malfunctions.
Applicability. Useful in any system in which multiple sensors and actuators are present.
Structure. A UML class diagram for the Actuator-Sensor pattern is shown in Figure 7.8.

Behavior. Figure 7.9 presents a UML sequence diagram for an example of the Actuator-Sensor
pattern as it might be applied for the SafeHome function that controls the positioning (e.g., pan,
zoom) of a security camera.
Participants. Patterns description “itemizes the classes/objects that are included in the
requirements pattern” and describes the responsibilities of each class/object (Figure 7.8). An
abbreviated list follows:
• Passive Sensor abstract: Defines an interface for passive sensors.
• PassiveBooleanSensor: Defines passive Boolean sensors.
• PassiveIntegerSensor: Defines passive integer sensors.
Collaborations. This describes how objects and classes interact with one another and how each
carries out its responsibilities.
• When the Computing Component needs to update the value of a Passive Sensor, it queries the
sensors, requesting the value by sending the appropriate message.
Consequences
1. Sensor and actuator classes have a common interface.
2. Class attributes can only be accessed through messages, and the class decides whether or
not to accept the message. For example, if a value of an actuator is set above a maximum
value, then the actuator class may not accept the message, or it might use a default maximum
value.
3. The complexity of the system is potentially reduced because of the uniformity of interfaces for
actuators and sensors.

3.10REQUIREMENTS MODELING FOR WEBAPPS

The Web development process must be agile, and analysis is time consuming
How Much Analysis Is Enough?: The degree to which requirements modeling for WebApps are
emphasized depends on the following factors:
• Size and complexity of WebApp increment.
• Number of stakeholders
• Size of the WebApp team.
• Degree to which members of the WebApp team have worked together before
• Degree to which the organization’s success is directly dependent on the success of the
WebApp.

Requirements Modeling Input: An agile version of the generic software process can be applied
when WebApps are engineered. The process incorporates a communication activity that
 Identifies stakeholders and user categories, the business context, defined informational and
applicative goals, general WebApp requirements, and usage scenarios—information that
becomes input to requirements modeling. This information is represented in the form of natural
language descriptions, rough outlines, sketches, and other informal representations.

To summarize, the inputs to the requirements model will be the information collected during the
communication activity—anything from an informal e-mail to a detailed project brief complete
with comprehensive usage scenarios and product specifications.

Requirements Modeling Output: Requirements analysis provides a disciplined mechanism for

representing and evaluating WebApp content and function. While the specific models depend largely
upon 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
WebApp.
Content can be developed prior to the implementation of the WebApp, while the WebApp is
being built, or long after the WebApp is operational. In every case, it is incorporated via
navigational reference into the overall WebApp structure. 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. In other words, a content object is any item of
cohesive information that is to be presented to an end user. Content objects can be determined
directly from use cases by examining the scenario description for direct and indirect references
to content. Refer to figure 7.10 for content modeling.
 A data tree can be created for any content that is composed of multiple content objects and data
items. The data tree is developed in an effort to define hierarchical relationships among content
objects and to provide a means for reviewing content so that omissions and inconsistencies are
uncovered before design commences. In addition, the data tree serves as the basis for content
design.

Interaction Model for WebApps: The vast majority of WebApps enable a “conversation” between an end
user and application functionality, content, and behavior. This conversation can be described using an
interaction model that can be composed of one or more of the following elements: (1) use cases, (2)
sequence diagrams, (3) state diagrams,16 and/or (4) user interface prototypes.
In many instances, a set of use cases is sufficient to describe the interaction at an analysis level.
However, when the sequence of interaction is complex and involves multiple analysis classes or
many tasks, it is sometimes worthwhile to depict it using a more rigorous diagrammatic form.
Because WebApp construction tools are plentiful, relatively inexpensive, and functionally
powerful, it is best to create the interface prototype using such tools.

Functional Model for WebApps: Many WebApps deliver a broad array of computational and
manipulative functions that can be associated directly with content and that are often a major goal of
user-WebApp interaction. For this reason, functional requirements must be analyzed, and when
necessary, modeled.

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. These functions may actually be implemented using operations within analysis
classes, but from the point of view of the end user, the function is the visible outcome.
At a lower level of procedural abstraction, the requirements model describes the processing to
be performed by analysis class operations. These operations manipulate class attributes and are
involved as classes collaborate with one another to accomplish some required behavior.

Regardless of the level of procedural abstraction, the UML activity diagram can be used to
represent processing details.

Configuration Models for WebApps: In some cases, 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 (e.g., distributing load among multiple servers, caching architectures, remote
databases, multiple servers serving various objects on the same Web page) 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 to another. The following questions should be considered:
• Should certain elements be easier to reach (require fewer navigation steps) 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?