Whatever your programming methodology, if you are involved in the design or reengineering of a project, then use cases are a vital starting point. Cockburn explains how these can serve as an important part of the boundary between the programmers and the non-programmer users and management. Given that the two (or three) groups often have quite different backgrounds, you can see the need for accurate and comprehensive examples.

Hence Cockburn explains how to extract these from users. And to describe the cases in a graphical manner that is meaningful to many. UML is used, especially for the programmers, who are more likely to be familiar with it than the others. But the text also pragmatically does not confine itself to strictly UML. (Unlike books devoted to UML, rather than use cases.) There are plenty of examples given where you can draw general purpose diagrams. Provided, of course, that you can still draw all the key cases.

This book really helped me gain a thorough understanding of Use Cases and how to apply them to capture Functional Requirements. After reading the book I was able to successfully apply these techniques on the job. If you have to buy one book on Use Cases, I recommend this one.

Great Use case book! Whether you read them or write them I consider this book critical. It has many examples and great explanations on when to use what format.

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.

I used the material in this book to define requirements for quality of delivered use cases, and then develop the use cases for a fully functional ecommerce and marketing site. I looked like a star when the job was done- it was one of the few efforts on this project that was recognized by everyone as being competent...

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.

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.

Finally, a book that explains, in plain english, what a use case is and how to write one. I just got a new position at work and since writing use cases is foreign ground for me, I tried to read a few books to get a grasp of how to write a use case. Unfortunately all I kept finding were books on syntax, diagramming or even worse - books to cure insomnia. This book stays open on my desk and has helped me to succeed at my new position.

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.

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.

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!!

Not a book for novice people, but for people with some backgroud on use cases and looking for good practical form of exploitting this technic.
Many examples of real use cases.
It's not a lost of time.

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.

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

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.

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.

I'm a project manager and have given less than 5 stars because the book seems to have been written in a hurry. There are points which perhaps should be highlighted more, eg what steps should be included in Use Cases, or are we concerned only with messages passing between actors or is there more to it? I had to refer back to previous sections a number of times to fully appreciate the real message of Use Cases.

This is a good book, also suitable for beginners. Personally I'd like to see more examples (summary level) for web projects, e-commerce and anything new.

This book has made me understand Use Cases and their purpose, it has a number of useful suggestions on their application and implementation problems/politics. There should be more on how to use/link Use Cases with the 'complete' systems/business requirements documents.

I will use this book as my reference when judging other people's understanding of Use Case concepts.

Arde
MS, PhD
UK

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.

This is an excellent text that covers the various aspects of writing use cases. Cockburn gives a good exposition on the various levels and types of use cases that people use. There is also excellent advice on how to keep from repeating yourself in use case and to keep from cluttering your use cases with conditional logic that is hard to follow. The notion that extensions to use cases include both exceptional and optional behavior simplify use case writing greatly. I have used these techniques and received good responses from my coworkers. Another improvement is splitting the traditional postcondition into minimal and success gaurantees. This idea frees you from the struggle between terminating a use case with a failure and meeting the postcondition. The advice is sound and the examples provide good illustrations for the concepts the author presents. This book is a must read for anyone serious about Writing Effective Use Cases.

The Amazon review does a very good job of summarizing the content. So I'll just clarify that the book is an actor-trigger based view of use cases. While there's certainly room to quarrel about Cockburn's particular flavor (arguments about how to write requirements can approach religious wars), I think that most would agree that he explains his style well.

A good place for beginners to start and I think that even professionals quite experienced in requirements definition will find new ways of thinking about system design.

This book, along with "Use Cases: Requirements in Context", is one of the best ones out there.

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......

I read this book some months ago now, and I still feel that it is the best book on use cases that was evre written. It perfectly removes the illusion that use cases are just diagrams with ellipses. They are stories and the culture of structured story telling is taught in an excelent way by Alistair.

I used this book to teach object oriented analysis to novices and they produced outstanding results. The book helps a lot, when focusing the analysis and aligning the use cases on the right level of abstraction.

Finally! A book that corrects the numerous problems with use cases - or shall I say the mis use of use cases (no pun intended). Here are some common problems that this book will help you to avoid (there are many more, but these spring immediately to mind):

PROBLEM: A horde of analysts descend and produce reams of paper that are little more than stick figures and ellipses. They are, well, of little value because they are devoid of any real information and too often confusing. The other side of this problem is an unmanageable number of these "use cases" are produced with inconsistent detail, or an overwhelming amount of detail crammed into a single use case. RESULT: Developers have no clear idea about how to proceed and much rework is done to get the needed information (or developers do proceed and create something not envisioned).

