UNIT 2

Requirement analysis and specification – Requirements gathering and analysis – Software

Requirement Specification – Formal system specification – Finite State Machines – Petrinets
– Object modelling using UML – Use case Model – Class diagrams – Interaction diagrams –
Activity diagrams – State chart diagrams – Functional modelling – Data Flow Diagram- CASE
TOOLS.

Requirement Analysis
What is Requirement Analysis?
Requirement analysis is the process of understanding what users want from a system. Before
developing software, it is important to clearly define its functions to ensure that it meets user
needs. This process helps in making sure the software works correctly and solves the
intended problem.

Steps in Requirement Analysis

1. Requirements Gathering & Analysis
This step involves collecting and understanding the needs of users and stakeholders.
How Do We Collect Requirements?
1. Interviews
• Talk to users, managers, and stakeholders (people who will use or be affected by the
software).
• Ask questions to understand their expectations and problems.
• Example: If we are building a hospital management system, we can interview doctors
and nurses to know what features they need.
2. Surveys & Questionnaires
• Create forms with questions and distribute them to multiple users.
• This helps in collecting feedback from a large number of people quickly.
 • Example: A company planning to build an online shopping app can send surveys to
customers asking about their shopping experience.
3. Document Analysis
• Study existing documents, reports, and software related to the project.
• Helps in understanding how things currently work and what improvements are
needed.
• Example: If we are improving a payroll system, we can analyze salary slips and
payment reports to understand the current process.
4. Workshops & Brainstorming
• Arrange discussions with teams and experts to gather different ideas.
• Helps in getting creative solutions to problems.
• Example: If we are developing an e-learning platform, brainstorming sessions with
teachers and students can help identify useful features.
5. Observation
• Watch how users interact with existing systems.
• Identify problems and areas that need improvement.
• Example: If we observe cashiers in a supermarket, we may notice that their billing
software is slow, and we can improve it.
Types of Requirements
1. Functional Requirements
These define what the system should do. They describe specific actions or tasks the software
must perform.

Example:
A banking system should allow users to:
Check their account balance.
Transfer money to other accounts.
Pay bills online.
2. Non-Functional Requirements
These define how the system should perform. They focus on the quality and performance of
the system rather than specific functions.

Example:
A website should:
Load in under 3 seconds.
Handle 1,000 users at the same time without crashing.
Be accessible on both mobile and desktop devices.
Requirement Specification
Once requirements are analysed, they need to be documented properly. Requirement
Specification
A Requirement Specification is a formal document that outlines the functionalities, features,
and constraints of a system or product. It serves as a guide for developers, testers, and
designers to ensure that all stakeholders have a clear understanding of what needs to be built.
Key Aspects of Requirement Specification:
1. Acts as a Contract – It establishes a mutual agreement between developers and
customers, ensuring both parties understand the scope and expectations of the project.
2. Defines What Needs to Be Built – Provides a clear and structured description of the
system’s functionalities, performance criteria, and constraints.
3. Ensures Alignment – Helps developers, testers, and designers work in sync by
offering a common reference document.
Types of Requirement Specifications:
1. Software Requirement Specification (SRS) – A detailed document describing
software functionalities, system requirements, and constraints.
2. Business Requirement Specification (BRS) – Outlines the high-level business
objectives and needs of the system.
3. Functional Requirement Specification (FRS) – Defines specific functions and
behaviors of the system.

=================================================================

Requirements Gathering
Requirements gathering is the first and most important step in making a system. It means
collecting information about what the system should do. We talk to different people who will
use or be affected by the system. These people are called stakeholders (such as customers,
employees, and managers).
This step helps us understand what users need so we can build a system that works well for
them.
Steps in Requirements Gathering
1. Identify Stakeholders
• Stakeholders are the people who will use the system or be affected by it.
• They can be customers, employees, managers, or even company owners.
Why is this important?
• If we don’t know who will use the system, we won’t know what they need.
• Each stakeholder may have different needs, so we must consider all of them.

2. Conduct Meetings & Interviews

• We talk to different people (users, managers, employees, etc.).
• We ask them what they expect from the system.
• We listen to their problems and suggestions.
Why is this important?
• Talking to people directly helps us understand their needs better.
• We get detailed information that we might not get from surveys or observations.

