Requirements Engineering — Requirements Specification (Part 3)
Writing down the user and system requirements into a document.
This is a series of articles inspired by Software Engineering, 9th edition
Requirements Specification
It’s the process of writing down the user and system requirements into a document. The requirements should be clear, easy to understand, complete, and consistent.
In practice, this is difficult to achieve as stakeholders interpret the requirements in different ways and there are often inherent conflicts and inconsistencies in the requirements.
As we’ve mentioned before, the process in requirements engineering is interleaved, and it’s done iteratively. In the first iteration you specify the user requirements, then, specify a more detailed system requirement.
User Requirements
The user requirements for a system should describe the functional and non-functional requirements so that they are understandable by users who don’t have technical knowledge.
You should write user requirements in natural language supplied by simple tables, forms, and intuitive diagrams.
The requirement document shouldn’t include details of the system design, and you shouldn’t use any software jargon or formal notations.
System Requirements
The system requirements on the other hand are an expanded version of the user requirements that are used by software engineers as the starting point for the system design.
They add detail and explain how the user requirements should be provided by the system. They shouldn’t be concerned with how the system should be implemented or designed.
The system requirements may also be written in natural language but other ways based on structured forms, or graphical notations are usually used.
Ways of Writing Requirements Specification
As we’ve mentioned, there are different ways to specify the requirements. The most two common ways are natural and structured languages.
Natural Language Specification
It’s a way of writing the requirements in normal plain text, there is no defined format by default.
Requirements written in natural language are vague and ambiguous. Hence, you need to follow these guidelines to minimize the consequences and misunderstanding:
- Create your own format for writing the requirements. For example, you can write the requirements in this format:
“A/The (Actor) shall (do something), By (how; explain how the user can trigger this feature), In order to/so that (why; explain the benefits or the objects of this requirement).
Example: “A system shall allow the users to register by entering their username and password, In order to get an access to the system”.
- When we say “a system”, this word is very vague, we need to define exactly the part of the system that will take care of this requirement.
- We may highlight the important keywords.
- Don’t use abbreviations and acronyms, and If you want to, you have to add what’s called “Appendix”. It defines all the abbreviations and acronyms in your specification and their relevant meaning.
Structured Language Specification
It’s a way of writing the requirements in a more formal and structured form.
It uses standard templates to specify the requirements. The specification can be structured around the functions or events performed by the system.
Software Requirements Document
The software requirements document (also called software requirements specification or SRS) is an official document of what should be implemented. It’s also used as a contract between the system buyer and the software developers.
It should include both; user and system requirements. Usually, the user requirements are defined in an introduction to the system requirements.
In other cases, especially if there are large number of requirements, the detailed system requirements may be presented in a separate document.
The requirement document has a diverse set of users, ranging from the customers to the system engineers.
The diversity of possible users means that the requirements document has to be a compromise between communicating the requirements to customers, defining the requirements in detail for developers and testers, and information about predicted changes can help system designers to avoid restrictive design decisions, and help the system maintenance engineers to adapt the system to new requirements.
In agile methods, since the requirements change so rapidly, it’s a waste of time to deliver a full document at once, instead, collects the requirements incrementally, and writes them on cards as user stories.
Each user story has an estimated time of completion, and priority. Related user stories are grouped together.
Next is the last pillar of requirements engineering; requirements validation.
References:
- Software Engineering, 9th edition, Chapter 4, Ian Sommerville — A highly recommended comprehensive textbook on software engineering.
