Software

Requirements Analysis
and Modeling
What is Requirement
Engineering
● Requirement Engineering is the process of
understanding what a software system must
do.
● Goal: To collect, analyze, document, and
manage user needs clearly and completely.
Why It’s Important:
● Avoids confusion
● Saves time and money
● Helps build the right product
Types of Requirements
Functional: What the system should do.

Eg. College Student Portal

● Students can log in using roll number and password.
● Students can view attendance percentage.
● Teachers can upload internal marks.
● Admin can generate monthly reports for each dept.
Non-functional: How the system should
work, for eg. –
● Passwords shall be encrypted using
SHA-256.
● Users shall be locked out after 3 failed
login attempts.
● The interface shall be mobile-friendly and
responsive.
● New users shall be able to learn to use the
app within 10 minutes.
● Navigation shall be intuitive and require no
training.
Business: describe the high-level goals or
objectives of the organization that the software
system should fulfill.
Eg. College Management System
● The system must reduce paperwork by
90% within one semester.
● The goal is to automate student
attendance and fee tracking.
● Help the administration generate reports in
1 click instead of manual effort.
User: User Requirements describe what
tasks or features the end-users (students,
teachers, customers, staff, etc.) expect from the
system.
e.g., College Management System
● A student should be able to log in and view
attendance.
● Teachers should be able to upload internal
marks easily.
● Admin should be able to generate student
ID cards with one click.
System: System Requirements define the
hardware, software, network, and platform
conditions needed for the software to run properly.
e.g., Hardware Requirements
● Minimum RAM: 4 GB
● Processor: Intel i5 or better
● Hard Disk: 500 GB free space
● Display: 1920x1080 resolution

🟢 Example: "The software should run on lab

computers with 8 GB RAM and 1 TB HDD."
Steps in Requirement
Engineering
1. Requirement Elicitation
Talk to users, observe, and gather needs
● Example: Meet college staff to know
what they want in the app
2. Requirement Analysis – Study the needs, find
conflicts or missing parts
● Example: One teacher wants attendance
weekly, one wants monthly
3. Requirement Specification
An SRS (Software Requirement
Specification) is a formal document that
defines the complete requirements of the
software — what it should do, how it should
behave, and any constraints.
● Serves as an agreement between client and
developer
● Helps developers know what to build
● Helps testers know what to test
4. Requirement Validation – Check if the
requirements are correct and complete
● Example: Review SRS with the
college to get approval for the College
Management System.
5. Requirement Management – Requirement
Management is the process of tracking,
controlling, and updating software
requirements throughout the software
development life cycle (SDLC). For eg :-
Client may change their mind mid-project
New laws or policies may affect requirements
Budget, timeline, or technology might
change.
Prevent scope creep and confusion.
Requirement Elicitation
Techniques
 (Assume a College Management
System as an example)
● Interviews: Ask users directly –
e.g., Ask principal for daily reports
on the system.
● Questionnaires: Provide forms for
feedback – e.g., Teachers fill
forms and give reviews on
features.
● Observation: Watch current
system – e.g., Observe how marks
are entered
● Document Analysis: Study old
systems – e.g., Look at paper
forms of attendance
● Workshops: Group discussion –
e.g., Meeting with teachers &
admin team
● Prototyping: Sample screens –
e.g., Create mock screen of login
page
Assignment - 1
(1 page)
Step 1: Select a Software Product
Eg. College Attendance System, Online Food Ordering App

Step 2: Perform the Following Tasks

1. Introduction of the Software Product
Who will use it? What is the purpose?

2. Identify Types of Requirements

■ 3 Functional Requirements
■ 2 Non-functional Requirements
■ 1 Business Requirement
■ 1 User Requirement
■ 1 System Requirement

3. Explain how you would do these for your selected product:

■ Requirement Elicitation
■ Requirement Analysis
■ Requirement Specification
■ Requirement Validation
■ Requirement Management

4. Apply at Least 3 Elicitation Techniques

Sample questions or outputs (e.g., interview questions)
Requirement Modeling
● Requirement modeling means creating
simple visual diagrams or pictures that
show what a system needs to do and what
rules it must follow.
● This helps everyone involved—like
developers, clients, and users—clearly
understand how the system should work
and what limits it has.
● It uses different types of modeling
methods to study and show the
requirements from different viewpoints.
 Types of
