--- title: "SRS and characteristics of a good SRS" subject: "Software Engineering" chapter: 1 key: "semester_5/software_engineering:srs-characteristics" source: https://www.bctengineer.com/q/semester_5/software_engineering/srs-characteristics site: BCT Engineering --- # SRS and characteristics of a good SRS Software Engineering · Chapter 1: Software Process and requirements - Asked in: 2068 Baishakh (old course), 10 marks - Video: [07 - System Analysis and Design | What is SRS document | Features or Characteristics of a good SRS |](https://www.youtube.com/watch?v=jxLDCNRvBu4) — Touseef Jamal - Answer checked by Claude Sonnet 5.5 on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_5/software_engineering/srs-characteristics - Whole chapter: https://www.bctengineer.com/md/semester_5/software_engineering/chapter-1 ## Question Explain software requirement specification (SRS). What are the characteristics of a good software requirement specification document? ## Short answer An SRS describes what the software must do and its constraints, without specifying how. A good SRS is correct, unambiguous, complete, consistent, ranked, verifiable, modifiable, and traceable, with each requirement uniquely identified and testable. ## Answer #### Software Requirement Specification (SRS) A **Software Requirements Specification (SRS)** is the official document that describes completely **what** the software system must do (functional requirements) and the constraints on it (non-functional requirements), without describing **how** it will be implemented. It is produced at the end of requirements analysis and is agreed by the customer and the developer. **Users of the SRS** - Customers: check that it meets their needs and specify changes. - Managers: plan the bid, estimate cost and schedule. - System engineers / developers: understand what to build. - Test engineers: develop validation tests. - Maintenance engineers: understand the system and its parts. **Typical structure (based on IEEE 830)** ```text 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions 1.4 References 1.5 Overview 2. Overall description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 3. Specific requirements functional requirements, external interfaces, performance, design constraints, quality attributes (security, reliability, etc.) Appendices and index ``` #### Characteristics of a good SRS IEEE 830 lists the following qualities. 1. **Correct**: every requirement stated is one that the software must actually meet. Only the user can confirm correctness. 2. **Unambiguous**: every requirement has only one interpretation. Words like "fast" or "user friendly" are avoided or defined; a glossary is included. - Bad: "The system shall respond quickly." Good: "The system shall display search results within 2 seconds for 95% of queries." 3. **Complete**: includes all significant requirements (functions, performance, interfaces, constraints), defines responses to all valid and invalid inputs, labels all figures and tables, and has no "to be decided" items left. 4. **Consistent**: no requirements conflict with each other, for example one saying "report in tabular form" and another "report in text form", or two different names for the same object. 5. **Ranked for importance and/or stability**: each requirement is marked as essential, conditional or optional, and as likely or unlikely to change, so that priorities can be set. 6. **Verifiable**: there is a finite, cost-effective process (test, inspection, analysis) to check that the software meets each requirement. "Works well" is not verifiable; "MTTF of at least 500 hours" is. 7. **Modifiable**: the structure and style allow changes to be made easily, completely and consistently: organised with a table of contents and index, no redundancy, each requirement stated once. 8. **Traceable**: the origin of each requirement is clear (backward traceability), and each requirement has a unique ID so it can be referenced in design, code and tests (forward traceability). Other desirable qualities: - **Understandable** by customers and developers (simple language, diagrams). - **Design independent**: states what, not how, leaving design choices open. - **Concise**: no unnecessary detail or repetition. - **Organised**: grouped logically by feature, user class or mode. | Characteristic | Quick check | |---|---| | Correct | Does the user agree it is needed? | | Unambiguous | Only one meaning? | | Complete | Anything missing or TBD? | | Consistent | Any conflicts? | | Ranked | Priority/stability given? | | Verifiable | Can it be tested? | | Modifiable | Easy to change in one place? | | Traceable | Has ID and known source? | A good SRS reduces development effort, provides a baseline for validation and verification, and makes cost estimation and future enhancement easier. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. What does an SRS describe? A. How the software is implemented in code B. What the software must do and its constraints, not how it is implemented C. Only the user interface colours D. Only the project schedule Answer: B. An SRS is design independent: it states what, not how. (Key point: What an SRS states) 2. Which requirement is unambiguous? A. The system shall respond quickly B. The system shall be user friendly C. The system shall display search results within 2 seconds for 95% of queries D. The system shall work well Answer: C. Unambiguous requirements have one interpretation and are measurable; 'quickly' or 'user friendly' are vague. (Key point: Unambiguous) 3. Which is an example of an inconsistent SRS? A. One requirement says reports are in tabular form and another says text form B. Every requirement has an ID C. Requirements are ranked D. A glossary is included Answer: A. Consistent means no requirements conflict, and the same object has one name. (Key point: Consistent) 4. Which requirement is verifiable? A. The system works well B. MTTF of at least 500 hours C. The system is reliable enough D. The system is pleasant Answer: B. Verifiable means there is a finite, cost-effective way to check it, such as measuring MTTF. (Key point: Verifiable) 5. What makes an SRS traceable? A. It is short B. The origin of each requirement is clear and each has a unique ID for reference in design, code and tests C. It has an index only D. It has no changes Answer: B. Backward traceability shows origin; forward traceability uses unique IDs in design, code and tests. (Key point: Traceable) ## Related in Software Engineering - [Why an SRS is worth the early effort](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Asrs-justify) — 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 - [Software characteristics and software crisis](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Acharacteristics-and-crisis) — 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 - [Requirement gathering and analysis techniques](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-gathering-techniques) — 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 - [Good programming practice and software selection](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Agood-programming-software-selection) — Instrumentation II, chapter 9, asked 2× - [Characteristics of good building stones](https://www.bctengineer.com/question.md?key=semester_3%2Fcivil_engineering_materials%3Acharacteristics-good-building-stones) — Civil Engineering Materials, chapter 2, asked 9× - [Characteristics of good bricks](https://www.bctengineer.com/question.md?key=semester_3%2Fcivil_engineering_materials%3Acharacteristics-good-bricks) — Civil Engineering Materials, chapter 3, asked 4×