We ran a series called Writing Good Requirements – The Big Ten Rules in May 2006. Bloggers are notorious for not being able to count. We had ten rules at the time, and now we’re adding an eleventh. Writing Correct Requirements may have been the unwritten rule, but now we take a look at it.
Background
The original series started with a summary of the ten rules to writing good requirements, and then we followed up with ten articles with details of each rule. And now we add another one – writing correct requirements.
The Big Ten Eleven Rules of Writing Requirements
- Valuable
- Concise
- Design Free
- Attainable
- Complete
- Consistent
- Unambiguous
- Verifiable
- Atomic
- Passionate
- Correct
Correct Requirements
Correctness in requirements is simply about getting it right. We wrote previously about how to apply use cases to creating correct requirements. Writing requirements correctly is as much about getting accurate information as it is about accurately documenting the information we gather.
Correctness applies in a context. “Are these the right requirements to achieve goal X?” Verification is the process of verifying that we identified the right requirements to achieve a particular goal. Validation, on the other hand is the process of assessing requirement completeness. People often swap these terms as being nearly synonymous.
Verification Techniques
To verify that requirements are correct, we start by asking two simple questions. Here’s an example for writing a software requirements specification. Set aside for the moment that some people consider this to be design, although from a developer’s perspective, it is a specification (or requirement). This serves as a good example for business analysts.
- Does each of these requirements contribute to achieving our goal? If a requirement does not help us achieve the goal that it supports (in a structured requirements framework), it is not a correct requirement. Either the requirement is placed under the wrong goal, or it truly doesn’t belong.
- Can our goal be achieved without these requirements? If our goal can be achieved without the requirement, then it isn’t required. “The system shall generate a report of all outstanding customer bills” is a requirement. If the goal is “Identify a customer’s unpaid bills”, then “The system shall display any unpaid bills for a customer” is a more correct requirement, because the goal can be achieved without a report.
A market requirement (useful to product managers) would be “Reduce the cost of accounts payable by 5%.” There is an ideation step in going from documenting market requirements to documenting product requirements. In that step, a product manager will decide how to approach, with her product, the reduction of accounts payable. Consider the following approaches and requirements and their hypothetical correctness verification.
- Approach: Remind customers of outstanding bills. Requirement: “The system shall generate past-due notices for all bills on the monthly anniversary of each bill.” This requirement would not be correct if bills are issued with 90-day terms, because the bills are only due, not past-due. We identify that this requirement is incorrect because of the semantics of past-due billing, and the hidden complexity of varying billing terms.
- Approach: Relax outstanding debt by 5%. Requirement:” The system shall reduce the outstanding balance of all past-due accounts by 5%.” This requirement would reduce accounts payable amounts, but it would not address the opportunity cost of the missing funds. Companies earn interest on credit balances, and pay them on debts. By decreasing the amount owed, a company would not have any impact on the amount that it could have earned (or avoided paying) in interest. This does reduce the size of the accounts payable amount, it does not achieve the goal.
- Approach: Increase prices for high-risk customers. Requirement: “The system shall adjust product prices per [referenced actuarial table], to reflect the risk of late payment.” This would not reduce the cost of accounts payable, although it might increase the profitability of the product (and might not). Since this doesn’t directly contribute to achieving the goal, the requirement is incorrect.
Context
As the examples highlight, we have to understand how the market requirement works. A knowledge of the billing rules for our customers, as well as an understanding of the cost of capital are both required.
Conclusion
Writing good requirements demands that the requirements be correct. Correctness can only be identified with context and domain understanding. Correctness can be determined by asking if a requirement achieves the goal, and is required to achieve the goal.
Latest Articles
Comments on all Articles
