Use Cases

The concepts of Happy, Alternate, and Exception Paths originated with Use Cases, but turn out to be applicable to any graphical modelling technique that depicts Flow. This article presents examples of Business Process, Activity, and State Transition diagrams with these concepts represented simply using the common “Traffic Light” colors green, amber, and red. The benefits to both business analysts and stakeholders are discussed.

I like use cases. There, I said it, and I’m not sorry. Use cases have fallen out of fashion in recent years, being largely replaced by user stories on agile projects. The two techniques can coexist and complement each other, however.  Use cases offer several advantages that user stories lack. This article describes some of the many benefits that use cases can provide and why every business analyst (BA), product owner (PO), and software development team should include them in their tool kit.

Although use cases are valuable for many projects, sometimes event analysis is a more effective requirements elicitation technique. Valuable as they are, use cases aren’t the ideal tool for every type of product. A complementary requirements elicitation strategy is to explore the various events that a system or product could experience and how it should respond to each of them. The response depends on what state the system is in when it detects the event. Event analysis is particularly well-suited for middleware products and real-time systems that include both software and hardware components.

What is Use Case?

Use case represents requirement in the form of user interactions with the system. Use case is always written with a specific user goal in mind. Each use case must contain an actor and verb. For example, ‘online buyer’ is an actor and ‘add item to cart’ is a verb.

A use case diagram represents the scope of all the features of the solution. It follows Unified Modelling Language™ notation. Use case diagram comprises of several use cases that make the system altogether.

What is User Story?

User story is a business analysis artifact that is also user or persona driven. It describes the business need in the form of an ability user (or system) wants in the solution. It also must state why the ability is required and what the benefits of that ability are. It does not have any mandatory format though

User story is part of the (product/project) backlog. The backlog in turn contains user stories/tasks (requirements) in a linear fashion. Backlog is usually prioritized from high to low, additionally with a ranking when priorities are the same. When it is prioritized by business value of the tasks/stories in it, it is called managed backlog. In many projects, user stories are also represented visually as a user story map, which is a structured visualization of a backlog. User story map is a map of user stories that are transposed from a linear backlog, onto a visual working board.

Each of this concept is a detailed topic in itself. For the context of this article, I will limit it only at the introductory level. Let's now look into differences and similarities between user stories and use cases.

So how do you handle CRUD in your use cases? Please don’t confuse CRUD with CRAP in your use cases. That’s a lot harder to deal with and requires a conversation with your subject matter experts (SMEs). CRUD is an acronym for Create, Read, Update and Delete. It describes the lifecycle in the maintenance of system data, whether that data is stored in a database or is file based data stored in a document management system like SharePoint.

In the world of software development Use Cases are one of many very powerful techniques often used these days.  Use cases describe how a person or a system interacts with the solution being modeled/built to achieve a goal. Basically, it’s a step by step explanation of what a user can do and how the solution must respond.

As any other business analysis technique, use cases have their advantages and disadvantages. One of the main disadvantages of use cases is that this technique is not graphical – a use case diagram is but use case descriptions are not, and use case descriptions really lack of visualization especially if there are multiple alternative flows and exception flows that branch out and then loop back into the main one.

Several years ago I was looking for examples using the generalization / specialization technique with use cases. They are not easier to find. And they are typically limited to a use case diagram like the two below. This article provides examples of both the diagrams and the scenarios for a future gas station business.

A list of business analysis techniques is pretty extensive and from year to year new techniques appear, or become more formalised, and are adopted by business analysts all over the world. Some techniques become more popular and are widely used and some are used rare or only when a specific need arises. But definitely there are techniques that became very popular and are used on a daily basis and even become buzz words for some people. These techniques are mainly used to create solution design and they are business process maps, use cases, user stories, wireframes and business rules. Sometimes even business analysts are confused how they should create solution design and what techniques they should use.

A UML Use Case is an atomic system function with a well-defined and standardized specification, which is performed by or o behalf of a system user or ‘actor’. This article describes how a UML Use Case Specification should be written.

Rather than expecting use cases to contain all of a system’s functionality, I prefer to employ use cases to help the business analyst discover the functional requirements. That is, the use cases become a tool to reveal functionality rather than being an end requirements deliverable themselves. Users can review the use cases to validate whether a system that implemented the use cases would meet their needs. The BA can study each use case and derive the functional requirements the developer must implement to realize the use case in software. I like to store those functional requirements in a software requirements specification, although you could add them to the use case description if you prefer.

It is certainly true that use cases are a powerful technique for discovering the functional requirements for a system being developed. However, this statement suggests that use cases are the only tool needed for representing a software system’s functionality. In most cases, they aren't.

The structure that use cases provide is far superior to the nearly worthless technique of asking users “What do you want?” or “What are your requirements?” In this article I share my perspectives on when use cases work well, when they don’t, and what to do when use cases aren't a sufficient solution to the requirements problem.

A typical business function might contain several unique events each of which we want to end up as a component of a larger software application. So how do we go from a table containing textual information to a specification which a developer can use?

This article discusses Stephen King’s creative writing method and provides an example of using it in developing a use case narrative: the main scenario with alternate and exception paths. Yes, that is correct – Stephen King, the prolific writer of contemporary horror, science fiction and fantasy novels.