SOFTWARE ENGINEERING & PROJECT MANAGEMENT MODULE-2

UNDERSTANDING REQUIREMENTS
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
modelling activity
Requirements engineering builds a bridge to design and construction. Requirements engineering provides
the appropriate mechanism for understanding what the customer wants, analyzing need, assessing
feasibility, negotiating a reasonable solution 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: At project inception, you establish a basic understanding of the problem, the people who
want a solution, 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: It certainly seems simple enough—ask the customer, the users and what the objectives for
the system or product are, what is to be accomplished, how the system or product fits into theneeds of
the business, and finally, how the system or product is to be used on a day-to-day basis The number of
problems that are encountered as elicitation occurs.
Problems of scope: customers/users specify unnecessary 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 computingenvironment, don’t have a full
understanding of the problem domain, have trouble communicating needs to the system engineer
Problems of volatility. The requirements change over time

• 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, behaviour, 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

Dept. of CS&E, BIT Page 1

SOFTWARE ENGINEERING & PROJECT MANAGEMENT MODULE-2
• Negotiation:
It isn’t unusual for customers and users to ask for more than can be achieved, given limited business
resources. It’s also relatively common for different customers or users to propose conflicting
requirements.
Customers, users, and other stakeholders are asked to rank requirements and then discussconflicts in
priority. So that each party achieves some measure of satisfaction
• Specification:
In the context of computer-based systems (and software), the term 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. a “standard template” should be
developed and used for a specification.
For large systems, a written document, combining natural language descriptions and graphical models
may be the best approach. However, usage scenarios may be all that arerequired for smaller products
• Validation.
The work products produced as a consequence of requirements engineering are assessed for quality
during a validation step. Requirements validation examines the specification5 to ensure that all
software requirements have been detected and corrected; and that the work products conform to the
standards established for the process, the project, and the product. The primary requirements
validation mechanism is the technical review.
• Requirements Management.
Requirements for computer-based systems change, and the desire to change requirements persists
throughout the life of the system
Requirements management is a set of activities that help the project team identify, control, and track
requirements and changes to requirements at any time as the project proceeds
• Establishing the ground work:
In the sections that follow, I 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: Define a stakeholder as “anyone who benefits in a direct or indirect way from
the system which is being developed.”
business operations managers, product managers, marketing people, internal and external customers, end
users, consultants, product engineers, software engineers, support and maintenance engineers, and others.
Each stakeholder has a different view of the system, achieves different benefits when the system is
successfully developed

Dept. of CS&E, BIT Page 2

SOFTWARE ENGINEERING & PROJECT MANAGEMENT MODULE-2
Recognizing Multiple Viewpoints
Because many different stakeholders exist, the requirements of the system will be explored from many
different points of view. For example, the marketing group is interested in functions and features that will
excite the potential market, making the new system easy to sell. Business managers are interested in a
feature set that can be built within budget and that will be ready to meet defined market windows. End
users may want features that are familiar to them and that are easy to learn and use.
Support engineers may focus on the maintainability of the software.

Working toward Collaboration

If five stakeholders are involved in a software project, you may have five (or more) different opinions
about the proper set of requirements. Throughout earlier chapters, I have noted that customers
Must collaborate among themselves and with software engineering practitioners if a successful system is
to result
Collaboration does 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”(e.g., a
business manager or a senior technologist) may make the final decision about which requirements make
the cut.

Asking the First Questions

The customer and other stakeholders, the overall project goals and benefits. For example, youmight ask:
a. Who is behind the request for this work?
b. Who will use the solution?
c. What will be the economic benefit of a successful solution?
d. Is there another source for the solution that you need?

The next set of questions enables you to gain a better understanding of the problem andallows the
customer to voice his or her perceptions about a solution:
e. How would you characterize “good” output that would be generated by a successfulsolution?
f. What problem(s) will this solution address?
g. Can you show me (or describe) the business environment in which the solution willbe used?
h. Will special performance issues or constraints affect the way the solution isapproached?

The final set of questions focuses on the effectiveness of the communication activity itself. Which are
called as “meta-questions” and propose the following (abbreviated) list:

Dept. of CS&E, BIT Page 3

