Writing Effective Use Cases

Having tried 'Use Cases: Requirements in Context' and 'Managing Software Requirements: A Use Case Approach' I can tell you this is the book to really understand what's the whole point of Use Cases.Whenever I am introduced to a modeling tool (UML would be another example for me) I always end up wondering what to put and what to leave out of the model I am building for the problem at hand. This book does not give you a specific answer (who would want a solution that would only apply to only a limited set of problems? I did not, at least for the project I used this book for), it gives you the very essence of the criteria you should apply to include something or not.By comparing this book to the other ones, this is superior because it does not provide a specific framework with esoteric descriptions about how Use Cases evolve throughout the project life cycle. It describes the purpose of writing use cases: describing a goal of some importance to an actor.So many times I have read these 'Use Cases' that describe a system in terms of people pushing buttons, changing values in some UI and end up describing the system in terms of CRUD operations not descriptive by any means. If, after all, most 'Enterprise Systems' built are just fancy and costly web-versions of SELECT, INSERT, DELETE and UPDATE statements executed against a database, how informative can be use cases that only say a system INSERTS/UPDATES/DELETES/QUERIES data in a database? By describing a user goal, all database operations (and many other interactions with any back-end systems) start making sense. I have found that we human beings are so good at 'filling out the blanks' that some of these operations might even sound obvious at times.This book will guide you during the writing of your use cases, keep them at consistent levels of abstraction and, more important, at all times highlight the ultimate goal your user wants to achieve by executing a use case.If you really want to complement the topics in this book, consider the perfect companion 'Patterns for Effective Use Cases'.Cheers!Ytsejammer

I love this book. I needed to get a good book to be able to review the best use cases.

It's year 2017, software development went through major transformations, waterfall is (mostly) dead, RUP is dead, heavy UML is dead. Most of the companies now use some sort of agile-inspired technique to manage their software deliveries. Why on earth would anyone want to read a 17 year old book on use cases today? Well let me tell you something. It's good and it has a lot of value, that's why.I've had a chance to work with use cases and specification of variable quality in my career. Some were much better than the other, but it really varied company-to-company. One common denominator (and sadly an annoying one) was inconsistency regarding naming, conventions, level of detail ... I can't stress enough how much development time I've wasted due to unclear definitions, missing specifications, and general confusion. The author of this book does a great job explaining how use cases fill in this missing piece by suggesting use case format and listing many, many real world examples.You will read about important aspects of good use cases such as scope definition, which things are to be used in the use case, which things are to be designed as a result of the use case, and the importance of listing preconditions and postconditions. All of this is was demonstrated with great examples. There were things I didn't really like about the book and they seemed like an amusingly big hammer - especially all the little icons and colours trying to introduce some sort of visual framework to it. I'd rather not see any of that noise, but that's a personal preference.By now use cases have a bit of bad reputation due to heavy-weight methodologies that were encouraged in the past. RUP. Waterfall. BPM. You name it. The author suggests that use cases don't need to be "fully dressed" - we can use different kinds of formal language for use cases. A banking analyst is most likely going to be required to "dress them up", while a startup product owner may come up with something much less formal and relaxed.With hindsight we can ask ourselves a question. Is this still worth it? Do we still want use cases in young dynamic and fast changing environments like new tech startups? I do think that user stories or BDD are a better fit here. On the other hand we can't forget that there still are huge software companies running important aspects of our daily lives (banks, telco, transport etc.). These companies try to change as well, but it often results in some form of poorly implemented and conceptually broken agilefall process. While I don't really want to advocate for full-blown use cases, it made me stop and think plenty of times, and I am absolutely convinced that some businesses would massively profit from quality use cases.

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.

Very helpful. Cockburn is a good teacher. Concepts are presented in multiple ways to give you multiple chances to get it. As tech books go, this one is pretty "squishy." Which is exactly right. The fact that it's 20 years old isn't a problem. Cockburn is teaching a method for creating coherence and completeness in designing a system. Sure, he's focused on computer systems, but I'm starting to think about how this methodology applies to a business plan.The most important idea in the book, for me, is about "levels." How to know when you're getting too airy-fairy and when you're getting bogged down in the details and when you're getting it just right. I had a project where the problem was I was all over the place on levels, and this straightened me right out.

excellent book

Livre très riche en enseignements et plein de bon conseils.Je conseille chaque architecte informatique à l'avoir et mettre en pratique les "recettes" de ce livre.

The book provides a very effective methodology to collect and describe functional requirements.The presentation is very clear and reach of examples from real projects. It is possible to learn use cases since reading the first sections. The rest of the book is dedicated to in-depth analysis of some topics.

This is a top-notch book on Use Cases. I got it because I had to write Use Cases for a programming and configuration tool for a safety controller used with electric motor drives in industrial automation systems. This is a SIL3 safety-critical application.I disagree entirely with the two-star-awarding reviewer who calls Cockburn "naive". Indeed the great virtue of Cockburn's approach to Use Cases is that he keeps them simple. This is a major advantage in high-integrity systems where simplicity is the friend of reliability and safety. I also applaud Cockburn's evident disdain for using UML graphical notations for UCs. OO-methods are generally shunned in safety-critical systems as they are regarded as too imprecise (Indeed hardened practitioners in critical systems engineering often regard the use of UML/OO as a sign of limited competence.)Cockburn is IMO absolutely right in saying that UCs are an essentially textual form. Sooner or later the developers of MIS-type systems will realise that those of us who have been doing hard software engineering (in this reviewer's case for over 40 years) actually have a far clearer idea of the kinds of specification formalisms that work when things absolutely have to be right. And when the OO fad has finally died, I reckon Cockburn's book will still be in print because it does not shackle itself to the UML/OO bandwagon.IMO, this book is exceptionally well-written and down-to-earth. It is, I think, a solid and welcome contribution to the literature on specification.

after years in practice i really liked the thought process of the book which helped me think in an organised manner and express clearly the requirements of the system to be developed, even if I was the end developer