One of the ten big rules of writing a good MRD is writing verifiable requirements. Verification is both a function of having a precise goal, and having the ability to affordably measure the requirement. A precise goal is a verifiable requirement if we can clearly answer “yes” or “no” when asked if the requirement has been implemented. We also face the practical realities of being able to measure the results profitably.
The Big Rule of Writing Verifiable Requirements
From our previous article, Writing Good Requirements – Big Ten Rules:
We use a process that starts with market requirements, and then decomposes them into software requirement specifications. the market requirements must be written in a way that we can verify that the associated requirements specification will meet the market need.
Verifiable
We wrote previously that if a requirement can’t be tested, it should be rewritten. Roger Cauvin has recently reposted on testable requirements. Perhaps in anticipation of this article? :).
In the world of test driven design (TDD), the philosophy is to write the test first, and then write the code. We use a continuous integration approach to check in code regularly and run all of the tests as we go. When the test for a particular requirement passes, the code is done for that requirement.
We also get a big benefit in validating that we have delivered the right functionality to the customer. When we agree on the language of the requirement, we are also agreeing on the language of its verifiability.
Affordably Verifiable
With this big rule, we are assuming that we have already eliminated impractical or unattainable requirements.
Some tests are very expensive, or nigh on impossible. Roger alludes to this as testable in principle. Requirements should be testable in practice whenever possible. If a requirement can not be tested (“Must last 10 years”) in the delivery timeframe, we need to at least define a specific acceptance criteria – (“95% confidence in a cycle life of 10,000 cycles per procedure XYZ.doc”). This is the approach that Underwriter Labs uses for awarding UL certification to electrical appliances for safety.
Semantically, we can argue that this proxy criteria is in fact the requirement. It is the criteria by which acceptance is determined.
If the test is possible, but impossibly expensive, we shouldn’t run the test. If we can not agree on a practical proxy criteria, we are left with two choices. We can choose to not implement the requirement. Or we can choose to agree that the requirement is delivered when we say it is. Neither is a particularly good option, but the former is better than the latter, when it comes to maintaining a positive relationship with our customer.
Writing requirements without acceptance criteria introduces risk into our project. The last thing we want is to enter into a nitpicking discussion about what we have and have not delivered. We would much rather spend that time discussing what we can deliver next.
Conclusion
Write requirements that can be verified given the constraints of the project. Common constraints are time, money, equipment and expertise. Use language that makes the verification process explicit. The process of determining verifiability also dramatically helps eliminate ambiguity in our requirements.
Is it possible to chain requirements for verification? Imagine a closed system that has two components inside. The first one produces A and feeds it into the next component that produces B with a visible A in it. The desire is to write a separate requirement for the system to produce A and another one to produce B.
However, people cannot look inside the system to verify that A is produced by the first component and can only verify that in the end B comes out with A in it. This implies that requirement for A cannot be verified until the requirement for B is implemented.
Is there any prescribed way to set up verification for such requirements without creating an oversized combined requirement that a system shall produce A and B?
My quick thought to your abstract question – if it is a closed system, and no one can observe A (it is an intermediate product), then the requirement is only to produce B. A design choice to produce B by first producing A is perfectly valid, and should be _tested_ as a unit test, reflecting the system’s conformance to its designer’s intent. But it is not a requirement of the system.