Software Requirement Specification (SRS)

What is a Software Requirement Specification(SRS)

• A document that defines detailed system requirements
• Serves as a contract between stakeholders and developers
• Provides a technical blueprint for implementation

Why is SRS Important?

• Ensures that all stakeholders agree on system expectations.
• Reduces ambiguity and misinterpretations in system design.
• Helps in testing and validation by providing measurable criteria.

Key information presents

• System Overview
• Overall Description
• Functional Requirements (FR)
• Non-Functional Requirements (NFR)
• External Interfaces
• System Features
• Validation and Acceptance Criteria

Writing Effective SRS

• Be specific and unambiguous
• Use “shall” for mandatory requirements
• Ensure testability – Every requirement should be verifiable
• Keep requirements organised and structured

Common Mistakes in SRS

• Using vague terms like “the system should be fast”
• Mixing functional and non-functional requirements
• Omitting constraints or external dependencies
• Not involving stakeholders in the process

Summary

• SRS translates user requirements into system specifications.
• It is essential for accurate development, testing, and validation.
• A well-written SRS reduces project risks and scope creep.

Key Information	URS (User Requirements Specification)	SRS (Software Requirements Specification)
Who the users are	Defined explicitly	Implied through requirements
What users want to achieve	Captures user goals and needs	Translates goals into functional specs
Functional Requirements	High-level expectations	Detailed software behaviors
Non-Functional Requirements	Performance expectations	Technical performance constraints
User Interaction	Describes how users interact	Defines UI and interface requirements

Verification of SRS

1. Formal review (evaluated for accuracy, completeness, consistency, and feasibility.)
   • Business Analysts
   • Developers
   • QA/Test Engineers
   • Product Owners
   • End Users (if applicable)

• Checklist
  • Are all functional and non-functional requirements clearly defined?
  • Are requirements unambiguous (no vague terms like “fast” or “user-friendly”)?
  • Are there any conflicting or duplicate requirements?
  • Are external dependencies or constraints documented?
  • Is the document structured correctly?

2. Validate against URS
   • Requirement Traceability Matrix (each SRS requirement should map to at least one URS requirement, and vice versa).
   • Stakeholder Validation (survey)
   • Gap Analysis (ensure that no URS requirement is missing)
3. Check for Completeness and Consistency
   • Does it cover all expected functionalities?
   • Are there missing edge cases? (e.g., error handling, alternative flows)
   • Are terms and abbreviations well defined and consistent throughout the document?
   • Are functional and non-functional requirements clearly separated?
4. Ensure Feasibility and Testability
   • Can each requirement be verified through testing?
   • Are acceptance criteria well-defined?
   • Are edge cases and failure scenarios considered?
5. Model based validation
   • Use Case Diagrams — ensure all user interactions are covered
   • Sequence Diagrams — validate system interactions
   • State machine diagrams — Confirm system behaviour in different states
6. Walkthroughs (informal, exploratory process for understanding and feedback)

---

Back to parent page: Requirement Elicitation and Analysis

SDLC Requirement_Engineering Requirement_Elicitation Software_Requirement SRS SOFT3202