编写有效用例（英文版） (2008 年度畅销榜NO.2410 )

Highlights of the book include: A thorough discussion of the key elements;of \r\n\r\nuse cases-actors. stakeholders.design scope. scenarios, and more A use case style \r\n\r\nguide with action steps and suggested formats An extensive list of time-saving \r\n\r\nuse case writing tips A helpful presentation of use case templates. with commentary \r\n\r\non when and where they should be employed A proven methodology for taking advantage \r\n\r\nof use cases With this book as your guide. you will learn the essential elements \r\n\r\nof use Case writing. Improve your use case writing skills, and be well on your \r\n\r\nway to employing use cases effectively for your next development project. \r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n \r\n\r\n \r\n\r\n IT之源推出国内首个面向对象需求分析课程\r\n\r\n\r\n “用例与UML需求工程”\r\n\r\n \r\n\r\n \r\n\r\n\r\n
\r\n

Preface \r\n\r\n Acknowlegments \r\n\r\n Chapter 1 Introduction \r\n\r\n 1.1 What Is a Use Case (More or Less)? \r\n\r\n 1.2 Your Use Case Is Not My Use Case \r\n\r\n Steve Adolph: 'Discovering' Requirements in New Territory \r\n\r\n 1.3 Requirements and Use Cases \r\n\r\n 1.4 When Use Cases Add Value \r\n\r\n 1.5 Manage Your Energy \r\n\r\n 1.6 Warm Up with a Usage Narrative \r\n\r\n Usage Narative: Getting 'Fast cash' \r\n\r\n 1.7 Exercises \r\n\r\n Part 1 The Use Case Body Parts \r\n\r\n Chapter 2 The Use Case as a Contract for Behavior \r\n\r\n 2.1 Interactions between Actors with Goals \r\n\r\n 2.2 Contract between Stakeholders with Interests \r\n\r\n 2.3 The Graphical Model \r\n\r\n Chapter 3 Scope \r\n\r\n 3.1 Functional Scope \r\n\r\n 3.2 Design Scope \r\n\r\n 3.3 The Outermost Use Cases \r\n\r\n 3.4 Using the Scope-Defining Work Products \r\n\r\n 3.5 Exercises \r\n\r\n Chapter 4 Stakeholders and Actors \r\n\r\n 4.1 Stakeholders \r\n\r\n 4.2 The Primary Actor \r\n\r\n 4.3 Supporting Actors \r\n\r\n 4.4 The System Under Discussion \r\n\r\n 4.5 Internal Actors and White-Box Use Cases \r\n\r\n 4.6 Exercises \r\n\r\n Chapter 5 Three Named Goal Levels \r\n\r\n 5.1 User Goals (Blue, Sea-Level) \r\n\r\n 5.2 Summary Level (White, Cloud/Kite) \r\n\r\n 5.3 Subfunctions (Indigo/Black, Underwater/Clam) \r\n\r\n 5.4 Using Graphical Icons to Highlight Goal Levels \r\n\r\n 5.5 Finding the Right Goal Level \r\n\r\n 5.6 A Longer Writing Sample: 'Handle a Claim' at Several Leveis \r\n\r\n 5.7 Exercises \r\n\r\n Chapter 6 Preconditions, Triggers, mld Cuarantees \r\n\r\n 6.1 Preconditions \r\n\r\n 6.2 Ninimal Guarantees \r\n\r\n 6.3 Success Guarantee \r\n\r\n 6.4 Triggers \r\n\r\n 6.5 Exercises \r\n\r\n Chapter 7 Scenarios and Steps \r\n\r\n 7.1 The Main Success Scenario \r\n\r\n 7.2 Action Steps \r\n\r\n 7.3 Exercises \r\n\r\n Chapter 8 Extensions \r\n\r\n 8.1 Extension 8asics \r\n\r\n 8.2 The Extension Conditions \r\n\r\n 8.3 Extension Handling \r\n\r\n 8.4 Exercises \r\n\r\n Chapter 9 Technology and Data Variations \r\n\r\n Chapter 10 Linking Use Cases \r\n\r\n 10.1 Sub Use Cases \r\n\r\n 10.2 Extension Use Cases \r\n\r\n 10.3 Exercises \r\n\r\n Chapter 11 Use Case Formats \r\n\r\n 11.1 Formats to Choose From \r\n\r\n 11.2 Forces Affecting Use Case Writing Styles \r\n\r\n 11.3 Standards for Five Project Types \r\n\r\n 11.4 Conclusion \r\n\r\n 11.5 Exercise \r\n\r\n \r\n\r\n Part 2 Frequently Discussed Topics \r\n\r\n Chapter 12 When Are We Done? \r\n\r\n Chapter 13 Scaling Up to Many Use Gases \r\n\r\n Chapter 14 CRUD and Parameterized Use Cases \r\n\r\n 14.1 CRUD Use Cases \r\n\r\n 14.2 Parameterized Use Cases \r\n\r\n Chapter 15 Business Process Modeling \r\n\r\n 15.1 Modeling versus Designing \r\n\r\n 15.2 Linking Business and System Use Cases \r\n\r\n Ruety Walters: Business Modeling and System Requirements \r\n\r\n Chapter 16 The Missing Requirements \r\n\r\n 16.1 Precision in Data Requirements \r\n\r\n 16.2 Cross-linking from Use Cases to Other Requirements \r\n\r\n Chapter 17 Use Cases in the Overall Process \r\n\r\n 17.1 Use Cases in Projea Organization. \r\n\r\n 17.2 Use Cases to Task or Feature Lists \r\n\r\n 17.3 Use Cases to Design \r\n\r\n 17.4 Use Cases to UI Design \r\n\r\n 17.5 Use Cases to Test Cases \r\n\r\n 17.6 The Actual Writing \r\n\r\n Andy Kraus: Collecting Use Cases from a Large, Diverse Lay Group \r\n\r\n Chapter 18 Use Case Briefs and Extreme Programming \r\n\r\n Chapter 19 Mistakes Fixed \r\n\r\n 19.1 No System \r\n\r\n 19.2 No Primary Actor \r\n\r\n 19.3 Too Many User interface Details \r\n\r\n 19.4 Very Low Goal Levels \r\n\r\n 19.5 Purpose and content Not Aligned \r\n\r\n 19.6 Advanced Example of Too Much UI \r\n\r\n \r\n\r\n Part 3 Reminders for the Busy \r\n\r\n Chapter 20 Reminders for Each Use Case \r\n\r\n Chapter 21 Reminders for the Use Case Set \r\n\r\n Chapter 22 Reminders for Working on the Use Cases \r\n\r\n Appendiees \r\n\r\n Appendix A Use Cases in UML \r\n\r\n A.1 Ellipses and Stick Figures \r\n\r\n A.2 UML's Includes Relation \r\n\r\n A.3 UML's Extends Relation \r\n\r\n A.4 UML's Generalizes Relations \r\n\r\n A.5 Subordinate versus Sub Use Cases \r\n\r\n A.6 Drawing Use Case Diagrams \r\n\r\n A.7 Write Text-based Use Cases Instead \r\n\r\n Appendix B Answers to (Some) Exercises \r\n\r\n Appendix C Glossary \r\n\r\n Appendix D Readings \r\n\r\n index \r\n
\r\n

