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 dealing with if they are complete, clear and consistent.
- Control dealing with if they are certifiable, chosen, and chaseable.
- Construction dealing with it they are credible and clean.
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:
- Complete - All that is needed is stated.
- Clear - They are unambiguous.
- Consistent - They do not contradict other requirements.
Complete
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:
- Functional requirements including the various real world paths the system will have to deal with including valid and invalid data, as well as details of any detailed processing.
- Non-functional requirements describing the performance and development constraints on the system.
- Design objectives to guide the system designers.
- Reference material including a definition of terms used and units of measurement.
Clear
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.
Consistent
The key point about consistency is that no requirement contradicts what another says. In particular:
- Paths though the system must not process the same input differently. This can occur due the paths being written by separated teams, and they not having agreed what should be done.
- Detailed processes not providing the output necessary to drive the paths through the system.
- Non-functional requirements conflicting with the functional ones. An example would be having to use old versions of system software, but the functional requirements needing facilities only available in a new version.
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:
- Certifiable - They can be verified and validated.
- Chosen - They have been ranked as to importance.
- Chaseable - They can be traced forward and backwards.
Certifiable
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.
Chosen
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.
Chaseable
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 - What is asked for is technically possible.
- Clean - They do not have any implementation decisions.
Credible
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.
Clean
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.
Summary
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
- User Requirements - three areas to include and one to avoid when writing them.
- Requirements and Design - User Requirements and the Business Case, requirements documents, and design documents.