PROBLEM: Use cases are considered to be the requirements specification. RESULT: Developers build something based solely on behavior, leaving out functions and features that customers want or need, and most likely not suited to requirements.

PROBLEM: [Related to the preceding] Test plans and test cases for systems built upon the shaky foundation of bad use cases cannot be properly developed. RESULT: A hit-or-miss test cycle that is almost certainly destined to miss a large number of defects (functional and operational).

Mr. Cockburn's approach to use cases will allow you to sidestep not only the more common problems associated with improper use cases, but hundreds more than will crop up unless the value and context of use cases in the development or project life cycle is understood. Here are some of the key points in this book that make it so valuable: use cases are but one element of requirements and the hub-and-spoke model given in the book places them into proper context, properly developed use cases are written documents, not diagrams (more about that later), use cases are NOT the requirements document, properly formed use cases DO have a set structure and different levels of precision in accordance with well-defined rules, and the use case creation process needs to be carefully managed because, like software source code, you need to ensure that you're working from the right revision.

Part 1 of this book provides clear guidance for writing, managing and using use cases. Part 2 of the book is especially valuable because it addresses frequently discussed topics. Part 3 is a comprehensive list of reminders and rules that will guide you, and Appendix A is a succinct discussion on use cases in UML. A few other things that set this book apart: there are numerous "short stories" throughout the book. Each of these stories reinforce information and concepts, and also epitomize Mr. Cockburn's recurring advice to keep things short - he shows by example how to cram clear information into brief chunks of writing. He also provides a summary of pass/fail tests for use case fields that will make inspections and walkthroughs easy. One piece of trivia answered a question that had been bothering be for years, "why the emphasis on stick figures and ellipses?" The answer: the CASE tool industry, which sold graphical tools, had a lot of influence on the emphasis placed on graphical depictions vs. text-based use cases. This book will set you on the right course and not one that has evolved from vendor agendas. I personally think this is the best book on use cases and is the only one I recommend to clients and associates.

'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.

I have read lots of books in this subject area and have found this one to be the best. It is a good combination of theoretical and practical. Lots of good, relevant examples. Also, follow this author's other work

If there's one book that can be credited with popularizing use cases, this is it. Alistair Cockburn shares his applied knowledge in `Writing Effective Use Cases' and does so in a very digestible format. This is a handbook, a self-study guide - one full of real-world examples and exercises (with solutions even!) that any analyst or designer can relate to.

Use cases are a form of documenting systems requirements and behavioral design specifications. Written well, they offer benefits to all who participate in the development life cycle. This includes analysts, designers, project managers, developers, testers and even end users. Mr. Cockburn's book takes the reader through the writing process, highlighting both good and bad examples. He makes no claims that any of these examples are perfect. And that is perhaps the greatest element of his book. Commit yourself to read through all the examples. By the time you're finished studying them, you will find your own skills in identifying what makes a `good' or `bad' use case have been sharply honed.

Perhaps the one area this book does not explore in enough detail is the translation of documented use cases into user interface designs. Mr. Cockburn defers to `Software for Use' (another great book) for this. Even so, I would like to have seen some screen shots and comments about the user interfaces that were created from the examples provided. It would have helped tie the whole picture together. Translating use cases to highly usable interfaces is as much an art as it is a science. I believe this element of use-case driven development is best communicated in a live, face-to-face format. That's why organizations like Classic Systems offer workshops on this topic. As an instructor who teaches use case-driven development, I have found `Writing Effective Use Cases' to be invaluable reference tool. Having tried out a number of Mr. Cockburn's ideas in the classroom, student feedback and learning results have shown me just how potent a learning tool this book can be.

Many designers and developers will tell you they are writing use cases; upon closer inspection, we find very few are writing them well. A poorly written use case can actually cost, rather than save, a project time and money. If your looking for a book that will help you and your team harness the benefits of use cases, this one is a good as it gets.

It's about time somebody wrote a good book about use cases. Cockburn provides excellent advice based on years of experience in the trenches. We're implementing the RUP in my company and this book was a useful resource for our analysts.

My background is not software engineering - it's service delivery and process development. I got this book on a strong recommendation from my mentor because one of my techniques, information mapping, has some gaps when it comes to portraying processes. I had heard of use cases before getting the book, but paid little attention to them.