3. Use Surveys & Questionnaires

• We create a set of questions and ask many people to answer them.
• These questions help us understand their needs in a structured way.
• Surveys can be online, on paper, or through phone calls.
Why is this important?
 • It helps collect information from a large number of people quickly.
• It provides clear and organized data for analysis.

4. Observe Work Processes

• We watch how people work in their daily tasks.
• We take notes on what they do, how they do it, and what problems they face.
Why is this important?
• Sometimes people don’t realize what problems they have until we observe them.
• It helps us find areas where a new system can improve their work.

5. Study Existing Systems

• If there is an old system, we check how it works.
• We find out what users like and dislike about it.
• We see which parts need improvement.
Why is this important?
• If something works well, we don’t need to change it.
• It saves time because we don’t have to build everything from scratch.

6. Create Use Cases & Scenarios

• We write small stories (scenarios) about how users will use the system.
• For example:
"A customer logs in, checks the product list, adds items to the cart, and makes a
payment."
• These stories help us design the system properly.
Why is this important?
• It shows how the system should behave in real-life situations.
• It helps developers and designers understand what needs to be built.

=================================================================
Software Requirement Specification (SRS)
A Software Requirement Specification (SRS) is a document that explains what a software
system should do. It describes the purpose of the software, how it will work, and what
features it must have.
Think of it as a blueprint for building software—just like an architect’s plan for a house. It
helps developers, testers, and users understand the software before it is built.
The SRS is like a contract between:
• The developers (who create the software)
• The users or clients (who will use the software)

SRS Components:
An SRS document typically includes the following sections:
1. Introduction
This section explains the basic details of the software:
• What is the software about?
• Why is it being created?
• How will it help users?
For example, if the software is an online shopping app, the introduction will describe:
• The app's goal (helping people buy products online)
• Who will use it (customers, sellers, admins)
• How it makes shopping easier (secure payments, fast delivery, etc.)
2. Overall Description
This part gives a broader view of the system. It includes:
• Types of users – Who will use the software? (e.g., customers, employees, managers)
• Main features – The key functions of the software (e.g., product search, order
tracking, customer support)
• Limitations or restrictions – Any boundaries for the software (e.g., available only in
certain countries, requires an internet connection)
3. Functional Requirements
These describe what the software must do. It includes all the tasks and features the system
needs to perform.
For example, in a shopping app, functional requirements may include:
 • Users can search for products.
• Users can add products to their cart.
• Users can proceed to checkout and make payments.
• Admins can add or remove products from the store.
Each function is explained clearly so developers know exactly what to build.
4. Non-Functional Requirements
These describe how well the software should perform. They focus on quality, including:
• Performance – How fast should the app load? How many users can it handle at once?
• Security – How will user data be protected? Will it use encryption?
• Reliability – Will the system work properly even during heavy usage?
• Usability – How easy is it to navigate and use the app?
For example:
• The shopping app should load within 3 seconds.
• It should encrypt customer payment details for security.
• It should be available 24/7 without crashing.
5. Constraints
This section lists the rules and limitations the software must follow. These could be
technical, legal, or business-related.
Examples:
• The software must be built using Python and MySQL.
• It must comply with data protection laws like GDPR.
• It must support both Android and iOS devices.

Why is an SRS Important?

✔ Prevents misunderstandings – Everyone knows what to expect.

✔ Acts as a guide – Developers and testers can refer to it during software development.

✔ Helps in testing – Ensures that the final software meets all requirements.

✔ Saves time and cost – Avoids rework and confusion by having clear expectations from the
start.
=================================================================
Formal System Specification
A Formal System Specification is a method of defining a system using mathematical and
logical notations to ensure accuracy, consistency, and completeness. It helps in designing
error-free systems by providing a precise and unambiguous description of system behavior.

Main Components of Formal Specification

1. Specification Language
• This is a structured way of writing system rules using mathematical symbols and
logic.
• Unlike normal language, which can be unclear, a specification language ensures
precise and accurate descriptions.
• Examples of formal specification languages: Z notation, VDM (Vienna
Development Method), Alloy, and B-method.
Example:
Think of giving directions to a robot. If you use simple English, it may misunderstand. But if
you use clear mathematical steps, the robot will always follow them correctly.

