Module 2

Requirement analysis and specification

• The goal of the requirements analysis and specification phase is to clearly understand
the customer requirements and to systematically organise the requirements into a
document called the Software Requirements Specification (SRS) document.
• Its usually carried out by a few experienced members of the development team.
• The engineers who gather and analyse customer requirements and then write the SRS
document are called as system analysts.
• The SRS document is the final outcome of the requirements analysis and specification
phase.
• Requirement analysis and specification mainly involves carrying out the following
two important activities:
– Requirements gathering and analysis
– Requirements specification

Requirements gathering and analysis

The complete set of requirements is rarely available in the form of a single document from
the customer. The requirements have to be gathered by the analyst from several sources in
bits and pieces which are then analysed to remove several types of problems and
inconsistencies.

Requirements gathering and analysis activity into two separate tasks:

 Requirements gathering
 Requirements analysis

Requirements Gathering

Requirements gathering is also popularly known as Requirements Elicitation. The primary

objective of the requirements gathering task is to collect the requirements from the
stakeholders.

A stakeholder is a source of the requirements and is usually a person, or a group of persons

who either directly or indirectly are concerned with the software.

The important ways in which an experienced analyst gathers requirements are:

  Studying existing documentation:
The analyst usually studies all the available documents regarding the system to be
developed before visiting the customer site. Customers usually provide statement of
purpose (SoP) document to the developers which discuss issues such as the context in
which the software is required, the basic purpose, the stakeholders, features of any
similar software developed elsewhere, etc.
 Interview:
Typically, there are many different categories of users of a software. Each category of
users typically requires a different set of features from the software. Therefore, it is
important for the analyst to first identify the different categories of users and then
determine the requirements of each.
 Task analysis:
The users usually have a black-box view of a software and consider the software as
something that provides a set of services (functionalities). A service supported by a
software is also called a task. In this context, the analyst tries to identify and
understand the different tasks to be performed by the software. For each identified
task, the analyst tries to formulate the different steps necessary to realise the required
functionality in consultation with the users.
 Scenario analysis:
A task can have many scenarios of operation. The different scenarios of a task may
take place when the task is invoked under different situations. For different types of
scenarios of a task, the behaviour of the software can be different. For various
identified tasks, the possible scenarios of execution are identified and the details of
each scenario is identified in consultation with the users.

Requirements Analysis

After requirements gathering is complete, the analyst analyses the gathered requirements to
form a clear understanding of the exact customer requirements and to weed out any problems
in the gathered requirements.

The main purpose of the requirements analysis activity is to analyse the gathered
requirements to remove all ambiguities, incompleteness, and inconsistencies from the
gathered customer requirements and to obtain a clear understanding of the software to be
developed.

During requirements analysis, the analyst needs to identify and resolve three main types of
problems in the requirements:

 Anomaly
 Inconsistency
 Incompleteness

Anomaly:
An anomaly is an ambiguity in a requirement. When a requirement is anomalous, several
interpretations of that requirement are possible.

Inconsistency:
Two requirements are said to be inconsistent, if one of the requirements contradicts the other.
Incompleteness:
An incomplete set of requirements is one in which some requirements have been overlooked.
The lack of these features would be felt by the customer much later, possibly while using the
software.

SOFTWARE REQUIREMENTS SPECIFICATION

The SRS document usually contains all the user requirements in a structured though an
informal form. The production of the requirements stage of the software development process
is Software Requirements Specifications (SRS) (also called a requirements document).
This report lays a foundation for software engineering activities and is constructing when
entire requirements are elicited and analyzed. SRS is a formal report, which acts as a
representation of software that enables the customers to review whether it (SRS) is according
to their requirements.

Characteristics of good SRS

1. Correctness:

User review is used to provide the accuracy of requirements stated in the SRS. SRS is said to
be perfect if it covers all the needs that are truly expected from the system.

2. Completeness:

The SRS is complete if, and only if, it includes the following elements:
I. All essential requirements, whether relating to functionality, performance, design.
II. Definition of their responses of the software
III. Full labels and references to all figures, tables, and diagrams

3. Consistency:

The SRS is consistent if, and only if, no subset of individual requirements described in its
conflict. Example: One condition may state that all lights shall be green while another states
that all lights shall be blue.

4. Unambiguousness:

SRS is unambiguous when every fixed requirement has only one interpretation.

5. Ranking for importance and stability:

The SRS is ranked for importance and stability if each requirement in it has an identifier to
indicate either the significance or stability of that particular requirement. Typically, all
requirements are not equally important. Some prerequisites may be essential, especially for
life-critical applications, while others may be desirable.

6. Modifiability:
SRS should be made as modifiable as likely and should be capable of quickly obtain changes
to the system.

7. Verifiability:

SRS is correct when the specified requirements can be verified with a cost-effective system to
check whether the final software meets those requirements.

8. Traceability:

The SRS is traceable if the origin of each of the requirements is clear and if it facilitates the
referencing of each condition in future development or enhancement documentation.

