THE SRS (also: requirements document, functional specification) is the OFFICIAL STATEMENT of what the system developers should implement. It should include BOTH the user requirements and a detailed specification of the system requirements. IT IS NOT A DESIGN DOCUMENT. As far as possible it says WHAT the system should do, not HOW. This line is not absolute — organisational and interoperability requirements do constrain the how — but every "how" that sneaks in removes a design option the engineers might have needed. SIX AUDIENCES, SIX PURPOSES (Sommerville): SYSTEM CUSTOMERS specify the requirements and read them to check they meet their needs. They state changes to the requirements. MANAGERS use it to bid for the system and to plan the development process. SYSTEM ENGINEERS use it to understand what system is to be developed. SYSTEM TEST ENGINEERS use it to develop validation tests for the system. → THIS IS THE MOST DEMANDING READER. If a requirement cannot be turned into a test, it is not a requirement. Testers find the unmeasurable requirements faster than reviewers do. SYSTEM MAINTENANCE ENGINEERS use it to understand the system and the relationships between its parts — years later, when everyone who wrote it has left. (and in regulated domains) AUDITORS AND CERTIFIERS use it as the evidence base for compliance. THE CONFLICT THIS CREATES: no single writing style serves all six. That is precisely why the two-level structure (user requirements then system requirements) exists.

1. PREFACE Who the document is for; version history; the change rationale for each version. Cheap to write, and the first thing a maintenance engineer reads. 2. INTRODUCTION Why the system is needed; its functions briefly; how it fits with other systems; the business objectives. 3. GLOSSARY Every technical term and domain term, defined. Do not skip this — it is where DOMAIN REQUIREMENTS get surfaced, because defining a term forces the expert to state the convention hidden inside it. 4. USER REQUIREMENTS DEFINITION Natural language + diagrams. The services, the non-functional requirements, the constraints. Written for the customer. 5. SYSTEM ARCHITECTURE A high-level overview of the anticipated architecture, showing the distribution of functions across modules, and marking reused components. 6. SYSTEM REQUIREMENTS SPECIFICATION Detailed functional and non-functional requirements. May define interfaces to other systems. 7. SYSTEM MODELS Graphical models: object models, data-flow models, entity- relationship models, state machines — showing relationships between components and between system and environment. 8. SYSTEM EVOLUTION The fundamental ASSUMPTIONS the system is based on, and anticipated changes from hardware evolution, user needs etc. Useful to designers: it says which decisions must stay flexible. 9. APPENDICES Detailed, specific information — hardware requirements (minimum and optimal configurations), database requirements (logical organisation, relationships). 10. INDEX Several may be appropriate: alphabetical, by diagram, by function. HOW MUCH DETAIL? It depends on the system: · a fixed-price contract to an external supplier → maximum detail, because the document is the contract · an in-house agile team building an evolving product → lighter, because the conversation continues Very detailed requirements for a small, in-house, rapidly changing system are waste. Under-specified requirements for a fixed-price outsourced safety-critical system are negligence.

1. CORRECT every requirement stated is one the system must meet 2. UNAMBIGUOUS every requirement has exactly one interpretation 3. COMPLETE all significant requirements present; responses defined for all classes of input, valid AND invalid; all figures labelled and referenced; no "TBD" 4. CONSISTENT no requirement conflicts with another 5. VERIFIABLE a finite, cost-effective process exists to check each requirement is met 6. TRACEABLE each requirement has a unique identifier, with backward traceability to its origin and forward traceability to design, code and tests (also: RANKED for importance and stability, MODIFIABLE) FAILURE MODES, WITH SPECIMENS: ✗ AMBIGUOUS "The system shall provide reports for managers and supervisors as required." → which reports? as required by whom? separate reports or one? "as required" is a blank cheque. ✗ INCOMPLETE — the invalid-input case is missing "On entering a valid application number the system shall display the applicant's record." → and on an INVALID number? Completeness demands responses to all classes of input, including the illegal ones. This omission is the single commonest SRS defect. ✗ INCONSISTENT — a real pair, and both were signed §4.2 "Applications shall be retained for 7 years for audit." §9.1 "Personal data shall be deleted within 90 days of the application being closed." → these cannot both hold for an application's personal data. Consistency checking is what reviews are FOR; neither statement looks wrong alone. ✗ NOT VERIFIABLE "The system shall never crash." → no finite test establishes this. The verifiable form is "MTBF shall exceed 5000 hours in a 6-month trial". ✗ NOT TRACEABLE Requirements written as flowing prose with no numbers. When the customer asks to change one thing, nobody can say which tests, modules and design decisions are affected. ✗ DESIGN LEAKING IN "The system shall store applications in a PostgreSQL table named licence_app." → unless the database is genuinely an organisational constraint, this removes a design choice for no requirement-level reason.