Chapter 2-Requirements Analysis and Modeling

Syllabus Content

2.1 Requirement Engineering, Requirement Modeling, Data flow diagram, Scenario

based model

2.2 Software Requirement Specification document format(IEEE)

Requirement Engineering

• The process of establishing the services that the customer requires from a system

and the constraints under which it operates and is developed.

• The requirements themselves are the descriptions of the system services and

constraints that are generated during the requirements engineering process.

Exam Question-: Write short note on Requirement Analysis

What is Requirement ?

• A condition or capability needed by a user to solve a problem or achieve an

objective

• A condition or capability that must be met or possessed by a system or system

component to satisfy a contract, standard, specification or other formally imposed
documents

• A documented representation of a condition or capability as in 1 and 2.

Requirement Analysis

• Requirements Analysis is the process of defining the expectations of the users

for an application that is to be built or modified.

• Requirements analysis involves all the tasks that are conducted to identify the
needs of different stakeholders.

• Therefore requirements analysis means to analyze, document, validate and

manage software or system requirements.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• High-quality requirements are documented, actionable, measurable, testable,
traceable, helps to identify business opportunities, and are defined to a facilitate

system design.

• Requirement analysis is significant and essential activity after elicitation.

• This activity reviews all requirements and may provide a graphical view of the
entire system.

• After the completion of the analysis, it is expected that the understandability of

the project may improve significantly.

• Here, we may also use the interaction with the customer to clarify points of

confusion and to understand which requirements are more important than

others.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

1) Draw the context diagram:

• The context diagram is a simple model that defines the boundaries and interfaces
of the proposed systems with the external world.

• It identifies the entities outside the proposed system that interact with the system.

2) Development of a Prototype (optional):

• One effective way to find out what the customer wants is to construct a prototype,
something that looks and preferably acts as part of the system they say they want.

• We can use their feedback to modify the prototype until the customer is satisfied

continuously.

• Some projects are developed for the general market. In such cases, the prototype

should be shown to some representative sample of the population of potential

purchasers

• The prototype should be built quickly and at a relatively low cost.

3) Model the requirements:

This process usually consists of various graphical representations of the functions, data
entities, external entities, and the relationships between them.

The graphical view may help to find incorrect, inconsistent, missing, and superfluous

requirements.

Such models include the Data Flow diagram, Entity-Relationship diagram, Data

Dictionaries, State-transition diagrams, etc.

4) Finalise the requirements:

After modeling the requirements, we will have a better understanding of the system

behavior.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

 Exam Question-: Explain any four Requirement Elicitation Techniques

Requirement Elicitation

• In requirements engineering, requirements elicitation is the practice of researching

and discovering the requirements of a system from users, customers, and other
stakeholders.

• Requirements elicitation is perhaps the most difficult, most error-prone and most
communication intensive software development.

• It can be successful only through an effective customer-developer partnership.

• It is needed to know what the users really need.

Now we finalize the analyzed requirements, and the next step is to document these
requirements in a prescribed format.

There are a number of requirements elicitation methods. Few of them are listed below –

• Interviews
• Brainstorming

• Document Analysis
• Focus Groups

• Interface Analysis
• Observation

• Prototyping
• Requirements Workshops
• Survey/Questionnaire

1) Interviews:

• Objective of conducting an interview is to understand the customer’s expectations

from the software.

• It is impossible to interview every stakeholder hence representatives from groups
are selected based on their expertise and credibility.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• Interviews maybe be open ended or structured.
• In open ended interviews there is no pre-set agenda. Context free questions may

be asked to understand the problem.

• In structured interview, agenda of fairly open questions is prepared. Sometimes a

proper questionnaire is designed for the interview

2) Brainstorming Sessions:

• It is a group technique
• It is intended to generate lots of new ideas hence providing a platform to share

views

• A highly trained facilitator is required to handle group bias and group conflicts.
• Every idea is documented so that everyone can see it.
• Finally a document is prepared which consists of the list of requirements and their
priority if possible.

3) Survey:
• Leading a survey is an incredible method to find solutions to questions you can’t

answer by yourself.
• Questionnaires take into consideration data to be evoked from numerous

