Software requirements specifications are living documents and also serve as a means of communication between all stakeholders involved in the product development process. Iterations are inevitable during software development projects: if changes are well recorded in the SRS, all project stakeholders will be able to review and approve them.
What is an SRS?
A Software Requirements Specification (SRS) is a formal document outlining the fundamental requirements—such as functionalities, performance metrics, design constraints, and attributes—of the software, along with its internal and external interfaces. The SRS should be developed and maintained to encompass the following elements:
- Requirements for customer or user interfaces
- Functional, performance, usability, and safety requirements based on intended use
- Security requirements, including those for cybersecurity
- Relevant regulatory requirements and standards
- Usability or human factor requirements, when applicable
- Outputs from risk management processes
- Traceability to product requirements, as needed
- Information from previous similar designs, where appropriate
- Additional requirements critical to the product’s design and development processes
Basically, an SRS must be complete, clear, verifiable, and free of conflicts among requirements.
Cardinality
One of the main elements for writing requirements is: Cardinality. It refers to the quantity of instances of one entity that relate to instances of another entity.
For a given requirement, the quantities of preconditions, triggers, system names, and system responses are limited as follows:
- Preconditions: zero to many
- Triggers: zero or one
- System name: one
- System responses: one to many
It’s advisable to restrict the number of preconditions and system responses in a single requirement to two or three at most, as too many can make the requirement difficult to comprehend. When preconditions or system responses exceed this limit, it’s often better to use alternative formats, like tables or diagrams.
Gherkin Syntax
Each requirement statement should be independent, general, and clearly understandable on its own. Types of requirement statements include:
1) Ubiquitous: Always active
- The car shall have five (5) tires with two (2) at opposite ends of each axle and one (1) spare in the trunk
2) State-Driven: Related to the app’s states (e.g., launching, active, background)
- WHILE the turn signal is engaged downward, the car shall intermittently illuminate the driver-side blinker lights, 1 second on, 2 seconds off.
3) Event-Driven: Related to system events (e.g., open, exit, register, login)
- WHEN the car’s collision sensor detects an impact equivalent of hitting a solid, fixed barrier at 8 to 14 mph or higher, all airbags shall inflate at the equivalent of 200mph within 1/25th of a second.
4) Behavior-Driven: Related to user actions (e.g., swipe, tap, scroll)
- IF the car’s passenger detection system cannot communicate the weight of the passenger to the airbag control system, THEN the airbag control system shall enable the passenger airbag.
5) Optional Feature Requirements: Applies only when an optional feature is included in the system, indicated by the keyword “WHERE.” Certain optional features may have state-driven or event-driven requirements associated with them.
- WHERE navigation is available, the infotainment system shall display google maps when the navigation button is pressed.
6) Complex Requirements: Combinations of the previous categories.
- WHILE the Computer is working, when it detects a failure, the Computer shall reboot.
Gherkin syntax will help to structure and write requirements, so the following table may help you understand it better and more concisely: 
Characteristics of Effective Requirements
Conclusion
Software requirements are important because they are the fundamental basis of software development. Thanks to them, both the documentation and the testing phase of the different systems can be successful. Therefore, it is very important to know how to write them clearly and even to be able to identify improvements in them.
Additional resources
- miCoach Training: Technical Writing in the Software Industry
- Gherkin Syntax
- EARS – The Easy Approach of Requirements Syntax: The Definitive Guide
