In the preceding chapters, we have focused principally on use-case modeling as a technique for capturing and communicating requirements. Before we conclude, a few issues remain to be resolved: a quick overview on how use cases are used in the broader life cycle and a brief discussion of how use cases are developed across the project life cycle, especially in the context of an iterative software development life cycle. Finally, we conclude with a look toward the future, toward new ways of using use cases to develop solutions.
As we have shown in the previous chapters, use cases are a simple but powerful technique for capturing and communicating requirements. This is certainly important, but there is more. Use cases can be used as a unifying principle that unites the activities of the project and gives the project a consistent, solution-oriented focus that always keeps the customer solution in mind. [1] The use of use cases to unify software development activities was introduced by Ivan Jacobson and explained in Object-Oriented Software Engineering.
In the Introduction, we mentioned that the following kinds of people are interested in use cases:
Customers,. who need to be sure that the system that is getting built is the one that they want
Managers,. who need to have an overall understanding of what the system will do in order to effectively plan and monitor the project
Analysts,. who need to describe and document what the system is going to do
Developers,. who need to understand what the system needs to do in order to develop it
Testers,. who need to know what the system is supposed to do so that they can verify that it does it
Technical writers,. who need to know what the system is supposed to do so that they can describe it
User-Experience designers,. who need to understand the users’ goals and how they will use the system to achieve these goals
By this point, it should be obvious how customers and users would be interested in use cases—they are, in fact, some of the major stakeholders with whom one will work when establishing the vision (for a review of this, see Chapter 3, Establishing the Vision). It should also be obvious that most of this book is for analysts, the people who elicit the requirements from stakeholders, capture the requirements in an understandable form, and communicate the requirements to the rest of the development team. But what about the other stakeholders presented here? How do they use use cases? This was touched on in Chapter 6, The Life cycle of a Use Case, but it is worth another, more detailed examination.
Developers are responsible for realizing the requirements in software, trans-lating descriptions of what the system must do into actual code. In this process, they will analyze the use cases, perhaps describing how the system works as a series of collaborations of objects. These collaborations are first done at a high level, from an “ideal” perspective that omits details of the implementation environment to ensure a focus on supporting the behavior of the use case. These ideal descriptions are later refined by considering the details of the implementation environment. [2]
The value of using use cases is that the same description that is used to gain agreement with the stakeholders can also be used to drive the analysis, design, and implementation efforts. This greatly reduces the chance that the requirements will be ignored, forgotten, or overlooked by the development team. In addition, and perhaps more important, it gives the development team a place to start and an easy way to understand what it is supposed to build.
Requirements have always had a central role in testing. In order to determine whether the system does what it is supposed to do, it’s necessary to know just what the system is supposed to do. Testers often suffer from a lack of adequate information about what the system is supposed to do. We have seen many projects on which testers expended great effort reconstructing the requirements from inadequate documentation. The existence of use cases solves this problem, allowing testers to focus on testing the system, not trying to figure out what the system is supposed to do.
As we have discussed at length, use cases are excellent vehicles for describing the behavior of the system and so provide an excellent source for defining test cases. Since use cases describe what the users want from the system, they are an excellent source for defining user-acceptance test cases. In addition, because the use cases drive the development of the system, they provide important inputs for the definition of performance, system, and integration tests. [3]
It stands to reason that use cases and usability will be intimately intertwined. Use cases describe how the system is used, and understanding how the system is used is essential to ensuring that the system is useable.
As we discussed earlier, details of the user interface should not be included in use cases. Doing so renders the use cases difficult to understand because it obscures the objectives of the system behind a mass of user-interface details and difficult to maintain because the user interface will continue to evolve long after the use-case descriptions have stabilized. User-interface designs will evolve in parallel with the use cases in the form of use-case storyboards and user-interface prototypes, which in turn give rise to the actual user interfaces.
Even though the details of the user interface are omitted from the use cases, the use-case descriptions provide essential context for the user-interface design. In addition, development of use-case storyboards and user-interface prototypes, coupled with walk-throughs of the use cases using the storyboards and prototypes, provides an excellent way of reviewing the use cases with key stakeholders. The storyboards and prototypes bring the use cases to life, while the use cases provide a coherent thread through the storyboards and prototypes. [4]
Typical software documentation tends to be organized around features, which tend to be rather arbitrary and only loosely related to the things of value the users want from the system, or around functions, which are capabilities of the system but are also only loosely related to the things of value the system does for its users. As a result, documentation is often not very useful in helping users to accomplish their goals when using the system. Even when the documentation is task oriented, a great deal of effort has to be expended by technical writers to determine the system’s intended uses and the users’ desired results.
Because use cases describe how the users will use the system, they provide a natural way of organizing the documentation. Documentation that mirrors the use cases, and which helps users understand how to use the system to achieve their goals, will immediately be of greater value to users than functionally organized documentation. Documentation can be organized by using the use cases as major sections in the documentation, with the help topics mirroring the basic flow, the named subflows, and the alternative flows. By doing this, the documentation leverages the work already done to understand what the system does for its users and how the users use the system.
Since use cases can define a very large subset of the system, they will drive a substantial amount of the overall work on the system. The relationship of the use cases to the other software development activities, as described in the preceding sections and Chapter 6, The Life Cycle of a Use Case, makes them ideal for structuring the work breakdown structure and planning the development activities.
The structure of the use-case model and the use-case descriptions is also ideal for scope managing the project, as their additive nature allows the impact of removing flows and use cases from the project scope to be particularly visible and understood in terms of the value to the user of the sets of functionality.
They are also very useful for tracking the progress of the project and how much value the project has earned to date. They are particularly powerful when used in conjunction with an iterative and incremental development process, as the defining of the results of iterations in terms of use cases and flows of events allows the system to demonstrably deliver additional value to the users with each iteration.
The nature of, and the role played by, the structure of the use-case model and the use-case descriptions was discussed in detail in Chapter 7, The Structure and Contents of a Use Case. To fully understand the role that use cases can play in the planning and execution of a project, you need to understand the role that the use cases play as the project progresses. This is discussed in the next section.
In the preceding chapters, it is easy to get the idea that one develops use cases all at once, then hands them off to other people to develop, test, and document. While it is possible to take this approach (sometimes called the waterfall approach, since each discipline tends to cascade into the next [5]), it tends to ignore the synergy achieved by having all team members participating in the evolution of the use cases. The reality is that each team member brings a different and valuable perspective to the process, and engaging all members in the evolution leads to an overall improvement in the end result.
The truth is that finding the right level of detail in the use-case description is a collaborative effort. Developers need a certain amount of detail to build the system, testers need a certain amount of detail to test the system, and so on. Working on requirements, development, testing, documentation, and other project activities in a more concurrent manner enables the team to identify knowledge gaps sooner, resulting in a better system. This is not to say that things happen randomly—in fact, to be successful at a more “parallel” approach, some strategies are needed to get the team fully engaged and working on the right things at the right time.
A modern software development project is conducted as a series of iterations, each of which consists of a little requirements definition, analysis, design, implementation, and testing. Each iteration results in something executable, possibly just a prototype, but increasingly a larger and larger portion of the complete system as the project nears completion. A widely used process framework that embodies the principles of iterative software development is the Rational Unified Process (RUP). [6] In describing how use cases are used to develop a system in a series of iterations, we will use the project phases it defines.
The RUP divides the process into four sequentially arranged phases, each of which may contain one or more iterations:
Inception: dealing with business risks (the vision for the project, the funding for the project, and issues dealing with the financial viability of the project)
Elaboration: dealing with technical and architectural risks
Construction: dealing with “project execution” risk (building the project on time and within budget), and finally
Transition: Dealing with risks related to rolling the project out to its users
As noted, the purpose of the Inception phase is to define the vision for the system and by doing so to assess the business viability of the project. In addition to defining the vision as described in Chapter 3, actors and use cases will be identified as described in Chapters 4 and 5. Finding actors and use cases helps us to understand the value that the system provides to its stakeholders, which is an important part of determining whether the system is worth building. In addition to identifying actors and use cases, use-case storyboards and user-interface prototypes are often created in the Inception phase to help visualize and illustrate the use cases. Planning for the user documentation is also begun, based on the identified use cases. Use cases may be outlined, to help give a better understanding of the behavior of the system, but the work is bounded by the goal of determining whether the system has a viable business case.
In the Elaboration phase, a subset of the use cases is selected for detailing, analysis, design, implementation, and testing, for the purpose of exploring the architecture of the system. Not all use cases are architecturally significant, and in fact it is often only part of a use case that significantly exposes architectural issues. The art of planning the Elaboration phase involves selecting the scenarios that will expose architectural issues that, when addressed, will define the architecture of the system.
Once a set of architectural scenarios is selected, the portions of the use cases that define the scenarios are detailed, as described in Chapters 8 and 9. Following this, the use cases are analyzed, designed, and implemented to a degree sufficient to allow the validation of the architecture. This means that some of the functionality of the system will be implemented as stubs, in which the real behavior of the system is only simulated. Behavior is stubbed when it is determined to be architecturally insignificant.
During Elaboration, test cases are also written to assess the architectural viability of the system, based on the use cases that are determined to be architecturally significant. The test cases are evaluated against the architectural prototypes, resulting in either identification of new architectural risks or retirement of existing architectural risks. Also, work on the user documentation continues.
At the end of the Elaboration phase, the requirements should be stable and understood. This does not mean that all of them have been captured and documented, but that there should be no major surprises as the requirements specification is incrementally completed. The additive structure of the use-case model, and the use cases’ flows of events, is again very important here as it provides a high-level framework for assessing the stability of the system’s requirements. If it is felt that a use case contains areas of instability, risk, or complexity, then these unstable flows of events can be detailed to a level that removes the uncertainty. If a use case or a flow of events is considered to be low risk and well understood, its detailed authoring can be left until a later iteration. This allows the use cases to be completed in a “just-in-time” fashion as part of the iteration that implements them.
Not all use cases are completely detailed by the end of the Elaboration phase. Typically, some of the use cases have a number of flows detailed, but many use cases may still be only briefly described. In the Construction phase, the remaining use cases are detailed (if detailed descriptions are determined to be needed), analyzed, designed, and implemented. The resulting system is progressively tested until, by the end of the Construction phase, the system is ready to be delivered for beta testing. User documentation needed for beta testing is completed based on the use cases completed.
No use-case work is done in the Transition phase, except indirectly; testing is completed using test cases that are derived from use cases. Work on the user documentation concludes, final defects are fixed, and the product is prepared for final release.
And what happens to use cases once the product is released? Use cases continue to provide value to the people who maintain and support the system— they provide a way to understand what the system was supposed to do. The use cases also provide a basis for future development of the system when it requires enhancements, which begins a new project and a new round of evolution of the use cases.
Another interesting perspective on the role of use cases across the life cycle is that of the relative amounts of effort expended on requirements work in general and use cases in particular across the phases of a typical project. This is shown in Figure 12-1. As you can see from the figure, if the approach recommended by this book is adopted, then the majority of the requirements work is typically related to the development and detailing of the use-case model. This is not the only requirements effort necessary, as we would also recommend developing a vision document and a Supplementary Specification. (Note: The glossary is so tightly coupled to the use-case model that it is considered to be part of the use-case model when assessing the effort expended.) You can also see that requirements work, and use-case modeling in particular, continues throughout all of the phases of the project. The amount of effort expended in these areas typically peaks during the Elaboration phase when the majority of the requirements are discovered and the overall requirements definition stabilizes.
The preceding sections described a number of artifacts that are derived from use cases (principally use-case realizations—that is, collaborations—and test cases), and the preceding chapters of the book described a number of types of requirements that are related in some way to use cases (needs, features, special requirements, and supplementary requirements). These artifacts are related by traceability relationships (a kind of dependency in UML). Traceability relationships indicate that one thing is derived from or dependent on another thing.
While knowing about what a thing was derived from is interesting, the main benefit of traceability comes from its role in assessing the completeness of a system with respect to its requirements and from determining the coverage of testing. Traceability’s role in assessing completeness and coverage arises from being able to use the relationships to determine the following:
Whether every requirement is handled by at least one use case
Whether every user type has at least one actor whose role it can play
Whether every actor is involved in at least one use case
Whether every use case has at least one use-case realization
Whether the use-case realizations have participating classes that are fully designed and implemented
Whether all use cases have associated test cases and, more specifically, whether all scenarios are covered
And finally whether all test cases have been successfully executed
Traceability is also useful in managing change on the project, by allowing the team to determine what things need to be updated when something changes. By following the traceability relationships, the team can find the use-case realizations and test cases that need to be updated when a use case changes or find the use cases that need to be updated when a stakeholder need changes (due to a change in the business environment, for example). Traceability is, in effect, the glue that holds the artifacts together and makes iterative software development possible.
Our journey into the world of use cases has drawn to a close, and yet in many respects it has just begun. First, no new technique is mastered without practice. We have tried to share with you the many years of experience of a great number of people. As hard as we have tried to impart this experience, only practice will hone this knowledge to a keen edge. You must try, struggle, fall short, and then succeed on your own, building your own knowledge with experience.
In addition, we have intentionally kept our examples simple as an aid to understanding. The real world is considerably more varied, and while our les-sons still apply, there are subtle nuances of technique to be applied to different kinds of systems. There are, in effect, patterns of description to use cases that can be identified and shared among teams working on similar kinds of systems. We hope that future authors (perhaps even ourselves) can focus on these areas to continue to expand the usefulness of use-case modeling.
We have provided what we hope is a strong foundation for these efforts. Use cases are a simple but powerful technique, one that is easily applied to a wide range of projects and problem domains. We wish you good luck in your efforts to apply them to your projects.
[1] The use of use cases to unify software development activities was introduced by Ivar Jacobson and explained in Object-Oriented Software Engineering.
[2] The details of this process are the subjects of a number of excellent books, among which are Ivar Jacobson’s Object-Oriented Software Engineering: A Use Case Driven Approach, Doug Rosenberg and Kendall Scott’s Use Case Driven Object Modeling With UML : A Practical Approach and Craig Larm-an’s Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process.
[3] An excellent reference for defining test cases (as well as the rest of the testing process) is Lessons Learned in Software Testing by Cem Kaner, James Bach, and Bret Pettichord.
[4] A number of excellent references provide the full story on how this happens, notably Constantine and Lockwood, Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design.
[5] For a discussion of project life cycles and how to manage project iteratively, see Walker Royce’s Software Project Management: A Unified Framework.
[6] For an introduction to the Rational Unified Process, see The Rational Unified Process: An Introduction by Philippe Kruchten.