In our article, The 8 Goals of Use Cases, the first goal is that our use cases must support requirement-completeness validation. In this article, we explore how to address this goal and how use cases can help. There are many pieces to this puzzle, and this article is one of them.
Review
There are several good books and articles about how to use use cases, but little if anything is written on why we use them. For folks who are new to Tyner Blain and Use Cases in general, here is an introduction on how to read a formal use case.
From our previous article:
Why Write Use Cases?
We write use cases for the same reasons that people use our software – to achieve goals. In our case, we want to assure that we are creating the right software. By looking at this high level goal in more detail, we can make decisions that drive the best possible use case creation. Let’s apply our product management skills to writing better use cases by writing an MRD for use cases.
We also wrote a series on use cases, including descriptions of formal and informal use cases, as well as use case diagrams. Check out the introduction to brush up on concepts.
Requirement Completeness
We also wrote an article on the importance of validating requirement completeness, as part of our series, Writing Good Requirements – The Big Ten Rules.
Simply put, if the requirement is implented as written, the market need is completely addressed. No additional requirements are required. When writing a specification, we may use decomposition to break individual requirements into more manageable, less abstract criteria.[…]
Completeness comes from analysis. And our degree of completeness comes from the quality of our analysis. There is no silver bullet, we just have to think. Remembering to validate completeness, and base our decisions on data gets us half-way there, but we have to get ourselves the rest of the way there.
The Use Cases of Completeness Validation
Requirements completeness validation is performed, when using structured requirements, by validating that the supporting documents completely support the requirement being validated. Each market requirement is supported by one or more use cases, as shown in the following diagram:
Determining if a goal will be completely achieved is a function of confirming that it will be completely enabled. This requires us to review the use cases that have been written to support the goal (or market requirement).
There are therefore two activities – writing the use cases, and reviewing the use cases. We’ve already described the activity of writing the use cases to support a market requirement. We only now need to cover the activity of reviewing the use cases.
Reviewing the Use Cases that Support a Goal
We will use the format of an informal use case to document this activity.
Title: Review Supporting Use Cases for a Goal
Trigger: Validation of the completeness of a market requirement is required.
Actors: Business Analyst and Stakeholder
Description:
- Business Analyst (BA) organizes all use cases that have been identified as supporting the market requirement to be validated for completeness.
- BA and Stakeholder (SH) review the goal.
- BA and SH confirm that the goal can be achieved solely by performing the assembled use cases.
- BA and SH confirm that none of the assembled use cases can be ignored and still achieve the goal.
- BA and SH record their agreement that the use cases are both neccessary and sufficient to achieve the goal.
Additional Notes:
- The reviewers are not evaluating the quality of the use cases, and work under the assumption that the use cases are successfully completed. Reviewing the quality or accuracy of the use cases is out of scope for this procedure (but is still required).
- If additional use cases are required, the BA and SH will identify their titles and brief descriptions to act as placeholders for the purpose of this review.
- If use cases are determined to be redundant or extraneous, their existence must be justified. For example, there may be more than one way to achieve the supported goal. Each method of success must be explicitly valued and prioritized.
Execution Tips
The process above tells us what we need to do, but doesn’t provide guidance on how to do it. Two common mistakes made when validating completeness are overlooking missing activities, and not discovering alternative activities.
To assure that missing activities are not overlooked, we can imagine playing a game, where the actors in the use cases are only allowed to perform the actions that are documented in the use cases. With one person verbally walking the actor(s) through the steps, the other person will likely find any missing steps. Changing from reading to listening triggers our brains to process the information differently and uncover gaps that we might overlook when reading (because our brains will fill in the gaps in the prose).
To discover alternatives to the documented use cases, we can apply brainstorming techniques. We can start the brainstorming process with a simple question, applied to each use case. “How else could someone possibly achieve the results of this use case?” We must make sure that we don’t constrain our answers to the easy, practical, or relevant – these constraints will make it harder for us to stumble upon a novel idea. We can also ask the question “How else could someone possibly achieve the goal?” For this question, answers are allowed to re-use existing use cases or ignore them completely.
While finding a better alternative approach could be a nice surprise, our primary goal is to explore the standing solution approach from all angles, in hopes of finding and strengthening it’s weaknesses.
Summary
Validating the completeness of a market requirement can be accomplished by reviewing that goal and the use cases that are designed to enabled it. If the use cases are neccessary and sufficient, then the requirement is complete. Brainstorming about alternatives can help us discover issues with completeness that are not obvious from traditional, top-down review. Brainstorming may also uncover a novel and more valuable solution.
This is only the first of the 8 uses for use cases. We will cover the rest of them in the future. Refer back to the original article, The 8 Goals of Use Cases, to find links to further detailed articles.