More and more people are writing use cases, for behavioral requirements, for software systems or to describe business processes. It all seems easy enough—just write about using the system. But, faced with writing, one suddenly confronts the question, "Exactly what am I supposed to write—how much, how little, what details?" That turns out to be a difficult question to answer. The problem is that writing use cases is fundamentally an exercise in writing prose essays, with all the difficulties in articulating good that comes with prose writing in general. It is hard enough to say what a good use case looks like, but we really want to know something harder: how to write them so they will come out being good.

These pages contain the guidelines I use in my use case writing and in coaching: how a person might think, what he or she might observe, to end up with a better use case and use case set.

I include examples of good and bad use cases, plausible ways of writing differently, and, best of all, the good news that a use case need not be the best to be useful. Even mediocre use cases are useful, more so than are many of the competing requirements files being written. So relax, write something readable, and you will have done your organization a service.

Audience

This book is predominantly aimed at industry professionals who read and study alone, and is therefore organized as a self-study guide. It contains introductory through advanced material: concepts, examples, reminders, and exercises (some with answers, some without).

Writingcoaches should find suitable explanations and samples to show their teams. Course designers should be able to build course material around the book, issuing reading assignments as needed. (However, as I include answers to many exercises, they will have to construct their own exam material. :-) )

Organization

The book is organized as a general introduction to use cases followed by a close description of the use case body parts, frequently asked questions, reminders for the busy, and end notes.

The Introduction contains an initial presentation of key notions, to get the discussion rolling: "What does a use case look like?," "When do I write one?," and "What variations are legal?" The brief answer is that they look different depending on when, where, with whom, and why you are writing them. That discussion begins in this early chapter, and continues throughout the book.

Part 1, The Use Case Body Parts, contains chapters for each of the major concepts that need to mastered, and parts of the template that should be written. These include "The Use Case as a Contract for Behavior," "Scope," "Stakeholders and Actors," "Three Named Goal Levels," "Preconditions, Triggers, and Guarantees," "Scenarios and Steps," "Extensions," "Technology and Data Variations," "Linking Use Cases," and "Use Case Formats."