2. Mathematical Logic
• It is a set of rules that describe what actions should happen based on conditions.
• It ensures that the system behaves exactly as expected.
• It follows an "If-Then" structure.
Example:
• If a user enters the correct username and password, they should be logged in.
• If they enter the wrong password three times, their account should be locked.
This ensures that the system follows strict rules without errors.

3. Set Theory
• Set Theory is a way of grouping things together.
• It helps define valid inputs for the system.
Example:
• Suppose we have a set of valid passwords:
o Valid passwords: "pass123", "admin2024", "welcome!"
 • A user can only log in if their password is in this set.
• If the user enters a password that is not in the set, login will fail.
This prevents errors and makes sure only valid users can access the system.

4. State and Transition

• A state is the current condition of the system.
• A transition is a change from one state to another based on actions.
Example: Login System States
A user can be in one of these states:
1. Logged Out – When they have not logged in yet.
2. Logged In – After entering the correct username and password.
3. Locked – If they enter the wrong password too many times.
How State Transitions Happen:
• If the login is successful, the user moves from Logged Out → Logged In.
• If the user enters the wrong password three times, the system moves from Logged
Out → Locked.
• If the account is Locked, the user cannot log in anymore.
This ensures strict security and proper system behavior.
=================================================================

Finite State Machines

A Finite State Machine (FSM) is a way to describe how a system behaves using states and
transitions between those states. It is like a flowchart where something can be in one state at
a time and can switch to another state based on certain conditions.
Imagine you are using a traffic light. The traffic light can be in only one of three states:
1. Red
2. Yellow
3. Green
It changes from one state to another based on time or sensors. This is an example of a finite
state machine because:
• It has a limited number of states (finite states).
• It can switch from one state to another based on conditions.
• It can be in only one state at a time.
Components of a Finite State Machine
1. States
A state is like a “mode” or “condition” of a system. At any time, the system can be in only
one state.
Example: A Fan
Think about an electric fan with three settings:
• State 1: Fan is OFF
• State 2: Fan is running at LOW speed
• State 3: Fan is running at HIGH speed
The fan can only be in one state at a time. It cannot be OFF and ON at the same time.
2. Transitions
A transition is how the system moves from one state to another. It happens because of some
event or action.
Example: Fan Transitions
• If the fan is OFF and you press the switch, it moves to LOW speed.
• If the fan is at LOW speed and you press the switch again, it moves to HIGH speed.
• If the fan is at HIGH speed and you press the switch again, it turns OFF.
So, the fan transitions between OFF → LOW → HIGH → OFF based on pressing the
switch.
3. Inputs
An input is something that makes the system change its state.
Example: Fan Inputs
• Pressing the switch → Changes the speed.
• Unplugging the fan → Turns it OFF immediately.
• Power outage → Turns it OFF automatically.
Inputs cause transitions between states.
4. Outputs
An output is what happens as a result of being in a state or changing states.
Example: Fan Outputs
• If the fan is in LOW speed, the blades rotate slowly.
• If the fan is in HIGH speed, the blades rotate fast.
 • If the fan is OFF, the blades stop moving.
These are the results (outputs) of being in a particular state.
Types of Finite State Machines
(a) Deterministic Finite State Machine (DFA)
• "Deterministic" means fixed and predictable.
• At any state, there is only one possible next state for each input.
• If you give an input, you always know what will happen next.
• Example: A vending machine – if you insert the correct money, you always get the
product.

(b) Non-Deterministic Finite State Machine (NFA)

• "Non-Deterministic" means there are multiple possible next states.
• A given input might lead to different states instead of one fixed state.
• The system might choose a path randomly or based on probability
• Example: A chatbot – based on user input, it may give different responses.

Example: A Simple Door Lock System

• Locked State → User enters the correct code → Unlocked State.
• Unlocked State → After 5 seconds → Locked State again.
Current State Input Next State
Locked Correct Code Unlocked
Unlocked Wait 5 secs Locked
This is a basic FSM where the door can only be in Locked or Unlocked states.
=================================================================

Petrinets
A Petri Net is a mathematical model used to describe systems where things happen step by
step. It is widely used to study and design computer systems, workflows, and processes
where multiple activities occur at the same time.

Basic Components of a Petri Net

