Module 2

UNDERSTANDING REQUIREMENTS
2.1 REQUIREMENTS ENGINEERING
The broad spectrum of tasks and techniques that lead to an understanding of requirements is called
requirements engineering. From a software process perspective, requirements engineering is a major software
engineering action that begins during the communication activity and continues into the modeling activity. It
must be adapted to the needs of the process, the project, the product, and the people doing the work.

Requirements engineering builds a bridge to design and construction. Requirements engineeringprovides the
appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility,
negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and
managing the requirements as they are transformed into an operational system. It encompasses seven distinct
tasks: inception, elicitation, elaboration, negotiation, specification, validation, and management.

Inception:
In general, most projects begin when a business need is identified or a potential new market or service is
discovered. Stakeholders from the business community define a business case for the idea, try to identify the
breadth and depth of the market, do a rough feasibility analysis, and identify a working description of the
project’s scope.
At project inception, you establish a basic understanding of the problem, the people who want asolution, the
nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration
between the other stakeholders and the software team.

Elicitation:
Ask the customer, what the objectives for the system or product are, what is to be accomplished, how the
system or product fits into the needs of the business, and finally, how thesystem or product is to be used on a
day-to-day basis. A number of problems that are encountered as elicitation occurs.
• Problems of scope. The boundary of the system is ill-defined or the customers/users specifyunnecessary
technical detail that may confuse, rather than clarify, overall system objectives.
• Problems of understanding. The customers/users are not completely sure of what is needed, have a poor
understanding of the capabilities and limitations of their computing environment, don’t have a full
understanding of the problem domain, have trouble communicating needs to thesystem engineer, omit
information that is believed to be “obvious,” specify requirements that conflict with the needs of other
customers/users, or specify requirements that are ambiguous or un testable.
• Problems of volatility. The requirements change over time. To help overcome these problems, you must
approach requirements gathering in an organized manner.

Elaboration:
The information obtained from the customer during inception and elicitation is expanded and refined during
elaboration. This task focuses on developing a refined requirements model that identifies various aspects of
software function, behavior, and information.
Elaboration is driven by the creation and refinement of user scenarios that describe how the end user (and other
actors) will interact with the system. Each user scenario is parsed to extract analysis classes—business domain
entities that are visible to the end user. The attributes of eachanalysis class are defined, and the services that are
required by each class are identified. The relationships and collaboration between classes are identified, and a
variety of supplementary diagrams are produced.
 Negotiation:
It usual for customers, to given limited business resources. It’s also relatively common for different
customers or users to propose conflicting requirements, arguing that theirversion is “essential for our special
needs.”
You have to reconcile these conflicts through a process of negotiation. Customers, users, and other
stakeholders are asked to rank requirements and then discuss conflicts in priority. Using aniterative approach
that prioritizes requirements, assesses their cost and risk, and addresses internal conflicts, requirements are
eliminated, combined, and/or modified so that each party achieves some measure of satisfaction.

Specification:
Specification means different things to different people. A specification can be a written document, a set of
graphical models, a formal mathematical model, a collection of usage scenarios, a prototype, or any
combination of these. Some suggest that a “standard template” should be developed and used for a
specification, arguing that this leads to requirements that are presented in a consistent and therefore more
understandable manner. However, it is sometimes necessary to remain flexible when a specification is to be
developed. For large systems, a writtendocument, combining natural language descriptions and graphical
models may be the best approach.

Validation:
The work products produced during requirement engineering are assessed for quality during a validation step.
A key concern during requirement validation is consistency. Requirement validation examines the
specification to ensure that all software requirements have been stated unambiguously; that inconsistencies,
omissions, and errors have been detected and corrected, and that the work products conform to the standards
established for the process, the project, and the product.

Requirement Management:
Requirement for computer based system change and the desire to change requirements persists throughout the
life of system. Requirement management is a set of activities that help the project team identify, control and
track requirement and change to requirements at any time as the project proceeds.

