This is the fourth entry in a series on what constitutes good requirements, regardless of how they are written, stated, shown, or otherwise intended. In this entry, we offer a gentle reminder that requirements should also be verifiable. When requirements are verifiable it simply means that they are expressed in a way that our product can prove that they are met.
You may have heard the theory that an infinite number of monkeys randomly tapping the keys of an infinite number of typewriters will eventually produce the collective works of William Shakespeare. By the way, the same theory posits that an infinite number of coders randomly tapping the keys of an infinite number of keyboards will eventually produce a buildable version of Microsoft Bob.
The Infinite Monkey Theory is an interesting thought experiment, and, although it has some mathematical proof, it would be extremely difficult to verify in the real world. The good folks at the IEEE don’t write a lot of sonnets, but they have worked out guidelines for good requirements that include the topic of verifiability:
A requirement is verifiable if, and only if, there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement. If a method cannot be devised to determine whether the software meets a particular requirement, then that requirement should be removed or revised
In other words, if a requirement is not verifiable, then it is a matter of opinion whether it was correctly implemented or not .
In the last post we covered ambiguity, which is a major factor in the verifiability of requirements. When requirements are unambiguous it means that they have one and only one interpretation by everyone involved. But for a requirement to be verifiable, it also needs to meet a few more criteria. Requirements that are incomplete, inconsistent, ambiguous, or infeasible are also unverifiable. Herein lies the rubric for creating verifiable requirements.
Examples of unverifiable requirements:
The system shall have at least 500 concurrent users during peak time.
This statement is incomplete. 500 is the minimum, but what is the maximum?
When two orders are placed at the same time, both shall be on hold and neither shall proceed until the other one does.
This statement is inconsistent. How can an order proceed when both need to be on hold?
The report writer shall be user friendly.
This statement is ambiguous. “User friendly” is a subjective observation that is unique to each individual.
The recommendation engine will provide users the content they intended to request.
This statement is infeasible. It is not realistic to presume that technology can actually perform precognitive mind-reading techniques to know what content you will want to see. Someone is working on this, but even Google does not have an infinite number of monkeys nor coders to complete this work.
Keeping these other requirements characteristics “clean” goes a long way to keeping them verifiable. There are few more techniques will keep your stakeholders steady and your project teams focused. Use concrete language and measurable quantities where possible, even breaking your requirements down into smaller, more manageable pieces until a good test case can be written for it. When presented a requirement, immediately discuss how it can be tested, reviewed or demonstrated. Build the demo script now! Above all, check as you go. Adopt test-driven development techniques by writing test cases and requirements together. Reviewing test cases early is a great way to verify the requirements with the customer so you can easily run the same test cases later to verify the product with requirements.
Hopefully you found this post complete, consistent, unambiguous, and feasible, and therefore verifiable.
“The Infinite Monkey Theory is an interesting thought experiment, and, although it has some mathematical proof, it would be extremely difficult to verify in the real world.”
I beg to differ 😉
http://www.bbc.co.uk/news/technology-15060310