Unit III
Software Requirement Specification
The SRS document is the foundation of any software project — it captures what the system must do, how it should behave, and the constraints it must satisfy.
👤 Role of the System Analyst
The system analyst acts as a bridge between the client/user and the development team. They are responsible for gathering, analyzing, and documenting requirements.
- Requirements Elicitation: Interviews, questionnaires, observation, workshops
- Feasibility Study: Technical, financial, and operational feasibility
- Documentation: Creates the formal SRS document
- Validation: Ensures requirements are correct, complete, and consistent
- Liaison: Coordinates between stakeholders throughout the project
📋 Need for an SRS Document
The SRS serves as a contract between the client and the developer. It defines what the system will and will not do — preventing misunderstandings and scope creep.
- Provides a baseline for design, testing, and acceptance
- Helps estimate cost, schedule, and resources
- Reduces development rework and late-stage changes
- Used by testers to write test plans
- Legal reference in case of disputes
🧩 Components of an SRS
Functional Requirements
What the system should do — specific behaviors, functions, and features.
- Use case descriptions
- Business rules
- Input/output specifications
- Processing logic
Non-Functional Requirements
Quality attributes — how the system should perform.
- Performance (response time, throughput)
- Security & reliability
- Usability & accessibility
- Portability & scalability
Other Key Sections of an SRS
| Section | Content |
|---|
| Introduction | Purpose, scope, definitions, overview |
| Overall Description | Product perspective, user characteristics, assumptions |
| Specific Requirements | All functional and non-functional requirements |
| External Interface Requirements | UI, hardware, software, communication interfaces |
| Constraints | Regulatory, design limitations, hardware constraints |
| Appendix | Glossary, data flow diagrams, ER diagrams |
✅ Characteristics of a Good SRS
01
Correct
Every requirement represents something actually needed
02
Complete
All requirements are included, nothing missing
03
Unambiguous
Each requirement has only one interpretation
04
Consistent
No conflicting requirements
05
Verifiable
Can be tested / confirmed objectively
06
Traceable
Each requirement traceable to its source
⚠️ Problems Without an SRS
Without a proper SRS, projects often suffer from "requirements creep" — requirements keep changing without control, leading to cost overruns, delays, and poor quality.
- Misunderstanding between client and developers
- Inconsistent design decisions across team members
- No basis for testing — unclear what to test against
- Frequent rework and cost overruns
- Difficult to estimate time and cost accurately
- Legal disputes due to unmet expectations
📝 SRS Document — Example (Library System)
SRS Outline — Library Management System
1. Introduction
1.1 Purpose: Automate library operations
1.2 Scope: Book issue, return, search, fine calculation
1.3 Users: Librarian, Students
2. Functional Requirements
FR-01: User can search books by title/author
FR-02: Librarian can issue books to registered members
FR-03: System calculates fine for late returns
FR-04: Generate monthly report of issued books
3. Non-Functional Requirements
NFR-01: Response time < 2 seconds for searches
NFR-02: System uptime ≥ 99.5%
NFR-03: Secure login (password-protected)