--- title: "Why an SRS is worth the early effort" subject: "Software Engineering" chapter: 1 key: "semester_5/software_engineering:srs-justify" source: https://www.bctengineer.com/q/semester_5/software_engineering/srs-justify site: BCT Engineering --- # Why an SRS is worth the early effort Software Engineering · Chapter 1: Software Process and requirements - Asked in: 2069 Chaitra, 7 marks - Video: [Software Requirements Specification (SRS) | Software Engineering](https://www.youtube.com/watch?v=83-S5Qu6VP8) — Gate Smashers - Answer checked by Claude Sonnet 5.5 on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_5/software_engineering/srs-justify - Whole chapter: https://www.bctengineer.com/md/semester_5/software_engineering/chapter-1 ## Question Why the Software Requirement Specification (SRS) document is required during the system development phases? How could you justify the extra efforts and resources being used in this specification detailing at the early stage, which outweigh the resource and efforts required to meet the obscures specification later? ## Short answer The SRS is the official statement of what the system must do, serving as contract, basis for design, testing, estimation, communication, and change control. Early detailed specification is justified because fixing requirement errors later is far costlier: relative cost grows from 1 in requirements to 100-200 after delivery. ## Answer #### Why the SRS is required A **Software Requirements Specification (SRS)** is the official, detailed statement of what the system must do and the constraints under which it must operate. It is needed throughout development because it serves as: 1. **Agreement / contract** between customer and developer on exactly what will be delivered; it reduces disputes. 2. **Basis for design and implementation**: designers and programmers build from it. 3. **Basis for cost and schedule estimation**: size measures such as function points come from the SRS. 4. **Basis for testing and acceptance**: test cases and acceptance criteria are derived from each requirement. 5. **Communication tool** among users, managers, analysts, developers and testers, who all refer to one document. 6. **Basis for change control and maintenance**: changes are evaluated against the baseline SRS, and maintainers use it to understand the system. 7. **Reduces ambiguity**: writing requirements precisely forces the team to find missing, conflicting and unclear requirements early. #### Justifying the extra early effort Writing a detailed SRS takes time and money at a stage when no code is produced. This is justified because **the cost of fixing a requirement error grows sharply the later it is found**. An error in the requirements spreads into design, code, tests, manuals and training; fixing it late means changing all of them. Widely cited studies (Boehm and others) give approximate relative costs: | Phase where the error is fixed | Relative cost | |---|---| | Requirements | 1 | | Design | about 5 | | Coding | about 10 | | Testing | about 20–50 | | After delivery (operation) | about 100–200 | In addition, requirement errors form a large share of all defects found in projects, and they are among the most expensive to correct. **Illustration:** suppose a detailed SRS costs an extra 40 person-hours and finds 10 requirement errors. Fixing each now takes about 2 hours, i.e. 20 hours. If the same 10 errors were found after delivery at about 100 times the cost, they would need about 10 × (2 × 100) = 2,000 hours, plus lost user trust and possible penalties. The extra 60 hours early (40 + 20) is clearly worth it. Other benefits that justify the effort: - **Less rework and scope creep**, since an agreed baseline exists. - **More accurate estimates**, so fewer budget and schedule overruns. - **Better quality and user satisfaction**, because the system does what users need. - **Easier maintenance and enhancement** in the long term, when most life-cycle cost is spent. - **Legal protection** in contract disputes, since the agreed scope is written. Thus a vague ("obscure") specification only appears cheap; the real cost is paid later through rework, delays and failures. The detail should still be balanced: for stable, critical systems a full SRS is essential, while for fast-changing products a lighter but still precise, living specification is appropriate. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. Which is NOT a stated use of the SRS? A. Contract between customer and developer B. Basis for testing and acceptance C. Basis for cost and schedule estimation D. A replacement for the source code Answer: D. The SRS is the agreement, basis for design, estimation, testing and change control, not a substitute for code. (Key point: Role of SRS) 2. Why is extra effort on a detailed SRS justified? A. Fixing a requirement error costs more the later it is found B. Coding is cheaper when requirements are vague C. Errors cost the same in all phases D. Customers prefer long documents Answer: A. Requirement errors spread into design, code, tests and manuals, so late fixes are very expensive. (Key point: Cost of late errors) 3. In the illustration (40 extra hours, 10 errors at 2 hours each early), what is the total early effort? A. 40 hours B. 20 hours C. 2,000 hours D. 60 hours Answer: D. 40 + (10 x 2) = 60 hours, versus about 2,000 hours if found after delivery. (Key point: Illustration calculation) 4. Roughly what relative cost is given for fixing an error after delivery, compared with requirements stage = 1? A. About 5 B. About 10 C. About 20-50 D. About 100-200 Answer: D. The table gives about 100-200 after delivery. (Key point: Relative cost) 5. For a fast-changing product, what specification approach does the answer recommend? A. No specification at all B. A full formal SRS frozen at start C. A lighter but precise living specification D. Only verbal agreements Answer: C. Full SRS is essential for stable, critical systems; fast-changing products suit a lighter, precise, living specification. (Key point: Balanced detail) ## Related in Software Engineering - [SRS and characteristics of a good SRS](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Asrs-characteristics) — Software Engineering, chapter 1 - [Requirement engineering and specification](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-engineering-views) — Software Engineering, chapter 1 - [Why software development is complex; man-month myth](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Acomplex-development) — Software Engineering, chapter 1 - [Requirement gathering and analysis techniques](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-gathering-techniques) — Software Engineering, chapter 1 - [Importance of requirement engineering; elicitation techniques](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-engineering-importance) — Software Engineering, chapter 1 - [Requirement management process](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-management) — Software Engineering, chapter 1 ## Related in other subjects - [Requirement alternatives and SRS document](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Arequirement-alternatives-srs-unified-process) — Object Oriented Analysis and Design, chapter 2 - [Software process models and effort estimation](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Asw-process-models) — Instrumentation II, chapter 9, asked 2× - [Development phases; pre-feasibility factors](https://www.bctengineer.com/question.md?key=semester_7%2Fhydropower_engineering%3Adev-phases-prefeasibility-factors) — Hydropower Engineering, chapter 2 - [Project development life cycle phases](https://www.bctengineer.com/question.md?key=semester_7%2Fict_project_management%3Aproject-development-life-cycle) — ICT Project Management, chapter 1