It might be just me but I have detected a subtle, but significant, change in the meaning of the term use case of late. Something I have found I’ve been going along with but not without feeling slightly uncomfortable whilst doing so. The two definitions I’ve always used for use cases, namely a business use case and system use case come from Alistair Cockburn’s excellent and pretty much definitive guide: Writing Effective Use Cases (shame on you if this is not in your library).

A business use case is one in which the design scope is business operations. It is about an actor outside the organisation achieving a goal with respect to the organisation. The business use case often contains no mention of technology, since it is concerned with how the business operates.

A system use case is one in which the design scope is the computer system to be designed. It is about an actor achieving a goal with the computer system; it is about technology.”

For a discussion on the differences see this blog post. Ivar Jacobson, the person who pretty much invented the term ‘use case’, defines it in the following way:

When a user uses the system, she or he will perform a behaviorally related sequence of transactions in a dialogue with the system. We call such a special sequence a use case.

The way in which I am increasingly seeing use case being used is in a more informal, or less precise way, which is best described in terms of how I actually hear them being used. Here are some examples:

• I need to understand the use case(s) for how we would use that product.
• Is that a use case our operations people would support?
• We need to run some use cases through that solution to test out some of the assumptions.
• That use case calls for a larger number of users than we had envisaged.

In all of these examples the term ‘use case’ is pretty much synonymous with the term ‘requirement’. The scope may be a product, a system, a solution or an organisation and the actor may or may not be clearly identified. The use cases may imply some function of those entities or some quality (such number of users in the last example above).

Does this matter? At first the purist in me said it did. A use case has to have a well defined actor and a clearly stated set of ‘steps’ that actor performs when interacting with the system or organisation. However on reflection I’ve become slightly more relaxed about it on the basis that:

• Any term which becomes a common, de-facto currency of understanding is better than not having one.
• Adding the prefix ‘system’ or ‘business’ still gives us the more formal definitions most architects (business, solution or application) would recognise) so why not relax the use of the term when it does not have one of these prefixes?

Entering into the spirit of this ‘relaxed’ use of the term here are a set of use cases I’ve recently used when trying to articulate some of the uses of ‘Big Data’.This maps use cases onto two of the three so called “Big Data 3-V’ framework” (velocity, variety and (missing on here) volume).

Each of the boxes represents a ‘use case’ (no prefix) which has an informal description as in the following example.

Use Case: Social media analysis: Although basic insights into social media can tell you what people are saying and how sentiment is trending, they cannot answer what is ultimately a more important question: Why are people saying what they are saying and behaving the way they are behaving? Answering this type of question requires enriching the social media feeds with additional data residing in other enterprise systems. In other words, linking behaviour, and the driver of that behaviour, requires relating social media analytics back to traditional data repositories.

In the traditional context of a business or system use case this could be decomposed into a number of these more detailed and precise types of use case. What it does do however is provide a basic scope for such a further, more detailed, analysis to be performed.