individuals, which is vital if the venture has several partners.

• The ideal approach to this technique is by making a basic Google Form and offering

it to the correct individuals, and whenever required, determining a due date.

Misunderstanding of inquiries can prompt useless and pointless answers

4) Prototyping
• Prototyping is a relatively latest procedure for gathering requirements.

• In this technique, you gather initial requirements for making a basic sort of
clarification – known as a prototype.

• Prototyping is a valuable device for business analysts to decide whether the solution
being created is actually what the stakeholder’s demand.

• Stakeholders can provide suggestions or changes on the prototypes before the plan
is implemented.

• In this methodology, the fundamental prerequisites will be collected.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• This procedure is repeated until the point that the application satisfies customer
necessities, business requirements, and brand quintessence.

• Prototyping works on the principal of – a picture tells a thousand words.

• Prototypes are very useful, especially where the solution includes the usage of new

technology and can support stakeholders to imagine what the final product will
seem like.

5) Document Analysis

• Document analysis is an extremely valuable requirements elicitation method which

is generally utilized in the IT industry.

• This method is particularly significant when you are rolling out an improvement to
a current structure like an upgrade or change request.

• Document analysis includes investigating down all the current documentation

identified with a processor the system.

• Studies of those business prerequisites documents offer context and understanding

into the issues being tended by the new application.

• Document Analysis can act as beginning stages for brainstorming and interviews
topics.

How to Prepare for Requirements Elicitation?

1) The first step is to take time and do some research, have multiple discussion and
find out the business need of the project

2) Understanding of the business need will make sure that scope creep and gold

plating won’t happen

3) Make sure that you have chosen the right technique for requirement elicitation

4) The analyst must ensure that an adequate amount of stakeholders are added to the

project

5) Make sure that the stakeholders are actively engaging from the requirement phase
itself

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

Challenges for requirements elicitation:

1) 'Problems of scope‘: The boundary of the system is ill-defined or the

customers/users specify unnecessary technical details that may confuse, rather

than clarify, overall system objectives.

2) 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 the system 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

untestable.

3) Problems of volatility: The requirements change over time. The rate of change

is sometimes referred to as the level of requirement volatility

4) Visualization: Using tools that promote better understanding of the desired

end-product such as visualization and simulation.

5)Consistent language: Using simple, consistent definitions for requirements

described in natural language and use the business terminology that is prevalent in

the enterprise.

6) Guidelines: Following organizational guidelines that describe the collection

techniques and the types of requirements to be collected. These guidelines are then

used consistently across projects.

7) Consistent use of templates: Producing a consistent set of models and

templates to document the requirements.

8) Documenting dependencies: Documenting dependencies and

interrelationships among requirements.

9) Analysis of changes: Performing root cause analysis of changes to requirements

and making corrective actions & dependancies.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

 Types of Requirements
A software requirement can be of 3 types:

• Functional requirements
• Non-functional requirements

• Domain requirements

Functional Requirements
• These are the requirements that the end user specifically demands as basic

facilities that the system should offer.

• All these functionalities need to be necessarily incorporated into the system as a

part of the contract.

• These are represented or stated in the form of input to be given to the system, the

operation performed and the output expected.

• These are requirements stated by the user which one can see directly in the final
product, unlike the non-functional requirements.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• For example, in a hospital management system, a doctor should be able to retrieve
the information of his patients.

• Each high-level functional requirement may involve several interactions or

dialogues between the system and the outside world.

• In order to accurately describe the functional requirements, all scenarios must be

enumerated.

• There are many ways of expressing functional requirements e.g., natural

language, a structured or formatted language with no rigorous syntax and formal

specification language with proper syntax.

Non-Functional Requirements

These are basically the quality constraints that the system must satisfy according to

the project contract. The priority or extent to which these factors are implemented
varies from one project to other. They are also called non-behavioral requirements.

They basically deal with issues like:

• Portability

• Security

• Maintainability

• Reliability

• Scalability

• Performance

• Reusability

• Flexibility

NFR’s are classified into following types:

• Interface constraints

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

 • Performance constraints: response time, security, storage space, etc.

• Operating constraints