SOFTWARE ENGINEERING & PROJECT MANAGEMENT MODULE-2
i. Are you the right person to answer these questions? Are your answers “official”?
j. Are my questions relevant to the problem that you have? • Am I asking too manyquestions?
k. Can anyone else provide additional information?
l. Should I be asking you anything else?

Requirements elicitation
Requirements elicitation (also called requirements gathering) combines elements of problem solving,
elaboration, negotiation, and specification. In order to encourage a collaborative, team-oriented approach
to requirements gathering, stakeholders work together to identify the problem, propose elements of the
solution, negotiate different approaches and specify a preliminary set of solution requirements.

Collaborative Requirements Gathering

Many different approaches to collaborative requirements gathering have been proposed. Eachmakes use
of a slightly different scenario, but all apply some variation on the following basic guidelines:
m. Meetings are conducted and attended by both software engineers and otherstakeholders.
n. Rules for preparation and participation are established.
o. An agenda is suggested that is formal enough to cover all important points but informal
enough to encourage the free flow of ideas.
p. A “facilitator” (can be a customer, a developer, or an outsider) controls the meeting.
q. A “definition mechanism” (can be work sheets, flip charts, or wall stickers or anelectronic
bulletin board, chat room, or virtual forum) 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.
I present a brief scenario that outlines the sequence of events that lead up to the requirements gathering
meeting, occur during the meeting
Out of these initial meetings, the developer and customers write a one- or two-page “productrequest.”
A meeting place, time, and date are selected; a facilitator is chosen; and attendees from the software team
and other stakeholder organizations are invited to participate. The product request is distributed to all
attendees before the meeting date.
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 objects that are to be
produced by the system, and objects that are used by the system to perform its functions. In addition, each
attendee is asked to make another list of services (processes or functions) that manipulate or interact with
the objects. Finally, lists of constraints (e.g., cost, size, business rules) and performance criteria.
Dept. of CS&E, BIT Page 4
SOFTWARE ENGINEERING & PROJECT MANAGEMENT MODULE-2
As an example, consider an excerpt from a product request written by a marketing person involved in the
SafeHome project. This is an home security function that is to be part of SafeHome.
Objects described for SafeHome might include the control panel, smoke detectors, window and door
sensors, motion detectors, an alarm. The list of services might include configuring the system, setting the
alarm, monitoring the sensors, dialing the phone, programming the control panel, and reading the display
The lists of objects have been posted on an electronic bulletin board.
In many cases, an object or service described on a list will require further explanation. To accomplish
this, stakeholders develop mini-specifications for entries on the lists. Each mini- specification is an
elaboration of an object.
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 (QFD)

Quality function deployment (QFD) is a quality management technique that translates the needs of the
customer into technical requirements for software. QFD “concentrates on maximizing customer
satisfaction from the software engineering process”:
QFD identifies three types of requirements :
1. 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. Example:
requested types of graphical displays, specific system functions,
2. 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 Example: Ease of software Installation.
3. Exciting requirements: These features go beyond the customer’s expectations and prove to be
very satisfying when present. For example: software for a new mobile phone comes with standard
features.

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 by different 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. The scenarios, often called use cases.

Dept. of CS&E, BIT Page 5

SOFTWARE ENGINEERING & PROJECT MANAGEMENT MODULE-2

Elicitation Work Products:

The work products produced as a consequence of requirements elicitation will varydepending on 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 requirementselicitation.
• A description of the system’s technical environment.
• A list of requirements (preferably organized by function) and the domain constraintsthat apply to
each

Developing Use Cases:

• A use case captures a contract that describes the system’s behavior under various conditions as the
system responds to a request from one of its stakeholders. A use case tells a stylized story about how an
end user (playing one of a number of possible roles) interacts with the system under a specific set of
circumstances.
• A use case can be a template-based description, or a diagrammatic representation The first step in
writing a use case is to define the set of “actors” that will be involved in the story.
• An actor is anything that communicates with the system or product and that is external to the system
itself. Every actor has one or more goals when using the system.
• It is important to note that an actor and an end user are not necessarily the same thing. A typical user
may play a number of different roles when using a system, whereas an actor represents a class of
external entities
• As an example, consider a machine operator (a user) who interacts with the control computer for a
manufacturing cell that contains a number of robots and numerically controlled machines.
• The software for the control computer requires four different modes (roles) for interaction:
programming mode, test mode, monitoring mode, and troubleshooting mode. Therefore, four actors can
be defined: programmer, tester, monitor, and troubleshooter.
• In some cases, the machine operator can play all of these roles.
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. A number of questions that should be
answered by a use case:

Dept. of CS&E, BIT Page 6

SOFTWARE ENGINEERING & PROJECT MANAGEMENT MODULE-2
• 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? Recalling
basic SafeHome requirements, we define four actors:
homeowner (a user),
setup manager (likely the same person as homeowner, but playing a different role),
sensors (devices attached to the system),
and the monitoring and response subsystem.
The homeowner actor interacts with the home security function in a number of different ways using
either the alarm control panel or a PC:
4. Enters a password to allow all other interactions.
5. Inquires about the status of a security zone.
6. Inquires about the status of a sensor.
7. Presses the panic button in an emergency.
8. Activates/deactivates the security system.

Dept. of CS&E, BIT Page 7

SOFTWARE ENGINEERING & PROJECT MANAGEMENT MODULE-2

In many instances, uses cases are further elaborated to provide considerably more detail about the
interaction. For example, the following template for detailed descriptions of use cases.

Fig. UML use case diagram for SafeHome Home Security Function.

Dept. of CS&E, BIT Page 8

SOFTWARE ENGINEERING & PROJECT MANAGEMENT MODULE-2

Dept. of CS&E, BIT Page 9

SOFTWARE ENGINEERING & PROJECT MANAGEMENT MODULE-2
Building The Requirements Model:
The model changes dynamically as you learn more about the system to be built, and other stakeholders
understand more about what they really require.
As the requirements model evolves, certain elements will become relatively stable, providing a solid
foundation for the design tasks that follow. However, other elementsof the model may be more volatile.

Elements of the Requirements Model

There are many different ways to look at the requirements for a computer-based system. Some software
people argue that it’s best to select one mode of representation (e.g., the use case) and apply it to the
exclusion of all other modes. Other practitionersbelieve that it’s worthwhile to use a number of different
modes of representation to depict the requirements model. A set of generic elements is common to most
requirements models:

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 (Figure 5.3) evolve
into more elaborate template-based use cases.
Scenario-based elements of the requirements model are often the first part of themodel that is developed.
As such, they serve as input for the creation of other modelling elements.

Class-based elements:
Each usage scenario implies a set of objects that are manipulated as an actor interacts with the system.
These objects are categorized into classes—a collection of things thathave similar attributes and common
behaviors.

Dept. of CS&E, BIT Page 10

SOFTWARE ENGINEERING & PROJECT MANAGEMENT MODULE-2
For example, a UML class diagram can be used to depict a Sensor class for the SafeHome security
function

Behavioral elements:
Therefore, the requirements model must provide modeling elements that depictbehavior.
The state diagram is one method for representing the behavior 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 behavior. In
addition, the state diagram indicates actions (e.g., process activation) taken as a consequence of a
particular event. To illustrate the use of a state diagram, consider software embedded within the
SafeHome control panel that is responsible for reading user input. A simplified UML state diagram is
shown in Figure 5.5.

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 atransducer, a series of numbers typed by a human operator, a packet of
information transmitted on a network link, or a voluminous data file retrieved from secondary storage.

Dept. of CS&E, BIT Page 11

SOFTWARE ENGINEERING & PROJECT MANAGEMENT MODULE-2
Analysis Patterns:
Anyone who has done requirements engineering on more than a few software projects begins to notice
that certain problems reoccur across all projects within a specific application domain.18 These analysis
patterns suggest solutions (e.g., a class,a function, a behavior) within the application domain that can be
reused when modelling many applications. Analysis patterns are integrated into the analysis model by
reference to the pattern name. Information about an analysis pattern (and other types of patterns) is
presented in a standard template.

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 software increments. 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 be essential
to the objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally, a specific individual)
noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house the system or
product?
• Is each requirement testable, once implemented?
• Does the requirements model properly reflect the information, function, and behavior of the
system to be built?
• Has the requirements model been “partitioned” in a way that exposes progressively more detailed
information about the system?
• Have requirements patterns been used to simplify the requirements model? Have all patterns been
properly validated? Are all patterns consistent with customer requirements? These and other
questions should be asked and answered to ensure that the requirements model is an accurate
reflection of stakeholder needs and that it provides a solid foundation for design

