Software requirements specification

History

Software requirement specifications are already used in software development processes as early as 1975.

The purpose and content of software requirement specifications was formalised in 1983 by the IEEE. The standard was published in 1984 as IEEE-830-1984 and approved by ANSI. It was revised in 1993 and 1998, before being superseded by an international standard. This standard aimed at providing criteria for a good SRS, and recommendations about its content. It recognised the benefits of prototyping for the requirement engineering. It propose an example of structure and several variants.

The ISO/IEC/IEEE 29148 standard "Systems and software engineering —Life cycle processes — Requirements engineering" superseded IEEE 830 in 2011. The current revision is from 2018. This standard is broader as it covers also requirement quality criteria, requirement management processes, and business requirement specification (BRS), as well as stakeholder requirement specification (StRS). It proposes a slightly changed example structure.

Structure

An example organization of an SRS is as follows:

1. Purpose
2. Definitions
3. Background
4. System overview
5. References
6. Overall description
7. Product perspective 1. System Interfaces 1. User interfaces 1. Hardware interfaces 1. Software interfaces 1. Communication Interfaces 1. Memory constraints
8. Design constraints 1. Operations 1. Site adaptation requirements
9. Product functions
10. User characteristics
11. Constraints, assumptions and dependencies
12. Specific requirements
13. External interface requirements
14. Performance requirements
15. Logical database requirement
16. Software system attributes 1. Reliability 1. Availability 1. Security 1. Maintainability 1. Portability
17. Functional requirements 1. Functional partitioning 1. Functional description 1. Control description
18. Environment characteristics 1. Hardware 1. Peripherals 1. Users
19. Other It would be recommended to address also verification approaches planned to qualify the software against the requirements, for example with a specific section with a structure that mirrors the section on specific requirements.

Requirement quality

Requirements should strictly be about what is needed, independently of the system design, and not how the software should do it. Individual requirements shall hence be necessary, appropriate, and unambiguous. A set of requirements shall moreover be complete, consistent, feasible, and comprehensible.

Following the idea of code smells, the notion of requirements smell has been proposed to describe issues in requirements specification where the requirement is not necessarily wrong but could be problematic. Examples of requirements smells are subjective language, ambiguous adverbs and adjectives, superlatives and negative statements. Comparative phrases, non-verifiable terms or terms implying totality should also be avoided.

References

References

1. (2014). "Guide to the Software Engineering Body of Knowledge (SWEBOK)". IEEE Computer Society.
2. Pressman, Roger. (2010). "Software Engineering: A Practitioner's Approach". McGraw Hill.
3. (1975-04-01). "Testing large software with automated software evaluation systems". ACM SIGPLAN Notices.
4. "IEEE Standards Association - IEE-830-1984".
5. "IEEE Standards Association - IEEE 839-1993".
6. "IEEE Standards Association IEEE 830-1998".
7. "ISO/IEC/IEEE 29148:2018".
8. (2005). "Applied software project management". O'Reilly Media, Inc.
9. (2017). "Rapid quality assurance with Requirements Smells". Journal of Systems and Software.
10. "Mr".