Mr. Cockburn gives one of the most sensible, logical approaches to capturing, validating and modeling requirements I have ever come across. My initial concern that this book was focused on software requirements was assuaged by the numerous case studies that address processes and policies. This is the heart of what I do, and the book gave complete coverage of it. Of course software engineering-specific material is also addressed since this discipline has the biggest audience.

The sections from which I got the most knowledge are: setting scope for the use cases and the way to use a hierarchy of use cases to depict increasing levels of detail, business process modeling, and the tips for writing use cases. This material pointed me in the right direction for resolving some of the shortcomings inherent in information mapping, and also gave me some fresh ideas on how to effectively and clearly develop processes that are traceable to requirements.

One of the things I liked most about the book is its fast pace and reasonable page count. There is no fluff, and at approximately 300 pages it is an easy read for someone on a busy schedule.

My personal opinion is that this book should be promoted to a much wider audience than software engineering - the approach and techniques will certainly serve the software engineering community well, but are also practices that business analysts, process engineers and others in IT can effectively employ. This one goes in that special section of by library that is reserved for books to which I frequently refer.

I had been writing use cases for some time when I stumbled upon the first draft of this book, which Mr. Cockburn very graciously made publicly available on his website (don't look for it now, the drafts have been removed). It became not only my personal bible for writing effective use cases; it became the foundation for every group of engineers, designers, analysts, and even suits I taught to read and write use cases. It conveyed the essence and intention of use cases better than I or any other book could.

I must state my personal preference for the first draft, which was more strongly worded in some areas and generated more emotional emphasis on some topics where engineers can be very wrongheaded. However, all my subsequent reading groups tended to prefer the third draft, so any reservations I may have I forego and gratefully give this book five stars. It's required reading.

This book was very informative. It really teaches you great techniques for writing Use Cases. It is the best book I've found for writing Use Cases but introduces a couple of concepts that it falls short in conveying understanding. There was never any explanation referring to Extensions meaning Alternative Flow Of Events. This is obvious, so I presumed it to be true. I'm sure many of you know, but nothing explained it, and every example said: None. Even the example that states that an Extension Point is used in the next Use Case, still says: None.

There are grammatical mistakes throughout the book (Not a big deal).

I felt, that if you read this and stay within the realm of the authors suggestions, and disregard the alternative methods, you should be alright. I would suggest to the author improving the explanations of a White Box Use case, instead of supplementing content with examples. I know what White Box is in Design, but It would be wrong of me to presume the same behavior in a Use Case.

The icons are a very handy reminder, and even with all the the perceived problems with the book, I think it's the best one available that I've seen. ESPECIALLY when compared to the Unified Process books.

I held off on reviewing this book until I had not only read it but also "worked with it" awhile. It was an obvious four-star title from the get go, but did it deserve five stars? I reserve five stars for "classics"--those volumes that one keeps going back to, those that keep yielding more knowledge the more times you read them. Is this book a classic? Yup--it definitely deserves five stars. I agree with Craig Larman--don't judge the book by the early chapters--they're important, but it's the later chapters that are priceless. I also agree with Dan Rawsthorne--this is the only book about use cases that a professional developer needs on his/her bookshelf.

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.

This book takes the task of writing use cases and provides a set of processes and templates that you can use yourself when you need to define requirements for a software project. The author provides many tips and suggestions that you can apply as well as some real world examples from actual projects. There are different approaches talked about which you can choose from, depending on how detailed you can afford to make your use cases. I immediately created a word template based on some of the examples presented in the book...very useful for creating your own process to use when writing use cases. There's also a lot of very useful tips presented throughout the text (along with examples of poor use cases and how to correct them).

It's an easy read and provides sections that summarize the key points so that you can use it as a quick reference for future work. I recommend it to anyone working on requirements or design for a project.

This book takes the task of writing use cases and provides a set of processes and templates that you can use yourself when you need to define requirements for a software project. The author provides many tips and suggestions that you can apply as well as some real world examples from actual projects. There are different approaches talked about which you can choose from, depending on how detailed you can afford to make your use cases. I immediately created a word template based on some of the examples presented in the book...very useful for creating your own process to use when writing use cases. There's also a lot of very useful tips presented throughout the text (along with examples of poor use cases and how to correct them).

It's an easy read and provides sections that summarize the key points so that you can use it as a quick reference for future work. I recommend it to anyone working on requirements or design for a project.