Requirement Analysis and Specification_SE

Software Engineering
Prepared by:
Asst. Prof. Nikul Zinzuvadiya

Unit-4 Requirement Analysis and Specification

What are “Requirements” and why do we need them?
Requirement = a need or expectation from a system.
If we build a system without clear requirements, we’ll build the wrong thing perfectly.
A requirement in software engineering is a statement that describes:
● What the software system should do (its functionality), or
● How the system should behave (its performance, limits, conditions, etc.)

What is Requirements Engineering (RE)?
RE is the front part of software development where we
(1) discover what the system must do (services/functions)
(2) define the limits and rules it must obey (constraints).
Then we write this down clearly so everyone agrees before coding.

1. Establishing the Services (Functional Requirements):
These are the features or functions the system must perform.
Example:
In a Student Attendance System, the services might be:
Teachers can mark attendance.
Students can view their attendance.
Admin can generate attendance reports.
It answers:
"What should the system do?

2. Constraints (Non-Functional Requirements):
These are the rules, limitations, or conditions under which the system operates or is developed.
Example:
The system must work on both mobile and desktop.
The system should be able to handle 500 users at once.
The system should be developed within 3 months.
It answers:
"Under what conditions should the system work or be built?"

Types of requirements
● Business requirement: why are we doing this? the goal.
● User requirement: what users want to do. (User view)
● System requirement: what the system must do to satisfy users. (Engineer view)
● Functional requirement (FR): specific features/behaviors (e.g., “Login”).
● Non-Functional requirement (NFR): quality levels (e.g., “Login in < 2 seconds”).

1) Business Requirements (BR)
The why behind the project. Business goals, value, and success criteria. Written for management and
stakeholders, not technical details.
What it contains
● Problem/opportunity (“event participation is low”)
● Goals & measurable targets
● High-level scope, risks, constraints (budget, timeline, policies)
Example: College Event App
● BR-1: Increase student participation in college events by 30% within one semester.
● BR-2: Reduce volunteer desk workload by 50% using online registration and e-tickets.
● BR-3: Comply with college privacy policy for student data.

2) User Requirements (UR)
What users need to do—written from the user’s point of view. Often captured as user stories or use
cases.
What it contains
● User roles/personas (student, organizer, admin)
● Tasks they want to perform
● Acceptance criteria (when we know it’s done)
● UR-1 (Student): As a student, I want to search and filter events (date, category, free/paid) so I can
quickly find relevant events.
● UR-2 (Student): As a student, I want an e-ticket with a QR code after registration so entry is easy.
● UR-3 (Organizer): As an organizer, I want to create/edit/cancel events so information is always up
to date.
● UR-4 (Admin): As an admin, I want to see registration stats so I can plan venues.

3) System Requirements (SR)
What the system must do to satisfy user requirements—more technical and detailed than UR. It includes
rules, data, interfaces, and integrations. (Think: the engineer’s view of the solution.)
Note: Many teams split SR into Functional and Non-Functional sections; below I show the
“system-level” details that aren’t yet low-level design.
What it contains
● Data/entities & relationships
● Business rules enforced by the system
● External interfaces (payment, email/SMS, SSO)
● Constraints (tech stack, compliance, platform support)

● SR-1 (Data): The system shall store Users, Events, Registrations with relationships: one User can
have many Registrations; one Event can have many Registrations.
● SR-2 (Rules): Registration is allowed only when event status is Open and seats are available;
otherwise show waitlist.
● SR-3 (External): System shall integrate with SMTP for email and a notification service for
SMS/app push.
● SR-4 (Security/Access): Only Organizers/Admins can create or cancel events; students have
read/registration permissions.
● SR-5 (Audit): All admin actions are logged with userId, action, timestamp, IP.

4) Functional Requirements (FR)- “What the system
does”
Specific features/behaviors the system must perform—observable actions. Usually written as “The
system shall …”.
What it contains
● Clear action/behavior
● Inputs/outputs
● Pre-conditions & post-conditions
● Error handling
● Acceptance tests

● FR-1: User can register with email/OTP.
● FR-2: User can browse upcoming events with filters.
● FR-3: System generates a QR e-ticket after registration.
● FR-4: Admin can create/edit/cancel events.
● FR-5: System sends reminder notifications 24 hours before the event.

