6.21. Process: How to Work With Use Cases in Iterative Methods?
Use cases are central to the UP and many other iterative methods. The UP encourages use-case driven development . This implies:
- Functional requirements are primarily recorded in use cases (the Use-Case Model); other requirements techniques (such as functions lists) are secondary, if used at all.
- Use cases are an important part of iterative planning. The work of an iteration isin partdefined by choosing some use case scenarios, or entire use cases. And use cases are a key input to estimation.
- Use-case realizations drive the design. That is, the team designs collaborating objects and subsystems in order to perform or realize the use cases.
- Use cases often influence the organization of user manuals.
- Functional or system testing corresponds to the scenarios of use cases.
- UI "wizards" or shortcuts may be created for the most common scenarios of important use cases to ease common tasks.
How to Evolve Use Cases and Other Specifications Across the Iterations?
This section reiterates a key idea in evolutionary iterative development: The timing and level of effort of specifications across the iterations. Table 6.1 presents a sample (not a recipe) that communicates the UP strategy of how requirements are developed.
Discipline | Artifact | Comments and Level of Requirements Effort | ||||
---|---|---|---|---|---|---|
Incep1 week | Elab 14 weeks | Elab 24 weeks | Elab 33 weeks | Elab 43 weeks | ||
Requirements | Use-Case Model | 2-day requirements workshop. Most use cases identified by name, and summarized in a short paragraph.Pick 10% from the high-level list to analyze and write in detail. This 10% will be the most architecturally important, risky, and high-business value. | Near the end of this iteration, host a 2-day requirements workshop. Obtain insight and feedback from the implementation work, then complete 30% of the use cases in detail. | Near the end of this iteration, host a 2-day requirements workshop. Obtain insight and feedback from the implementation work, then complete 50% of the use cases in detail. | Repeat, complete 70% of all use cases in detail. | Repeat with the goal of 8090% of the use cases clarified and written in detail.Only a small portion of these have been built in elaboration; the remainder are done in construction. |
Design | Design Model | none | Design for a small set of high-risk architecturally significant requirements. | repeat | repeat | Repeat. The high risk and architecturally significant aspects should now be stabilized. |
Implementation | Implementation Model (code, etc.) | none | Implement these. | Repeat. 5% of the final system is built. | Repeat. 10% of the final system is built. | Repeat. 15% of the final system is built. |
Project Management | SW Development Plan | Very vague estimate of total effort. | Estimate starts to take shape. | a little better… | a little better… | Overall project duration, major milestones, effort, and cost estimates can now be rationally committed to. |
Figure 6.7. Process and setting context for writing use cases.
[View full size image]
When Should Various UP Artifact (Including Use Cases) be Created?
Table 6.2 illustrates some UP artifacts, and an example of their start and refinement schedule. The Use-Case Model is started in inception, with perhaps only 10% of the architecturally significant use cases written in any detail. The majority are incrementally written over the iterations of the elaboration phase, so that by the end of elaboration, a large body of detailed use cases and other requirements (in the Supplementary Specification) are written, providing a realistic basis for estimation through to the end of the project.
Discipline | Artifact | Incep. | Elab. | Const. | Trans. |
---|---|---|---|---|---|
Iteration | I1 | E1..En | C1..Cn | T1..T2 | |
Business Modeling | Domain Model | s | |||
Requirements | Use-Case Model | s | r | ||
Vision | s | r | |||
Supplementary Specification | s | r | |||
Glossary | s | r | |||
Design | Design Model | s | r | ||
SW Architecture Document | s |
How to Write Use Cases in Inception?
The following discussion expands on the information in Table 6.1.Not all use cases are written in their fully dressed format during the inception phase. Rather, suppose there is a two-day requirements workshop during the early NextGen investigation. The earlier part of the day is spent identifying goals and stakeholders, and speculating what is in and out of scope of the project. An actor-goal-use case table is written and displayed with the computer projector. A use case context diagram is started. After a few hours, perhaps 20 use cases are identified by name , including Process Sale, Handle Returns , and so on. Most of the interesting, complex, or risky use cases are written in brief format, each averaging around two minutes to write. The team starts to form a high-level picture of the system's functionality.After this, 10% to 20% of the use cases that represent core complex functions, require building the core architecture, or that are especially risky in some dimension are rewritten in a fully dressed format; the team investigates a little deeper to better comprehend the magnitude, complexities, and hidden demons of the project through deep investigation of a small sample of influential use cases. Perhaps this means two use cases: Process Sale and Handle Returns .
How to Write Use Cases in Elaboration?
The following discussion expands on the information in Table 6.1.This is a phase of multiple timeboxed iterations (for example, four iterations) in which risky, high-value, or architecturally significant parts of the system are incrementally built, and the "majority" of requirements identified and clarified. The feedback from the concrete steps of programming influences and informs the team's understanding of the requirements, which are iteratively and adaptively refined. Perhaps there is a two-day requirements workshop in each iterationfour workshops. However, not all use cases are investigated in each workshop. They are prioritized; early workshops focus on a subset of the most important use cases.Each subsequent short workshop is a time to adapt and refine the vision of the core requirements, which will be unstable in early iterations, and stabilizing in later ones. Thus, there is an iterative interplay between requirements discovery, and building parts of the software.During each requirements workshop, the user goals and use case list are refined. More of the use cases are written, and rewritten, in their fully dressed format. By the end of elaboration, "8090%" of the use cases are written in detail. For the POS system with 20 user-goal level use cases, 15 or more of the most complex and risky should be investigated, written, and rewritten in a fully dressed format.Note that elaboration involves programming parts of the system. At the end of this step, the NextGen team should not only have a better definition of the use cases, but some quality executable software.
How to Write Use Cases in Construction?
The construction phase is composed of timeboxed iterations (for example, 20 iterations of two weeks each) that focus on completing the system, once the risky and core unstable issues have settled down in elaboration. There may still be some minor use case writing and perhaps requirements workshops, but much less so than in elaboration.
Case Study: Use Cases in the NextGen Inception Phase
As described in the previous sections, not all use cases are written in their fully dressed form during inception. The Use-Case Model at this phase of the case study could be detailed as follows:
Fully Dressed | Casual | Brief |
---|---|---|
Process SaleHandle Returns | Process RentalAnalyze Sales ActivityManage Security… | Cash InCash OutManage UsersStart UpShut DownManage System Tables… |