9. Design Independence:

There should be an option to select from multiple design alternatives for the final system.
More specifically, the SRS should not contain any implementation details.

10. Testability:

An SRS should be written in such a method that it is simple to generate test cases and test
plans from the report.

11. Understandable by the customer:

An end user may be an expert in his/her explicit domain but might not be trained in computer
science. The language should be kept simple and clear.

12. The right level of abstraction:

If the SRS is written for the requirements stage, the details should be explained explicitly.

Attributes of Bad SRS Documents

SRS documents written by novices frequently suffer from a variety of problems.

Over-specification:

It occurs when the analyst tries to address the “how to” aspects in the SRS document. For
example, in the library automation problem, one should not specify whether the library
membership records need to be stored indexed on the member’s first name or on the library
member’s identification (ID) number.

Forward references:

One should not refer to aspects that are discussed much later in the SRS document. Forward
referencing seriously reduces readability of the specification.

Wishful thinking:
This type of problems concern description of aspects which would be difficult to implement.

Noise:

The term noise refers to presence of material not directly relevant to the software
development process.

Software Requirements Specification Format

A Software Requirements Specification (SRS) is a formal document that describes all the
requirements of a software system in a structured manner.

The standard SRS format is generally divided into the following sections:

1. Introduction

This section gives a basic overview of the system and the document.

• Purpose: Explains why the SRS document is created.

• Scope: Defines what the software system will do and its objectives.

• Definitions, Acronyms, Abbreviations: Explains technical terms used in the document.

• References: Lists books, documents, or websites referred to.

• Overview: Explains how the document is organized.

Purpose of this section:

To help readers understand the system and the document structure.

2. Overall Description

This section provides a high-level description of the system.

Includes:

• Product Perspective

Shows how the system fits into existing systems.

• Product Functions

Summarizes major functionalities of the software.

• User Characteristics

Describes the types of users and their skill levels.

• Constraints

Lists limitations such as hardware, software, legal, or memory constraints.

• Assumptions and Dependencies

Specifies conditions assumed to be true.

Purpose of this section:

To provide the overall context of the software system.

3. Specific Requirements

This is the most important section of the SRS.

a) Functional Requirements

Describe what the system should do.

Example:

 User login
 Online payment
 Report generation

Defines system functionalities.

b) Non-Functional Requirements

Describe how the system should perform.

Example:

 Security
 Reliability
 Performance
 Speed

Defines quality attributes of the system.

c) External Interface Requirements

Describes interaction with external entities.

Includes:

 User Interface
 Hardware Interface
 Software Interface
  Communication Interface

Explains system interaction with users and other systems.

4. Other Requirements

Contains additional requirements not covered earlier.

Examples:

 Database requirements
 Safety requirements
 Business rules

Covers special system requirements.

5. Appendices

Contains supporting information.

Includes:

 Glossary
 Additional documents
 References

Helps readers understand the system better.

Formal system Specification

 Formal specification is the process of defining software systems’ requirements and
behaviour with rigorous mathematical and logical techniques.
 Unlike informal specifications, which often rely on natural language descriptions and
diagrams, formal specifications use precise formal languages to outline exactly what
the system should do.
 This approach provides a clear and unambiguous description of the system’s intended
behaviour.

Benefits of Formal Specification

– Removes Ambiguity: Requirements are written precisely using mathematics. No
multiple interpretations.
– Early Error Detection: Errors and inconsistencies can be identified during the
specification stage itself. Reduces costly fixes later.
– Better Verification: System correctness can be mathematically [Link]
reliability.
– High Reliability: Very useful for banking, medical and aerospace systems where
failures are dangerous.
– Reduces Development Cost: Finding errors early reduces maintenance and debugging
cost.

Formal Specification Languages

Z notation: It is based on set theory and first-order logic. Z provides a mathematically
rigorous framework for specifying system requirements and design. It employs schemas
to define data structures and operations, offering a clear and precise way to model system
behavior. Z has been successfully applied in various domains, including safety-critical
systems and high-assurance software.
B method: It is based on abstract machines and refinement. The B Method offers a
structured approach to specifying, designing, and verifying software systems. It
emphasizes stepwise refinement, where a system is incrementally developed from an
abstract specification to a concrete implementation. The B Method includes proof
obligations to ensure that the implementation meets the specified requirements. It is
commonly used in systems requiring high reliability and correctness, such as embedded
systems and safety-critical applications.
Alloy: It is another formal specification language based on relational logic. Alloy
provides a framework for modeling and analyzing complex systems. It includes a built-in
analyzer that can automatically check properties of models and generate
counterexamples, making it a powerful tool for system verification. Alloy is particularly
useful for modeling and analyzing software designs, ensuring that they meet their
intended specifications.
Example: ATM Withdrawal
A user can withdraw money only if the account balance is sufficient.
Using mathematical notation:
If balance ≥ withdrawal_amount
→ Allow withdrawal
Else
→ Deny transaction