5) Non-Functional Requirements (NFR) - “How well it
does it”
Quality attributes and constraints—how well the system must perform its functions. Must be
measurable.
Common categories & examples:
● Performance: search results in < 2 sec for 95% of requests.
● Availability: system up 99.5% during semester.
● Security: passwords hashed (e.g., bcrypt), OTP expires in 5 min.
● Usability: first-time user completes registration in ≤ 2 minutes.
● Reliability: mean time between failures ≥ 30 days.
● Maintainability: new event field can be added in < 4 hours by dev.
● Scalability: supports 10,000 concurrent users during fest week.
● Portability: works on Chrome, Firefox, Edge, Android, iOS.

Aspect Functional Requirement (FR) Non-Functional Requirement (NFR)
Focus Features, actions, outputs for inputs Quality levels, constraints, “-ilities”
Wording “The system shall allow/do …” “The system shall meet <metric> …”
Driven by User tasks & use cases Cross-cutting concerns (UX, performance, security,
etc.)
Examples Register user, search events,
generate QR ticket
p95 response < 2s, uptime 99.5%, OTP expires in 5
min, SUS ≥ 85
Validation Functional/unit/integration tests Load/security/usability/reliability tests with
measurements
Failure
impact
Missing/incorrect feature System “works but poorly” (slow, unsafe, hard to use)
Traceability Maps to user stories/use cases Maps to quality scenarios/architecture decisions
Change
impact
Often localized code changes Often architectural or system-wide changes

Requirements Engineering Tasks
Requirements Engineering encompasses seven distinct tasks:
1. Inception (શરૂઆત)
2. Elicitation (આવશ્યકતાઓ શોધવાની પ્ર ક્રિયા)
3. Elaboration (િવસ્તરણ)
4. Negotiation (મંત્રણા)
5. Specification(સ્પષ્ટીકરણ)
6. Validation (માન્યતા)
7. Requirements Management (જરૂરીયાતો વ્યવસ્થાપન)

1) Inception(Beginning)
Initial phase → gather basic idea of the project.
Example: University says: “We need a Student Attendance Management System

2) Elicitation (Gathering Requirements)
Collect requirements by talking with users, customers, and stakeholders.
Example:
Faculty: “I should be able to mark daily attendance.”
Student: “I should be able to check my monthly attendance.”

3) Elaboration (Detailing)
Describe requirements in detail with use cases, diagrams, and workflows.
Example: Use case diagram → Faculty → Mark Attendance → Database.
For example In a Library Management System, elaboration deﬁnes:
● Classes like Book, Member, IssueRecord.
● Attributes like Book_ID, Title.
● Functions like issueBook(), returnBook().
● Relationships like “Member borrows Book.
Elaboration Making requirements more detailed and technical for developers to understand and design
the system properly.

4) Negotiation (Discussion & Agreement)
Resolve conflicts, set priorities, and decide what features to develop first.
Example: First develop Login, then Attendance marking, then Report generation.

5) Specification (Documentation)
Write requirements in a formal document (SRS – Software Requirement Specification).
Example: “System shall allow the teacher to enter Present/Absent for each student daily and save it into
the Attendance table.”

6) Validation (Checking/Verification)
Check whether requirements are correct, complete, and match user needs.
Example: Teacher logs in, marks attendance, report is generated → stakeholders verify it works as
expected.

7) Requirements Management (Handling Changes)
Manage requirement changes during the project.
Example: Later, the university requests: “Send SMS notifications of attendance to parents.” →
requirement is updated and managed.

Initiating Requirements Engineering Process
To start requirements engineering, we need a clear talk between customer and software engineers. We do
it in four simple steps:
✔ Identification of stakeholders
✔ Recognizing multiple viewpoints
✔ Working towards the collaboration
✔ Questioning

1) Identification of Stakeholders
A stakeholder is anyone who is affected by the system or benefits from it—directly or indirectly.
Who can be stakeholders?
● End users: people who will use the system (e.g., students, customers)
● Customer / Client: who requested the system
● Business/Marketing people: who plan selling/launch
● Product owner / Consultant
● Software team: developers, testers, designers
● Support & maintenance engineers
● Managers: project/business managers
● Others: finance, security/compliance, vendors, auditors

What to do at project start:
● Make a list of all stakeholders (name/role/contact).
● Note how each one is connected to the system and what they want.
● Keep updating this list as the project moves forward.
Quick example (College Event App):
Students, Event Organizers, Admin/IT, Marketing, Accounts (payments), Developers, Testers, Support,
Principal/Dean.

