| Managing the Requirements of Requirement Management |
| How to Best Apply Use Cases to Your Project |
| October 2, 2002 |
| Abstract |
| Many organizations are adopting use cases as a means to document requirements for their application development projects. Use cases can be an effective means for adopting a consistent and repeatable process for capturing requirements which can increase the productivity and quality of your software development project. However, it is important to understand that use cases themselves can have a wide variety of formats and their effectiveness is directly influenced by the people that use them and the project they are used on. This article describes some techniques for managing use cases in a way that might help avoid some of the pitfalls that I have seen on many projects. |
| What's in a Use Case? |
| Writing effective uses cases is as much an art as a science and for every good business analyst or 'use case specifier' you will probably find someone with their own nuances for developing a use case. From an enterprise or project management perspective, there are probably elements of good use case design you want to ensure are followed but the most important component of this is to develop a reference or style-guide for your use case structures. As intuitive as this might seem, there are plenty of large organizations which have standardized on use cases but do not have examples of formats or contents for development groups to reference. |
| The benefits of adopting these standards for use case documentation is that it allows for more consistent and repeatable requirements gathering techniques. Over time business users and technology groups will have a common language by which to express requirements which will be reflected in faster development iterations and, ideally, more accurate requirements resulting in less rework and fewer defects. Eventually, a well defined mechanism for documenting requirements through use cases can allow your company to adopt a role based organizational structure, freeing it to focus on its core processes as opposed to under/over utilizing resources within a functional organization structure (but this might be a better explored in a future article). |
| Creating a use case standard, however, requires some flexibility if it is to scale to the variety of projects where they are to be used. Here are some considerations if you choose to embark down the path: |
| Common Language: Don't assume that everyone is familiar with the literature on use cases. Provide a high level overview to act as a reference with definitions of common terms and overall structure. Also describe the vision of how use cases should interact with other documents like test cases so the age old debates on 'abstraction' between architects and testers can be nipped in the bud. |
| Boiling the Ocean: If your job is to encourage the application of use cases across your organization then realize that developing good use cases takes time and experience. Don't expect all software development projects to readily adopt use cases or to even do a good (or consistent) job. Take the time to educate and learn about how use cases are being used. Even getting consistent use cases within a project can take a fair amount of energy. Don't try to boil the ocean but apply the same principles of incremental improvement that are followed in an iterative software development project. |
| To a Hammer Everything is a Nail: One key learning that I have discovered is that use cases don't solve every requirement issue for a project. Use cases need to be complemented by supporting artifacts where and when it makes sense. Typically for the projects that I manage, use cases are complemented by screens, object models, data models and supplementary specifications which include activity, sequence and other UML diagrams where appropriate (there's no point creating these unless they help convey the behavior of the system to your developers). Trying to load too much into your use cases will just make them unwieldy to manage and hard for business users and developers to understand the system's behavior. |
| The View From the Top: The need to tackle the level of abstraction expected in use cases should be reviewed and discussed up front. There are as many opinions on this subject as there are people offering them. Unnecessary detail in use cases makes them hard to maintain and difficult for users to understand. Too little detail and you run the risk of a disconnect between the developers and testing groups who rely on use cases to define system behavior. The key is to accept that less can be more and that ultimately, everything is about people. In other words, there is no substitute for good people and regardless of how fine grained a use case might be it won't remove the need for strong individual talent in your business, development, architecture and testing areas (to name only a few). Ensuring that your staff are well trained and experienced will ensure that use cases and your entire software development project can deliver on time. |
| Using the Right Tool |
| As if the process of agreeing to use cases and defining their construction wasn't difficult enough, the other part of the equation is to determine how to document them. Under the best circumstances I would personally encourage the use of a database driven requirements management tool. Although these tools are not universally praised (in fact the mere suggestion is enough to drive shivers down the backs of many developers and architects), they do get you out of the challenges of updating multiple, independent Word or Excel documents. A database driven requirements management tool is much easier to not only update but allows greater opportunities to manage traceability and versioning within your software development lifecycle. However, if you are new to use cases and are simply trying your hand at them before investing in a tool, here are some suggestions I might make: |
| One Use Case One Document: Keeping each use case as its own document will make it much easier for your project to track and update use cases. Embedding all of your use cases in one large word processing document might make it easier to print but overtime the guilt of destroying countless trees each time a small change is made to a Post Condition will overwhelm you. It is easier to to review changes made to use cases if they are in separate documents too, there isn't a need to wade through a 90 page document to find a single use case instance. Develop a template that can be used for your use cases before you start your project, retro-fitting 30 use cases to a new format is tedious and entirely unproductive. Use descriptive names for your use case documents to make them easier to find and sort within a directory, I use Project Name - Use Case Number - Use Case Title. Sometimes adding a version number is useful too although this can be difficult to maintain. Using one document per use case also makes it easier for more than one person to work on updating a use case. |
| Consistency is King: The benefits from use cases come from their consistency, this means completing all of their fields regardless of whether they have any information. If this doesn't happen it can be difficult to determine if there is no Pre-Condition for a use case or if it was forgotten. This consistency should also extend to page numbers and dates on each of the pages of your use cases. It might seem like a small thing but I have seen much confusion in large use case review sessions where people have not been able to find the page number or use case that they are all reviewing. |
| In Conclusion |
| There are quite a few tips and techniques to following use cases that I can (and probably will) continue to add to this article. However, these are some general observations which might be assistance to those managing large scale projects with multiple use cases or enterprise business analysts working on establishing standards for use case adoption within their organization. |
| Good Reading Material |
| There are a number of excellent books written on the subject of use cases and their documentation. Here is a subset that I have found useful which provide more detailed analysis of the subject: |
| Writing Effective Use Cases by Alistair Cockburn - a practical and informative approach to what works and what doesn't work in documenting use cases. |
| The Rational Unified Process: An Introduction by Philippe Krutchen - a good primer on how use cases can be applied within the entire software development framework |
| Advanced Use Case Modeling: Software Systems by Frank Amour and Granville Miller - a well researched and thoughtful approach to use case modeling which contains good examples of blending other artifacts (most significantly user interface design and test cases). |
| Use Cases: Requirements in Context by Daryl Kulak et al. - An excellent book that provides very practical examples of good (and bad) use case design. |
| About the Author |
| Bryan Campbell (www.bryancampbell.com) is an IT consultant with 20 years of IT experience and more than a decade in software development. As the Vice-President of Delivery Services for Valtech Technologies Inc. Mr. Campbell was responsible for directing more than 150 consultants applying agile and lean software development techniques. Previous to that Mr. Campbell has managed a series of large scale IT projects including software development projects using iterative development techniques and worked in a variety of industries including Telecommunications, Utilities and Insurance. He is the author of several articles on software development and has presented at several conferences. |
| Publication in part or in whole, without the authors' written permission is prohibited |
