Rating: 
Summary: This cuts through all the .. different perspectives.
Review: 'A Use Case is a prose essay' -- great summary, from a great book.I've been meaning to read this book again. I learned how to write use cases while reading this book. The value comes through right there. This book was not as easy to read as I would have liked, but it takes a difficult topic and provides enough usable material to master it. I'm not certain an easy "for dummies" style book is possible, or appropriate. Minus half a star. The problem with use cases, is that it's an extremely general term that means a lot of specific things to different people. Even with this book, I had to have my co-workers review my format, to establish what conventions to use. What I found extremely useful, given the complexity of the topic, is that the author presented a number of flexable approaches to developing a use case, stating that the environment and subject matter would determine what details needs to be preserved. The author uses a confusing visual notation in addition to section headers, which I think would strengthen the book by it's absence. I'm not familar with UML, and some degree of UML knowledge is tacitly expected. That was easy to look past. I gave this book four stars, because I think a better book on Use Cases is possible. However, from what I have seen, this is the best one out there.
Rating: 
Summary: A pragmatic guide to writing use cases
Review: A huge thumbs up to Alistair for writing this book. He has a very readable writing style, and gives sound advice on writing use cases. After reading his book I have been able to see why some of my previous use cases were harder to read than others. His book covers the topic well, covering his approach, tools and techniques, writing style and guidelines. The text is supplemented with copious examples. Previously I had read books like 'Applying Use Cases : A Practical Guide' but found them hard to relate to my real-world challenges. I just wish Cockburn's book had been available when I started writing use case. I think this is an essential read for both the beginner and the use case veteran.
Rating:
Summary: A book of substance, written for the busy
Review: About a year ago I came across the manuscript of Alistair's book and, as they say, THE BULB WENT ON in my head.
My use cases were a mambo-jambo of business rules and wordy system descriptions at mixed levels.
The book introduced me to the orderly science of "doing" use cases.
In a VERY SIMPLE fashion it teaches to sort out the cases by levels, to choose appropriate format for each level, and to place non-functional reqs where they belong to.
The author deserves a praise for "usability", because he structured a book with a busy person in mind (get to the "meat" fast).
It is safe to say, that this book and works by Constintine & Lockwood are the best practical guidance available in SE literature today, if you'are writing reqs for highly interactive business systems.
Rating:
Summary: An excellent use case book
Review: Alistair is _the_ master of use cases, with many years of consulting, teaching, and careful thought. I suspect no one knows more about what use cases are, or should be, than the author. The advice in this book shows the polish of much practice and feedback, with insights and tips from the small-scale notational to large-scale process context. I recommend buying this book and making it the cornerstone bible of our use case practice. His emphasis that use case work is about writing text and stories, and fulfilling goals, not diagramming or relating things, is an important message. Don't be put off the entire book by his use of icons for different use case levels, or the early emphasis on levels and use case taxonomy. The icons are optional and minor. And although the discussion of levels and goals may at first seem a diversion, those who have consulted with use cases for some time are painfully aware that many projects get tied up in a knot during use case modeling by mixing up use cases from different levels, or by writing them at too low a level. The subject is more practical than may first appear.
Rating:
Summary: Excellent
Review: An excellent User Guide on how to write use cases. Do's and Dont's, advice, hints, ... We passed it around our project and people got on board right away. Explanations are clear and rely on real project experiences.
Rating:
Summary: Buy this Book!
Review: 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.
Rating:
Summary: Buy this Book!
Review: 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.
Rating: 
Summary: Arms stolen to Agriculture...
Review: As we say in italian of someone who is pretending to be
skilled in some area, or just plain doing something completely useless. This book is a disenheartening 250 pages of fluff...
Could be reduced to 50 pages max and be marginally useful for someone who needs to work with use cases and has no experience with them. The only thing methologist are good at is finding methods to make bucks without doing anything even remotely beautiful or
useful.
Rating: 
Summary: Cockburn's approach naive
Review: Being a consultant requirements/acceptance test/systems test analyst working on large business systems using OOA techniques, I was hoping that this would be a significant improvement over e.g. Jacobson and Schneider & Winters. Cockburn's approach to business use-cases is centred on an actor wanting to achieve a goal rather than a business event/response focus. Although business events are stated as triggers to a use-case, I am not happy with this, as a business event occurrence needs to cause the instantiation of an actor to handle the event. If BPR is part of the programme, the actor may not yet be known, as the determination of actors may be deferred until design, which is possible with the business event/response paradigm. Cockburn partitions use case scenarios into those which 'succeed', i.e. the actor achieves the goal, and those that 'fail', i.e. the goal is not achieved due to violation of a rule. I do not agree with this view; a use case 'fails' if it puts the business into an undefined state, which must never happen. The content of the example use cases made no explicit mention of business objects, i.e. the static data-centric viewpoint was completely missing. As a result, I found the use cases to be too imprecise and largely untestable. In order to be precise and unambiguous, business use cases must be written in terms of a static business object model, supplemented with statecharts for business objects with complex lifecycles. On page 164 Cockburn states that ' business rules do not fit well into the use case narrative'. I totally disagree : business use cases are the dynamic process view, and this is exactly where business rules must be, in their context of application. Business rules are often candidate variation points in a design, but for the designer to make intelligent decisions about them, their context of application to transactions must be clearly defined. Cockburn's recommended format for use cases is numbered paragraphs detailing the main 'success' scenario, with extensions for other scenarios. He does not recommend if..then..else statements, as he believes this leads to the document being difficult to read. If ... statements have basically been transmuted into extension paragraphs, but this will quickly degenerate into the 'Fragmentary' type of process specification, which is hard work for designers and test analysts. The section on stakeholders in use cases is focussed on business interests, whereas the focus should be on designers and test analysts as being the primary audience. As a result, the sections on QA and testing are woefully inadequate. Much is made of 'readability'; in my experience, the reason requirements documents do not get read is because they do not directly tell the the reader what he/she wants to know. Cockburn's method is more compact than the 'Wuthering Heights' and 'Fragmentary styles', but ultimately still falls into this trap. Overall, I found this approach naïve, there being no evidence of any real analysis or modelling. This is reinforced by the reading list being very short for a technical book and not containing a single 'serious' requirements engineering reference. I also believe Cockburn's approach is dangerous, in that it could lead to a totally false sense of security in the hands of inexperienced practitioners with a low level of knowledge of real requirements engineering. Although the format is an improvement over the 'Wuthering Heights' and 'Fragmentary' styles of functional requirements specification, the example use cases are at 'Concept of Operations' level, and are not sufficient for process requirements specification. If I were an acceptance test analyst given this content from which to identify test cases, I would know that I would have a lot of work to do; and yes, in my opinion there is a better way......
Rating:
Summary: The Good Books are Always Dog-earred
Review: Certainly my copy of "Writing Effective Use Cases" is beginning to show signs of being pulled off the shelf numerous times during every project I work on. Cockburn's text-based approach to use cases is very well thought-out, very practical, and non-dogmatic. We use his detail level icons (cloud, kit, sea-level, fish, clam) as a sort of verbal short-hand to keep everybody focused on the correct level of detail even when we aren't actively writing use cases! Remember that text use cases are just as effective for process evaluation and re-design as they are for software development projects, and that use case development almost always goes better in a workshop environment.
| 