2) Recognizing Multiple Viewpoints
Different stakeholders see the project from different angles. Their expectations can be different or even
conflicting.
Typical viewpoints (with expectations):
● End User:
○ Wants the system to be easy to learn and familiar.
● Marketing People:
○ Want exciting features to attract users and make selling easy.
● Business Managers:
○ Want the system within budget and fit for market needs.
● Software Developers:
○ Want clear, realistic, unambiguous requirements to build solid architecture.
● Support Engineers:
○ Want a system that is easy to maintain and monitor.

What the RE team does:
● Collect inputs from all viewpoints.
● Notice that some inputs may be confusing or conflicting.
● Organize them clearly so decision-makers can choose the right set of requirements.
Example conflicts:
● “One-click login” (End User) vs “Strong verification” (Security/Support)
● “Many flashy features” (Marketing) vs “Stay in budget” (Business Manager)

3) Working Towards the Collaboration
Stakeholders and engineers must work together not in isolation.
(Isolation means separated, working alone, without connection or communication with others.)
Collaboration helps in:
● Reducing misunderstandings.
● Building trust between client and developer.
● Agreeing on priorities (what features are most important).

4) Questioning
At the beginning (project inception), ask clear, open questions to understand people, goals, and limits.
These are often context-free (not assuming any specific design).
Asking questions is the key technique.
Types of questions:
1. What should the system do?
2. Why is this feature needed?
3. Who will use it?
4. How should it behave in certain situations?
Purpose: To clarify doubts and remove assumptions.

Eliciting requirements:
● “Questioning is useful at the inception of the project, but for detailed requirement elicitation it is not
sufficient.”
● Eliciting requirements means gathering and understanding what the customer or user really needs
for the system.It involves techniques like interviews, surveys, and scenarios to turn their needs into
clear, detailed requirements.
● During requirement elicitation certain activities such as problem solving, elaboration, negotiation and
specification must be carried out.
● Various ways by which the requirement elicitation can be done are
1. Collaborative requirement gathering
2. Quality function deployment
3. Use scenarios
4. Elicitation work product

1) Collaborative Requirements Gathering
Collaborative Requirement Gathering means Customers + Developers working together to collect
clear and practical system requirements through structured meetings (like FAST).
(Facilitated Application Specification Technique)
It is a team-based approach where both customers and developers work together to gather
requirements.
Example (Student Attendance System):
Must-have: take attendance in < 2 minutes/class
Should-have: upload CSV roster(means excel sheet not one by one)
Acceptance test: “Mark 60 students in ≤120 seconds with ≤1% error.”

2) Quality Function Deployment (QFD)
QFD is a method that helps convert customer needs into clear, technical requirements for the software.
It focuses on:
● What the customer values most.((what is important for them).
● Turning these values into functions, tasks, and features during software development. (functions,
tasks, design).
It identifies three types of requirements
1) Normal requirements(Normal Needs)
These requirements are the objectives and goals stated for a product or system during meetings with the
customer.
Example:
Customer says: “I want a login page and attendance reports.”
Developers must implement these because customer clearly asked for them.

2) Expected requirements(Basic Needs)
These requirements are implicit to the product or system and may be so fundamental that the customer
does not explicitly state them.
Example:
Security features like password protection, which customers assume will be there.
3) Exciting requirements
These requirements are for features that go beyond the customer's expectations and prove to be very
satisfying when present.
Example:
Auto-generating colorful graphs in reports,
or mobile app notifications.

3) Usage Scenarios
● As the requirements gathering progresses, a clear picture of the system’s functions and features
starts to form.
● To better understand how the system will be used, we create Usage Scenarios, also called Use
Cases.
● Usage Scenarios are like step-by-step stories that explain how the system will actually be used.

4)Elicitation Work Products
Elicitation Work Products are the official documents, diagrams, and models created after gathering
requirements, to clearly explain:
What the system needs to do?
Who is involved?
What environment is needed?
How the system will work?
These documents help in design, development, and validation of the project.

Building the Requirements Analysis Model :
● When we gather requirements, we don’t just write them in text. We also create models (diagrams +
documents) to visualize the system.
● These models explain what the system will do (functions), how it behaves, and how data flows.
● It’s like making a blueprint of a house before building it.

