How to write clear and effective requirements

Requirements are the documented needs of the project, mission or organisation. As quality practitioners, we should seek to embed the discipline of writing good, clear requirements, regardless of whether an organisation produces a sofa or a satellite. Requirements should become the foundation for all other activities that occur during the project lifecycle.

Often the cause of a project failing to be delivered on time, in budget and of high quality is a failure to meet requirements. If they are incorrect or inadequate, the need for re-work becomes increasingly likely and the cost multiplies. Therefore, the earlier deficiencies in requirements are found, the less expensive they are to fix.

Actionable tasks

The best time for quality practitioners to help fix written requirements is when we are involved in gathering, understanding and documenting them. The most difficult requirements to fix are those that have been omitted. Again, our expertise in understanding the needs of interested parties can come to the forefront of discussions to resolve such issues.

According to IEEE 1233-1998 IEEE Guide for Developing System Requirements Specifications, well-formed requirements should include capability, condition and constraints. In this context, 'capability' refers to whether a specified function can be carried out; ‘condition' means the state that must exist before something else is possible; and ‘constraints' are the limitations or restrictions applied to the requirements, usually with regard to the availability of resources or information.

Requirements are ready to become actionable tasks once resources, methods, testing and constraints can be applied to them. Requirements should state what is needed, but not how to provide it. It is often easy to fall into the trap of 'solutioneering' before requirements are ready to become actionable tasks.

"Having well-formed requirements, with the necessary resources, leads on to the development of well-formed processes."

– Dale Rollinson, IRCA ISMS Principal Auditor and Security Assurance Manager at a space and defence organisation 

Developing processes

Having well-formed requirements, with the necessary resources, leads to the development of well-formed processes. Here, we recall that processes transform inputs into outputs through value-adding activities, to which resources, methods, measurements (testing) and constraints are applied.

In the discipline of requirements engineering, although opinions vary, there are often considered to be five phases of requirements: 

• Elicitation.
• Analysis.
• Specification.
• Validation and verification (testing)
• Management.

First, 'elicitation' refers to the source of project requirements and how they can be collected. This is the first stage in building an understanding of the problem that the project is required to solve.

Next, 'analysis' concerns the process of detecting and resolving conflicts between requirements; discovering the boundaries of the project and how it must interact with its environment; and elaborating high-level requirements to derive more specific requirements.

'Specification' means the assignment of values or restrictions to the project's design goals, focusing on quantifying requirements and managing interactions between them. A requirements specification should be produced, which is then appropriately reviewed, approved, distributed and controlled. It is important that the requirements specification is comprehensible, consistent and complete to enable effective testing.

Requirements are the foundation for testing. It is impossible to carry out effective testing if the applicable requirements do not exist or are not well-written. Consider having the tester create the test cases while the requirements are nearing completion. If the tester cannot create a valid test case, the requirement is not testable and therefore needs to be re-written.

A testable requirement is written in the form “the system shall...”. Measurable terms must be included, such as “the system shall return a response to the user request within three seconds”.

During testing, we are ensuring that the people responsible understand the requirements and can develop in accordance with them. It is therefore critical to describe requirements precisely enough to allow the requirements to be validated, implementation to be verified and costs to be estimated.

Finally, requirements must be effectively managed. Here, the quality practitioner can add value by putting their experiences of document control, configuration and change management into practice.

Summary

This is just a snapshot on the subject of requirements. To learn more, I would recommend quality practitioners consult the following two standards:

• IEEE Standard 1233-1998 IEEE Guide for Developing System Requirements Specifications;
• ISO/IEC 25010:2011 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models.