Dept. of CS&E, BIT Page 12

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2

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 us 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 model so 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-orientedmodelsthatrepresentthefunctionalelementsofthesystemandhowtheytransformdataasit
moves through the system.
• Behaviouralmodelsthatdepicthowthesoftwarebehavesasaconsequenceofexternal“events”.
• These models provide a software designer with information that can be translated to architectural,
interface, and component-level designs. Finally, the requirements model (and the software
requirements specification) provides the developer and the customer with the means to assess
quality once software is built.

Over all 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 descriptions that describes overall system

Dept. of CS&E, BIT Page 1

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2

or business functionality as it is achieved by applying software, hardware, data, human, and other system
elements and a software design that describes the software’s application architecture, user interface, and
component-level structure. This relationship is illustrated in Figure 6.1.
Analysis Rules of Thumb
Arlow and Neustadt [Arl02] 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 behaviour 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
behaviour 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.
• [Link] 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 none win
formation. 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, the creation of the analysis model is expedited. More important, the likelihood of
applying design patterns and executable software components grows dramatically. This improves time- to-
market and reduces development costs.

Dept. of CS&E, BIT Page 2

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2

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.

The goal of domain analysis is straight forward: to find or create those analysis classes and/or analysis
patterns that are broadly applicable so that they may be reused. Domain analysis may be viewed as an
umbrella activity for the software process. By this I mean that domain analysis is an ongoing software
engineering activity that is not connected to any one software project. In a way, the role of a domain
analyst is similar to the role of a master tool smith in a heavy manufacturing environment.
The job of the toolsmith is to design and build tools that may be used by many people doing similar but
not necessarily the same jobs. The role of the domain analyst5 is to discover and define analysis patterns,
analysis classes, and related information that may be used by many people working on similar but not
necessarily the same applications.

Requirements Modelling Approaches

One view of requirements modelling, called structured analysis, considers data and the processes that
transform the data as separate entities. Data objects are modelled in a way that defines their attributes and
relationships. Processes that manipulate data objects are modelled in a manner that shows how they
transform data as data objects flow through the system. A second approach to analysis modelling, called
object-oriented analysis, focuses on the definition of classes and the manner in which they collaborate
with one another to effect customer requirements.