• Life cycle constraints: maintainability, portability, etc.

• Economic constraints

The process of specifying non-functional requirements requires the knowledge of

the functionality of the system, as well as the knowledge of the context within which
the system will operate

Domain Requirements

• Domain requirements are the requirements which are characteristic of a

particular category or domain of projects.

• The basic functions that a system of a specific domain must necessarily exhibit
come under this category.

• For instance, in an academic software that maintains records of a school or college,

the functionality of being able to access the list of faculty and list of students of
each grade is a domain requirement.

• These requirements are therefore identified from that domain model and are not
user specific.

Exam Question-: What is SRS?

Software Requirement Specification

• In SRS is a Software Requirement Specification document which serves as a written

contract between client and an organization.

• SRS is a written and documented understanding between organization and the

client about the features and functionality of the product.

• SRS an assurance between client and organization that both stakeholders

understand the other’s requirements from that perspective at a given point in time.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• There are a set of guidelines to be followed while preparing the software
requirement specification document.

• This includes the purpose, scope, functional and nonfunctional

requirements, software and hardware requirements of the project.

• In addition to this, it also contains the information about environmental conditions

required, safety and security requirements, software quality attributes of the project

etc.

Why Use an SRS Document?

• SRS serves as an input our other all documents created in later stages of software

development life cycle.

• It is a feedback to the customer.

• It’s modularized the problem statement.

• It the bases of system design.

• It defines product scope.

Software Requirements Specification vs. System Requirements Specification

• A software requirements specification (SRS) includes in-depth descriptions of

the software that will be developed.

• A system requirements specification (SyRS) collects information on the

requirements for a system.

• “Software” and “system” are sometimes used interchangeably as SRS. But, a software

requirement specification provides greater detail than a system requirements

specification

Features of SRS

• Correct – It should accurately reflect product functionality and specification at any

point of time.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• Unambiguous – There should not any confusion regarding interpretation of the
requirements.

• Complete – It should contain all features requested by a client.

• Consistent – Same abbreviation and conventions must be followed throughout the

document.

• Ranked for importance and/or stability – Every requirement has its own

importance.It is better to rank every requirement according to its importance and

stability.

• Verifiable –Present requirements with numbers, facts and some measuring

parameters.

• Modifiable – Every SRS is subjected to be changed later. Clearly state every

requirement so it can be easily identified later, avoid redundancy, use change

control to manage modifications.

• Traceable – Trace of any requirement up to its origin. Add reference to high level

document from where any particular requirement started.

Advantages of SRS

• It provides client a satisfaction as this is the first response to the client.

• It defines functional and non-functional requirement.

• It eliminates any confusion or misunderstanding on initial stage.

• It reduces development effort.

• It reduces the chances of requirement creep.

• It makes testing easier.

• It defines project scope.

• It provides the basis for plan charter, work load, dependencies, etc.

Outline of SRS

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

1. Introduction

1.1 Purpose

1.2 Document Conventions

1.3 Intended Audience & Reading Suggestions

1.4 Project Scope

1.5 References

2. Overall Description

2.1 Product Perspective

2.2 Product Features

2.3 User classes and characteristics

2.4 Operating Environment

2.5 Design and implementation constaints

2.6 Assumptions and dependencies

3. System Features and Requirements

3.1 Functional Requirements

4. External Interfaces Requirements

4.1 User interfaces

4.2 Hardware interfaces

4.3 Software interfaces

4.4 Communication interfaces

5. Non Functional Requirements

5.1.Performance requirements

5.2.Safety requirements

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

 5.3 Security requirements

5.4 Software Quallity attributes

What is UML?

• UML is not a language in the same way that we view programming languages such
as ‘C++’, ‘Java’ or ‘Basic’.

• UML is however a language in the sense that it has syntax and semantics which
convey meaning, understanding and constraints to the reader and thereby allows

two people fluent in that language to communicate and understand the intention
of the other.

• UML represents a collection of 13 essentially graphical notations supplemented by

textual descriptions designed to capture requirements and design alternatives.

• UML is to software engineers what building plans are to an architect and an

electrical circuit diagrams is to an electrician.

