[Jump to start of article]

Home > Requirements > Eight Characteristics of Good Requirements

Eight Characteristics of Good Requirements

A good set of requirements has at least eight characteristics, which can be arranged under three broad sets dealing with different issues. These broad sets and the characteristics can all be defined by words beginning with the letter “C” and are:

Communication Characteristics

The set of communication characteristics deal with the issues of if the set of requirements are good enough to communicate between the users and the developers. As they have different backgrounds it is important that what the users say they want is what the developers understand is wanted. The key communication characteristics are that requirements should be:


Requirements must be complete, because if they are not then functionality expected by the users will be missing. This means as stated in User Requirements they must have all of the:


Even if the requirements are complete they must be understood with only one meaning. This means they must be unambiguous and specific.

Unambiguous is a tough characteristic to achieve as the users and developers each have different frames of reference so what is clear to one may not be to the other. This is one reason that the developers should put time aside to review the requirements with the users so that they both have the same understanding of them. A particular problem is different words being used for the same concept such as “data is input” and “details are entered”; are these two descriptions the same?

Making requirements specific is to avoid vague ill-thought out terms such as the “the system will be fast”. Requirements must have enough detail that developers can design a system that does what the users want.


The key point about consistency is that no requirement contradicts what another says. In particular:

Control Characteristics

A set of requirements need to do more than just communicate, there are also issues of how they will be controlled through the project. The key control characteristics are that the requirements must be:


A requirement is not a requirement unless it can be verified and validated. If no way can be found to show that a requirement has been built into a system; then it is not one. This means they should be expressed in physical terms and measurable attributes.


Not all requirements are created equal, some “Must” be included, or the system will be a waste of effort, others “Could” be included as they enhance what the system could achieve. All systems are subject to constraints on time, resources and quality, so control of the scope of the project is important. Prioritisation of the requirements allows the scope to be chosen from the correct set of requirements.


It must be possible to trace a requirement both back to its business reason, and through to the design and testing documentation. Without the ability to chase them through it is impossible to compare any documentation to see if they have been implemented. Even more important is without them it is impossible to make a judgement about what effect a system fault has on the system, and the business.

Construction Characteristics

Even with a set of requirements which communicate well and can be controlled there is still the issue of how they affect the developers. The two key characteristics are if the requirements are:


Credible means seeing if the project is technically feasible and achievable within the constraints of the project. If a project is not credible then it is better to say at the requirements stage then wait until later.

Technical feasibility means comparing the requirements logical model, with what is currently technically possible. There are many times when what is wanted is well beyond what can be delivered at the moment. An example from the past was ambitious websites, when users had slow dial-up lines. The websites were not technically feasible as users could not access them.

Achievable feasibility means comparing the time, resources, quality and scope of the projects and assessing the risk of ever achieving it.


A clean set of requirements is one where only the logical structure has been defined, and decisions about physical design and implementation have been left out. The more physical design decisions that are taken by the users the fewer the options that are available to the developers to deliver what is needed, and the more likely that a poor quality system will result.


These eight characteristics often overlap in detail, but by emphasising the issues of communication, control and construction they focus the users in creating a solid set of requirements which can result in a system that meets their needs.

Requirements Issues