Dept. of CS&E, BIT Page 3

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2

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 (some hierarchical) 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.
• Flow-oriented elements represent the system as an information transform, depicting how data objects
are transformed as they flow through various system functions. Analysis modelling leads to the
derivation of each of these modelling elements. However, the specific content of each element (i.e.,
the diagrams that are used to construct the element and the model may differ from project to project.

SENARIO-BASEDMODELLING
Creating a Preliminary Use Case:
Ausecasedescribesaspecificusagescenarioinstraightforwardlanguagefromthepointofviewofa 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?
These are the questions that must be answered if use cases are to provide value as a requirements
modeling tool.
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.

The Safe Home homesurveillance function (subsystem )discussed in the sidebar identifies the following
functions (an abbreviated list) that are performed by the home owner actor:
Select camera to view.
• Request thumbnails from all cameras.

Dept. of CS&E, BIT Page 4

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2

• Display camera views in a PC window.

• Control pan and zoom for a specific camera.
• Selectively record camera output.
• Replay camera output.
• Access camera surveillance via the Internet.

Use case: Access camera surveillance via the Internet—display camera views (ACS-DCV) Actor:
homeowner
1. The homeowner logs onto the SafeHome Products website.
2. The homeowner enters his or her user ID.
3. The homeowner enters two passwords (each at least eight characters in length).
4. The system displays all major function buttons.
5. The homeowner selects the “surveillance” from the major function buttons.
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house.
8. The homeowner selects a camera icon from the floor plan.
9. The homeowner selects the “view” button.
10. The system displays a viewing window that is identified by the camera ID.
11. The system displays video output within the viewing window at one frame per Second.

Refining a Preliminary Use Case

To fully understand a use case, it is essential to examine alternative interactions by asking specific
questions for each step in the primary scenario:
1. Can the actor take some other action at this point?
2. Is it possible that the actor will encounter some error condition at this point? If so, what might it be?
3. Is it possible that the actor will encounter some other behavior at this point (e.g., behavior invoked by
an external event)?
If so, what might it be? These questions help create secondary scenarios representing alternative
behaviors. For example, in a home security system:
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house. Alternative action: The actor may choose to view
thumbnail snapshots of all cameras simultaneously, creating a secondary scenario, “View thumbnail
snapshots for all cameras.”
Error condition: If no floor plan is configured, selecting “pickacamera” results in “No floor plan
configured for this house,” a secondary scenario.
Dept. of CS&E, BIT Page 5
SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2

Other behavior: An alarm condition may arise, leading to a special alarm notification and options relevant
to the alarm. This scenario, applicable to any interaction, becomes a separate use case, "Alarm condition
encountered."
Each situation is a use-case exception, describing a failure condition or an alternative chosen by the actor
that causes the system to behave differently. Cockburn recommends brainstorming to identify a
comprehensive set of exceptions for each use case.
Additional issues to explore include:
• Validation functions that might invoke potential error conditions.
• Supporting functions (or actors) failing to respond appropriately, such as timeouts.
• Poor system performance leading to unexpected user actions, such as multiple selections due to slow
response.
The list of exceptions should be rationalized: an exception is noted if the software can detect and handle
the condition. In some cases, an exception leads to developing another use case to handle the condition.
For example, improper system configuration causing an error or an alarm condition interrupting any
scenario must be addressed. Brainstorming identifies all possible exceptions, ensuring a comprehensive
use case that covers various interactions and system behaviors

Writing a Formal Use Case

FIGURE6.4 Preliminary use-case diagram for the Safe Home system description, a use case is only as
good as its author(s). If the description is unclear, the use case can be misleading or ambiguous. A use
case focuses on functional and behavioral requirements and is generally inappropriate for nonfunctional
requirements.

Dept. of CS&E, BIT Page 6

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2

For situations in which the requirements model must have every modeling notation has limitations, and
the use case is no exception. Like any other form of written significant detail and precision (e.g., safety
critical systems), a use case may not be sufficient. However, scenario-based modeling is appropriate for a
significant majority of all situations that you will encounter as a software engineer. If developed properly,
the use case can provide substantial benefit as a modeling tool.

UMLMODELSTHATSUPLIMENTSTHEUSECASE
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 (each arrow emanating from the diamond is labeled), and solid
horizontal lines to indicate that parallel activities are occurring.

For example, a user may only attempt to enter userID and password a limited number of times. This is
represented by a decision diamond below “Prompt for reentry.”

Dept. of CS&E, BIT Page 7

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2

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 (if there are
multiple actors involved in a specific use case) or analysis class (discussed later in this chapter) 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.

Referring to Figure 6.6, the activity diagram is rearranged so that activities associated with a particular
analysis class fall inside the swimlane for that class. For example, the Interface class represents the user
interface as seen by the homeowner. The activity diagram notes two prompts that are the responsibility of
the interface—“prompt for reentry” and “prompt for another view.” These prompts and the decisions
associated with them fall within the Interface swimlane. However, arrows lead from that swim lane back
to the Home owner swimlane, where homeowner actions occur.

Dept. of CS&E, BIT Page 8

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2

DATAMODELLINGCONCEPTS
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 modelling. 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.

DATAOBJECTS
A data object is a representation of composite information that must be understood by software. By
composite information, I mean something that has a number of different properties or attributes.
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). For example, a person or a car can be
viewed as a data object in the sense that either can be defined in terms of a set of attributes. 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.10
Therefore, the data object can be represented as a table as shown in Figure 6.7. The headings in the table
reflect attributes of the object. In this case, a car is defined in terms of make, model, ID number, body
type, colour, and owner. The body of the table represents specific instances of the data object. For
example, a Chevy Corvette is an instance of the data object car.

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. Referring to the
data object car, a reasonable identifier might be the ID number. The set of attributes that is appropriate

Dept. of CS&E, BIT Page 9

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2
for a given data object is determined through an understanding of the problem context.
The attributes for car might serve well for an application that would be used by a department of motor
vehicles, but these attributes would be useless for an automobile company that needs manufacturing
control software.
In the latter case, the attributes for car might also include ID number, body type, and colour, but many
additional attributes (e.g., interior code, drive train type, trim package designator, transmission type)
would have to be added to make car a meaningful object in the manufacturing control context.

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.

