Customer Reviews

Use Cases: Requirements in Context (2nd Edition)

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

 

 

Very interesting stuff and fluid understanding..Could have more topics though

Being in the middle of a messy project this book came to me a little late. I consider is one of the best introductions to
the understanding of what a use case is and WHAT things you should put in it. Everbody has suffered for long endless meetings discussing which is the scope of the use cases and how it should be used, I strongly recomend to read this book before start arguing.
I give it four starts because it lacks in some way of paths that can work as guidelines trough the process, although is not the focus of this book, it would very useful to include a couple of pages reviewing this subject.

I saw this book in a stall, while searching for some other book. I had a glance at it and really liked the simplicity and practical approach. Once I bought it and read it completely, I felt happy to find such a great book on Requirements Study. To read and understand this book you need not have a lot of experience or a Requirements Specialist. I feel anyone from Programmer to Project Manager will find this book very useful. The authors teach you in a very practical manner, how to come out with good Use Cases. I enjoyed reading this book, applied the concept in my projects while doing Requirements Study and now can happily recommend this book to others.

Three cheers to the authors for a great work.

Note: I found Craig Larmen, while talking about Use Cases in his best selling book on UML and Patterns talks highly about this book.

Programmers naturally hate use cases. They seem boring, and having seen hundreds of them (written by others and handed to me) over the years, I had lost hope that this practice would ever be of any benefit. I had grown tired of constantly reading varying levels of abstraction and 'use-case-itis'. All this, despite the fact that Jacobson's original work and the UDP incorporation of use cases as central to that process was clearly a better way to go than wading through hundreds, sometimes thousands of pages of 'shall' statements that accompany most projects (and too often, lead to their failure).

Then I read this book. I now use it regularly in every requirements-related class I teach, and I tell every programmer I meet to buy this book. Imagine a use case book that programmers can actually get excited about! This book blazes new territory and its practical insights and humor make it a fun read, as well.

Here are the great highlights:
1. Properly scoping and relating use cases
2. Introducing Business Rules as 'first-class citizens"
3. Applying UDP iterations to the use case development process.

These last two items make the book stand out. Understanding the importance of business rules as enterprise-wide invariants that span use cases is ground-breaking. The four UDP iterations are ingenious because they can help to enforce the proper level of abstraction, which is a big problem area for use cases. Try it, you'll like it!

In addition, the book is loaded with great practical advice and examples of good (and bad!) use case text. And finally, the authors present the most compelling arguments I've ever heard for ditching traditional requirements-gathering methods (which have clearly FAILED), because use cases are, after all, requirements IN CONTEXT (like the title says). If every use case writer read this book and followed it's advice, the software crisis would be dealt a serious blow.

Bottom line : If you write use cases (or worse, are forced to implement bad use cases at gunpoint), get this book!

This book, along with Alistair Cockburn's "Writing Effective Use Cases" is one of the best that I have read. It is very practical and very "how"-oriented.

This book is very concise and super helpful with it's concrete examples. This is the best book on documenting requirements that I have seen and I have been lokking for quite some time. Sure wish though there was a CD that had Word templates! Seems silly for me to have to create all these from scratch when they are right there in the book. Darn.

The best thing about this book is that the authors are not meekly presenting just a stream of bland bromides that echo the sentiments of a million other talking heads. On the contrary, they are quite opinionated and their opinions often illuminate some of the most important issues in the whole raging process debate. Specifically, their discussion of the uselessness of requirements that just appear as a gigantic list of commandments is truly on target. (The writers espouse attaching requirements to the appropriate [and specific] use case.) They also do a good job of dealing with the issue of scope and developing use cases for specific uses. Everyone who's read about use cases has confronted the issue of how to 'refine' them but this book does a better job than most at underlining the importance of scope in the iterative process.

The downsides of this book (IMHO) are:

1. The diagrams are all very simplistic. There really is no point in using a pictographic medium if there's nothing there.

2. The models that are talked about are also too simplistic (but I say that about every book).

3. There is a little bit of smugness about how *their* way is the sane and obvious answer to all that ails developers.

Still, I think this is one of the best Use Case books out there.

This book does a decent job of explaining the use of Use Cases in defining/documenting requirements. My only complaint is that the authors skip around in the text. Other than that the book was well thought out.

This book is a "not so bad" book on Use Cases. It shows clearly how the Use Cases are completed iteratively, with clearly named completion levels. The book also tackle the problem of detailed rules attached to Uses Cases as well as risk list mitigation. On the bad side, I don't like the Use Cases decomposition the authors adopt and, even if a case study is a good idea, two case studies which spend the half of the book seems too much. Another thing about the iterative approach : to oulines the difference between 2 iterations, it should be interesting to use 2 colors or at least bold characters.

This is a very practical, example-oriented book. It stands on its own, but is even better as a companion to some of the AWT titles. Highly recommended.