6.16. Use Cases Within the UP
Use cases are vital and central to the UP, which encourages use-case driven development. This implies:
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 is—in part—defined 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.
The UP distinguishes between system and business use cases. System use cases are what have been examined in this chapter, such as Process Sale. They are created in the Requirements discipline, and are part of the Use-Case Model.
Business use cases are less commonly written. If done, they are created in the Business Modeling discipline as part of a large-scale business process reengineering effort, or to help understand the context of a new system in the business. They describe a sequence of actions of a business as a whole to fulfill a goal of a business actor (an actor in the business environment, such as a customer or supplier). For example, in a restaurant, one business use case is Serve a Meal.
Use Cases and Requirements Specification Across the Iterations
This section reiterates a key idea in the UP and iterative development: The timing and level of effort of requirements specification across the iterations. Table 6.1 presents a sample (not a recipe) which communicates the UP strategy of how requirements are developed.
Note that a technical team starts building the production core of the system when only perhaps 10% of the requirements are detailed, and in fact, there is a deliberate delay in continuing with concerted requirements work until near the end of the first elaboration iteration.
This is the key difference in iterative development to a waterfall process: Production-quality development of the core of a system starts quickly, long before all the requirements are known.
| Discipline | Artifact | Comments and Level of Requirements Effort | ||||
|---|---|---|---|---|---|---|
| Incep 1 week | Elab 1 4 weeks | Elab 2 4 weeks | Elab 3 3 weeks | Elab 4 3 weeks | ||
| Requirements | Use-Case Model | 2-day requirements workshop. Most use cases identified by name, and summarized in a short paragraph. Only 10% written in detail. | 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 80-90% 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. |
Observe that near the end of the first iteration of elaboration, there is a second requirements workshop, during which perhaps 30% of the use cases are written in detail. This staggered requirements analysis benefits from the feedback of having built a little of the core software. The feedback includes user evaluation, testing, and improved “knowing what we don't know.” That is, the act of building software rapidly surfaces assumptions and questions that need clarification.
Timing of UP Artifact Creation
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 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 | ||||
| Data Model | s | r | |||
| Implementation | Implementation Model | s | r | r | |
| Project Management | SW Development Plan | s | r | r | r |
| Testing | Test Model | s | r | ||
| Environment | Development Case | s | r |
Use Cases Within 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 user goals (and thus, user goal level use cases) are identified, 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, or which 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 a small sample of interesting use cases. Perhaps this means two use cases: Process Sale and Handle Returns.
A requirements management tool that integrates with a word processor is used for the writing, and the work is displayed via a projector while the team collaborates on the analysis and writing. The Stakeholders and Interests lists are written for these use cases, to discover more subtle (and perhaps costly) functional and key non-functional requirements—or system qualities—such as for reliability or throughput.
The analysis goal is not to exhaustively complete the use cases, but spend a few hours to obtain some insight.
The project sponsor needs to decide if the project is worth significant investigation (that is, the elaboration phase). The inception work is not meant to do that investigation, but to obtain low-fidelity (and admittedly error-prone) insights regarding scope, risk, effort, technical feasibility, and business case, in order to decide to move forward, where to start if they do, or if to stop.
Perhaps the NextGen project inception step lasts five days. The combination of the two day requirements workshop and its brief use case analysis, and other investigation during the week, lead to the decision to continue on to an elaboration step for the system.
Use Cases Within 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 iteration—four 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, “80-90%” 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.
Use Cases Within Construction
The construction step 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 will still be some minor use case writing and perhaps requirements workshops, but much less so than in elaboration. By this step, the majority of core functional and non-functional requirements should have iteratively and adaptively stabilized. That does not mean to imply requirements are frozen or investigation finished, but the degree of change is much lower.