Customer Reviews

Writing Effective Use Cases

5 star:		(27)
4 star:		(7)
3 star:		(0)
2 star:		(1)
1 star:		(1)

 

 

As a novice to OO (and recent attendee of Sun's OO Analysis and Design course) I sat at my desk ready to write the Use Cases for our new system.

Actually I lie, I started to draw them using the UML.

Sun failed to convey that Use Cases are NOT exclusive to OO and they are primarily TEXT. After a few Use Case diagrams and some supporting "flow of events" I got lost.

This book is great! It's clear, simple, precise, and a great guide to beginning to write Use Cases. Good examples (of almost every possibility *grin*) and a good step by step approach will help anyone sitting at their desk in the state of "where to from here".

Add it to your library.

Requirements gathering/specification process is one of the most critical activities in any proyect endeavour. It is too easy to forget important things while you waste your time on not so important functionality or other attributes of the product or service being built.

Requirements gathering it is no more but not least than a bidirectional communication channel between developers and the customer, the users, or other stakeholders. Successful communication of your understanding on what are the needs, requires to use techniques easy mastered by both communicating parties. Use cases are one of such techniques, centered around the concept that users interact with the system in order to fulfill some concrete objectives.

Alistair Cockburn's book teach you what a use case really is or has to be(beyond any graphical notation used), and how to write them so that developers and users share a common understanding of the functionality required. In my development experience I've tried some different techniques for gathering and specifying requirements and I've found that the graphical notation of use cases (like UML) is difficult to grasp on the user side without any training (specially if your users are folks used to structured analysis notations). I've found also that the approach provided by Mr. Cockburn eases the communication among the different stakeholders so the number of misunderstandings be reduced to a minimum.

If you are involved in specifying a system, a process or almost whatever thing with an inherent functionality you must try this methodology and, undoubtly buy this book.

Suppose you have a team of new people, quite technical, but none practiced in developing software requirements. You need something to formalize the process. Somewhat bewildered by all of the UML and other modeling methods that are available, you decide that use cases are easy to understand, the methodology quite easily learned and particularly applicable to the workflow application that you have to design. You've got the Jacobson early books but need something that you can hand out and say, "This is our standard for use cases. We start next week on getting our software requirements done formally."

That's what I did. Bought one copy for myself. Got through the 270 well-written pages quickly and quickly ordered a copy for the other three members of the team.

The use-case methodology outlined is text-based with only the simplest graphics. If you like the more graphical methodology for use cases found in UML standard, you won't adopt this book as your company standard but will still gain valuable insight in use case analysis. At least pass it on to the business guys on the team so they have some clue on how to think about requirements.

I'm a project manager and have given less than 5 stars because the book seems to have been written in a hurry. There are points which perhaps should be highlighted more, eg what steps should be included in Use Cases, or are we concerned only with messages passing between actors or is there more to it? I had to refer back to previous sections a number of times to fully appreciate the real message of Use Cases.

This is a good book, also suitable for beginners. Personally I'd like to see more examples (summary level) for web projects, e-commerce and anything new.

This book has made me understand Use Cases and their purpose, it has a number of useful suggestions on their application and implementation problems/politics. There should be more on how to use/link Use Cases with the 'complete' systems/business requirements documents.

I will use this book as my reference when judging other people's understanding of Use Case concepts.

Arde
MS, PhD
UK

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.

This is an excellent text that covers the various aspects of writing use cases. Cockburn gives a good exposition on the various levels and types of use cases that people use. There is also excellent advice on how to keep from repeating yourself in use case and to keep from cluttering your use cases with conditional logic that is hard to follow. The notion that extensions to use cases include both exceptional and optional behavior simplify use case writing greatly. I have used these techniques and received good responses from my coworkers. Another improvement is splitting the traditional postcondition into minimal and success gaurantees. This idea frees you from the struggle between terminating a use case with a failure and meeting the postcondition. The advice is sound and the examples provide good illustrations for the concepts the author presents. This book is a must read for anyone serious about Writing Effective Use Cases.

The Amazon review does a very good job of summarizing the content. So I'll just clarify that the book is an actor-trigger based view of use cases. While there's certainly room to quarrel about Cockburn's particular flavor (arguments about how to write requirements can approach religious wars), I think that most would agree that he explains his style well.

A good place for beginners to start and I think that even professionals quite experienced in requirements definition will find new ways of thinking about system design.

This book, along with "Use Cases: Requirements in Context", is one of the best ones out there.

I read this book some months ago now, and I still feel that it is the best book on use cases that was evre written. It perfectly removes the illusion that use cases are just diagrams with ellipses. They are stories and the culture of structured story telling is taught in an excelent way by Alistair.

I used this book to teach object oriented analysis to novices and they produced outstanding results. The book helps a lot, when focusing the analysis and aligning the use cases on the right level of abstraction.

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.