What are Good Requirements?
We have established that poor requirements are harmful, costly, wasteful and in some cases, even dangerous. So how do we go about writing good requirements? How do we know if we have good requirements? How can we spot problems in requirements? There are some universal ingredients to good requirements that we will describe, that will help you:
All requirements must be expressed in terms of what a user needs. They may subsequently be broken into developer tasks, but a version of the requirement must first be expressed in relation to the user need so that we can be certain that what gets developed will meet the user’s need.
Clear and Unambiguous
A requirement should not be easily misunderstood by readers. This is perhaps the hardest dimension to ensure. It means that a requirement should describe clear functionality that a user needs to perform. Two readers of the same requirement should reach the same general understanding of what data needs to be handled as part of the requirement.
Requirements should be concise. A requirement does not need to be verbose, nor use flowery elegant language.
A set of requirements should use consistent terms for types of user e.g. administrator. A set of requirements should also use consistent terms of types of data (Object types)
A requirement should be complete in itself (describe all the functional steps needed for that user capability). Also, a set of requirements should be complete, describing all the functionality needed to maintain all the data within the system. For this, CRUD analysis is most helpful.
If a user requirement is not functionally sizeable (i.e. measurable in COSMIC function points) then it is almost certainly lacking in quality if one of the other aspects in this list. Which is why we consider that the ability to size in CFP is an excellent test of requirement clarity and quality. Nb. technical tasks and non-functional requirements are not sizeable in this way. Technical tasks are generally sized in staff hours. Non-functional sizing is an unresolved problem, although there are some recommendations (in a separate article).
Testers must be able to determine how to test that a requirement has been met. Therefore the requirement must be written such that it can be tested. One of the best ways of ensuring that that requirement is testable is to ensure that it clearly describes functional intent. (For this we recommend COSMIC sizing)
We don’t want a set of requirements to contain duplicate content or duplicate functionality. (This is perhaps one of the least significant quality problems of requirements.)
User stories should not contain any detail about how a capability should be implemented. A user story is not a placeholder for design details. You can break down the work to implement a user stories into technical tasks, but these are not user stories.
Every user story must provide value to the user or stakeholder, otherwise it should not be built. The value should be expressed in terms that the user (not the developer) will recognise.
That is our recommended list of 10 attributes of good user stories or software requirements. It applies in all situations. Some requirements experts will rightly argue that it does not go far enough. That is true, there are certain situations where requirements should meet even higher standards than what we have described here. What we have described is a set of attributes that should apply everywhere regardless of the type of software that you are developing/assembling/deploying.
Beware of INVEST!
INVEST is pneumonic coined by early agilists to provide some kind checklist to user stories. It stands for:
- I” ndependent (of all others)
- “N” egotiable (not a specific contract for features)
- “V” aluable
- “E” stimable (to a good approximation)
- “S” mall (so as to fit within an iteration)
- “T” estable (in principle, even if there isn’t a test for it yet)
We like checklists but we find that there are too many deficiencies with the INVEST list to be universally reliable for assessing requirements quality and advise against its use.
Fails to ensure that stories are User-oriented
If software is not doing something useful for a user, it is not useful. If our stories are not user-oriented, then they are simple work tasks. And this what so many user stories end up becoming, tasks not expressions of user recognisable functionality or capability. In short your expression of done will likely be poor.
Fails to ensure Consistency
If you only follow these guidelines you are likely to end up with requirements that muddle user/persona names and have many different terms for object types.
Fails to ensure Sizeable
By referencing Estimable and not sizeable this approach fails to ensure that each user story has (functional) size. Functional size is not only valuable for project management but is a good test of requirements quality. A sizeable requirement is a good quality one.
Fails to ensure Design-Free
Relying only on INVEST will cause your user stories to become muddled with tasks (and “technical user stories”) this distances the work from the user and it’s value to them.