Dept. of CS&E, BIT Page 10

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2
CLASS BASED MODELLING
Class-based modelling represents the objects that the system will manipulate, the operations (also
called methods or services) that will be applied to the objects to effect the manipulation, relationships
(some hierarchical) 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
responsibilitycollaborator (CRC) models, collaboration diagrams, and packages. The sections that follow
present a series of informal guidelines that will assist in their identification and representation.

Identifying Analysis Classes

Analysis classes manifest themselves in one of the following ways:
• External entities (e.g., other systems, devices, people) that produce or consume information to be used
by a computer-based system.
• Things (e.g., reports, displays, letters, signals) that are part of the information domain for the problem.
• Occurrences or events (e.g., a property transfer or the completion of a series of robot movements) that
occur within the context of system operation.
• Roles (e.g., manager, engineer, salesperson) played by people who interact with the system.
• Organizational units (e.g., division, group, team) that are relevant to an application.
• Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and the
overall function of the system.
• Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related
classes of objects. This categorization is but one of many that have been proposed in the literature. For
example, Budd [Bud96] suggests a taxonomy of classes that includes producers (sources) and consumers
(sinks) of data, data managers, view or observer classes, and helper classes. It is also important to note
what classes or objects are not. In general, a class should never have an “imperative procedural name”
[Cas89].
For example, if the developers of software for a medical imaging system defined an object with the name
InvertImage or even ImageInversion, they would be making a subtle mistake. The Image obtained from
the software could, of course, be a class (it is a thing that is part of the information domain). Inversion of
the image is an operation that is applied to the object. It is likely that inversion would be defined as an
operation for the object Image, but it would not be defined as a separate class to connote “image
inversion.” As Cashman [Cas89] states: “the intent of object-orientation is to encapsulate, but still keep
separate, data and operations on the data.”
To illustrate how analysis classes might be defined during the early stages of modelling, consider a
grammatical parse (nouns are underlined, verbs italicized) for a processing narrative16 for the SafeHome
security function.
The SafeHome security function enables the homeowner to configure the security system when it is

Dept. of CS&E Page 11

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2
installed, monitors all sensors connected to the security system, and interacts with the homeowner
through the Internet, a PC, or a control panel. During installation, the SafeHome PC is used to program
and configure the system. Each sensor is assigned a number and type, a master password is programmed
for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event
occurs. When a sensor event is recognized, the software invokes an audible alarm attached to the system.
After a delay time that is specified by the homeowner during system configuration activities, the software
dials a telephone number of a monitoring service, provides information about the location, reporting the
nature of the event that has been detected. The telephone number will be redialed every 20 seconds until
telephone connection is obtained. The homeowner receives security information via a control panel, the
PC, or a browser, collectively called an interface. The interface displays prompting messages and system
status information on the control panel, the PC ,or the browser window. Homeowner interaction takes the
following form . . . Extracting the nouns, we can propose a number of potential classes:

The list would be continued until all nouns in the processing narrative have been considered. Note that I
call each entry in the list a potential object. You must consider each further before a final decision is
made. Coad and Yourdon[Coa91] suggest six selection characteristics that should be used as you consider
each potential class for inclusion in the analysis model:
1. Retained information. The potential class will be useful during analysis only if information about it
must be remembered so that the system can function.
2. Needed services. The potential class must have a set of identifiable operations that can change the
value of its attributes in some way.
3. Multiple attributes. During requirement analysis, the focus should be on “major” information; a class
with a single attribute may, in fact, be useful during design, but is probably better represented as an
SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2
attribute of another class during the analysis activity.
4. Common attributes. A set of attributes can be defined for the potential class and these attributes apply
to all instances of the class.
5. Common operations. A set of operations can be defined for the potential class and these operations
apply to all instances of the class.
6. Essential requirements. External entities that appear in the problem space and produce or consume
information essential to the operation of any solution for the system will almost always be defined as
classes in the requirements model.
To be considered a legitimate class for inclusion in the requirements model, a potential object should
satisfy all (or almost all) of these characteristics. The decision for inclusion of potential classes in the
analysis model is somewhat subjective, and later evaluation may cause an object to be discarded or
reinstated. However, the first step of class-based modelling is the definition of classes, and decisions
(even subjective ones) must be made. With this in mind, you should apply the selection characteristics to
the list of potential SafeHome classes:
:

It should be noted that