Applications of formal system specifications:

 In banking systems, formal methods are used in ATM software, online banking,
and transaction processing systems to ensure secure and error-free operations.
Since even a small mistake can lead to financial loss, formal specifications help in
improving correctness and reliability.
  In aerospace systems, formal specification methods are used in aircraft control
systems, spacecraft software, and navigation systems. These systems are safety-
critical, and any software failure can cause serious accidents. Therefore,
mathematical specifications are used to verify the correctness of the software.

 Formal methods are also applied in medical systems such as patient monitoring
devices, heart monitors, and medical equipment software. These systems require
very high reliability because software errors may affect patient safety. Formal
specifications help reduce risks and improve accuracy.
 In railway and traffic control systems, formal specification methods are used for
train signaling systems and traffic management systems. These methods help
ensure proper synchronization and avoid dangerous failures or collisions.
 Security-critical systems such as authentication software, cryptographic
applications, and defense systems also use formal specifications. They help in
detecting vulnerabilities early and ensure that the system behaves correctly under
all conditions.
 Formal methods are additionally used in communication protocols and distributed
systems to verify data transmission and communication correctness. They are also
useful in embedded systems such as automobiles and industrial control systems
where hardware and software work together closely.

Disadvantages of Formal Specification Methods

1. Difficult to Understand

Formal specifications use mathematical symbols, logic, and notations that are hard for
ordinary users and non-technical stakeholders to understand. Only trained professionals with
knowledge of formal methods can easily read and write them.

2. Time-Consuming

Creating a formal specification requires detailed analysis and mathematical modeling.

Writing and verifying specifications takes a lot of time compared to normal requirement
documentation.

3. High Initial Cost

Formal methods require skilled experts, specialized training, and sometimes expensive tools.
Because of this, the initial development cost becomes high.

4. Poor Communication with Users

Customers and end users may not understand mathematical specifications easily. This creates
communication difficulties between developers and users during requirement discussions.
5. Not Suitable for All Projects

Formal specification methods are mainly useful for safety-critical and high-reliability
systems. For small, simple, or low-budget projects, using formal methods may be
unnecessary and impractical.

Finite State Machine

 A finite state machine (FSM) is defined as a mathematical model used to
represent and control the behavior of systems that can exist in a finite number of
states at any given time.
 This concept is widely used in computer science, engineering, and various other
fields to design, analyze, and implement systems with discrete and sequential
behavior.
 FSMs consist of:

– States: Represent different conditions or modes of the system.

– Transitions: The movement from one state to another based on specific
conditions.
– Input symbols: Events that trigger state transitions.
– Initial state: The starting state of the FSM.
– Final state: A state where the machine halts or finishes its process.

Types of Finite State Machine

Mealy State Machine

When the outputs depend on the current inputs as well as states, then the FSM can be named
to be a mealy state machine. The following diagram is the mealy state machine block
diagram. The mealy state machine block diagram consists of two parts
namely combinational logic as well as memory. The memory in the machine can be used to
provide some of the previous outputs as combinational logic inputs.

Block Diagram
Based on the current inputs as well as states, this machine can produce outputs. Thus, the
outputs can be suitable only at positive otherwise negative of the CLK signal. The mealy state
machine’s state diagram is shown below.

State Diagram of Mealy State Machine

The state diagram of mealy state machine mainly includes three states namely A, B, and C.
These three states are tagged within the circles as well as every circle communicates with one
state. Conversions among these three states are signified by directed lines. In the above
diagram, the inputs and outputs are denoted with 0/0, 1/0, and 1/1. Based on the input value,
there are two conversions from every state.

Generally, the amount of required states in the mealy machine is below or equivalent to the
number of required states in Moore state machine. There is an equal Moore state machine for
every Mealy state machine. As a result, based on the necessity we can employ one of them.

Moore State Machine

When the outputs depend on current states then the FSM can be named as Moore state
machine. The Moore state machine’s block diagram is shown below. The Moore state
machine block diagram consists of two parts namely combinational logic as well as memory.

Moore State Machine Block Diagram

In this case, the current inputs, as well as current states, will decide the next states. Thus,
depending on further states, this machine will generate the outputs. So, the outputs of this will
be applicable simply after the conversion of the state.

The Moore state machine state diagram is shown below. In the above state, the diagram
includes four states like a mealy state machine namely A, B, C, and D. the four states as well
as individual outputs are placed in the circles.

State Diagram of Moore State Machine

 In the above figure, there are four states, namely A, B, C & D. These states and the respective
outputs are labeled inside the circles. Here, simply the input worth is marked on every
conversion. In the above figure includes two conversions from every state depending on the
input value.

Generally, the amount of required states in this machine is greater than otherwise equivalent
to the required number of states in the mealy state machine

