SRS & Requirements Engineering

The SRS (Software Requirements Specification) is the contract between client and developer. It defines what the system should do, not how it should do it. Getting requirements wrong is the most expensive mistake in software — fixing a requirements error after deployment costs 10-100x more than catching it during elicitation.

Requirements Engineering Process

A systematic process with four phases:

1. Elicitation — gathering requirements from stakeholders via interviews, surveys, workshops, observation, and document analysis.
2. Analysis & Negotiation — resolving conflicts (e.g., user wants fast + cheap + full-featured — pick two), prioritizing, checking feasibility.
3. Specification — documenting the agreed-upon requirements in the SRS.
4. Validation — reviewing the SRS with stakeholders to ensure it accurately captures their needs.

Feasibility Study

Before detailed requirements, check feasibility from three angles:

Type	Questions
Technical	Do we have the technology, skills, and infrastructure?
Economic	Is the ROI positive? Development cost vs expected benefit?
Operational	Will the users adopt it? Does it fit the organization’s workflow?

SRS Document (IEEE Std 830)

A well-structured SRS typically includes:

• Introduction — purpose, scope, definitions, references.
• Overall Description — product perspective, user characteristics, constraints, assumptions.
• Specific Requirements — functional requirements (what it does), non-functional requirements (performance, security, usability), external interface requirements.
• Appendices — glossaries, models, to-do lists.

Functional vs Non-Functional Requirements

	Functional	Non-Functional
What	Specific behaviors or functions	Quality attributes or constraints
Example	”User can search by product name"	"Search results appear within 500ms”
How to test	Functional test	Performance test
Language	”The system shall…"	"The system shall…within X seconds”

Requirement Elicitation Techniques

Technique	Best for	Risk
Interviews	Deep understanding of one stakeholder	Time-consuming
Surveys/B questionnaires	Large number of stakeholders	Low depth
Workshops	Resolving conflicting requirements	Requires facilitation skill
Observation	Understanding actual workflow	Hawthorne effect (people act differently when watched)
Prototyping	Unclear requirements	Expensive to build

DFDs (Data Flow Diagrams)

A DFD shows how data moves through the system. Levels:

• Level 0 (Context diagram) — one bubble, the entire system, with external entities.
• Level 1 — major processes and data stores.
• Level 2+ — detailed breakdown of each process.

Quality Assurance Models

• ISO 9000 — quality management standards. Certification requires documented processes.
• SEI-CMM (Capability Maturity Model) — 5 levels of process maturity: Initial, Repeatable, Defined, Managed, Optimizing.
• CMMI — successor to CMM, integrates multiple disciplines.

Traceability Matrix — maps each requirement to its source, design element, code module, and test case. Proves every requirement is addressed.