Process: How to Work With Use Cases in Iterative Methods? - UML

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 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 realizationsdrive 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 presents a sample ( not a recipet ) that 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, the team deliberately delays in continuing with deep requirements work until near the end of the first elaboration iteration.

This is a key difference between iterative development and a waterfall process: Production - quality development of the core of a system starts quickly, long before all the requirements are known.

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." The act of building software rapidly surfaces assumptions and questions that need clarification.

In the UP, use case writing is encouraged in a requirements workshop. Figure offers suggestions on the time and space for doing this work.

Table Sample requirements effort across the early iterations; this is not a recipe

Table Sample requirements effort across the early iterations; this is not a recipe

When Should Various UP Artifact (Including Use Cases) be Created?

Table 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.

Table Sample UP artifacts and timing, s - start; r - refine

Table Sample UP artifacts and timing, s - start; r - refine

Figure Process and setting context for writing use cases

Figure Process and setting context for writing use cases

How to Write Use Cases in Inception?

The following discussion expands on the information in Table.

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.

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.

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:

Case Study: Use Cases in the NextGen Inception Phase


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics