📘 UNIT–II: Requirement Analysis and Specification

1. Introduction to Requirements Engineering

Software development starts with understanding what the customer wants. This step is
called requirements engineering (RE). It is the process of gathering, analyzing,
documenting, and validating what the software should do. If requirements are unclear or
incomplete, the entire project is at risk, because coding and design depend on them.

Think of it like building a house. If the owner only says, “I want a big house,” that is not
enough. The architect must ask: How many rooms? What style? How many floors?
Without clear requirements, the builder might create something the owner does not like.
The same applies to software.

So, requirements engineering ensures that the final product meets user expectations and
avoids costly mistakes later in development.

2. Functional and Non-Functional Requirements

Functional Requirements (FRs)

These describe what the system should do. They define the functions, tasks, or services
the system must provide. Functional requirements are usually described as statements
of behavior.

Example:

“The ATM must allow users to withdraw cash after PIN verification.”

“The online shopping system must allow users to add items to a cart and checkout.”

👉 In simple words, FRs are the features of the system.

Non-Functional Requirements (NFRs)

These describe how the system should behave. They do not add features, but specify the
qualities, constraints, and conditions under which the system must operate.

Example:

“The ATM must dispense cash within 5 seconds of approval.”

“The website should support 10,000 users simultaneously.”

👉 In simple words, NFRs are the qualities of the system, like speed, security, and
usability.

Why Both are Important?

Functional requirements ensure the system does the right job.

Non-functional requirements ensure the system does the job well.

If we ignore FRs, the system may be incomplete. If we ignore NFRs, the system may work
but will frustrate users (slow, insecure, or unreliable).

3. Requirement Sources

Requirements can come from many places. If we only ask one group (like end-users), we
might miss important constraints. So, engineers must gather input from different
sources:

• Customers or End-Users: They explain what they expect from the software. For
example, bank customers may say, “I want to transfer money online.”
• Business Managers/Analysts: They ensure the system aligns with business goals, like
reducing cost or improving efficiency.
• Domain Experts: They provide industry-specific knowledge. For example, a doctor
advising on hospital software.
• Regulations and Standards: Some requirements come from laws or industry
standards. For example, financial systems must follow RBI rules, and healthcare
systems must follow HIPAA (in the USA).

👉 Gathering requirements from multiple sources ensures completeness and reduces

misunderstandings.

4. Requirement Elicitation Techniques

Elicitation means collecting requirements from stakeholders. This is one of the hardest
steps, because stakeholders may not always know exactly what they want, or they may
express it in vague terms.

Techniques include:

• Interviews: One-on-one meetings with stakeholders. Developers ask questions to

clarify needs.

Example: Asking a teacher how they want an online grading system to work.

• Surveys/Questionnaires: Useful when many users are involved. Stakeholders fill out
forms, which gives broad feedback.

Example: Asking 500 students about their preferred features in an e-learning app.

• Observation: Watching how people currently do their tasks.

Example: Observing how nurses enter patient records in a hospital.

• Prototyping: Creating a quick mock-up or demo version of the system so stakeholders
can react and provide feedback.

Example: Showing a prototype of a shopping cart page before finalizing the design.

• Workshops / Brainstorming: Bringing multiple stakeholders together to discuss and

agree on requirements.

Example: Holding a session with teachers, students, and administrators for a university
portal.

👉 In practice, engineers often use a combination of these techniques to capture

requirements accurately.

5. Initiating the Requirements Engineering Process

The RE process starts with a structured plan to avoid confusion later. Typical steps are:

• Identify Stakeholders: Find all people who will use or be affected by the system (end-
users, managers, regulators).
• Collect Requirements: Use elicitation techniques to gather needs.
• Document Requirements: Record them clearly in an SRS (Software Requirements
Specification).
• Review with Stakeholders: Confirm whether the documented requirements match
stakeholder expectations.

👉 This ensures that everyone agrees on “what the system should do” before moving to
design and coding.

6. Developing Use Cases

A use case is a story of how a user interacts with the system to achieve a goal. It identifies
actors (users or external systems) and interactions.

Example: Online Shopping System

Actor: Customer

Goal: Place an order

Flow: Browse products → Add to cart → Checkout → Make payment → Receive confirmation

👉 Use cases make requirements easy to visualize. They also help uncover missing
requirements. For instance, if a “Return Order” use case is missing, the system won’t
support refunds.

7. Building the Analysis Model

Once requirements are gathered, they are represented in models to make them clearer
and structured. Common models are:

• Use Case Diagrams: Show interactions between users and system.

Example: Customer interacts with “Browse Products,” “Add to Cart,” “Place Order.”

• Data Flow Diagrams (DFD): Show how data moves between processes and data
stores.

Example: For ATM → Customer enters PIN → Verify PIN (with Bank Database) → Dispense
Cash.

• Entity-Relationship Diagrams (ERD): Show how data entities are related.

Example: In a library system, a Book is borrowed by a Member, and issued by a Librarian.

👉 These diagrams reduce ambiguity and make requirements more concrete.

8. Negotiating Requirements

Different stakeholders may have conflicting demands. For example:

• Customers want many features.

• Developers want to minimize complexity.
• Managers want low costs.
• Regulators want strict compliance.
• Negotiation is about finding a balance.

Example: A banking app customer wants quick logins (usability), but security requires
two-factor authentication. A compromise is using fingerprint login (both secure and fast).

👉 Engineers must prioritize and balance such conflicts, often using techniques like
trade-off analysis, cost-benefit studies, and requirement prioritization.

9. Validating Requirements

Validation ensures that the gathered requirements are:

• Correct (match stakeholder needs),

• Complete (nothing important missing),
• Consistent (no conflicts), and
• Feasible (can be implemented with available technology).

Techniques:

• Reviews and Walkthroughs: Stakeholders read the SRS and confirm accuracy.
• Prototyping: A working demo shows if the requirements were correctly understood.
• Test Case Generation: If a requirement cannot be tested, it is vague and must be
rewritten.

Example:

Requirement: “System should be user-friendly.” → This is vague.

Validated version: “New users should be able to learn the system in less than 1 hour of
training.”

UNIT–II Summary

Requirements engineering ensures the system meets user needs.

Functional requirements describe features; non-functional describe qualities.

Requirements come from users, experts, laws, and business needs.

Elicitation uses interviews, surveys, prototyping, etc.

Use cases and diagrams (DFD, ERD) model requirements.

Negotiation resolves conflicts.

Validation ensures requirements are correct, complete, and feasible.