Generally, the number of required states in this machine is more than otherwise equivalent to
the required states in MSM (Mealy state machine). For every Moore state machine, there is
a corresponding Mealy state machine. Consequently, depending on the necessity we can
utilize one of them.
There is an equal mealy state machine for every Moore state machine. As a result, based on
the necessity we can employ one of them.

Finite State Machine Applications

The finite state machine applications mainly include the following.
FSMs are used in games; they are most recognized for being utilized in artificial intelligence,
and however, they are also frequent in executions of navigating parsing text, input handling
of the customer, as well as network protocols.
These are restricted in computational power; they have the good quality of being
comparatively simple to recognize. So, they are frequently used by software developers as
well as system designers for summarizing the performance of a difficult system.

The finite state machines are applicable in vending machines, video games, traffic
lights, controllers in CPU, text parsing, analysis of protocol, recognition of speech, language
processing, etc.
Advantages of Finite State Machine
The advantages of Finite State Machine include the following.
 Finite state machines are flexible
 Easy to move from a significant abstract to a code execution
 Low processor overhead
 Easy determination of reachability of a state
Disadvantages of Finite State Machine
The disadvantages of the finite state machine include the following
 The expected character of deterministic finite state machines can be not needed in some
areas like computer games
 The implementation of huge systems using FSM is hard for managing without any idea of
design.
 Not applicable for all domains
 The orders of state conversions are inflexible.

Petri nets

• Petri net are a mathematical and graphical modeling tool used to represent systems
that involve concurrent, parallel, and synchronized activities.
 • Components of petri nets

– ▭ Transitions: Represent events or actions

– ⭕ Places: Represent conditions or states

– ➡ Arcs: Connect places and transitions, Show the flow direction

– Tokens: Represent the current state/activity

Example: Login Page

Object Modeling using UML
• Object modeling is the process of representing a system using objects, classes,
attributes, relationships, and behaviors.
• It helps developers understand:
– Structure of the system
– Interaction between objects
– System design before coding
• Unified Modeling Language is a standard graphical language used to model,
visualize, and design software systems.
• UML is used to provide ready to use visual model in order to develop the system
model effectively.
Perspectives of UML
• Structural Perspective: Focuses on the static structure of the system.
• Behavioral Perspective: Focuses on the dynamic behavior of the system.
• Interaction Perspective: Focuses on communication between objects.
• Implementation Perspective: Focuses on physical implementation of the system.
Types of UML Diagrams
• Use Case Diagram
• Class Diagram
• Interaction Diagram
• Activity Diagram
• State chart diagrams
• Object Diagram
• Sequence Diagram
 • Component Diagram
• Deployment Diagram

Use case Diagram

• A Use Case Diagram is a visual way to show how users (actors) interact with a system
and what functions (use cases) the system provides. It helps understand the system’s
behavior from the user’s perspective.
• Represents actors (users or external systems) and use cases (system functionalities).
• Shows the relationships between users and system features.
• Helps define system scope, requirements, and interactions clearly.
Notations
• Actor : Actors are external entities that interact with the system. These can include
users, other systems, or hardware devices.

• Use cases: Use cases are like scenes in the play. They represent specific things your
system can do.

• System Boundary: The system boundary is a visual representation of the scope or

limits of the system you are modeling. It defines what is inside the system and what is
outside.

Relationships

1. Association Relationship

The Association Relationship represents a communication or interaction between an actor

and a use case. It is depicted by a line connecting the actor to the use case. This relationship
signifies that the actor is involved in the functionality described by the use case.
Example: Online Banking System
 Actor: Customer
 Use Case: Transfer Funds
 Association: A line connecting the "Customer" actor to the "Transfer Funds" use case,
indicating the customer's involvement in the funds transfer process.
2. Include Relationship

The Include Relationship indicates that a use case includes the functionality of another use
case. It is denoted by a dashed arrow pointing from the including use case to the included use
case. This relationship promotes modular and reusable design.
Example: Social Media Posting
 Use Cases: Compose Post, Add Image
 Include Relationship: The "Compose Post" use case includes the functionality of "Add
Image." Therefore, composing a post includes the action of adding an image.

3. Extend Relationship

The Extend Relationship illustrates that a use case can be extended by another use case under
specific conditions. It is represented by a dashed arrow with the keyword "extend." This
relationship is useful for handling optional or exceptional behavior.
Example: Flight Booking System
 Use Cases: Book Flight, Select Seat
 Extend Relationship: The "Select Seat" use case may extend the "Book Flight" use case
when the user wants to choose a specific seat, but it is an optional step.

4. Generalization Relationship

The Generalization Relationship establishes an "is-a" connection between two use cases,
indicating that one use case is a specialized version of another. It is represented by an arrow
pointing from the specialized use case to the general use case.
Example: Vehicle Rental System
 Use Cases: Rent Car, Rent Bike
 Generalization Relationship: Both "Rent Car" and "Rent Bike" are specialized versions
of the general use case "Rent Vehicle."

Draw a Use Case diagram in UML

Below are the main steps to draw use case diagram in UML:
 Step 1: Identify Actors: Determine who or what interacts with the system. These are your