Why UML
• Provide users with a ready-to-use, expressive visual modeling language so they can

develop and exchange meaningful models.

• Provide extensibility and specialization mechanisms to extend the core concepts.

• Be independent of particular programming languages and development processes.

• Provide a formal basis for understanding the modeling language.

• Encourage the growth of the OO tools market.

• Support higher-level development concepts such as collaborations, frameworks,

patterns and components.

• Integrate best practices.

Structure diagrams show the static structure of the system and its parts on different
abstraction and implementation levels and how they are related to each other. The

elements in a structure diagram represent the meaningful concepts of a system, and

may include abstract, real world and implementation concepts, there are seven

types of structure diagram as follows:

1. Class Diagram

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

 2. Component Diagram
3. Deployment Diagram

4. Object Diagram
5. Package Diagram

6. Composite Structure Diagram

7. Profile Diagram

Behavior diagrams

Behavior diagrams show the dynamic behavior of the objects in a system, which can be

described as a series of changes to the system over time, there are seven types of behavior
diagrams as follows:

1. Use Case Diagram

2. Activity Diagram

3. State Machine Diagram

4. Sequence Diagram

5. Communication Diagram
6. Interaction Overview Diagram

7. Timing Diagram

What is a Use Case

• A formal way of representing how a business system interacts with its environment

• Illustrates the activities that are performed by the users of the system
• It is A scenario-based technique in the UML

• A sequence of actions a system performs that yields a valuable result for a particular
actor.

• It describe what a system does from the standpoint of an external observer. The
emphasis is on what a system does rather than how.

• Use case diagrams are closely connected to scenarios. A scenario is an example of

what happens when someone interacts with the system

An Actor is outside or external the system.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

It can be a:

• Human

• Peripheral device (hardware)

• External system or subsystem

• Time or time-based event

A use case is a summary of scenarios for a single task or goal.

An actor is who or what initiates the events involved in the task of the use case. Actors are
simply roles that people or objects play

The use case is a summary of scenarios for a single task or goal.

• The Use Case is Make Appointment. It is a use case for the medical clinic.

• The picture below is a Make Appointment use case for the medical clinic.

• The actor is a Patient. The connection between actor and use case is a
communication association (or communication for short).

Use Case Components

• The use case task referred to as the use case that represents a feature needed in a

software system.

• The actor(s) who trigger the use case to activate.

• The communication line to show how the actors communicate with the use case.

• A boundary rectangle is placed around the perimeter of the system to show how

the actors communicate with the system.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

Generalization Relationship

Represented by a line and a hollow arrow

From child to parent

Include Relationship

Represents the inclusion of the functionality of one use case within another

Arrow is drawn from the base use case to the used use case

Write << include >> above arrowhead line

Extend relationship

Represents the extension of the use case to include optional functionality

Arrow is drawn from the extension use case to the base use case

Write << extend >> above arrowhead line

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

 Benefits of Use Cases
• Use cases are the primary vehicle for requirements capture in RUP

• Use cases are described using the language of the customer (language of the
domain which is defined in the glossary)

• Use cases provide a contractual delivery process (RUP is Use Case Driven)
• Use cases provide an easily-understood communication mechanism

• When requirements are traced, they make it difficult for requirements to fall through
the cracks

• Use cases provide a concise summary of what the system should do at an abstract
(low modification cost) level.

Difficulties with Use Cases

• As functional decompositions, it is often difficult to make the transition from

functional description to object description to class design

• Reuse at the class level can be hindered by each developer “taking a Use Case and
running with it”. Since UCs do not talk about classes, developers often wind up in a

vacuum during object analysis, and can often wind up doing things their own way,
making reuse difficult

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

 • Use Cases make stating non-functional requirements difficult (where do you say that
X must execute at Y/sec?)

• Testing functionality is straightforward, but unit testing the particular

implementations and non-functional requirements is not obvious

Class Diagrams

• Class diagram is a static diagram. It represents the static view of an application.

• Class diagram is not only used for visualizing, describing, and documenting different
aspects of a system but also for constructing executable code of the software

application.

• Class diagram describes the attributes and operations of a class and also the
constraints imposed on the system.