Requirement Models
(1) Scenario-based Model
Use Case Diagrams
1) Use Case Diagram:
It is used in software engineering to show
how users interact with the system.
● It answers the question: “What does the
system do?” (functions / uses)
● Shows system functions from a user's
perspective
● It helps visualize user-system interaction
clearly.
Use Case Diagrams Elements
Main elements:
a) Actors – People or other systems
interacting with your system (e.g.,
customer, admin).
b) Use Cases – The tasks or services the
system performs (e.g., login, place order).
c) System Boundary – A box that defines
what is inside the system and what is not.
Use Case Diagrams
Relationships
1) Association Relationship
The Association Relationship
represents an interaction between an
actor and a use case. It signifies that
the actor is performing the function
described by the use case.
Example: Online Banking System
● Actor: Customer
● Use Case: Transfer Funds
● Association: A line indicating the
customer performing the funds transfer
process.
1) 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.
● Use Cases: Create Post, Add Image
● Include Relationship: The "Create
Post" use case includes the
functionality of "Add Image."
Therefore, creating a post includes
the action of adding an image.
1) 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.
● 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.
1) Generalization Relationship
It indicates 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.
● Use Cases: Rent Car, Rent Bike
● Generalization Relationship: Both
"Rent Car" and "Rent Bike" are
specialized versions of the general
use case "Rent Vehicle."
Use Case Diagrams Example
● Actors:
○ Customer
○ Admin
● Use Cases:
○ Browse Products
○ Add to Cart
○ Checkout
○ Manage Inventory (Admin)
● Relations:
○ The Customer can browse
products, add to the cart, and
complete the checkout.
○ The Admin can manage the
inventory.
 (2) Flow models
Data Flow Diagrams
● A DFD is a picture that shows how
data moves in a system
● It shows data coming in, data going
out, and data stored
● Gives a simple overview of what the
system does
● Easy to understand for both technical
and non-technical people
Levels of DFD
● Each level shows more detail about the
system
● Higher levels mean more detailed
diagrams
● Levels include:
○ 0-Level (Context Diagram)
○ 1-Level
○ 2-Level
○ 3-Level
0-Level DFD (Context Diagram)
● The top-level or most basic
diagram
● Shows the system as one single
process
● Shows how outside entities interact
with the system
● Shows major data going in and out
and where it is stored
1-Level DFD
● Gives more details than 0-Level
● Breaks the one big process into
smaller parts (called sub-processes)
● Shows how each smaller process
works
● Also shows data flow and data
stores for each part
2-Level DFD
● Breaks down the smaller
processes from Level 1 into even
more details
● Shows what happens inside each
sub-process
● Useful for closely looking at a
specific part of the system
3-Level DFD
● Gives the most detailed picture
● Shows:
○ All tiny processes
○ How every bit of data moves
○ Where every piece of data is kept
● Used for very complex systems
Types of DFD
Logical DFD
● Shows what the system does
● Doesn’t show tech stuff like
devices or servers
● Example: Shows how data moves
in a bank or online store
Physical DFD
● Shows how the system is actually
built and works
● Includes details like devices,
storage, and programs used
Components of DFD
1. Process
○ Function that transforms input data
into output data
○ Has a short name that tells what it
does, eg. calculate bill.
2. Data Flow
○ Arrow direction shows where
data is going.
3. Data Store (Warehouse)
○ A place where data is saved to
use later
○ Can be a file, folder, disk, cabinet,
etc.
○ Data going out = reading, Data
going in = writing or updating
4. External Entity (Terminator)
○ Something outside the system
○ Connects to the system but isn’t
part of it
○ Examples: Customer, client,
other departments
Rules of DFD
Data Can Flow Between:
● External Entity → Process
● Process → External Entity
● Process → Data Store
● Data Store → Process
● Process → Process
Data Cannot Flow Between:
● External Entity → Another External
Entity
● External Entity → Data Store
● Data Store → External Entity
● Data Store → Another Data Store
Example
0-Level DFD Example: Railway
Reservation
● Shows the full railway reservation
system as just one process
● Arrows show input/output between
users and other systems
● Does not show what happens
inside
2-Level DFD Example: Railway
Reservation
● Breaks each part from Level 1 into
smaller tasks:
○ Book Ticket → Validate Info →
Update Database → Confirm
Ticket
● Shows exactly what happens inside
each smaller process
(3) Class-based models
Class Diagram
In this system, we have two main entities:
Book and Library. Each Library contains
multiple Books, and each Book belongs to
a specific Library.
The directed association arrow may point from
the "Teacher" class to the "Course" class,
indicating that a teacher teaches a specific
course.
Employees belong to the company, and the
company can have multiple employees.
However, if the company ceases to exist,
the employees can still exist independently.
Each contact entry is fully owned and managed
by the contact book. If the contact book is
deleted or destroyed, all associated contact
entries are also removed.
Eg, in bank accounts, we can use
generalization to represent different types
of accounts such as current accounts,
savings accounts, and credit accounts.
Both the Person and Corporation classes
implement the "acquire(property)" and
"dispose(property)" methods defined in the
interface.
However, the Book class does not depend
on the Person class; it can exist
independently and does not rely on the
Person class for its functionality.
The "Car" class may need to access methods or
attributes of the "FuelTank" class to check the
fuel level, refill fuel, or monitor fuel
consumption.
(4) Behavioural Models
State Diagram
SOFTWARE REQUIREMENT
SPECIFICATIONS
Assignment 2:
● Create a scenario-based model and
data flow model for the topic
chosen in Assignment 1.

● Also, create an SRS Document.