(1) the preceding list is not all-inclusive, additional classes would have to be added to complete the model;
(2) some of the rejected potential classes will become attributes for those classes that were accepted (e.g., number
and type are attributes of Sensor, and master password and telephone number may become attributes of System);
(3) different statements of the problem might cause different “accept or reject” decisions to be made (e.g., if each
homeowner had an individual password or was identified by voice print, the Homeowner class would satisfy
characteristics 1 and 2 and would have been accepted).
SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2
Specifying Attributes

• Attributes describe a class that has been selected for inclusion in the requirements model.
• Attributes are the set of data objects that fully define the class within the context of the problem.
• 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. In addition, the following question should be
answered for each class: “What data items (composite and/or elementary) fully define this class in the
context of the problem at hand?”
• To illustrate, we consider the System class defined for SafeHome. A homeowner can configure the
security function to reflect sensor information, alarm response information, activation/deactivation
information, identification information, and so forth. We can represent these composite data items in the
following manner

• data items to the right of the equal sign constitute a reasonable list of attributes for the System class.
• Sensor has already been defined as a class, and multiple Sensor objects will be associated with the
System class. In general, we avoid defining an item as an attribute if more than one of the items is to be
associated with the class.

Defining Operations
Operations define the behavior of an object.
• Operations can generally be divided into four broad categories:
1. Operations that manipulate data in some way. Eg: adding, deleting, reformatting, selecting
2. operations that perform a computation
3. operations that inquire about the state of an object
4. Operations that monitor an object for the occurrence of a controlling event.
SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2

Class diagram for the System class

• 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
➢ ▪ verbs are isolated
• Some of these verbs will be legitimate operations and can be easily connected to a specific class.
• For example, from the SafeHome processing narrative, we see that “sensor is assigned a number and
type” or “a master password is programmed for arming and disarming the system.” These phrases
indicate:
➢ ▪ an assign() operation is relevant for the Sensor class
➢ ▪ a program() operation will be applied to the System class.
➢ ▪ arm() and disarm() are operations that apply to System class
• Objects communicate by passing messages to one another.

Class-Responsibility-Collaborator (CRC) Modeling

Class-responsibility-collaborator (CRC) modeling [Wir90] provides a simple means for identifying and organizing
the classes that are relevant to system or product requirements
• 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.
• 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.
• Collaboration implies either a request for information or a request for some action.
• A simple CRC index card for the FloorPlan 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.

Dept. of CS&E Page 15

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2
SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2

Classes:
The taxonomy of class types can be extended by considering the following categories:
1. 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 (unless they are specifically deleted).
2. Boundary classes: are used to create the interface that the user sees and interacts with as the software is used
(e.g., interactive screen or printed reports). Boundary classes are designed with the responsibility of managing the
way entity objects are represented to users. Entity objects contain information that is important to users, but they do
not display themselves.
3. Controller classes: manage a “unit of work” from start to finish. Controller classes are not considered until the
design activity has begun. 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.

Responsibilities:
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.
• “Dumb” classes (those that have few responsibilities) can be modeled to act as servants to a few “smart”
classes (those having many responsibilities)
• Although this approach makes the flow of control in a system straightforward, it has a few disadvantages:
it concentrates all intelligence within a few classes, making changes more difficult, and it tends to require
more classes, hence more development effort.
• If system intelligence is more evenly distributed across the classes in an application, each object knows
about and does only a few things, the cohesiveness of the system is improved. This enhances the
maintainability of the software and reduces the impact of side effects due to change.
• 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. This indicates a concentration of intelligence. In addition, the responsibilities for each
class should exhibit the same level of abstraction.
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 (because they are
generic, they will apply to all subclasses).
3. Information and the behavior related to it should reside within the same class. This achieves the object-

Dept. of CS&E, BIT Page 17

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2
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
2. a class can collaborate with other classes.
• Collaborations represent requests from a client to a server in fulfillment of a client responsibility. A
collaboration is the embodiment of the contract between the client and the server. We say that an object
collaborates with another object if, to fulfill a responsibility, it needs to send the other object any
messages. A single collaboration flows in one direction—representing a request from the client to the
server. From the client’s point of view, each of its collaborations is associated with a particular
responsibility implemented by the server.
• Collaborations are identified by determining whether a class can fulfill each responsibility itself. If it
cannot, then it needs to interact with another class. Hence, a collaboration To help in the identification of
collaborators, you can examine three different generic relationships between classes.