actors. They can be users, other systems, or external entities.
 Step 2: Identify Use Cases: Identify the main functionalities or actions the system must
perform. These are your use cases. Each use case should represent a specific piece of
functionality.
 Step 3: Connect Actors and Use Cases: Draw lines (associations) between actors and the
use cases they are involved in. This represents the interactions between actors and the
system.
 Step 4: Add System Boundary: Draw a box around the actors and use cases to represent
the system boundary. This defines the scope of your system.
 Step 5: Define Relationships: If certain use cases are related or if one use case is an
extension of another, you can indicate these relationships with appropriate notations.
 Step 6: Review and Refine: Step back and review your diagram. Ensure that it accurately
represents the interactions and relationships in your system. Refine as needed.
 Step 7: Validate: Share your use case diagram with stakeholders and gather feedback.
Ensure that it aligns with their understanding of the system's functionality.

Class Diagram
• A UML class diagram shows the structure of a system by displaying its classes, their
attributes, methods, and the relationships between them.
• It helps the team understand how the system is organized and how components
interact.
– Represents classes, attributes, methods, and relationships
– Helps communicate and document the software structure
– Makes it easier for developers and designers to understand the system
Notations

• Class Name: The name of the class is typically written in the top compartment of the
class box and is centered and bold.
• Attributes: Attributes, also known as properties or fields, represent the data members
of the class.
• Methods: Methods, also known as functions or operations, represent the behavior or
functionality of the class.
• Visibility Notation: It indicate the access level of attributes and methods. Common
visibility notations include:
– + for public (visible to all classes)
– - for private (visible only within the class)
– # for protected (visible to subclasses)
Relationships
• Inheritance (or Generalization):
– Represents an "is-a" relationship.
– SubClass1 and SubClass2 are specializations of Super Class.
– A solid line with a hollow arrowhead that point from the child to the parent
class

• Simple Association:
– A structural link between two peer classes.
– There is an association between Class1 and Class2
– A solid line connecting two classes
 • Aggregetion:
– It represents a "part of" relationship.
– Class2 is part of Class1.
– Many instances (denoted by the *) of Class2 can be associated with Class1.
– Objects of Class1 and Class2 have separate lifetimes.
– A solid line with an unfilled diamond at the association end connected to the
class of composite

• Composition:
– Objects of Class2 live and die with Class1.
– Class2 cannot stand by itself.
– A solid line with a filled diamond at the association connected to the class of
composite.

• Dependency:
– Exists between two classes if the changes to the definition of one may cause
changes to the other (but not the other way around).
– Class1 depends on Class2
– A dashed line with an open arrow

Purpose
• This is the only UML that can appropriately depict various aspects of the OOPs
concept.
• Proper design and analysis of applications can be faster and efficient.
• It is the base for deployment and component diagram.
 • Class diagrams serve as a visual tool for communication among team members and
stakeholders, bridging gaps between technical and non-technical audiences.

Interaction Diagram
A UML Interaction Diagram is a type of behavioural diagram used to visualize how objects in
a system interact through the exchange of messages. It focuses on the dynamic behaviour of a
system by showing what happens, when it happens, and which components
communicate during a specific process or use case. Interaction diagrams capture the
“conversation” between objects, helping designers and developers understand how parts of a
system collaborate to achieve a goal.

Purpose of an Interaction Diagram

 Visualize object collaboration: Shows how different objects or system components
communicate to perform a specific task.
 Model dynamic behavior: Represents the sequence and timing of messages exchanged
between objects during system execution.
 Clarify system logic: Helps teams understand how a particular use case or process
flows from start to finish.
 Validate design decisions: Allows designers to verify that interactions between objects
align with intended functionality.
 Identify inefficiencies or missing links: Highlights potential design gaps, redundant
communication, or logic errors in workflows.
 Facilitate team communication: Acts as a visual aid for developers, analysts, and
stakeholders to discuss system behavior clearly.
 Support debugging and maintenance: Provides a reference for tracing message flow
when troubleshooting system issues.
 Complement other UML diagrams: Works alongside structural diagrams (like Class
or Component diagrams) to give a complete picture of how a system operates.

Types of UML Interaction Diagrams

UML defines four main types of Interaction Diagrams, each highlighting a different aspect of
how system elements communicate and behave over time.

1. Communication Diagram
A Communication Diagram depicts the relationships and interactions among software objects
in a system. It focuses on the structural connections between objects rather than the timing or
sequence of messages. This makes it ideal for understanding how system components are
linked and how they collaborate to complete a task.

Components:

• Objects: Objects are described as rectangles with the name of the object on them.
They are the very subjects that perform actions with regard to each other.

• Links: Several straight lines depict the association and transmission of information
between various items.
 • Messages: Arrows are to be placed on the link to show the direction of the
communication, often accompanied by the message name and sequence number.

• Interaction Occurrences: Such may refer to situations or cases where certain social
interactions are done.

