(Ab)using Use Cases
I visit quite a few companies and routinely ask if they use Use Cases. At a depressingly high rate I get an explanation along the lines of: “We tried to use it but it was too hard”, “It is actually no good because business rules can’t be documented adequately”, “They are too complicated”, etc. etc.
The usual cause I see is that organisations try to make them the vehicle for all requirements. This leads to long, hard to read, use cases causing disenchantment and ultimately abandonment of this technique. This is a pity because there are few approaches so powerful in eliciting and structuring requirements.
So I went back and compiled a list of what I regard as the essential Must-Do’s of Use Cases.
DO #1: Employ Use Cases as an investigative tool
Use Cases are great to draw out requirements. They embody a conversational style that is easy for anyone to adopt. While working on the use case texts, it is common to have all
No matter what your ultimate packaging of requirements is, the way use cases are patterned is the easiest to elicit requirements from users. The structure of a use case actually patterns the way we tend to think the very first time about a requirement.
When you workshop Use Cases you not only going to collect the actual scenario texts but also be able to identify user interfaces, business rules, business objects etc. Use cases are like a vacuum that suck in all the other requirements. That’s good. But be aware that all those other requirements need to move into the right place in your requirements model.
So use Use Cases to elicit the requirements and then later factor out what doesn’t really belong into the text of a Use Case (see below).
DO #2: Map use cases to business processes
Requirements creep is a significant problem, when users behave like kids in a candy store. How do you justify the need for a use case? Mapping them to business processes is powerful, because it shows where the use case supports the business process – the ultimate justification for having the use case.
DO #3: Control the level of abstraction
Use cases can be applied at different levels of abstraction. The most common level is to describe the user interaction with the system for which requirements are being sought. It is however possible to use Use Cases to describe Business Processes (where multiple systems and even manual processes are being described) and conversely to describe processes internal to systems (which would be applicable during the design process).
To make Use Cases useful they need stick to a particular level of abstraction. If you write Use Cases to describe how a user expects to use a system for a particular objective, then the Use Case text should not describe the business process. That information would probably be better indicated in the description and then described in separate Use Cases that are at business process level.
Corollary: Group Use Cases for each level of abstraction – if you use documents, consider sticking them into separate documents.
DO #4: Refactor Use Cases
If Use Cases are the ultimate lint collector in the requirements space, then you need to clean them up. Revisit your Use Cases to see whether they represent a tight, functional, description of how a system is used. Often Use Cases have grown too complex – break them down into smaller, yet still functional, Use Cases. Remember that a Use Case still must be able to fulfil an objective that is fits into the conceptual world of your user.
If the scenario text contains other stuff like Business Rules, complex branches, UI specifics etc, then start pulling it out. Stick them into – well here comes the next DO…
DO #5: Store different types of requirements in appropriate locations
Use Cases are really only good to describe how a system is to be used. Trying to make them a vehicle for everything is bound to fail and will give Use Cases a bad name. Scenario text should therefore only contain the interaction between the user and the system. Anything else may be referred to but not described in the text.
Keep separate places for the following types of requirements:
- Business Rules
- User Interface Specifications
- External Interface Specifications
- Business Objects (Class or Entity Relationship diagrams)
- A glossary of terminology
Each of these requirements needs to go into a separate template, but properly cross-referenced.
DO #6: Document questions, answers and assumptions
Sounds like a lot? Well it isn’t sufficient. Because Requirements are never definitive you need to have a space to document the questions that come up. Once the questions are answered, add them to the question.
If you can’t get an answer (a not uncommon situation) the next best situation is to make an assumption. Assumptions equal risks. So document them well and flag them for what they are.
DO#7: Cross-reference
So you elicit your requirements with Use Cases and then extract the non-Use Case Requirements into other documents. Now you need a good referencing system. There are some tools that do that but not many of them are actually easy to use. But help is at hand. Invent a naming scheme that clearly identifies all kinds of requirements. So when you Use Case text identifies a UI, then all you need in the text is the ID (eg UI-1020) and the title of the UI.
DO #8: Cross-validate
Once your requirements are stabilising you will need to make sure your requirements are consistent. Here are some questions:
- Do all scenarios reference User Interfaces (remember, Use Cases are typically about interactions between users and the system)?
- Alternatively are there External Interfaces referenced if the actor is another system
- Is the User Interface able to support the text in the scenario?
- Is there a Business Object that is able to carry the information displayed or entered in the user interface?
- Does the User Interface have the appropriate validations?
- Do the business objects capture the information required by the business rules?
- Do you have Use Cases that cover basic functions such as Creation, Retrieving, Viewing and Updating for each of your Business Objects?