Elements of the Requirements Model:
Scenario-based elements:
● Show the system from the user’s point of view.
● Tools: Use Cases, Activity Diagrams.
Example: “A teacher logs in and marks attendance.” (Use Case + activity steps).
Class-based elements:
● Focus on the objects (things) in the system, their attributes (data), and relationships.
● Tools: Class Diagrams.
Example:
● Class: Student → Attributes: (Roll No, Name, Attendance%).
● Class: Teacher → Attributes: (ID, Name, Subject).
● Relation: Teacher marks Student attendance

Behavioral elements
● Show how the system or object changes state when events happen.
● Tools: State Diagrams.
Example: Attendance Record:
● State 1: Not Submitted → (Event: Teacher clicks Save) → State 2: Submitted
Flow-oriented elements
● Show how data flows into the system, is processed, and comes out.
● Tools: Data Flow Diagrams (DFD).
Example (Attendance System):
○ Input: Teacher enters student data →
○ Process: System validates →
○ Output: Attendance Report

Software Requirements Specification
● An SRS is a detailed document that explains what the software must do, but not how it will be
built.
● It’s like an agreement between the client and the developers.
● It ensures both understand the same requirements before development starts.
● An SRS is like a blueprint of the software, describing what the software will do, not how it will be
built.

Importance of SRS (Features of SRS)
1) Clear understanding between client & developers
● Acts like an agreement, Both know exactly what will be built.
2) Avoids misunderstandings
● Requirements are written clearly, so no confusion later.
3) Basis for design & development
● Developers use SRS as a blueprint to design and code.
4) Helps in cost & time estimation
● With clear requirements, project managers can estimate budget and timeline better.
5) Reference for testing
● Testers check the software against the SRS to see if it meets requirements.
6) Helps in maintenance & future updates
● When updating or fixing software, SRS serves as a guide to original requirements.
7) Customer satisfaction
● Since requirements are properly documented, the final product is more likely to match customer’s
needs.

Users of SRS
The list of users along with their role is explained below:
▪ Customers and end users: for understanding what they are expected to get.
▪ Project managers: to estimate and plan the project to deliver the system.
▪ Designers and programmers: to know what to build.
▪ Testers: to prepare for testing activities.
▪ Maintenance teams: for understanding the system that they will maintain.
▪ Trainers: to prepare training material for training the end users.

Characteristics of a Good SRS
Correct:
● The SRS must include all actual user requirements.
● Nothing should be missing or wrongly written.
● Example: If the client wants "attendance reports," it must be clearly written in SRS
Unambiguous:
● Each requirement should have only one meaning.
● No confusion or double interpretation.
● Bad Example: “System should be user-friendly.” (Too vague)
● Good Example: “System should load within 3 seconds for 95% of logins.
Complete:
● SRS should fully describe what the system must do.
● It should cover all inputs, outputs, errors, and features.
● Example: Login system → include correct login, wrong password, forgot password, timeout cases.

Ranked for Importance/Stability:
● Not all requirements are equally important.
● Each should be marked as Essential, Optional, or Desirable.
● Stability: Shows how likely a requirement is to change in the future.
● Example:
○ Essential → Login page
○ Optional → Dark mode theme
○ Unstable → Payment method (client may change later).
Modifiable:
● Requirements may change, so the SRS should be easy to update without breaking other parts.
● Example: If client changes “max 50 students per class” to “max 60 students,” it should be easy to
edit everywhere
Traceable:
● Every requirement should have a clear origin (who requested it, why it exists).
● Should be easy to trace each requirement throughout design, coding, and testing.
● Example: Requirement ID #101: “Generate attendance report” → requested by school admin.

Verifiable:
● Requirements should be testable so we can check if they are met.
● Bad Example: “System should be secure.” (How to test this?)
● Good Example: “System should lock account after 3 failed login attempts.”
Consistent:
● SRS is consistent when the subsets of individual requirements defined do not conflict with each
other.
● Example:
○ Req 1: “System should allow only admins to delete data.”
○ Req 2: “Teachers can delete student data.” (Conflict ❌)

Requirement Analysis and Specification_SE

Problems Without SRS(extra)
● Without developing the SRS document, the system would not be properly implemented
according to customer needs.
● Software developers would not know whether what they are developing is what exactly is
required by the customer.
● Without SRS, it will be very difficult for the maintenance engineers to understand the functionality of
the system.
● It will be very difficult for user document writers to write the users’ manuals properly without
understanding the SRS.

Requirement Analysis and Specification_SE

More Related Content

Recently uploaded (20)

Featured (20)

Requirement Analysis and Specification_SE