• Roles: Usually drawn as threads or individuals that interconnect to demonstrate how

one part or various users relate to another.

Advantages:

 Highlights how lifelines (objects) are connected and related.

 Focuses on system organization rather than message flow.
 Useful for visualizing object networks and component interactions.
Limitations:

 Can become complex in large systems.

 Makes it harder to analyze the behavior of specific objects.
 Often time-consuming to create and maintain for detailed processes.

2. Sequence Diagram
A Sequence Diagram illustrates how messages are exchanged between objects over time. It
provides a clear, chronological view of how operations occur within a specific process or use
case. Each object involved has a lifeline, and messages are arranged vertically in order of
occurrence. Sequence diagrams are especially useful for system modeling, debugging, and
documentation of workflows.

Notations:

• Actors: Represents a type of role where it interacts with the system and its objects.

• Lifelines: A lifeline is a named element which depicts an individual participant in a

sequence diagram.

• Activations: A thin rectangle on a lifeline represents the period during which an

element is performing an operation.
 • Call Message: Call message is a kind of message that represents an invocation of
operation of target lifeline.

• Return Message: Return message is a kind of message that represents the pass of
information back to the caller of a corresponded former message.

• Self Message: Self message is a kind of message that represents the invocation of
message of the same lifeline.

• Recursive Message: Recursive message is a kind of message that represents the

invocation of message of the same lifeline repeatedly.

• Create Message: Create message is a kind of message that represents the

instantiation of (target) lifeline.

• Destroy Message: Destroy message is a kind of message that represents the request
of destroying the lifecycle of target lifeline.

• Duration Message: Duration message shows the distance between two time instants
for a message invocation.

Advantages:

 Easy to generate, update, and maintain.

 Supports forward and reverse engineering of system logic.
 Clearly shows message order and object dependencies.
Limitations:

 Can become cluttered when too many lifelines or branches are added.
 Accuracy depends on the correct sequencing of interactions.
 Harder to interpret in highly complex scenarios.
With Creately’s Sequence Diagram Tool, you can quickly visualize interactions, define
message flows, and refine system logic.

3. Timing Diagram
A Timing Diagram focuses on changes in object states over time, often represented using
waveforms. It helps model time-sensitive behavior, showing how an object transitions
between states at specific moments. This type of diagram is crucial for analyzing real-time
systems, embedded processes, or any situation where timing and synchronization are critical.

Advantages:

 Represents object state at exact points in time.

 Supports forward and reverse engineering for precise modeling.
 Helps track state changes and response delays accurately.
Limitations:

 Can be difficult for beginners to understand or interpret.

 Requires careful maintenance as systems evolve.
 Not ideal for processes with many asynchronous interactions.
With Creately’s Timing Diagram Maker, you can effortlessly visualize state changes, signal
transitions, and object lifecycles over time..

Timing Diagram Example

4. Interaction Overview Diagram

An Interaction Overview Diagram provides a high-level summary of interactions within a
system. It acts as a control flow map connecting multiple interaction or activity diagrams.
This makes it ideal for understanding complex workflows that include branching, decisions,
or parallel interactions.

Advantages:
  Offers a clear, top-level view of activities across diagrams.
 Allows navigation between multiple interaction diagrams easily.
 Combines activity diagram features with added interaction elements for clarity.
Limitations:

 Requires consistent branching and behavioral structure.

 May oversimplify detailed interactions if not supported with sub-diagrams.

Interaction Overview Diagram Example

Activity Diagrams
• It helps visualize workflows, processes, or activities within a system.
• They depict how different actions are connected and how a system moves from one
state to another.
• They display the order in which activities happen and whether they occur one after the
other (sequential) or at the same time (concurrent).
Notations:
• Initial State
– Representation: Solid filled circle.
– Purpose: Represents the start state of the system.
 – Usage: Marks the beginning of the activity flow.
• Final State
– Representation: Circle with a solid filled circle inside.
– Purpose: Represents the termination state of the system.
– Usage: Indicates the end of the activity flow.

• Action State
– Representation: Rectangle with rounded corners.
– Purpose: Represents an operation, business activity, or process.
– Usage: Shows the actions or activities performed within the system.

• Decision
– Representation: Diamond shape with one incoming and multiple outgoing
transitions, each labeled with a guard condition.
– Purpose: Has one input and two or more outputs depending on the condition.
– Usage: Directs the flow based on specific conditions.
• Synchronization

• Fork:
– Representation: Horizontal or vertical bar with one incoming transition and
two or more outgoing transitions.
– Purpose: Divides a single activity flow into two or more concurrent activities.
– Usage: Used when multiple activities need to occur simultaneously.

• Join:
– Representation: Horizontal or vertical bar with two or more incoming
transitions and one outgoing transition.
– Purpose: Combines two or more concurrent activities into a single flow.
– Usage: Ensures that only one of the activities proceeds at a time.

