Drafting a good requirements specification (VSE) proves in practice to be a real art. It often happens that a requirements specification is poorly structured: there are gaps, the structure is unclear, requirements are not clearly formulated, etc. The result is usually difficult discussions with the contractor after award and often (unnecessary) additional work. Below is a very practical 7-step plan that can be used as a guide when drafting a good requirements specification.
- Ensure the project scope is clear
For drafting a good requirements specification, it is essential that the project scope is clear. If you don’t know what is to be built, what requirements can you write? Make sure all objects are known and what must be done with them. Often, not everything is certain at the start of the contracting phase. Will that structure be renewed, renovated, or not included in this project at all? In practice, it usually concerns only a few objects, so include them in the process but place them on a separate list of issues still to be clarified. - Create a function and object tree (based on a function analysis)
A good and clear function tree and corresponding object tree are absolutely necessary to prepare a requirements specification. Do not skip this step. Performing a functional analysis for the project can help. This identifies the main functions, function groups, and individual functions. Likewise, the object tree is built up from the project, with object groups below and then the objects themselves. Keep both the function tree and the object tree as shallow as possible. As a rule of thumb, for a not too large or complicated project, a maximum of 3 levels is sufficient, sometimes even 2. For the largest infrastructure projects (€100 million and more), you may go up to about 5 levels. More levels make it unmanageable. Note that the contractor will also decompose the object tree further to detail level. - Define the types of requirements and requirement tree
Determine at the start which types of requirements you will use. You will at least need:
- Functional requirements, specifying the primary functions of an object (group).
- Aspect requirements, relating to Reliability, Availability, Maintainability, Safety, Design, Environment, etc.
- Internal interface requirements, interfaces between object groups within the project.
- External interface requirements, interfaces between the system’s object groups and the environment.
- Execution requirements, specific requirements during execution.
In large projects, other types may also appear, such as “design constraints.” These are often essentially functional requirements but are named separately because they are imposed externally and specify the standards and guidelines that an object (group) must meet. Sometimes execution requirements are provided in a separate document attached to the contract.
- Define the top requirement(s)
At the highest level, you need at least one top requirement, but you may want 2 or 3. These top requirements express the ambition or highest goal of the project. Usually, they are fairly abstract. Note that they serve only as a framework for the underlying requirements and do not need to be demonstrated by the contractor (all underlying requirements do!). For large and complex projects, there is often another level of requirements under the 1, 2, or 3 top requirements relating to main functions and main object groups, to give more structure to the requirement tree. - Fill the requirement tree top-down
Many writers tend to start too detailed. They describe “nuts and bolts” without having specified what the object essentially has to do. Do not fall into this trap! It will not work. Make sure you already have a requirement at a higher level (perhaps not yet perfectly formulated) when you define a requirement at a lower level. Note: make sure all requirements are linked to an object group or system level. Functional requirements should also be related to a function (group) from the function tree. - Ensure requirements are defined at the right level
A common mistake is to formulate a requirement about an object that implicitly or explicitly also includes other matters, such as that the object must cooperate with another object. Wrong! A requirement linked to an object should only say something about that object. If you want to specify the relationship between two objects within an object group, you must link the requirement to the object group. If you want to describe the relationship between an object and the total system, then you must define this requirement at system level. - Ensure the same type of requirements are consistently classified
Sometimes requirement specifications look like a plate of spaghetti. One cause is that the same type of requirement is sometimes classified as functional, then as a reliability aspect requirement, and then again as an internal interface requirement. This usually happens because different writers contribute, each with their own style. But sometimes even one writer is inconsistent. Make sure you are consistent while writing the specification. Of course, it is advisable, once the specification is well advanced, to go through it critically again and ensure all requirements are properly placed (i.e., of the correct type).
There is, of course, much more to say about drafting a good requirements specification. But if you follow these 7 steps, you will get a long way. The 7 steps are primarily intended for the client in the contracting phase, but contractors can also benefit greatly when further decomposing requirements and preparing their Work Breakdown Structure (WBS).