What are the characteristics of a good requirement?
I've started compiling these requirements, but I'm not sure I'm doing it the right way. How can I tell a good requirement from one that won't be useful?
The IIBA Business Analyst Body of Knowledge lists the following characteristics of a good requirement: "cohesive, complete, consistent, correct, feasible, modifiable, unambiguous, and testable." How can you tell if a requirement you've documented is good?
Good requirements clearly and accurately reflect the business need. They can be used with confidence to develop and test the solution. As you document the requirements, ask the following questions:
Does this requirement contradict itself or another requirement? If so, take another look at the requirement, and try again.
Does this requirement contain all the information it needs to clearly express the need, and only that information? If not, identify what's missing or superfluous, and make the appropriate change.
Does this requirement accurately reflect the business needs? If not, correct it.
Would it be possible or practical to meet this requirement as stated? If not, isolate what isn't practical, or feasible, and review it with your stakeholders and development team, then help refine it.
Can this requirement be misinterpreted in any way? If so, fix any part of the requirement that is ambiguous, or edit it to avoid words with multiple meanings, etc.
Can this requirement be tested? If not, work with the stakeholder and quality assurance team to adjust the requirement to maximize its testability.
One of the best ways to learn to write good requirements is by reading as many well-written examples as you can get your hands on. Keep in mind that business requirements, user requirements, and system requirements are often written to various levels of detail; so don't be surprised if they vary in their granularity.