Preamble
As mentioned before, the primary objective of analysis is to align new applications with the functional architecture supporting existing ones, and that is best achieved with use cases that put the focus on the interactions between business processes (represented by users) and systems.
Yet, as originally defined by Ivar Jacobson, use cases, a key component of UML, take the system perspective and the question is to map use cases to their broader business objectives.
Broadly speaking, two approaches have been explored:
- Differentiated use cases, as epitomized by Alister Cockburn’s seminal book (Readings).
- Business use cases, to be introduced beside standard (often renamed as “system”) use cases.
Contrary to the second approach based on ill-defined concepts and fuzzy distinctions, Cockburn stays with UCs as defined by Jacobson and refines them to deal specifically with generalization, scaling, and extension.
Differentiated Use Cases
Being neatly defined by purposes (aka goals), Cockburn’s levels provide a good starting point:
- Users: sea level (blue).
- Summary: sky, cloud and kite (white).
- Functions: underwater, fish and clam (indigo).
As such they can be associated with specific concerns:
- Blue level UCs are concrete; that’s where interactions are identified with regard to actual agents, place, and time.
- White level UCs are abstract and cannot be instanciated; cloud ones are shared across business processes, kite ones are specific.
- Indigo level UCs are concrete but not necessarily the primary source of instanciation; fish ones may or may not be associated with business functions supported by systems (grey), e.g services , clam ones are supposed to be directly implemented by system operations.
As illustrated by the example below, use cases set at enterprise or business unit level can also be concrete:
UC abstraction connectors can then be used to define higher business objectives.
Business “Use” Cases
Compared to Cockburn’s efficient (no new concept) and clear (qualitative distinctions) scheme, the business use case alternative adds to the complexity with a fuzzy new concept based on quantitative distinctions like abstraction levels (lower for use cases, higher for business use cases) or granularity (respectively fine- and coarse-grained).
At first sight, using scales instead of concepts may allow a seamless modeling with the same notations and tools; but arguing for unified modeling goes against the introduction of a new concept. More critically, that seamless approach seems to overlook the semantic gap between business and system modeling languages. Instead of three-lane blacktops set along differentiated use cases, the alignment of business and system concerns is meant to be achieved through a medley of stereotypes, templates, and profiles supporting the transformation of BPMN models into UML ones.
But as far as business use cases are concerned, transformation schemes would come with serious drawbacks because the objective would not be to generate use cases from their business parent but to dynamically maintain and align business and users concerns. That brings back the question of the purpose of business use cases:
- Are BUCs targeting business logic ? that would be redundant because mapping business rules with applications can already be achieved through UML or BPMN diagrams.
- Are BUCs targeting business objectives ? but without a conceptual definition of “high levels” BUCs are to remain nondescript practices. As for the “lower levels” of business objectives, users’ stories already offer a better defined and accepted solution.
If that makes the concept of BUC irrelevant as well as confusing, the underlying issue of anchoring UCs to broader business objectives still remains.
Conclusion: Business Case for Use Cases
With the purposes clearly identified, the debate about BUC appears as a diversion: the key issue is to set apart stable long-term business objectives from short-term opportunistic users’ stories or use cases. So, instead of blurring the semantics of interactions by adding a business qualifier to the concept of use case, “business cases” would be better documented with the standard UC constructs for abstraction. Taking Cockburn’s example:
Different levels of abstraction can be combined, e.g:
- Business rules at enterprise level: “Handle Claim” (19) is focused on claims independently of actual use cases.
- Interactions at process level: “Handle Claim” (21) is focused on interactions with Customer independently of claims’ details.
Broader enterprise and business considerations can then be documented depending on scope.