• The class diagrams are widely used in the modeling of object oriented systems

because they are the only UML diagrams, which can be mapped directly with object-
oriented languages.

• Class diagram shows a collection of classes, interfaces, associations, collaborations,

and constraints. It is also known as a structural diagram.

The purpose of the class diagram can be summarized as −

• Analysis and design of the static view of an application.

• Describe responsibilities of a system.

• Base for component and deployment diagrams.

• Forward and reverse engineering.

How to Draw a Class Diagram?

• Class diagrams are the most popular UML diagrams used for construction of

software applications. It is very important to learn the drawing procedure of class

diagram.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• Class diagrams have a lot of properties to consider while drawing but here the
diagram will be considered from a top level view.

• Class diagram is basically a graphical representation of the static view of the system

and represents different aspects of the application. A collection of class diagrams

represent the whole system.

The following points should be remembered while drawing a class diagram −

• The name of the class diagram should be meaningful to describe the aspect of the
system.

• Each element and their relationships should be identified in advance.

• Responsibility (attributes and methods) of each class should be clearly identified

• For each class, minimum number of properties should be specified, as unnecessary

properties will make the diagram complicated.

• Use notes whenever required to describe some aspect of the diagram. At the end

of the drawing it should be understandable to the developer/coder.

• Finally, before making the final version, the diagram should be drawn on plain paper

and reworked as many times as possible to make it correct.

The following diagram is an example of an Order System of an application. It

describes a particular aspect of the entire application.

• First of all, Order and Customer are identified as the two elements of the system.
They have a one-to-many relationship because a customer can have multiple orders.

• Order class is an abstract class and it has two concrete classes (inheritance

relationship) SpecialOrder and NormalOrder.

• The two inherited classes have all the properties as the Order class. In addition, they
have additional functions like dispatch () and receive ().

Example

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

 Class diagrams are used for −

• Describing the static view of the system.

• Showing the collaboration among the elements of the static view.

• Describing the functionalities performed by the system.

• Construction of software applications using object oriented languages.

Object Diagrams

• Object diagrams are derived from class diagrams so object diagrams are dependent

upon class diagrams.

• Object diagrams represent an instance of a class diagram.

• The basic concepts are similar for class diagrams and object diagrams.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• Object diagrams also represent the static view of a system but this static view is a
snapshot of the system at a particular moment.

• Object diagrams are used to render a set of objects and their relationships as an

instance.

The purpose of the object diagram can be summarized as

• Forward and reverse engineering.

• Object relationships of a system

• Static view of an interaction.

• Understand object behaviour and their relationship from practical perspective

How to draw Object Diagram

1. First, analyze the system and decide which instances have important data and

association.

2. Second, consider only those instances, which will cover the functionality.

3. Third, make some optimization as the number of instances are unlimited.

Before drawing an object diagram, the following things should be remembered and

understood clearly −

• Object diagrams consist of objects.

• The link in object diagram is used to connect objects.

• Objects and links are the two elements used to construct an object diagram.

After this, the following things are to be decided before starting the construction of

the diagram −

• The object diagram should have a meaningful name to indicate its purpose.

• The most important elements are to be identified.

• The association among objects should be clarified.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• Values of different elements need to be captured to include in the object diagram.

• Add proper notes at points where more clarity is required.

Customer, Order, SpecialOrder & NormalOrder

• Now the customer object (C) is associated with three order objects (O1, O2, and O3).

These order objects are associated with special order and normal order objects (S1,
S2, and N1). The customer has the following three orders with different numbers

(12, 32 and 40) for the particular time considered.

• The customer can increase the number of orders in future and in that scenario the
object diagram will reflect that. If order, special order, and normal order objects are

observed then you will find that they have some values.

• For orders, the values are 12, 32, and 40 which implies that the objects have these

values for a particular moment (here the particular time when the purchase is made
is considered as the moment) when the instance is captured

• The same is true for special order and normal order objects which have number of

orders as 20, 30, and 60. If a different time of purchase is considered, then these
values will change accordingly.

Where to use it?

• Making the prototype of a system.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• Reverse engineering.

• Modeling complex data structures.

