• For the Love of Data: An Overview of Data Modeling for BAs
  • Be Careful What You Wish For: The Hazards Of Being Target-Focused
  • Resources for the Investigative Analyst: Take your pick!
  • For the Love of Data: An Overview of Data Modeling for BAs

    I have always been a data fanatic. It started when I was a programmer analyst and learned to love such arcane data structures as ISAM (a relic), VSAM (simple, but efficient), and later DB2 (powerful and flexible). My recent database exposure has been MySQL for websites, but only as a BA.

  • Be Careful What You Wish For: The Hazards Of Being Target-Focused

    Business analysis often focuses on making a situation better.  The challenge that I suspect many of us face is that it can be quite difficult to define what ‘better’ actually means, not least because different stakeholders often have very different perspectives.  People working on the front-line will have a different set of needs, fears and aspirations compared with the executives who are steering the ship.

  • Resources for the Investigative Analyst: Take your pick!

    Being a Business Analyst (BA) is a lot like being an investigative journalist.

Tuesday, 19 May 2015 11:24

Why are Use Cases So Hard?

Written by

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.

Phil Vincent

Phil is a business analyst coach and trainer who brings a wealth of experience and a passion for excellence to every endeavour. He’s also known as a great storyteller. Over the years he has helped dozens of companies and thousands of professionals to improve the way they do business analysis by working smarter, not just harder. He helps people to see new ways of doing things, and to hone their skills while avoiding common traps through a combination of professional training and hands-on coaching of project teams. As a consultant, his clients from industries like insurance, finance, pharmaceuticals, transportation, and government keep calling him back for more.
Phil is one of the core team leads for the upcoming BABOK® Guide v3.

© BA Times.com 2021

macgregor logo white web