( 5 reviews )
-
Posted: Feb 2 2007
This was the first book that really helped me to write use cases as part of my job and I really liked it until I found Writing Effective Use Cases by Alistair Cockburn. I took a class from Alistair and found certain concepts in his book and class that Applying Use Cases doesn't have to be extremely useful (you'll have to look at the book since this is a review of Applying Use Cases). Although this was a very good book for its time, I no longer even open it.
-
Posted: Oct 5 2006
Schneider and Winters present a clear, thorough introduction to "use cases," a well-established part of software requirements management. In logical structure, though not always in time order, use cases take the first step towards detailed technical requirements and design. They answer the question, just what is this thing supposed to do? The answer has narrative form, describing the sequence of events that pass between the system's internals and the outside world. It's well worth noting that a use case is written in informal, non-technical language, the kind that an end user can really understand and comment on. Anyone who's ever worked on something for a year only to hear "That's not what I wanted" will understand just how crucial early feedback can be. The book starts with summaries of the development process and of how use cases fit into that process. Next, the basics of a use case are introduced: who the outside people and systems are that interact with the new system must, and what needs and expectations are for each of those outsiders. Irrespective of internal implementation, they define the system as it's seem from the ouside. Next, the authors offer "script-writing" suggestions: first address the common cases, then go into the details of unusual cases and failures. The authors also show how OO design concepts can be used to treat special cases as elaborations of the basic system behaviors. Next, they relate narrative use cases to diagrammatic UML notations. They also offer a brief (too brief) discussion of traceability - that critical but insubstantial thread that binds together the strands of knowledge in the requirements, design, implementation, test cases, and usage documentation. After showing the goals of the use cases, discussion returns to the descriptive techniques that help to meet those goals. That includes confirmation that the use cases are correct and complete, or complete enough for a given phase of the software life cycle. The rest of the book deals more with managing that life cycle, emphasizing the place of use cases at each step. Although helpful, this book suffers one weakness that seems inherent in software process books: the vast gap between the static generality of the printed page and the dynamic complexity of any one application. I'm sure that a novice will get some value from this text. I'm equally sure that use cases' full value can only be learned by seeing an experienced practitioner adapting them to a specific project's constraints, history, goals, and team culture. Still, this gives the interested developer or project manager plenty to get started with. I recommend it. //wiredweird
-
Posted: Aug 27 2004
I have been a technology developer/manager for 20 years. In most organizations, there is little understanding of the value of structured requirements (there may be an acceptance philosophically, but in practice it done in pockets at best). This book not only helps communicate that value, it provides an excellent explanation of the Use Case Points estimation method. Managers who get their business partners to adhere to these practices and get their project managers to estimate in this fashion will begin to achieve far more predictable results.
