Declan Chellar

I have had discussions with colleagues about use cases (and seen discussions on LinkedIn) where it is clear that some people do not understand that there are different types of use case, so I hope the following definitions help.

Business Use Case
A technique for describing (in technology-agnostic terms) a business process which is invoked by business actors (people or external systems), often working in collaboration, in order to achieve a specific goal (or goals) that provides clearly defined business value to the actors (e.g., process a customer order).

A BUC can describe both manual steps, such as greeting a customer, as well as steps which are expected to be supported by an IT solution, such as recording customer details.

A BUC is often supported by several System Use Cases.

System Use Case
A technique for describing the interaction between a business actor (e.g., a person or external system) and the target system in order to achieve a result of clearly defined business value to the actor. A SUC will describe what the system will do for the actor but not how it will achieve it. A SUC will not describe any actions outside the actor/system interaction. A SUC is implementation-agnostic and does not make reference to screens, screen elements (e.g., buttons and drop-down lists) or screen activities (e.g., “clicking”).

A SUC is often supported by a single Technical Use Case.

A SUC is often supported by one or more UI Specifications.

One or more SUCs can be represented by a Screen Flow. Several SUCs can be represented by a Workflow.

Technical Use Case
A technique to describe, in implementation terms, how the target system will achieve what is described in the corresponding SUC, in order to provide the business value described in the SUC.

The following definitions are useful if you are involved in workflow solutions:

Work Type
A work type defines the kind of item that will be processed in a Workflow System.  A work type is represented as a work object to an end user.

Workflow
A workflow can be described as a repeatable collaboration of tasks (each of which may be represented by a System Use Case) that affect an identified piece of work (work type), across multiple roles. The workflow is governed by business rules. The flow begins with the generation of the work type and ends with the resolution of the work type.

Inexperienced analysts often confuse System Use Cases with screen flows. A poorly written SUC talks about clicking on buttons. This is not a good idea because the SUC should focus on describing what the business needs the System to do. Buttons, drop-down lists, checkboxes, etc, are all part of how the System does what it needs to do and belong in the realm of high-level design.

Moreover, when analysts write SUCs as if they were screen flows, they cause confusion because they start to talk about clicking the “Cancel” button instead of the “Confirm” button as if it were an alternate flow within the SUC, which it is not.

UI Specification
A technique for describing each required User Interface in terms of what needs to appear on the screen (data) and how the screen needs to behave. This technique describes the screen elements that are needed in conceptual terms (e.g., a widget to enable to User to select among several options), but not in concrete terms (e.g., a drop-down list). A UI Specification represents a single screen.

Screen Flow
A technique for illustrating all possible paths through the screens that support a specific set of SUCs, indicating what concrete UI elements trigger the movement from one screen to another along the path (e.g., “Submit” button).

I hope this helps.

Kind regards,

Declan Chellar