Requirements Engineering — Requirements Specification (Part 3)
Writing down the user and system requirements into a document.
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 are interleaved, and it’s done iteratively. First iteration you specify the user requirements, then, you specify a more detailed system 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 of software jargon, or formal notations.
The system requirements on the other hand are 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 the 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 what 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 of what’s called “Appendix”. It defines all the abbreviations and acronyms in the your specification and their relevant meaning.
Structured Language Specification
It’s a way of writing the requirements in 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 till 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 write them on a cards as user stories.
Each user story has estimated time of completion, and priority. Related user stories are grouped together.
Next is the last pillar of the requirements engineering; requirements validation.