How to write clear and effective requirements | CQI | IRCA Skip to main content

How to write clear and effective requirements

Progress indicator

Published: 19 Sep 2023

Principal auditor and Security Assurance Manager Dale Rollinson outlines the need for writing 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.


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.

Benefits and challenges of digitalisation

Following the recent publication of two documents from the United Nations Industrial Development Organization (UNIDO), Dr Nigel H Croft CQP FCQI, examines the benefits and challenges of the digitalisation of conformity assessment and quality infrastructure systems.

Join the conversation

Become a member and you too could input into future revisions of standards such as ISO 9001.

Quality World

Get the latest news, interviews and features on quality in our industry leading magazine.

Find an auditing course

Search our database of global training partners for a certified auditing training course in a location near you.