A Petri Net has four main parts:
1. Places (Represented as Circles ⚪)
What are Places?
• Places represent conditions or states in a system.
• Think of places as "waiting spots" for things to happen.
Example:
Imagine a machine in a factory. The machine can be in different states:
• Idle (not working)
• Busy (working on something)
In a Petri Net, we draw a circle for each state.
• A circle labeled "Idle" means the machine is not doing anything.
• A circle labeled "Busy" means the machine is working.

2. Transitions (Represented as Rectangles 🔲 or Bars)

What are Transitions?
• Transitions represent actions or events that can happen in the system.
• Think of transitions as "buttons" that make things change.
Example:
For the machine, two actions are possible:
1. Start Working (when the machine begins a task)
2. Finish Task (when the machine completes the task)
In a Petri Net, we draw a rectangle or bar for each action.
• A rectangle labeled "Start Working" means the machine starts.
• A rectangle labeled "Finish Task" means the machine completes its work.
3. Tokens (Represented as Dots 🔴 inside Circles ⚪)
What are Tokens?
• Tokens represent the current state of the system.
• A token inside a place means that condition is true right now.
Example:
• If there is a token inside "Idle", the machine is currently not working.
• When the machine starts working, the token moves to the "Busy" place.
Think of tokens as markers that tell us where we are in the process.

4. Arcs (Represented as Arrows ➝)

What are Arcs?
• Arcs show the flow of the process.
• They connect places to transitions and transitions to places.
Example:
• An arrow connects "Idle" (Place) to "Start Working" (Transition).
o This means that when the machine is idle, it can start working.
• Another arrow connects "Start Working" (Transition) to "Busy" (Place).
o This means that after starting, the machine is now busy.
Arcs guide the movement of tokens in the Petri Net.

Petri Net Working:

A Petri Net works like a step-by-step system that shows how things change over time. The
key idea is that transitions "fire" when the right conditions are met. Let’s break this down
with a simple example.
Step 1: Tokens Show the Current State

• A token (●) inside a place (⚪ circle) tells us what is happening right now.
• A system starts with tokens in certain places.
• Example: If a machine is Idle, a token will be inside the Idle place.
Step 2: A Transition "Fires" When the Right Condition is Met

• A transition (🔲 rectangle) represents an action or event.

• A transition can only happen (or "fire") if there are enough tokens in its input
place.
Example:
• A transition "Start Working" is connected to the Idle place.
• If there is a token in Idle, that means the machine is ready to start.
• Since the Idle place has a token, the Start Working transition can fire.
Step 3: Tokens Move from Input to Output Places
• When a transition fires, it takes tokens from the input place and moves them to the
output place.
Example:
1. The "Start Working" transition fires.
2. The token in Idle is removed.
3. A new token appears in Busy, showing that the machine is now working.
Step 4: The Process Repeats
• After some time, the machine finishes its work.
• The "Finish Task" transition fires.
• The token moves from "Busy" back to "Idle", showing that the machine is ready
for a new task.
• This cycle repeats again and again.

=================================================================

Unified Modeling Language (UML)

UML (Unified Modeling Language) is a set of diagrams that help software developers design
and plan object-oriented systems. It has become the industry standard for representing
how software systems work.
UML was developed by James Rumbaugh, Grady Booch, and Ivor Jacobson and was
later approved by the Object Management Group (OMG) as a standard for software
development.
• Helps developers understand and communicate how a system will work.
• Breaks down complex systems into easy-to-understand diagrams.
• Covers different aspects of software development, such as user interactions, data
structures, processes, and system components.
Main UML Diagrams and Their Purpose
UML Diagram What It Represents
Use Case Diagram How the system interacts with users.
Class Diagram The data elements (classes) in the system and how
they relate to each other.
Interaction Diagram (Sequence & How objects work together to perform a function.
Collaboration)
State Diagram How an object behaves throughout different use
cases.
Activity Diagram The sequence of activities that make up a process.
Component Diagram The different software components and their
dependencies.
Deployment Diagram The hardware and software elements and their
physical relationships.

Detailed Explanation of Each UML Diagram

