Preface

It has been an interesting three years since the first edition of this book was published. At that time, use cases were still an "interesting technique" but had not been widely adopted. Today, we see a software development marketplace where use cases are the standard practice for gathering requirements and have even migrated to other applications, including business processes and service offerings. We would not have predicted this wave of popularity in our happiest visions .

Of course, our book was not the only one in the last few years to proselytize use cases. But it has been gratifying to be part of this new technique's recognition in the software world. Given this trend, we've decided to publish a second edition of Use Cases , putting together the lessons we've learned since our original thoughts. And the lessons have been many. Our approach in the first edition was something we had created after several use-case-driven project efforts, but it was still a young process. Using it on many more projects since the book was published, we have had a chance to collaborate with many of the best minds in the software business and fine-tune the process into something much more workable , practical, and scaleable. We have also taken ideas from other emerging fields, including the ideas of chaordic organizations (Dee Hock 2000; Margaret Wheatley 2001; and others) as well as Drs. Theodore Williams and Hong Li of Purdue University and their Purdue Enterprise Reference Architecture. Both bodies of work have had a tremendous impact on how we've applied use cases on our projects and how we've recast our ideas in this new edition.

First and most noticeably, we have only three "F" iterations this time: Facade, Filled, and Focused. The last F (Finished) has proven troublesome on one project after another. First of all, in an iterative approach, nothing is ever truly finished . It is always evolving. Also, as an iteration, it really contained only the mesh between use cases and the user interface design. We have moved the user interface ideas into the Facade iteration because the evolution of the user interface should proceed in parallel with the creation of early use cases, not following it.

Another big change is our approach in our management chapter. Although we are not directly contradicting anything from before, we have expanded our explanation of iterative/incremental use-case-driven project management greatly in this edition. We call it holistic iterative/incremental, or HI/I (hi-eye). We believe this area of the lifecycle requires the most work of anything, since the waterfall project management processes from years past are not keeping up with the faster pace, more "chaordic" software lifecycles of today. We present our chapter on management here, but we eagerly look forward to other authors expanding on these ideas and inventing new ways of tackling this big problem. Also, the Project Management Institute (PMI) has made some gestures toward embracing some of the new software lifecycle ideas.

The appendixes in our first edition were regarded by many readers we heard from as the best and the worst parts of the book. We were the first to try to show partially complete use cases in our examples, which is a crucial step to understanding the iterative nature of use case creation. However, the presentation was quite confusing, because we repeated use cases through the four iterations, sometimes they changed, sometimes they didn't, and it was hard to tell what changed and when. This time we're taking a very different approach. We still want to tell the story of how use cases are applied to software requirements gathering, but we're doing it in a much less formal way. In each appendix, we've picked a style of application (large business application, technical subsystem, package evaluation, and so on) and shown how the use cases and other artifacts evolve through the story. We hope this will retain the good aspects of the first edition, but add some coherence to the evolution of use case versions.

We've found on many, many projects that the idea of use case hierarchies does nothing but add confusion. Creating use cases that are "high level" and then "detailed" use cases later is hurting the requirements process. Hierarchies that are taller and more complex (some books advocate four-level hierarchies or more) create more and more distance from the original business requirements. Even though our original process had only two levels of hierarchy (system context-level use case and one level below) we always had trouble with teams who wanted to add levels and confuse themselves . Similarly, using <<include>> and <<extend>> stereotypes on use case associations adds an unnecessary level of problems, which has caused us to eliminate their usage except in very specific circumstances. To this end, we've added a new tool to our familiar set of tools and filters: the hierarchy killer. We hope you have fun killing hierarchies everywhere.

Use cases are different from other types of requirements techniques in many ways, but one particular difference is in the realm of traceability. Use cases are much more traceable back to the business needs, and also traceable into the software development artifacts, to everything from UML analysis and design artifacts to testing, documentation, training, security, and even parts of the architecture. We've decided to dedicate a chapter to this traceability phenomenon of use cases, to show opportunities for making sure the team is "working on the right thing."

Finally, in the interests of keeping up-to-date with the technological tools of requirements gathering, we've listed the tools available at this writing and given some ideas as to their best use. Since these tools change so quickly (and books get written so slowly, especially by us!) we decided to keep this brief.

We hope you enjoy this second edition of Use Cases: Requirements in Context . We've enjoyed creating the updates and going through the publishing cycle again with our publishers at Pearson Education. Please feel free to contact us with your ideas, experiences, and comments anytime . Our e-mail addresses are listed at the end of the last chapter in the book.