The next piece in the puzzle of how and why we apply use cases to product management. Verification of requirement correctness.
Background
We started a series of posts exploring why we apply use cases as part of product management, identifying 8 goals for which use cases are relevant. That series post contains links to detailed articles on each goal as we write them over the next weeks. Bookmark it and come back to it to see the puzzle come together.
Verification of Requirement Correctness
One of the challenges of writing requirements is assuring that we are capturing the requirements correctly. Correctness represents two elements. First we must document the requirement as articulated for it to be correct – any errors are “typographic” in nature. Second, we must document the valid requirement. This requires understanding the business objectives, as well as the source of ROI associated with a proposed requirement. If we properly record a stakeholder’s desire for a low-value requirement, that does not mean that the requirement is correct – it is only correctly documented.
In the past, we’ve shown how to apply object oriented analysis to validate requirement correctness. We identify a few downsides to using OOA diagrams to represent requirements – one of which is that people must be able to read UML to correctly interpret the diagrams. This is usually not a problem when communicating requirements with the development teams. The percentage of stakeholders who can read UML is probably the inverse of the ratio of developers – and that causes a problem.
When we are using a structured requirements approach, we can use use cases to help validate correctness. Structured requirements use use cases to achieve goals, or market requirements.
Putting Things in Perspective
An alternative way to understand a requirement is to review the use cases that support it. After we have validated the completeness of a requirement, we can review the use cases to help make sure the requirement is correct. People can easily form a mental image of what a requirement is/does/achieves by reviewing the use cases that enable the requirement.
This allows us to answer the question, “What does this requirement intend?” From that answer we can then apply critical thinking to identify if it is the right intention. Knowledge of the use cases will help prevent a flawed understanding of the requirement.
Limitations
We mentioned earlier that an aspect of requirement correctness is that it is valuable (e.g. we’re doing the right thing). If we have a faulty analysis of the business model, then reviewing the use cases won’t identify that flaw. Reviewing the use cases will allow us to confirm that the goal is correct with respect to the business model. Every company will use a different approach to creating a business model or analysis. Generally, they will be based on ROI analysis or expected value calculation. Some may use a payback period as a means of evaluating the value of requirements.
One thought on “Verify Correct Requirements with Use Cases”