1. Use Case Diagram
• Shows how a user (actor) interacts with the system.
• Represents different functions (use cases) of the system.
• Example: In a Library Management System, users can borrow books, return
books, and search books.
2. Class Diagram
• Shows the structure of the system by defining classes, their attributes (data), and
their relationships.
• Example: A Library has many Books, and a Book has a Title, Author, and ISBN.
3. Interaction Diagram (Sequence & Collaboration)
• Sequence Diagram: Shows the step-by-step flow of messages between objects over
time.
• Collaboration Diagram: Focuses on how objects are connected to achieve a
function.
• Example: A Member requests a book → The Library System checks availability →
The book is issued.
4. State Diagram
 • Shows how an object behaves in different situations.
• Example: A Book in a library can be Available → Borrowed → Reserved →
Returned.
5. Activity Diagram
• Represents the flow of activities in a process.
• Example: In an Online Shopping System, activities include Selecting a Product →
Adding to Cart → Making Payment → Shipping.
6. Component Diagram
• Shows the different software components and their dependencies.
• Example: A Banking System has components like User Interface, Database, and
Payment Processor.
7. Deployment Diagram
• Represents how software is deployed on hardware.
• Example: A Web Application may run on a server, with a database stored on
another machine.
=================================================================

Use Case Model

A Use Case Model is a visual representation of how a system interacts with users and other
systems. It helps developers and stakeholders understand what the system does, who uses it,
and how it behaves in different situations.
A Use Case Model consists of:
1. Actors – Who interacts with the system (users or other systems).
2. Use Cases – The actions or functions that users can perform.
3. Relationships – The connections between actors and use cases.
Components of a Use Case Model
1. Actor
• An actor is a user or an external system that interacts with the software.
• Actors can be humans (customers, employees) or other software systems (payment
gateways, databases, etc.).
Types of Actors
1. Primary Actor – The main user who initiates the interaction with the system.
o Example: A Customer placing an order in an online shopping system.
 2. Secondary Actor – A system or user that helps complete the process but does not
start it.
o Example: A Payment System that processes payments in an online shopping
system.
Examples of Actors in Different Systems
A. Online Shopping System
• Customer (Primary Actor) – Places orders.
• Admin (Secondary Actor) – Manages inventory.
• Payment System (Secondary Actor) – Handles transactions.

2. Use Case
• A use case represents a function or action performed by the system.
• It describes what the system does in response to an actor’s request.
• Each use case delivers a specific outcome to the user.
Examples of Use Cases in Different Systems
A. Online Shopping System
• Browse Products – A customer views available products.
• Add to Cart – A customer selects products for purchase.
• Make Payment – The system processes the payment.
• Track Order – A customer checks order status.
3. Relationships
What are Relationships in a Use Case Model?
• Relationships define how actors and use cases are connected.
• There are three main types: Association, Include, and Extend.
A. Association Relationship
• Definition: A direct connection between an actor and a use case.
• Meaning: The actor uses the use case.
• Example:
o In an online shopping system:
▪ A Customer is associated with the Make Payment use case.
Diagram Representation:
scss
CopyEdit
(Customer) ------> (Make Payment)
B. Include Relationship
• Definition: A use case always includes another use case.
• Meaning: The included use case is mandatory whenever the main use case runs.
• Example:
o "Make Payment" always includes "Payment Confirmation" in an online
shopping system.
Diagram Representation:
scss
CopyEdit
(Make Payment) --------> (Payment Confirmation) [<<include>>]
• Whenever "Make Payment" happens, "Payment Confirmation" must occur.

C. Extend Relationship
• Definition: A use case may optionally extend another use case.
• Meaning: The extended use case happens only under certain conditions.
• Example:
o In an ATM system:
▪ "Withdraw Cash" may extend "Print Receipt", but printing the
receipt is optional.
Diagram Representation:
scss
CopyEdit
(Withdraw Cash) --------> (Print Receipt) [<<extend>>]
• The "Withdraw Cash" use case can work without printing a receipt, but if the user
selects the option, the "Print Receipt" use case will be executed.
How a Use Case Model Works
Let’s take an Online Shopping System as an example.
Step 1: Identify the Actors
Actors are users or external systems that interact with the online shopping system.
• Customer (Buys products)
• Admin (Manages inventory and orders)
• Payment System (Processes transactions)
Step 2: Identify the Use Cases
Use cases are the actions performed by the system for the actors.
• Browse Products – Customer views products.
• Add to Cart – Customer selects products.
• Make Payment – Customer completes the purchase.
• Track Order – Customer checks delivery status.
• Manage Inventory – Admin updates product details.
Step 3: Define Relationships
• Customer → Browse Products (Association: Customer can browse products)
• Customer → Make Payment → Payment System (External Interaction)
• Admin → Manage Inventory (Admin updates stock)
• Make Payment → Payment Confirmation (Include Relationship: Payment always
includes confirmation)
=================================================================