• Merge
 – Representation: Diamond shape with multiple incoming transitions and one
outgoing transition.
– Purpose: Merges input flows without synchronization.
– Usage: Allows the flow to proceed without waiting for other inputs.
• Activity Partition (Swimlane)
– Representation: Vertical or horizontal lanes.
– Purpose: Visually groups actions or activities based on the organizational unit
or actor responsible for them.
– Usage: Organizes activities by responsibility or role.
• Transition
– Representation: Directed arrows connecting activity states, initial states, final
states, decision nodes, merge nodes, fork nodes, and join nodes.
– Purpose: Represents movement from the source activity state to the target
activity state.
– Usage: Shows the flow of control between activities.

Order transaction
State Machine Diagrams
• A State Machine Diagram is used to represent the condition of the system or part of
the system at finite instances of time.
• A state machine diagram example for user verification:

Notation:
• Initial state: We use a black filled circle represent the initial state of a System or a
Class.

• State: A state represents the conditions or circumstances of an object of a class at an

instant of time.

• Transition: We use a solid arrow to represent the transition or change of control from
one state to another. The arrow is labelled with the event which causes the change in
state.
• Fork: We use the fork notation to represent a state splitting into two or more
concurrent states.

• Join: We use the join notation when two or more states concurrently converge into
one on the occurrence of an event or events.

• Self transition: There might be scenarios when the state of the object does not change
upon the occurrence of an event. We use self transitions to represent such cases.
 • Composite state: We represent a state with internal activities using a composite state.

• Final State: We use a filled circle within a circle notation to represent the final state
in a state machine diagram.

Functional Modeling
• Functional modeling is the process of representing the functions and data flow of a
software system.
• Purpose
– Understand system functionality
– Describe processing of data
– Analyze system operations before development
• Common Tools Used in Functional Modeling
– Data flow diagram (DFD)
 – UML diagrams

Data Flow Diagram (DFD)

A data flow diagram (DFD) is basically a graphical representation of how the data moves
through a system. It shows the flow of data or information between processes. It provides the
representation for both the incoming and outgoing data flow.

Characteristics of Data Flow Diagram (DFD)

 Graphical Representation: A data flow diagram (DFD) uses various types of symbols, such
as circles, arrows, rectangles, and open-ended rectangles, to represent the flow of data and
system components visually.
 Data Movement Focus: It shows how the data moves through the system rather than how
the system works internally.
 Hierarchy Levels: DFD is developed in different levels, such as Level 0, Level 1, etc., to
break down the processes into more manageable parts.
 Problem Analysis: A data flow diagram (DFD) is a valuable tool for understanding and
analyzing systems, especially to find any problems in the early stages of software
development.

Components of Data Flow Diagram (DFD)

1. External Entity

The external entity is the object outside the system that interacts with the system by providing
input data or receiving output data. These external entities are also known as sources or sinks.

The important things that you should keep in mind about the external entities are:
 The external entity is represented by the rectangles in a data flow diagram (DFD).

 It initiates data flow into the system or receives the information from it.

 It should be labeled clearly with descriptive names.

Example: In an online shopping system, a “Customer” who places orders would be an

external entity.
 2. Process

The process is the function that changes the input data into the output data in the system.

The important things that you should keep in mind about the processes are:
 A process is represented by the circles or rounded rectangles in the data flow diagram.

 It shows how the data is processed, including calculations, validations, or decisions.

 Every process must have at least one input and one output data flow.

 Always use the verb-noun format to write the name of the function.

 Also, the high-level processes can be decomposed or broken down into sub-processes for
more detail in lower DFD levels.

Example: In a library system, a process like “Issue Book” would take data from a user and
then update the records in the data store.

3. Data Store

Data store represents the places where the data is stored for processing when it is needed. It
can be databases, files, or any form of data storage.

The important things that you should keep in mind about the data stores are:
 A data store is represented by an open-ended rectangle or sometimes two parallel
horizontal lines in the data flow diagram.

 The data stores allow the data to be stored and retrieved by the processes when it is
needed.

 Only processes can read from and write to data stores, and the external entities do not
directly access them.

 The data stores should be named using the noun-based labels.

 Arrows are used to show the data flow to a data store. An arrow to a data store means data
is being written, and an arrow from a data store means data is being retrieved.

Example: In a hospital management system, a data store like “Patient Records” stores the
patient details for use in various treatment processes.
 4. Data Flow

A data flow shows the movement of data between the external entities, processes, and data
stores within the system.

The important things that you should keep in mind about the data flows are:
 The data flow is represented by the arrows labeled with the name of the data being moved.

 The direction of the arrows shows the flow of the data from the source to the destination.

 Data flows link processes, external entities, and data stores together to show the
interactions between them.

 Always use noun-based labels that describe the data content for the naming of the data
flow.

Example: In an ATM system, a data flow labeled “PIN Entry” might go from the “User” to
the “Validate PIN” process.

Rules for Creating a Data Flow Diagram (DFD)

