countdown boutiques-francophones Learn more scflyout Pets All-New Kindle Music Deals Store sports Tools

Customer Reviews

4.6 out of 5 stars
4.6 out of 5 stars
Format: Paperback|Change
Price:$44.57+ Free shipping with Amazon Prime
Your rating(Clear)Rate this item

There was a problem filtering reviews right now. Please try again later.

on August 5, 2001
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......
0Comment| 3 people found this helpful. Was this review helpful to you?YesNoReport abuse
on May 5, 2002
I had been looking at the value of writing use cases for some time, but hadn't done so because I couldn't visualize clearly how they added value or what was the best format, text or symbols. "Writing Effective Use Cases" answered my specific questions, which is why I'm adding a 26th review to the 25 excellent previous ones.
* How do I apply use cases to non-business software?
"Writing Effective Use Cases" includes 40 completed use cases related to a range of activities from Register Arrival of a Box to Apply a (System) Lock. That gave me a better feel for how use cases work than the usual Bank Customer Withdraws Cash or Online Customer Makes Puchase. As far as system software is concerned, Cockburn says:
"Occasionally I hear someone complain that it is hard to describe the requirements for a tape merge operation or a compiler with use cases. I wholeheartedly agree. Those are best described using algebraic or tabular forms."
* Can I go straight from use cases to design?
One of the misconceptions I had was that you could design directly from use cases. Cockburn goes to some trouble to explain that there is no one-to-one mapping between use cases and code, although use cases do make an excellent basis for test cases.
"The design doesn't cluster by use case. Blindly following the use case structure leads to functional decomposition designs (this is really of concern to object-oriented and component design teams.)"
* How do use cases relate to requirements?
The most valuable concept I obtained from "Writing Effective Use Cases" was that the primary value of use cases is to tease out the complete requirements, including how failures should be handled, from the potential customers of the system.
"[The use case] becomes a communication device between the different stakeholders on the project".
Recommended by the author:
Mastering the Requirements Process by Suzanne and James Robertson
0Comment| 2 people found this helpful. Was this review helpful to you?YesNoReport abuse
on June 20, 2004
I had never heard of Use Cases until taking a class in Systems Analysis and Development. So I went to Amazon and did a search for books on Use Cases and saw that this one was rated quite high. I believe I read all the customer reviews. I don't understand how most everyone can give a 5 star rating and one person gives it a 1 star rating.
I must say that this book could make even someone new like me, being new to Use Cases, look good. The Table of Contents makes it easy to find an overall view of Use Case topics and the Index breaks it down in great detail. The book is described by the author as a book that is, "predominately aimed at industry professionals who read and study alone, and is therefore organized as a self-study guide." I like that.
If you are looking for a book for a class, such as the one I took, or just want to look good at work to describe a process, behavioral requirements, or software development, surely this book could help you too.
0Comment| 2 people found this helpful. Was this review helpful to you?YesNoReport abuse
on March 3, 2003
I like this book. It's from "the man" himself. It shows how flexible use cases can be; it demonstrates many different styles and uses for them. Unfortunately I think it doesn't really tie use cases into the larger picture, such as their place as *one step* in a good requirements modeling process, or the fact that you can generate test cases from use cases very easily.
It goes a little far with silly icons of waves and kites and so on, too. Sometimes you get the feeling that he is really in love with his invention and has lost perspective on its place in the grand scheme of things: just one (vital, of course) piece in the puzzle.
That said, by all means buy the book. You will read about use cases in many books, but this one will show you many different ways to write them -- many styles, many ways to make them effective for different needs. Other books place them as one step in "My E-Z-Omatic software process (tm)" and that's too specific to really help you leverage use cases for your unique needs.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on March 3, 2003
The first time i read the book, where's the use case? I'm from UML background type of person. I used to think that use case is a bunch of elipses with line connecting to each other and actors. Since i read this book, hey that wasn't a use case after all. Use cases come in different ways. You can either state them using model / diagram like UML, you can use text description, and many more. They're all covered in this book. It also has many templates which you can choose to describe software/system requirements easily and meaningfully.
This book is the book for requirements analysts, who deals with defining understable requirements both for technical side and also the business side. It also useful for anyone who's interested in project management. I use this book also for my undergraduate thesis.
This book is a must to be added to your library!!
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on June 25, 2003
There are a wide variety of books on Use Case writing and design. But few comes as close as Alistair Cockburn's book in discussing Use Cases from practical experiences.
Developing Use Cases is not a difficult concept to grasp - it is the part which heavily involves the client and is one of the most critical moments in the software development lifecycle. The difficulty lies in developing Use Cases correctly and efficiently within the software development process. Few development teams have mustered this to perfection.
Mr. Cockburn's book gives excellent guidelines in the practical nature of Use Case development which tend to be omitted in most other books. I purchased this book for my development team and we found this a good back-to-basics reference guide for software development.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on May 2, 2003
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.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on April 11, 2002
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.
0Comment|Was this review helpful to you?YesNoReport abuse
on February 8, 2002
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.
0Comment|Was this review helpful to you?YesNoReport abuse
on 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.
0Comment|Was this review helpful to you?YesNoReport abuse