Class Diagram
A Class Diagram is a visual representation that shows how different parts of a system (called
"classes") are connected.
Components:
1. Classes – These are like templates or blueprints for creating objects in a program.
Each class represents something meaningful in the system, like a Book or a Member.
2. Attributes – These are pieces of data stored in a class. For example, a Book class
might have an attribute for its title or author.
3. Methods – These are functions inside a class that define what the class can do. For
example, a Library class might have a method to AddBook() or IssueBook().
 4. Relationships between classes – These define how different classes are connected to
each other. For example, a Member class might have a relationship with the Book
class, showing that a member can borrow a book.
(Draw empty diagram and mark the parts)
Example – Library System Class Diagram
Imagine a library system where:
• A Library has books and manages them.
• A Book has details like title, author, and ISBN.
• A Member can borrow books from the library.
Here’s how the classes would look:
Classes and Their Details:
1. Book
o Attributes: Title, Author, ISBN
o Methods: Borrow(), Return()
2. Member
o Attributes: Name, MemberID
o Methods: Register(), BorrowBook()
3. Library
o Attributes: Name, Address
o Methods: AddBook(), IssueBook()
Relationships:
• A Library contains many Books.
• A Member can borrow a Book from the Library.
Why Use Class Diagrams?
• Helps in software design: Before writing code, developers can plan how data will be
organized.
• Defines structure clearly: Shows how different classes interact, making it easier for
teams to understand the system.
• Saves time: Reduces confusion during coding and helps in debugging.
=================================================================
Interaction Diagrams
These diagrams show how objects interact with each other during system execution. There
are two types:
A. Sequence Diagram
B. Collaboration Diagram

A. Sequence Diagram
A sequence diagram shows the step-by-step interaction between objects in a system. It
focuses on the order of events and how messages are passed over time.
Key Features:

✅ Shows the flow of messages between objects.

✅ Displays events in the order they happen.
✅ Uses vertical lines (lifelines) to represent each object.
✅ Arrows indicate messages sent between objects.
Example: ATM Withdrawal Process
Let's say a person is withdrawing money from an ATM. The sequence of events would be:
1. User inserts card into the ATM.
2. ATM asks for a PIN (sends a message to the user).
3. User enters the PIN (sends a message back to the ATM).
4. ATM verifies details by contacting the Bank Server.
5. Bank Server checks the details and sends a response.
6. ATM dispenses cash if the withdrawal is approved.
This diagram helps understand how each step follows the previous one and how objects
communicate in a specific order.
B. Collaboration Diagram
A collaboration diagram (also called a communication diagram) is similar to a sequence
diagram but focuses on how objects are connected and work together. Instead of focusing on
the order of events, it highlights relationships between objects and how they interact to
complete a task.
Key Features:

✅ Shows objects as circles or rectangles.

✅ Arrows between objects represent messages exchanged.
✅ Numbers or labels may indicate the order of messages.
Example: ATM Withdrawal Process (Collaboration Diagram)
In this case, the diagram would show:
• The User connected to the ATM.
• The ATM connected to the Bank Server.
• Arrows between them showing the exchange of messages.
The main difference from a sequence diagram is that a collaboration diagram does not
emphasize time—it focuses more on how objects are linked and work together.

=================================================================

Activity Diagram
An Activity Diagram is a simple way to show how a process works step by step. It helps us
understand what happens first, what happens next, and how the process ends.
It is like a flowchart, where we use arrows to show the flow of activities. Each step is called
an activity, and the arrows show the order in which the activities happen.
Why Do We Use an Activity Diagram?
Activity diagrams are useful for many reasons:
1. Understanding a process – It helps us see the steps in a task or a system.
2. Finding problems – It helps identify issues, delays, or inefficiencies.
 3. Making improvements – Once we see the process clearly, we can make it better.
