Last year, I touched on the concept of use case versions. A use case version is a use case with simplifying assumptions attached to it. Use case versions help with incremental delivery, scheduling, and product roadmaps.
Use case versions help with incremental delivery by enabling shorter iterations and releases. With incremental delivery, you should be iterating on the development of the product and "releasing" the product for testing and feedback after each iteration. But often a use case is far too complex to implement within a single iteration time-box. In such situations, you can implement a succession of simplified versions of the use case instead.
For example, imagine your organization is implementing an e-commerce web site. One of the highest-level use cases (perhaps even the only use case at the requirements level) is Purchase Items. You've attached various nonfunctional requirements to this use case regarding usability, payment flexibility, etc. It's unlikely that your developers will be able to deliver a fully tested implementation of the use case that satisfies all of these requirements in a single two week iteration.
What to do? Throw up your hands and extend the length of the iteration? No need. Instead, divide the use case into versions:
Note that the simplying assumptions in this example were feature assumptions. It is a feature of the system to support credit payments. It is a feature of the system to support receipts. Such features represent design choices to satisfy the nonfunctional requirements. Scheduling the incremental delivery of a system is not a requirements activity.
You can, however, divide use cases into versions along nonfunctional requirements lines. To do so, you loosen the constraints (rather than features) on the first iteration and attach progressively more stringent constraints in succeeding iterations. My next entry will explore a specific example of constraint-based use case versions.
Use case versions help with incremental delivery by enabling shorter iterations and releases. With incremental delivery, you should be iterating on the development of the product and "releasing" the product for testing and feedback after each iteration. But often a use case is far too complex to implement within a single iteration time-box. In such situations, you can implement a succession of simplified versions of the use case instead.For example, imagine your organization is implementing an e-commerce web site. One of the highest-level use cases (perhaps even the only use case at the requirements level) is Purchase Items. You've attached various nonfunctional requirements to this use case regarding usability, payment flexibility, etc. It's unlikely that your developers will be able to deliver a fully tested implementation of the use case that satisfies all of these requirements in a single two week iteration.
What to do? Throw up your hands and extend the length of the iteration? No need. Instead, divide the use case into versions:
Purchase Items (cash only, no receipt)Now your developers can realistically implement each version of the use case within the two-week time-box. Furthermore, they can deliver concrete, end-to-end user value at the end of each iteration.
Purchase Items (cash, receipt)
Purchase Items (cash and check, receipt)
Purchase Items (cash, check, credit, receipt)
Note that the simplying assumptions in this example were feature assumptions. It is a feature of the system to support credit payments. It is a feature of the system to support receipts. Such features represent design choices to satisfy the nonfunctional requirements. Scheduling the incremental delivery of a system is not a requirements activity.
You can, however, divide use cases into versions along nonfunctional requirements lines. To do so, you loosen the constraints (rather than features) on the first iteration and attach progressively more stringent constraints in succeeding iterations. My next entry will explore a specific example of constraint-based use case versions.
Comments