2.2 ESTABLISHING THE GROUNDWORK

In an ideal setting, stakeholders and software engineers work together on the same team. In such cases,
requirements engineering is simply a matter of conducting meaningful conversations with colleagues who are
well-known members of the team.
We discuss the steps required to establish the groundwork for an understanding of software
requirements to get the project started in a way that will keep it moving forward toward a successful
solution.

Identifying Stakeholders:
Stakeholder is “anyone who benefits in a direct or indirect way from the system which is being developed.”
The usual stakeholders are: business operations managers, product managers, marketing people, internal and
external customers, end users, consultants, product engineers, software engineers, support and maintenance
engineers. Each stakeholder has a different view of the system, achieves different benefits when the system is
successfully developed, and is open to different risks if the development effort should fail.
Recognizing Multiple Viewpoints:
Because many different stakeholders exist, the requirements of the system will be explored frommany
different points of view. Each of these constituencies will contribute information to the requirements
engineering process. As information from multiple viewpoints is collected, emerging requirements may be
inconsistent or may conflict with one another. You should categorize all stakeholder information in a way
that will allow decision makers to choose an internally consistent set of requirements for the system.

Working toward Collaboration:

If five stakeholders are involved in a software project, you may have five different opinions about the proper
set of requirements. Customers must collaborate among themselves and with software engineering
practitioners if a successful system is to result. The job of a requirements engineer is to identify areas of
commonality and areas of conflict or inconsistency. Collaborationdoes not necessarily mean that
requirements are defined by committee. In many cases, stakeholders collaborate by providing their view of
requirements, but a strong “project champion” may make the final decision about which requirements make
the cut.

Asking the First Questions:

Questions asked at the inception of the project should be “context free. The first set of context-free
questions focuses on the customer and other stakeholders, the overall project goals and benefits. You might
ask:
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?
These questions help to identify all stakeholders who will have interest in the software to be built. In
addition, the questions identify the measurable benefit of a successful implementationand possible
alternatives to custom software development.
The next set of questions enables you to gain a better understanding of the problem and allowsthe customer
to voice his or her perceptions about a solution:
• How would you characterize “good” output that would be generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which the solution will be used?
• Will special performance issues or constraints affect the way the solution is approached? The
final set of questions focuses on the effectiveness of the communication activity itself.
• Are you the right person to answer these questions? Are your answers “official”?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else? These questions will help to “break the ice” and initiatethe
communication that is essential to successful elicitation.
Non-Functional Requirement:
A non-functional requirement can be described as a quality attribute, a performance attribute, a security
attribute, or a general constrained on a system.
It is possible to define a two phase of approaches:
In first phase, a set of software engineering guidelines is established for the system to be built. These include
guidelines for best practice, architectural style and use of design patterns.
In second phase, the team prioritizes each non-functional requirement by creating a homogeneous set of non
functional requirement using a set of decision rules that establish which guidelines to implement or reject.

Traceability:
Traceability is a software engineering team that refers to document links between software engineer work
products. A traceability matrix allows a requirement engineer to represent the relationship between
requirement and other software engineering work products.
Row of the traceability matrix are labelled using requirement name and columns can be labelled with the
name of software engineering work products.
The traceability matrix can support a verity of engineering development activities. They can provide the
continuity for developers as a project moves one project phase to another.

2.3 ELICITING REQUIREMENTS (REQUIREMENT GATHERING):

Requirements elicitation combines elements of problem solving, elaboration, negotiation, and specification.
To encourage a collaborative, team-oriented approach to requirement gathering, identify the problem, propose
elements of solution and negotiate different approaches.

Collaborative Requirements Gathering:

Many different approaches to collaborative requirements gathering have been proposed.
• Meetings are conducted and attended by both software engineers and other stakeholders.
• Rules for preparation and participation are established.
• An agenda is suggested that is formal enough to cover all important points but informal enoughto encourage
the free flow of ideas.
• A “facilitator” controls the meeting.
• A “definition mechanism” (can be work sheets, flip charts etc) is used.
The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and
specify a preliminary set of solution requirements in an atmosphere that isconducive to accomplishment of
the goal.
While reviewing the product request in the days before the meeting, each attendee is asked to make a list of
objects that are part of the environment that surrounds the system, other objectsthat are to be produced by the
system, and objects that are used by the system to perform its functions.
The mini-specs are presented to all stakeholders for discussion. Additions, deletions, and further elaboration
are made. In some cases, the development of mini-specs will uncover new objects, services, constraints, or
performance requirements that will be added to the original lists. During all discussions, the team may raise an
issue that cannot be resolved during the meeting. An issues list is maintained so that these ideas will be acted
on later.
Quality Function Deployment:
Quality function deployment (QFD) is a quality management technique that translates the needsof the
customer into technical requirements for software. QFD “concentrates on maximizing customer satisfaction
from the software engineering process”.
QFD identifies three types of requirements:
Normal requirements. The objectives and goals that are stated for a product or system during meetings
with the customer. If these requirements are present, the customer is satisfied.
Examples of normal requirements might be requested types of graphical displays, specificsystem
functions, and defined levels of performance.
Expected requirements. These requirements are implicit to the product or system and may be so
fundamental that the customer does not explicitly state them. Their absence will be a cause for
significant dissatisfaction. Examples of expected requirements are: ease of human/machine interaction,
overall operational correctness and reliability, and ease of software installation.
Exciting requirements. These features go beyond the customer’s expectations and prove to bevery
satisfying when present. For example, software for a new mobile phone comes with standard features,
but is coupled with a set of unexpected capabilities (e.g., multitouch screen, visual voice mail) that
delight every user of the product.
Usage Scenarios:
As requirements are gathered, an overall vision of system functions and features begins to materialize.
However, it is difficult to move into more technical software engineering activities until you understand
how these functions and features will be used bydifferent classes of end users. To accomplish this,
developers and users can create a set of scenarios that identify a thread of usage for the system to be
constructed.
Elicitation Work Products:
The work products produced as a consequence of requirements elicitation will vary dependingon the size of
the system or product to be built. For most systems, the work products include
• A statement of need and feasibility.
• A bounded statement of scope for the system or product.
• A list of customers, users, and other stakeholders who participated in requirements elicitation.
• A description of the system’s technical environment.
• A list of requirements and the domain constraints that apply to each.
• A set of usage scenarios that provide insight into the use of the system or product underdifferent
operating conditions.
• Any prototypes developed to better define requirements.
Each of these work products is reviewed by all people who have participated in requirementselicitation.
2.4 DEVELOPING USE CASES:
In essence, a use case tells a stylized story about how an end user interacts with the system undera specific set
of circumstances. The story may be narrative text, an outline of tasks or interactions, a template-based
description, or a diagrammatic representation. Regardless of its form, a use case depicts the software or
system from the end user’s point of view.
The first step in writing a use case is to define the set of “actors” that will be involved in the story. Actors
are the different people (or devices) that use the system or product within the context of the function and
behavior that is to be described.
It is important to note that an actor and an end user are not necessarily the same thing. It is possible to
identify primary actors during the first iteration and secondary actors as more is learned about the
system.
Primary actors interact to achieve required system function and derive the intended benefit from the system.
They work directly and frequently with the software. Secondary actors support the system so that primary
actors can do their work.
Once actors have been identified, use cases can be developed. Jacobson suggests a number ofquestions that
should be answered by a use case:
• Who is the primary actor, the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the story is described?

• What variations in the actor’s interaction are possible?

• What system information will the actor acquire, produce, or change?
• Will the actor have to inform the system about changes in the external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?
2.5 BUILDING THE REQUIREMENTS MODEL:
The intent of the analysis model is to provide a description of the required informational, functional, and
behavioral domains for a computer-based system.
The model changes dynamically as you learn more about the system to be built, and other stakeholders
understand more about what they really require. For that reason, the analysis modelis a snapshot of
requirements at any given time.