1. The is-part-of relationship all classes that are part of an aggregate class are connected to the aggregate
class via an is-part-of relationship. Consider the classes defined for the video game, the class PlayerBody is-
part-of Player, as are Player Arms, Player Legs, and Player Head. In UML, these relationships are

Dept. of CS&E, BIT Page 18

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2
represented as the aggregation shown in Figure 6.12.
2. The has-knowledge-of relationship When one class must acquire information from another class, the has-
knowledge of relationship is established. The determine-sensor-status() responsibility noted earlier is an
example of a has-knowledge-of relationship
3. The depends-upon relationship The depends-upon relationship implies that two classes have a
dependency that is not achieved by has-knowledge-of or is-part-of
• In all cases, the collaborator class name is recorded on the CRC model index card next to the
responsibility that has spawned the collaboration. Therefore, the index card contains a list of
responsibilities and the corresponding collaborations that enable the responsibilities to be fulfilled.

Associations and Dependencies

• An association defines a relationship between classes.
• Multiplicity defines how many of one class are related to how many of another rclass
• In many instances, two analysis classes are related to one an other 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.
• These multiplicity constraints are illustrated in Figure 6.13, where “one or more” is represented
using1..*,and“0ormore”by0 ..*.In UML, the asterisk indicates an unlimited upper bound on the
range.

Dept. of CS&E, BIT Page 19

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2

• In many instances, a client-server relationship exists between two analysis classes. In such cases, a client class
depends on the server class in some way and a dependency relationship is established.
• Dependencies are defined by a stereotype.
• A stereotype is an “extensibility mechanism” within UML that allows you to define a special modeling element
whose semantics are custom defined.
• In UML stereotypes are represented in double angle brackets (e.g., <>).
In Figure 6.14 <> implies that the use of the camera output is controlled by a special password

Analysis Packages
• A package is used to assemble a collection of related classes.
• An important part of analysis modeling is categorization
• That is, various elements of the analysis model (e.g., use cases, analysis classes) are categorized
in a manner that packages them as a grouping—called an analysis package—that is given a
representative name.

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

Dept. of CS&E, BIT Page 20

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2
• Other symbols can precede an element within a package.
• A minus sign indicates that an element is hidden from all other packages
• A # symbol indicates that an element is accessible only to packages contained within a given package.

FLOW ORIENTED MODELLING

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

A few simple guidelines can aid immeasurably during the derivation of a data flow

diagram:

(1) The level 0 data flow diagram should depict the software/system as a single

bubble.

(2) Primary input and output should be carefully noted.

(3) Refinement should begin by isolating candidate processes, data objects, and

data stores to be represented at the next level.

(4) All arrows and bubbles should be labeled with meaningful names;

(5) Information flow continuity must be maintained from level to level, 2

(6) one bubble at a time should be refined. There is a natural tendency to overcomplicate the data flow diagram.

Dept. of CS&E, BIT Page 21

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2
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

 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

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.

Dept. of CS&E, BIT Page 21

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2
• 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; for

example, ask: “Is there any other way I can get to this state or exit from it?”

THE CONTROL SPECIFICATION

 A control specification (CSPEC) represents the behavior of the system (at the level from which it has been
referenced) in two different ways.

 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 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, you can determine the behavior of the system and, more important, ascertain
whether thereare “holes” in the specified behavior.

Dept. of CS&E, BIT Page 21

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2
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)
description of the process algorithm, mathematical equations, tables, or UML activity diagrams.

Creating a Behavioral Model

The behavioral model indicates how software will respond to external events or

stimuli. To create the model, the following steps are required:

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

 A use case is examined for points of information exchange.

 An actor should be identified for each event; the information that is exchanged should be noted, and any
conditions or constraints should be listed.

State Representations

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.

An action occurs concurrently with the state transition or as a consequence of it and generally involves one or more
operations (responsibilities) of the object.

Dept. of CS&E, BIT Page 21

SOFTWARE ENGINEERING & PROJECT MANAGEMNET MODULE-2

Two different characterizations of states must be considered:

(1) The state of each class as the system performs its function

(2) The state of the system as observed from the outside as the system performs its function

Sequence diagrams

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

Dept. of CS&E, BIT Page 21

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-3

Dept. of CS&E, BIT Page

16