Why are Use Cases So Hard?

Maybe it’s because they are so easy to write. Given a template and a few minutes of guidance, anyone can write a use case description. The problem is that everyone writes them differently, and from different perspectives. One person may describe what they want a solution to do, while another tries to describe the design of a set of screens, and another tries to explain how an existing system works. If they all try to collaborate on the same use case, chaos is likely, personalities will take over, and the result will only satisfy the requirements of some of the stakeholders. Usually the technical solution providers persevere and we lose sight of what the business users wanted. We end up with use cases like “Create”, “View”, “Modify” and “Browse” which represent the developers’ point of view, rather than the business point of view.

For some people the use case description is the only requirements artifact they use. They embed data descriptions, business rules, and even screen navigation, resulting in overly complex, confusing, impossible to keep-up-to-date documents.

Look around at all the online discussions about use cases, read the books, take courses, read the UML specification, ….they’re all different! And they’re all more or less right. It’s like a mob contest, where great ideas are embraced temporarily and then tossed aside in favour of the most stubborn, or the loudest, or the biggest. Or for the most cunning, wealthiest or the most popular proponents.

I think we can fix this.

All we need to do is agree on different kinds of use cases to suit the needs of different kinds of stakeholders at different times in a solution’s lifecycle. Now, before you dismiss this as just another feeble attempt by one guy to impose his view of the world, I realize that this has been tried before, quite a few times. Without success.

But what do you think of this idea? Both the BABOK® Guide and the PMBOK® Guide agree on requirements classifications: business, stakeholder, solution, and transition requirements. Could we in the business analysis profession agree on a corresponding set of use case classifications? (Yes, business and system use cases were introduced back in the 1990’s, but nobody agrees on how to write them, either).

“Use Cases are a means to capture the requirements of systems, i.e., what systems are supposed to do.”

As a business analyst, you know that use cases can be a very effective tool for eliciting and describing what stakeholders would like a system to do. And you also know that developers can write use cases to describe what a system will do for its users. So why not use both perspectives in two separate sets of use cases, linked through requirements traceability?

Stakeholder use cases could describe what the stakeholders need to be able to do with a system, written in the vocabulary of the stakeholders, from the point of view of the stakeholders, without using words like “enter”, “dropdown”, “select”, “page”, “screen”, “submit”, “click”, or any other words that impose a design on the system. Scenarios inside the use cases would be written using business nouns and verbs, avoiding abstract terms like “data”, “information”, and “process”, and instead telling us what that data is about, and using the verbs that the stakeholders use to precisely state their requirements.

In response to the approved set of stakeholder use cases, system use cases could describe a proposed design in the vocabulary of the proposed solution. Then business analysts could trace between what the stakeholders said they needed to what the solution proposes to deliver. In this way, different solution options could be proposed and assessed to see how well they meet the stakeholder needs.

A stakeholder use case model (made up of use case diagrams and the use case scenarios) would describe the scope of a proposed solution in business terms, and so could be used to assess feasibility, identify and evaluate alternate solutions, estimate business value and project costs and identify business risks.

A stakeholder use case model could be the starting point to develop system use cases, and could be used to solicit and evaluate solution proposals from vendors and in-house development teams.

A system use case model based on the stakeholder use case model would be faster and easier to develop because the scenarios and the steps of the stakeholder scenarios are already written.

User test cases to validate that the solution will allow the stakeholders to do their work would be based on the stakeholder use cases. Functional test cases would verify that the solution is built according to the design in the system use cases.

There is also a need for understanding how external customers and partners interact with an organization, but BPMN collaboration diagrams can capture that well. If you are not using BPMN, then perhaps you could use business use cases to show that interaction and to establish the business vocabulary while you are describing the business value that the organization delivers to its customers. You could trace between business use cases and stakeholder use cases to make sure that the stakeholder use cases are providing real business value, and not just some internal improvements.

People who support an existing system in production would benefit from use cases that describe the system “as-built”; these use cases would evolve over a useful life of many years.

Four different types of use cases are identified, created at different times and for different audiences, with traceability between them. Business use cases describe how the organization provides value to its customers; stakeholder use cases describe what stakeholders need to be able to do using a system to deliver that value; system use cases describe the design of the system, and as-built use cases describe the system as it really exists in production. Both the stakeholder and as-built use cases would be the basis for ongoing support and continuous improvement.

Don’t forget to leave your comments below.