Elements of the Requirements Model:

There are many different ways to look at the requirements for a computer-based system. Different modes of
representation force you to consider requirements from different viewpoints—an approach that has a higher
probability of uncovering omissions, inconsistencies, and ambiguity.
 Scenario-based elements: The system is described from the user’s point of view using a scenario-
based approach. For example, basic use cases and their corresponding use-case diagrams evolve into
more elaboratetemplate-based use cases. Scenario-based elements of the requirements model are
often the first part of the model that is developed. Three levels of elaboration are shown, culminating
in a scenario-based representation
 Class-based elements: Each usage scenario implies a set of objects that are manipulated as an actor
interacts with thesystem. These objects are categorized into classes—a collection of things that have
similar attributes and common behaviors. Example shown in figure below.

 Behavioural elements: The behaviour of a computer-based system can have a profound effect on the
design that is chosenand the implementation approach that is applied. Therefore, the requirements
model must provide modelling elements that depict behaviour.
The state diagram is one method for representing the behaviour of a system by depicting its states and
the events that cause the system to change state. A state is any externally observable mode of
behaviour. In addition, the state diagram indicates actions taken as a consequence of a particular
event.
  Flow-oriented elements: Information is transformed as it flows through a computer-based system.
The system accepts input in a variety of forms, applies functions to transform it, and produces output
in a variety of forms. Input may be a control signal transmitted by a transducer, a series of numbers
typed by a human operator, a packet of information transmitted on a network link, or a voluminous
data fileretrieved from secondary storage. The transform(s) may comprise a single logical
comparison, acomplex numerical algorithm, or a rule-inference approach of an expert system.

Analysis Patterns:
Anyone who has done requirements engineering on more than a few software projects begins tonotice that
certain problems reoccur across all projects within a specific application domain.
These analysis patterns suggest solutions (e.g., a class, a function, 53 a behavior) within the application
domain that can be reused when modeling many applications. Analysis patterns are integrated into the
analysis model by reference to the pattern name. They are also stored in a repository so that requirements
engineers can use search facilities to find and apply them.
Information about an analysis pattern (and other types of patterns) is presented in a standardtemplate.

2.6 NEGOTIATING REQUIREMENTS:

In an ideal requirements engineering context, the inception, elicitation, elaboration tasks determine customer
requirements in sufficient detail to proceed to subsequent software engineering activities. You may have to
enter into a negotiation with one or more stakeholders. In most cases, stakeholders are asked to balance
functionality, performance, and other product orsystem characteristics against cost and time-to-market.
The intent of this negotiation is to develop a project plan that meets stakeholder needs while atthe same time
reflecting the real world constraints (e.g., time, people, budget) that have been placed on the software team.
The best negotiations strive for a “win-win” result. That is, stakeholders win by getting the system or product
that satisfies the majority of their needs and you win by working to realisticand achievable budgets and
deadlines.
Boehm [Boe98] defines a set of negotiation activities at the beginning of each software process iteration.
Rather than a single customer communication activity, the following activities are defined:
1. Identification of the system or subsystem’s key stakeholders.
2. Determination of the stakeholders’ “win conditions.”
Negotiations of the stakeholders’ win conditions to reconcile them into a set of win-winconditions for all
concerned.
 2.7 VALIDATING REQUIREMENTS:
As each element of the requirements model is created, it is examined for inconsistency, omissions, and
ambiguity. The requirements represented by the model are prioritized by the stakeholders and grouped within
requirements packages that will be implemented as softwareincrements. A review of the requirements model
addresses the following questions:
• Is each requirement consistent with the overall objectives for the system/product?
• Have all requirements been specified at the proper level of abstraction? That is, do some requirements
provide a level of technical detail that is inappropriate at this stage?
• Is the requirement really necessary or does it represent an add-on feature that may not beessential to the
objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house the system orproduct? • Is
each requirement testable, once implemented?
• Does the requirements model properly reflect the information, function, and behavior of thesystem to be
built?
• Has the requirements model been “partitioned” in a way that exposes progressively moredetailed
information about the system?
• Have requirements patterns been used to simplify the requirements model? Have all patternsbeen properly
validated? Are all patterns consistent with customer requirements?