4. Software design – Programmers use activity diagrams to design how software will
work.
Components of an Activity Diagram
1. Initial Node (Start)
o Represents the starting point of the workflow.
o Depicted as a solid black circle.
2. Activity/Action
o Represents a task or operation in the workflow.
o Depicted as a rounded rectangle.
o Example: "User logs in," "Process order."
3. Control Flow (Arrow)
o Shows the sequence of activities.
o Depicted as a solid arrow pointing from one action to the next.
4. Decision Node (Branching)
o Represents conditional paths (like an IF-ELSE decision).
o Depicted as a diamond shape.
o Example: "Is payment successful?" → Yes → "Ship order"; No → "Retry
payment."
5. Merge Node
o Combines multiple alternative flows back into a single flow.
o Also represented as a diamond but used to join paths.
6. Fork Node (Parallel Execution)
o Splits the workflow into multiple parallel activities.
o Depicted as a thick horizontal or vertical bar.
7. Join Node
o Merges parallel activities back into a single flow.
o Also represented as a thick bar.
8. Swimlanes
o Divides the diagram into sections representing different actors, departments,
or systems.
 o Helps clarify responsibilities for each activity.
9. Signals (Send/Receive)
o Represents asynchronous communication or external events.
o Depicted as an envelope icon.
10. Final Node (End)
• Represents the termination of the process.
• Depicted as a solid black circle with an outer ring.
Eg:-

State Chart Diagram

A State Chart Diagram is a type of diagram used in software design to show how an object
changes from one state to another based on different events. It helps us understand how
something behaves over time when different actions occur.
Basic Components of a Statechart Diagram
1. Initial State – A black-filled circle represents the initial state of a system or a class.

2. Transition – A solid arrow is used to indicate the transition or shift of control from
one state to another. The arrow is labeled with the event that triggers the state change.
3. State – A rounded rectangle represents a state. It defines the conditions or
circumstances of an object in a class at a specific moment in time.

4. Fork - A rounded solid rectangular bar is used to represent a fork notation, where an
incoming arrow originates from the parent state and outgoing arrows point toward the
newly created states. This notation is used when a state splits into two or more
concurrent states.

5. Join-A rounded solid rectangular bar is used to represent a join notation, where
incoming arrows come from multiple joining states and an outgoing arrow leads to the
common goal state. The join notation is used when two or more concurrent states
merge into a single state upon the occurrence of an event.

6. Self transition - We use a solid arrow pointing back to the state itself to represent aself
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.
 7. Composite state - We use a rounded rectangle to represent a composite
state also. We represent a state with internal activities using a composite
state.

8. Final state - We use a filled circle within a circle notation to represent

the final statein a state machine diagram.

Steps to draw a state diagram

1. Identify the initial state and the final terminating states
2. Identify the possible states in which the object can exist (boundary
values corresponding to different attributes guide us in identifying
different states).
3. Label the events which trigger these transitions.
Example - state diagram for an online order –

=================================================================
Functional Modeling
Functional modeling is a method used in system analysis and design that focuses on what a
system does rather than how it works. It represents the system's functions, processes, inputs,
and outputs, ensuring that the system's behavior is well understood before implementation.
Key Aspects of Functional Modeling:
1. Descriptive, Not Procedural:
o Functional modeling describes the functions of a system without detailing
how those functions are implemented internally.
o It answers the “what” rather than the “how.”
2. Focus on Inputs, Processes, and Outputs:
o Input: The data or actions provided by users or other systems.
o Process: The transformation of input data into meaningful outputs.
o Output: The result produced after processing, which could be a report, a
confirmation message, or a completed transaction.
3. Systematic Representation:
o It provides a structured way to analyze system requirements before
development.
o It helps in understanding and documenting the expected behavior of a system.
Common Functional Modeling Techniques:
1. Data Flow Diagrams (DFD):
o Graphically represents how data moves within a system.
o Shows relationships between inputs, processes, and outputs.
2. Use Case Diagrams:
o Depicts interactions between users (actors) and the system.
o Helps in identifying functional requirements.
3. Activity Diagrams:
o Describes the workflow of processes within a system.
o Useful in visualizing decision points and process sequences.

Example: Functional Modeling in a Banking System

