SECTION 10 / 19
What is an SRS?
In the Plan and Document perspective, requirement gathering and analysis is usually done by a system analyst, with other members of the software team. The analyst then organises the requirements in a Software Requirements Specification (SRS) document, which contains all the user requirements in a structured form.
| Section | Content |
|---|---|
| 1 Introduction | 1.1 Purpose; 1.2 Scope; 1.3 Definitions, acronyms and abbreviations; 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 | Specific functional and non-functional requirements |
| 3.1 External interface requirements | User, hardware, software, communication interfaces |
| 3.1.1 User interfaces | |
| 3.1.2 Hardware interfaces | |
| 3.1.3 Software interfaces | |
| 3.1.4 Communication interfaces | |
| 3.2 System features | For each: introduction/purpose of feature; Stimulus/response sequence; associated functional requirements |
| 3.2.1 System feature 1 | |
| 3.2.1.1 Introduction/purpose of feature | |
| 3.2.1.2 Stimulus/response sequence | |
| 3.2.1.3 Associated functional requirements | |
| 3.2.1.3.1 Functional requirement 1 | … |
| 3.2.1.3.n Functional requirement n | |
| 3.2.2 System feature 2 | … |
| 3.2.m System feature m | |
| 3.3 Performance requirements | Non-functional requirements |
| 3.4 Design constraints | Non-functional requirements |
| 3.5 Software system attributes | Non-functional requirements |
| 3.6 Other requirements | Non-functional requirements |
Sections 1 and 2 give a broad outline and description of the system. Section 3 contains specific functional and non-functional requirements; 3.3–3.6 cover non-functional requirements like performance and security.
This is a guideline; based on the organisation and context, modifications to the structure and content are possible.