Requirements Modelling (Scenarios, Information and Analysis Classes)

2.8 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 ofmodels:
• 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) andthe manner
in which classes collaborate to achieve system requirements
• Flow-oriented models that represent the functional elements of the system and how theytransform
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 translatedto 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 thatcan 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 below.

Fig: The requirements model as a bridge between the system description and the design model

Analysis Rules of Thumb:

Arlow and Neustadt suggest a number of worthwhile rules of thumb that should be followedwhen
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 softwarerequirements
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, adatabase 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 betweenclasses 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 constituencyhas 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. Above
Figure illustrates key inputs and outputs for the domainanalysis process. Sources of domain knowledge are
surveyed in an attempt to identify objects that can be reused across the domain.

Fig: Input and output for domain Analysis

Requirements Modelling Approaches:

What different points of view can be used to describe the requirements model?

One view of requirements modeling, called structured analysis, considers data and the processesthat 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 theUnified Process are predominantly
object oriented.
Each element of the requirements model (Figure below) 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 willbe 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.
 Fig: Elements of the analysis model

2.9 SCENARIO-BASED MODELING:

If u understands how end users want to interact with a system, your software team will be better able to
properly characterize requirement and build meaningful analysis and design models.
Requirements modelling with UML begin with the creation of scenarios in the form of use cases, activity
diagrams, and swimlane diagrams.

Actors and User Profile:

A UML actor models an entity that interacts with a system object. Actor may represent roles played by human
stakeholders or external hardware as they interact with system object by exchanging information.
A UML profile provides a way of extending an existing model to other domains or platforms. This might allow
you to revise the model of a Web-based system and model the system for various mobile platforms.

Creating a Preliminary Use Case:

A use case describes a specific usage scenario in straightforward language from the point of viewof 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 ofthe 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 functionthat is being
described by a use case. Therefore, each step in the primary scenario is evaluated byasking 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 ofthe 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 oferror
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 tothe question
is “yes.”
In addition to the three generic questions suggested, the following issues should also beexplored:
• Are there cases in which some “validation function” occurs during this use case? This impliesthat
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? Forexample, 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(Documenting 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.

Fig: preliminary use case diagram for the safehome system

.
The above figure shows depicts a use case diagram for the safe home product
 The home owner logs onto the SafeHome product website, with User ID and passwords
 The system displays the all major function buttons.
 The home owner selects the “surveillance” button from major function buttons.
 The system home owner selects the “pick a camera”.
 The system displays the floor plan of the house.
 The home owner selects the camera icon from the floor plan. and select “view” button.
 The system display a viewing window that is identified by the camera ID.
 The system displays video output within the viewing window at one frame per second.

2.10 UML MODELS THAT SUPPLEMENT THE USE CASE:

The UML activity diagrams can be used to model how system elements respond to internal events.
The UML state diagram can be used to model how system elements respond to external events.
A broad array of UML graphical models are as follows

Developing an Activity Diagram:

Fig(a): Activity diagram for access camera surveillance via the internet-display camera views function.
.

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 (a)

Developing Swimlane Diagrams:

Fig(b): Swimlane diagram for Access camera surveillance via the Internet—display camera views function

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 whichactor 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 (b).
2.11 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 (incorporatingheight, 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), athing (e.g., a
report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), arole (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 operationsthat 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) areunique, 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(a). 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 roleof 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 (b)
illustrates these object-relationship pairs graphically. The arrows noted in Figure(b) provide important
information about the directionality of the relationship and often reduceambiguity or misinterpretations.