• Understanding the system from practical perspective

Component Diagram

• Component diagrams are different in terms of nature and behavior.

• Component diagrams are used to model the physical aspects of a system.

• Component diagrams are used to visualize the organization and relationships

among components in a system.

• These diagrams are also used to make executable systems.

The purpose of the component diagram can be summarized as −

• Visualize the components of a system.

• Construct executables by using forward and reverse engineering.

• Describe the organization and relationships of the components.

• How to Draw a Component Diagram?

Before drawing a component diagram, the following artifacts are to be identified

clearly −

• Files used in the system.

• Libraries and other artifacts relevant to the application.

• Relationships among the artifacts.

After identifying the artifacts, the following points need to be kept in mind.

• Use a meaningful name to identify the component for which the diagram is to be

drawn.

• Prepare a mental layout before producing the using tools.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• Use notes for clarifying important points.

Example

Where to use

• Model the components of a system.

• Model the database schema.

• Model the executables of an application.

• Model the system's source code.

Deployment Diagram

• Deployment diagrams are used to visualize the topology of the physical

components of a system, where the software components are deployed.

• Deployment diagrams are used to describe the static deployment view of a

system.

• Deployment diagrams consist of nodes and their relationships.

The purpose of deployment diagrams can be described as −

• Visualize the hardware topology of a system.

• Describe the hardware components used to deploy software components.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• Describe the runtime processing nodes.

Deployment diagrams can be used −

• To model the hardware topology of a system.

• To model the embedded system.

• To model the hardware details for a client/server system.

• To model the hardware details of a distributed application.

• For Forward and Reverse engineering.

Package Diagram

• It simplify complex class diagrams, it can group classes into packages.

• A package is a collection of logically related UML elements.

• Packages are depicted as file folders and can be used on any of the UML diagrams.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

 Behaviours Diagram

1) Use Case Diagram(refer above section)

2) Interaction Diagram
• This interactive behavior is represented in UML by two diagrams known as Sequence

diagram and Collaboration diagram. The basic purpose of both the diagrams are
similar.

• Sequence diagram emphasizes on time sequence of messages and collaboration

diagram emphasizes on the structural organization of the objects that send and

receive messages.
• The purpose of interaction diagram is −
• To capture the dynamic behaviour of a system.
• To describe the message flow in the system.

• To describe the structural organization of the objects.

• To describe the interaction among objects.

• Following things are to be identified clearly before drawing the interaction

diagram

• Objects taking part in the interaction.

• Message flows among the objects.

• The sequence in which the messages are flowing.

• Object organization.
• The Sequence Diagram

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• The sequence diagram has four objects (Customer, Order, SpecialOrder and
NormalOrder).

• The following diagram shows the message sequence for SpecialOrder object and
the same can be used in case of NormalOrder object. It is important to understand

the time sequence of message flows. The message flow is nothing but a method
call of an object.

• The first call is sendOrder () which is a method of Order object. The next call
is confirm () which is a method of SpecialOrder object and the last call is Dispatch

() which is a method of SpecialOrder object. The following diagram mainly

describes the method calls from one object to another, and this is also the actual

scenario when the system is running.

The Collaboration Diagram

• The second interaction diagram is the collaboration diagram.

• It shows the object organization as seen in the following diagram. In the

collaboration diagram, the method call sequence is indicated by some numbering

technique.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• The number indicates how the methods are called one after another. We have taken
the same order management system to describe the collaboration diagram.

• Method calls are similar to that of a sequence diagram. However, difference being

the sequence diagram does not describe the object organization, whereas the
collaboration diagram shows the object organization.

• To choose between these two diagrams, emphasis is placed on the type of

requirement. If the time sequence is important, then the sequence diagram is used.
If organization is required, then collaboration diagram is used.

• Interaction diagrams can be used −

• To model the flow of control by time sequence.

• To model the flow of control by structural organizations.

• For forward engineering.

• For reverse engineering.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

 3) StateChart Diagram

• A Statechart diagram describes a state machine.

• State machine can be defined as a machine which defines different states of an

object and these states are controlled by external or internal events.

• As Statechart diagram defines the states, it is used to model the lifetime of an

