Most Helpful Customer Reviews
|
|
73 of 76 people found the following review helpful:
5.0 out of 5 stars
Use cases done right - sensible and effective approach, June 30, 2001
Finally! A book that corrects the numerous problems with use cases - or shall I say the mis use of use cases (no pun intended). Here are some common problems that this book will help you to avoid (there are many more, but these spring immediately to mind):PROBLEM: A horde of analysts descend and produce reams of paper that are little more than stick figures and ellipses. They are, well, of little value because they are devoid of any real information and too often confusing. The other side of this problem is an unmanageable number of these "use cases" are produced with inconsistent detail, or an overwhelming amount of detail crammed into a single use case. RESULT: Developers have no clear idea about how to proceed and much rework is done to get the needed information (or developers do proceed and create something not envisioned). PROBLEM: Use cases are considered to be the requirements specification. RESULT: Developers build something based solely on behavior, leaving out functions and features that customers want or need, and most likely not suited to requirements. PROBLEM: [Related to the preceding] Test plans and test cases for systems built upon the shaky foundation of bad use cases cannot be properly developed. RESULT: A hit-or-miss test cycle that is almost certainly destined to miss a large number of defects (functional and operational). Mr. Cockburn's approach to use cases will allow you to sidestep not only the more common problems associated with improper use cases, but hundreds more than will crop up unless the value and context of use cases in the development or project life cycle is understood. Here are some of the key points in this book that make it so valuable: use cases are but one element of requirements and the hub-and-spoke model given in the book places them into proper context, properly developed use cases are written documents, not diagrams (more about that later), use cases are NOT the requirements document, properly formed use cases DO have a set structure and different levels of precision in accordance with well-defined rules, and the use case creation process needs to be carefully managed because, like software source code, you need to ensure that you're working from the right revision. Part 1 of this book provides clear guidance for writing, managing and using use cases. Part 2 of the book is especially valuable because it addresses frequently discussed topics. Part 3 is a comprehensive list of reminders and rules that will guide you, and Appendix A is a succinct discussion on use cases in UML. A few other things that set this book apart: there are numerous "short stories" throughout the book. Each of these stories reinforce information and concepts, and also epitomize Mr. Cockburn's recurring advice to keep things short - he shows by example how to cram clear information into brief chunks of writing. He also provides a summary of pass/fail tests for use case fields that will make inspections and walkthroughs easy. One piece of trivia answered a question that had been bothering be for years, "why the emphasis on stick figures and ellipses?" The answer: the CASE tool industry, which sold graphical tools, had a lot of influence on the emphasis placed on graphical depictions vs. text-based use cases. This book will set you on the right course and not one that has evolved from vendor agendas. I personally think this is the best book on use cases and is the only one I recommend to clients and associates.
|
|
|
43 of 43 people found the following review helpful:
4.0 out of 5 stars
The power of providing real-world examples, May 22, 2001
If there's one book that can be credited with popularizing use cases, this is it. Alistair Cockburn shares his applied knowledge in `Writing Effective Use Cases' and does so in a very digestible format. This is a handbook, a self-study guide - one full of real-world examples and exercises (with solutions even!) that any analyst or designer can relate to.Use cases are a form of documenting systems requirements and behavioral design specifications. Written well, they offer benefits to all who participate in the development life cycle. This includes analysts, designers, project managers, developers, testers and even end users. Mr. Cockburn's book takes the reader through the writing process, highlighting both good and bad examples. He makes no claims that any of these examples are perfect. And that is perhaps the greatest element of his book. Commit yourself to read through all the examples. By the time you're finished studying them, you will find your own skills in identifying what makes a `good' or `bad' use case have been sharply honed. Perhaps the one area this book does not explore in enough detail is the translation of documented use cases into user interface designs. Mr. Cockburn defers to `Software for Use' (another great book) for this. Even so, I would like to have seen some screen shots and comments about the user interfaces that were created from the examples provided. It would have helped tie the whole picture together. Translating use cases to highly usable interfaces is as much an art as it is a science. I believe this element of use-case driven development is best communicated in a live, face-to-face format. That's why organizations like Classic Systems offer workshops on this topic. As an instructor who teaches use case-driven development, I have found `Writing Effective Use Cases' to be invaluable reference tool. Having tried out a number of Mr. Cockburn's ideas in the classroom, student feedback and learning results have shown me just how potent a learning tool this book can be. Many designers and developers will tell you they are writing use cases; upon closer inspection, we find very few are writing them well. A poorly written use case can actually cost, rather than save, a project time and money. If your looking for a book that will help you and your team harness the benefits of use cases, this one is a good as it gets.
|
|
|
33 of 33 people found the following review helpful:
5.0 out of 5 stars
Indispensable., October 12, 2001
This book is filled with both information and examples on how to build use cases to do what they absolutely have to do -- communicate the requirements for software behavior to all involved stakeholders. While Cockburn is perhaps too quick in de-emphasizing most aspects of visual modeling, he is very correct in stating that the model is a small part of the story of the software to be. Happily, Cockburn does not focus much on elicitation techniques (as many other books of its ilk do); frankly, elicitation is probably mostly unteachable and certainly a manner of personal style. Instead, the author focuses on how to distill elicited information into written material that will actually move the project forward.This book probably works very well for a novice. For the more experienced professional, it provides a wealth of ideas to return to. While there are a few bits (the cloud-kite-box indicator scheme comes to mind) that are probably not bound to make an appearance in the average analyst's repertoire, it is hard to imagine anyone dealing in problem domain engineering that wouldn't find considerable value here. Good books have been written on the subject, including ones by Armour and Miller, Kulak, and Conallen. While they might provide valuable context, the Cockburn manual easily stands on its own.
|
|
|
Most Recent Customer Reviews
|