Consider a banking system where a user wants to transfer money. The functional model can
be outlined as follows:
1. Inputs:
• The user enters their account details (username, password, account number).
• The user enters transaction details (recipient account, amount to transfer).
2. Function (Processes):
• The system verifies the user’s identity (authentication).
• It checks for sufficient funds in the account.
• If all checks pass, the system processes the transaction.
3. Output:
• The system completes the transaction.
• A confirmation message is sent to the user (via SMS or email).

Uses of Functional Modeling:

1. Requirement Analysis
2. System Functionality Definition
3. Improved Communication
4. Foundation for Further Design
=================================================================

Data Flow Diagram (DFD)

A Data Flow Diagram (DFD) is a graphical representation that illustrates how data moves
within a system. It visually depicts:
• The flow of information between different entities.
• How data is processed and transformed.
• The interaction between external users and the system.
DFDs are widely used in system analysis and design, helping developers and stakeholders
understand the overall functionality of a system.
Example – The following diagram illustrates a process called Compute_HCF_LCM, which
takes two integers as inputs and produces their HCF (Highest Common Factor) and LCM
(Least Common Multiple) as outputs.
Key Elements of a DFD
A DFD consists of four main components:
1. External Entities (Sources or Sinks)
o These are external users, organizations, or systems that provide or receive data
from the system.
o Represented by rectangles.
2. Processes
o These are operations that transform incoming data into outgoing data.
o Represented by circles or ovals.
3. Data Stores
o These hold data for future processing or retrieval.
o Represented by two parallel horizontal lines.
4. Data Flows
o These represent the movement of data between entities, processes, and data
stores.
o Represented by arrows.

Levels of a DFD
DFDs are divided into different levels based on detail:
Level 0 (Context Diagram)
• The highest-level DFD, providing an overview of the entire system.
• Shows the system as a single process, with external entities interacting with it.
Level 1 (More Detailed Breakdown)
• Expands on Level 0 by breaking the system into multiple processes.
• Shows major functions and their interactions.

Level 2 (More Granular Details)

• Further breakdown of each process in Level 1.
• Includes sub-processes within each function.

=================================================================
CASE Tools (Computer-Aided Software Engineering Tools)
What Are CASE Tools?
Computer-Aided Software Engineering (CASE) tools are software applications that help
automate different phases of the software development lifecycle (SDLC). These tools assist
software engineers, developers, and project managers in designing, coding, testing, and
maintaining software applications. By automating various tasks, CASE tools improve
productivity, enhance software quality, and reduce development time.

Types of CASE Tools

CASE tools can be categorized based on the stage of software development they assist in.
The three main types are:
1. Upper CASE Tools
Upper CASE (Computer-Aided Software Engineering) tools focus on the early stages of the
software development lifecycle, such as planning, requirement analysis, and design. These
tools help in structuring and organizing software development projects by providing
graphical representations and models.
Examples of Upper CASE Tools:
• UML Modeling Tools – Used to create Unified Modeling Language (UML) diagrams
that visually represent software architecture and design.
• ER Diagram Tools – Used for designing database schemas and relationships.
• Data Flow Diagram (DFD) Tools – Help in visualizing how data moves within a
system.

2. Lower CASE Tools

Lower CASE tools focus on the later stages of software development, such as coding,
debugging, testing, and maintenance. These tools help developers automate tasks related to
software implementation.
Examples of Lower CASE Tools:
• Code Generators – Automatically generate source code from design models.
• Debugging Tools – Help find and fix errors in the source code.
• Testing Tools – Automate unit testing, integration testing, and performance testing.

3. Integrated CASE Tools

Integrated CASE tools (I-CASE) provide an end-to-end solution by covering both upper
CASE (design and modeling) and lower CASE (coding, testing, and maintenance). These
tools support the entire SDLC by offering a unified environment for developers and
designers.
Examples of Integrated CASE Tools:
• IBM Rational Rose – A comprehensive tool for object-oriented design and modeling.
• Visual Paradigm – A tool that supports UML modeling, database design, and code
generation.
• Oracle Designer – Helps in database design, application development, and process
modeling.

Uses of CASE Tools

CASE tools are widely used in software development for several key reasons:
1. Speeds Up Development with Automation
2. Reduces Errors with Structured Design
3. Improves Collaboration Between Teams

========================================================