object.

• Following are the main purposes of using Statechart diagrams −

• To model the dynamic aspect of a system.

• To model the life time of a reactive system.

• To describe different states of an object during its life time.

• Define a state machine to model the states of an object.

• Statechart diagram is used to describe the states of different objects in its life cycle.

Emphasis is placed on the state changes upon some internal or external events.
These states of objects are important to analyze and implement them accurately.

• Statechart diagrams are very important for describing the states. States can be

identified as the condition of objects when a particular event occurs.

• Before drawing a Statechart diagram we should clarify the following points −

1) Identify the important objects to be analyzed.

2) Identify the states.

3) Identify the events.

A statechart diagram where the state of Order object is analyzed

• The first state is an idle state from where the process starts. The next states are

arrived for events like send request, confirm request, and dispatch order. These
events are responsible for the state changes of order object.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• During the life cycle of an object (here order object) it goes through the following
states and there may be some abnormal exits. This abnormal exit may occur due to

some problem in the system. When the entire life cycle is complete, it is considered
as a complete transaction as shown in the following figure. The initial and final state

of an object is also shown in the following figure.

The main usage can be described as −

• To model the object states of a system.

• To model the reactive system. Reactive system consists of reactive objects.

• To identify the events responsible for state changes.

• Forward and reverse engineering.

4) Activity Diagram

• Activity diagram is basically a flowchart to represent the flow from one activity to

another activity. The activity can be described as an operation of the system.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

• The control flow is drawn from one operation to another. This flow can be
sequential, branched, or concurrent. Activity diagrams deal with all type of flow

control by using different elements such as fork, join, etc

The purpose of an activity diagram can be described as −

• Draw the activity flow of a system.

• Describe the sequence from one activity to another.

• Describe the parallel, branched and concurrent flow of the system.

• How to Draw an Activity Diagram?

• Activity diagrams are mainly used as a flowchart that consists of activities performed
by the system. Activity diagrams are not exactly flowcharts as they have some

additional capabilities. These additional capabilities include branching, parallel flow,

swimlane, etc.

• Before drawing an activity diagram, we must have a clear understanding about the

elements used in activity diagram. The main element of an activity diagram is the
activity itself. An activity is a function performed by the system. After identifying the

activities, we need to understand how they are associated with constraints and
conditions.

Before drawing an activity diagram, we should identify the following elements −

• Activities

• Association

• Conditions

• Constraints

• an activity diagram for order management system. In the diagram, four activities are
identified which are associated with conditions. One important point should be

clearly understood that an activity diagram cannot be exactly matched with the

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

 code. The activity diagram is made to understand the flow of activities and is mainly
used by the business users

• Following diagram is drawn with the four main activities −

• Send order by the customer

• Receipt of the order

• Confirm the order

• Dispatch the order

After receiving the order request, condition checks are performed to check if it is

normal or special order. After the type of order is identified, dispatch activity is
performed and that is marked as the termination of the process.

Activity diagram can be used for −

• Modeling work flow by using activities.

• Modeling business requirements.

• High level understanding of the system's functionalities.

• Investigating business requirements at a later stage.

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

 Interaction Diagram

1) Timing Diagram

• Timing diagram shows the behavior of the objects in a given period of time.

• Timing diagram is a special form of a sequence diagram.

• The differences between timing diagram and sequence diagram are the axes are
reversed so that the time are increase from left to right and the lifelines are shown

in separate compartments arranged vertically.

Data Flow Diagram

1. Create a list of activities

2. Construct Context Level DFD

(identifies external entities and processes)

3. Construct Level 0 DFD

(identifies manageable sub process )

4. Construct Level 1- n DFD

(identifies actual data flows and data stores )

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

5. Check against rules of DFD

Example

Create list of activities

• Customer Order

• Serve Product

• Collect Payment

• Produce Product

• Store Product

• Order Raw Materials

• Pay for Raw Materials

• Pay for Labor

• Create a context level diagram identifying the sources and sinks (users).

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)

Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)
Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)
Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)
Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)
Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)
Chapter 2 Requirements Analysis and Modeling-Prepared by Prof .Prita Patil(VIT-CMPN)