What is Software requirement specification (SRS)?
Software requirements are documented using Software Requirement Specification (SRS) document.
- A Software Requirements Specifications (SRS) is a document or set of documentation that outlines a software application’s features and intended behavior of a software.
- In other words, it describes the business or organization’s understanding of the end user’s needs and dependencies as well as any constraints on the system.
- This document conveys the expectations of users from the software product.
- SRS is a document created by a system analyst after collecting various stakeholders
Importance of documentation
- SRS provides a clear goal in the software implementation phase.
- It gives a basis for agreement between the customers and the suppliers regarding the functions of the implemented software product.
- SRS provides a guideline for schedule and cost estimates.
- It also provides a basis for validation and verification.
Structure of SRS and its parts:
1. Introduction
i. Purpose of this document
Describes the purpose of the document.
ii. Scope of this document
Describes the scope of this requirements definition effort.
iii. Overview
Provides a brief overview of the product defined as a result of the requirements elicitation process.
2. General description
- Describes the general functionality of the product such as similar system information, user characteristics, user objective, general constraints placed on the design team.
- Describes the features of the user community, including their expected expertise with software systems and the application domain.
3. Functional requirements
A functional requirement describes the effects of a software system, in other words, what the system must accomplish.
Each functional requirement should be specified in the following manner:
i. Description
ii. Critically
iii. Technical Issues
iv. Cost and schedule
v. Risks
vi. Dependencies with other requirements
4. Interface requirements
This section describes how the software interfaces with other software products or users for input or output. Examples of such interfaces include library routines, token streams, shared memory, data streams, and so forth.
Each interface requirement should be specified in the following manner:
i. User Interfaces
ii. GUI
iii. CLI
iv. API
v. Hardware interfaces
vi. Communication interfaces
vii. Software interfaces
5. Performance requirements
Specify speed and memory requirements.
6. Design constraints
Specifies any constraints for the design team such as software or hardware limitations.
7. Other non-functional attributes
Specifies any other particular non-functional attributes required by the system. Such as
i. Security
ii. Binary compatibility
iii. Reliability
iv. Maintainability
v. Portability
8. Operational scenarios
This section should describe a set of scenarios that illustrate, from the user’s perspective, what will be experienced when utilizing the system under various situations.
9. Preliminary schedule
This section provides an initial version of the project plan, including the major tasks to be accomplished, their interdependencies, and their tentative start/stop dates.
10. Preliminary budget
This section provides an initial budget for the project.
11. Appendices
i. Definitions, Acronyms, Abbreviations
Provides definitions terms, and acronyms can be provided.
ii. References
Provides completer citations to all documents and meeting referenced.