Part 2, Frequently Discussed Topics, addresses particular topics that come up repeatedly: "When Are We Done?," "Scaling Up to Many Use Cases," "CRUD and Parameterized Use Cases," "Business Process Modeling," "The Missing Requirements," "Use Cases in the Overall Process," "Use Case Briefs and eXtreme Programming," and "Mistakes Fixed."

Part 3, Reminders for the Busy, contains a set of reminders for those who have finished reading the book, or already know this material and want to refer back to key ideas. The chapters are organized as "Reminders for Each Use Case," "Reminders for the Use Case Set," and "Reminders for Working on the Use Cases."

There are four appendices: Appendix A discusses "Use Cases in UML" and Appendix B contains "Answers to (Some) Exercises." The book concludes with Appendix C, Glossary; and a list of materials used while writing, Appendix D, Readings.

Heritage of the Ideas

In the late 1960s, Ivar Jacobson invented what later became known as use cases while working on telephony systems at Ericsson. In the late 1980s, he introduced them to the object-oriented programming community, where they were recognized as filling a significant gap in the requirements process. I took Jacobson's course in the early 1990s. While neither he nor his team used my phrases goal and goal failure, it eventually became clear to me that they had been using these notions. In several comparisons, he and I have found no significant contradictions between his and my models. I have slowly extended his model to accommodate recent insights.

I constructed the Actors and Goals conceptual model in 1994 while writing use case guides for the IBM Consulting Group. It explained away much of the mystery of use cases and provided guidance as to how to structure and write them. The Actors and Goals model has circulated informally since 1995 at http://members.aol.com/acockburn and later at www.usecases.org, and finally appeared in the Journal of Object-Oriented Programming in 1997, in an article I authored entitled "Structuring Use Cases with Goals."

From 1994 to 1999, the ideas stayed stable, even though there were a few loose ends in the theory. Finally, while teaching and coaching, I saw why people were having such a hard time with such a simple idea (never mind that I made many of the same mistakes in my first tries!). These insights, plus a few objections to the Actors and Goals model, led to the explanations in this book and to the Stakeholders and Interests model, which is a new idea presented here.

The Unified Modeling Language (UML) has had little impact on these ideas—and vice versa. Gunnar Overgaard, a former colleague of Jacobson's, wrote most of the UML use case material and kept Jacobson's heritage. However, the UML standards group has a strong drawing-tools influence, with the effect that the textual nature of use cases has been lost in the standard. Gunnar Overgaard and Ivar Jacobson discussed my ideas and assured me that most of what I have to say about a use case fits within one of the UML ellipses, and hence neither affects nor is affected by what the UML standard has to say. That means that you can use the ideas in this book quite compatibly with the UML 1.3 use case standard. On the other hand, if you only read the UML standard, which does not discuss the content or writing of a use case, you will not understand what a use case is or how to use it, and you will be led in the dangerous direction of thinking that use cases are a graphical, as opposed to a textual, construction. Since the goal of this book is to show you how to write effective use cases and the standard has little to say in that regard, I have isolated my remarks about UML to Appendix A.

Samples Used

The writing samples in this book were taken from live projects as much as possible, and they may seem slightly imperfect in some instances. I intend to show that they were sufficient to the needs of the project teams that wrote them, and that those imperfections are within the variations and economics permissible in use case writing.

The Addison-Wesley editing crew convinced me to tidy them up more than I originally intended, to emphasize correct appearance over the actual and adequate appearance. I hope you will find it useful to see these examples and recognize the writing that happens on projects. You may apply some of my rules to these samples and find ways to improve them. That sort of thing happens all the time. Since improving one's writing is a never-ending task, I accept the challenge and any criticism.

Use Cases in The Crystal Collection

This is just one in a collection of books, The Crystal Collection for Software Professionals, that highlights lightweight, human-powered software development techniques. Some books discuss a single technique, some discuss a single role on a project, and some discuss team collaboration issues.

Crystal works from two basic principles:

Software development is a cooperative game of invention and communication. It improves as we develop people's personal skills and increase the team's collaboration effectiveness.

Different projects have different needs. Systems have different characteristics and are built by teams of differing sizes, with members having differing values and priorities. It is impossible to name one, best way of producing software.

The foundation book for The Crystal Collection, Software Development as a Cooperative Game, elaborates the ideas of software development as a cooperative game, of methodology as a coordination of culture, and of methodology families. That book separates the different aspects of methodologies, techniques and activities, work products and standards. The essence of the discussion, as needed for use cases, appears in this book in Section 1.2, Your Use Case Is Not My Use Case on page 7.

Writing Effective Use Cases is a technique guide, describing the nuts-and-bolts of use case writing. Although you can use the techniques on almost any project, the templates and writing standards must be selected according to each project's needs.

无封面