Here are a few rules that you must follow while creating a data flow diagram:
 Every process must have at least one input and one output in a data flow diagram.

 The external entities cannot exchange data directly with each other; thus, data must pass
through a process.

 Data stores must connect only to processes, not directly to other data stores or entities.

 Do not include the control flow or decision logic; only focus on the data movement.

 Maintain the consistency between DFD levels, so that the data flows match them.

Levels of Data Flow Diagram (DFD)

DFDs (data flow diagrams) in software engineering are used to show the systems at different
degrees of abstraction. The levels of the data flow diagrams are numbered as 0, 1, 2, and
higher. Here are the three main levels of the data flow diagram (DFD) that we will discuss
briefly:
 0-Level DFD (Context Diagram)

A DFD at the 0-level is also known as the context diagram. It represents the entire system as
a single process. The diagram at this level shows the interaction of the system with the
external entities. A 0-level DFD shows all the input and output data flows between the system
and the external entities. At this level, no data stores are included in the data flow diagram. It
provides a high-level overview of the system without going into the internal processes. Also,
it helps the stakeholders to understand the system boundaries and data exchanges by viewing
it once.

Let’s understand the above 0-level data flow diagram in detail.

System: Online Bookstore
Components:

The three main components in this data flow diagram (DFD) are;
 External Entities:
o Customer

o Bank
 Single Process:
o Online Bookstore System
 Data Flows:
o From Customer to System: Order Details, Payment Info

o From System to Customer: Order Confirmation, Receipt

o From System to Bank: Payment Request

o From Bank to System: Payment Confirmation

1-Level DFD
 A 1-level data flow diagram breaks down the single process from the context diagram into
multiple sub-processes. This diagram shows how the data moves between internal processes,
data stores, and external entities. It includes data stores that were not present in the context
diagram. At this level, each process is labeled and represents a specific function or operation
within the system in the data flow diagram. It shows the detailed data flows of connecting
sub-processes, data stores, and external entities. It provides a better understanding of how the
particular function works within the system. The data flow diagram at this level helps the
analysts to identify the key processes and how they interact with data inputs and outputs.

Let’s understand the above 1-level data flow diagram in detail.

System: Online Bookstore

This level breaks down the main process (from Level 0) into sub-processes for more detail.
Processes:
 1.0 Browse/Search Books

 2.0 Place Order

 3.0 Process Payment

 4.0 Send Confirmation

Data Stores:
 D1: Book Database

 D2: Order Records

 D3: Payment Info

External Entities:
 Customer

 Bank

2-Level DFD

A level 2 data flow diagram is a diagram that is further decomposed into one or more
processes from the level 1 DFD into more detailed sub-processes. This DFD provides a more
detailed and granular view of how data flows within a specific part of the system. It maintains
the same data stores and external entities from level 1, where the data seems relevant.

In a 2-level DFD, each sub-process is labeled hierarchically, such as 1.1, 1.2, etc. This data
flow diagram shows the additional data flows between the new sub-processes and the existing
data stores or entities. It highlights the internal logic and functions that make up the single-
level process. The 2-level DFD helps the developers and system designers to understand
exactly how the individual components behave and interact.

Let’s understand the above 2-level data flow diagram in detail.

System: Online Bookstore – Process 2.0 “Place Order” Breakdown

At Level 2, we decompose Process 2.0 “Place Order” from the Level 1 DFD into more
detailed sub-processes.
Processes:
 2.1 Validate Book Availability

 2.2 Create Order Record

 2.3 Confirm Stock Update

 2.4 Forward Payment Info

Data Stores:
 D1: Book Inventory

 D2: Order Records

 D3: Payment Info

External Entities:
 Customer

 Bank

Advantages of Data Flow Diagram (DFD)

1. The data flow diagram (DFD) is a visual representation of the flow of data in the system
that allows you to see the entire flow of input and output data in the system.

2. A DFD makes it easier to identify the system boundaries, sources, sinks, and data stores.

3. One of the most helpful aspects of the data flow diagram is that it forms a bridge between
the technologists and the non-technologists.

4. The DFD is very helpful in gathering the requirements and in the analysis of the system,
because it makes the processes much more understandable since they are looked at in
smaller pieces.

5. The DFD helps to find the redundancies, inefficiencies, or missing processes in the design,
and it provides this capability early in the design process.

6. The data flow diagram essentially keeps the design modular by breaking the system into
smaller sub-processes.

7. The DFD is useful for documentation or as a reference as you move through the system
development life cycle.
 Disadvantages of Data Flow Diagram (DFD)
1. A DFD can become more complex and difficult to manage for large systems with many
processes.

2. It needs a deep understanding of the system to create accurate diagrams.

3. It is not suitable for modeling system behavior over time.

4. A data flow diagram lacks the ability to represent the conditions, loops, or decision logic
clearly.

5. It is so time-consuming when there is a need to update the frequent changes.

6. It does not represent user interface elements or physical components of a system.