I've been asked to help capture the requirements for our project, and I'm thinking about using use cases. It seems like the best strategy for us, but are there times when use cases aren't the best way to capture requirements?
are a wonderfully practical way to present high-level contextual information. They're also one of the best ways to document the requirements when you want to capture functionality related to the details about user/system interactions. They're easy to create and use, they're versatile, and they blend visual and narrative elements in a way that most audiences will enjoy and understand. But use cases aren't necessarily the be-all end-all of requirements capture.
A use case may not be the best choice for managing large volumes of data requirements, e.g., for a data conversion, database, or data model change project. They also aren't particularly useful for reporting requirements. In reporting, the user/system interaction is simple: the user runs a report, and the system generates it. That's nowhere near the level of detail that's ideal for a use case—the details of capturing reporting requirements around parameters, sort orders, filters, data sources, etc.
Use cases tend to be the best choice when you want to describe system functionality, especially user/system interactions. Non-functional specifications such as performance, response time, security, maintainability, and accessibility are often overlooked in use case documents. In other words, use cases are an excellent way to describe how a system works, but aren't the best way to describe how well a system should work. So if you've settled on use cases as your documentation tool of choice, think through how and where you'll capture the nonfunctional requirements.
The best rule of thumb is to consider whether you're trying to document how the user uses the system. If so, a use case is ideal. But if that isn't the primary focus of the requirements effort, consider an alternative tool like a business process map (to show business interactions), a data dictionary (to document detailed data requirements), or a business rule repository (to capture and manage the rules the system must apply when performing functions).