I find use cases extremely valuable for eliciting requirements. Focusing the discussion on the business process with an informal use case, where each step is simply a bullet point and we don’t worry about using correct use case terminology, makes it much easier to keep conversation on track and productive and helps clarify and avoid misunderstandings that often occur between stakeholders and development staff in requirements discussions.
An example of an informal use case
Use Case: Reserving a room
Primary Actor: Travel Agent
Use Case Level: Actor goal
Pre-condition(s): The user has selected the property and is ready to reserve
The user selects the type/size of room to reserve
The user indicates a range of dates for the reservation
The system provides a list of rooms of that type/size that are available for the entire range of dates
The user selects a room to reserve
No room of selected type available – The system informs the user of the lack of availability and proposes different dates when the room type/size is available
I have seen clients use a collection of use case descriptions as a standalone requirement specification, without supporting requirement statements. There are advantages to using them in this way. Use cases can be written in a highly formal format to describe the process extremely precisely, or in a simple paragraph format, what Alistair Cockburn described as a “Use Case Brief”, which is slightly more detailed than a User Story, and there are many variations in between. This gives the analyst a broad range of options to fit her use cases to the project need. Unfortunately, most organizations enforce a standard template for use cases which limits this flexibility.
Perhaps the greatest advantage of the use case description is that the requirements are described together with the business process, actors and goals. This provides continuity between the discussions and the resulting requirement specification, giving the customers confidence that their needs have been described. It also provides the consumers of the documentation who may not have been in the meetings with a lot of valuable contextual information. Quality Assurance in particular finds use cases extremely valuable for writing test scripts.
There are some major disadvantages to only having use case descriptions without requirement statements, however, which is why I usually write IEEE style requirement statements to support use cases. The problem with use cases is that they usually encapsulate a lot of requirements into one large chunk of information. This makes it hard for development teams to estimate the use case’s complexity and plan their work, and hard for the business to provide a meaningful estimation of value or priority. It’s possible to break each use case down into a list of ‘scenarios’ that describe each possible path through the steps, but if you’re doing that much additional work you might as well write “The system shall” in front of each scenario.
Use cases are also criticized for their lack of emphasis on non-functional requirements and data requirements. They’re also not very useful for specifying reporting, data warehouse, business intelligence and other data focused systems that don’t have a lot of business process around them.
When would I recommend relying on use cases as a standalone requirement specification? Business process improvement initiatives and business architecture mapping projects don’t need to prioritize or estimate pieces of technical work, so a use case specification more than suffices. Also, if you’re writing a requirement specification for the purchase of an off-the-shelf piece of software, a use case specification is a great way to carefully evaluate prospective products, while a long list of 200 requirement statements can be more time consuming when looking at many potential products.