This article puts use cases into context by exploring where they sit within a project. Various methods for validating them within the wider context are also discussed.
It also discusses what other techniques can or should be used in conjunction with them (and what comes before the use case model). Such as
- Business case vs use case;
- Business use cases vs use case;
- Business process vs use case.
Some readers may be interested in a recommended use case training course
.
Table of Contents
What Comes Before Use Cases ?
Use cases are rarely the starting point for any project when it is first being conceived. Initially, the business sponsor is thinking about business benefits, costs savings or creating competitive advantage. They will be starting to formulate a business case whether formally or informally.
This should always be the case whether it is done on a very informal basis in a smaller organisation or as part of a formal process which will be the case in larger organisations.
The need for a business case is required by all businesses even those in the not for profit sector although their desire to generate increased profit, for example, is not the same central, overriding goal as it is the private sector.
Anyhow, there could be a whole heap of preliminary work that goes on before the word use case is mentioned. It should involve defining strategy and achieving business goals in support of that which will be internally driven.
Alternatively, it may be driven externally by, for example, regulatory requirements where there is usually a timetable for compliance dictated by a body outside the business.
I do not intend to cover any of this in detail but just give a flavour of where use cases may sit and how they are just part of an ongoing process that starts some time before and may or may not involve the business analyst.
The more experienced senior business analyst, who is hooked into the corporate strategy, may well be participating or even driving this preliminary work.
Often, however, the business analyst (in the IT department) is only called in when the project has a name and some objectives.
At this stage there are some useful models that can bear fruit downstream before diving into the level of detail required by use cases.
Context Diagram
The first is called a context diagram and positions the system within the larger business context. It will identify the interfaces with other parts of the business – typically, this is a point of contact or handoff between two parties that shows the scope of the project.
Ultimately, it will be a box that defines the boundary or the project scope. Business activities within the box are in scope and activities outside the box are out of scope.
Below is an example of a context diagram.
Business Process Model
Producing a model of the business process or processes that are relevant will help towards this end.
If the business is undergoing a change, it is useful to see how the business operates today and how it will operate in the future which, in essence, are the ‘As Is’ (i.e. today) business processes and the ‘To Be’ (i.e. the future) business processes.
This is but a small part of the practice of business process reengineering which is a significant subject in its own right.
Business Use Cases
Business processes within an organisation can be modelled by business use cases. A business use case could come before the use cases sometimes referred to system use cases.
From a UML perspective, the processes of a business are defined as a number of different business use cases, each of which represents a specific workflow in the business.
A business use case defines what should happen in the business when it is performed; it describes the performance of a sequence of actions that produces a valuable result to a particular business actor. A business process either generates value for the business or mitigates costs to the business.
By establishing a set of business use cases in a business-use case model it can provide the basis for the use case model and subsequently use cases.
Business Use Case Model
Business use cases maybe combined into a business use case model. The business use case model is a model of the business intended functions. It is used as an essential input to identify business roles and deliverables in the business organisation.
Use Case Model
At last, we are approaching the use case model. Those business processes and the context diagram will provide an excellent point for first identifying our candidate use cases.
This is our first draft list of the ‘goals of observable value’ that will form the functional scope of our system.
In fact, it is often found that the business processes are composed of a series of steps and certain steps will fall within the scope of the project and will, therefore, need an actor to deliver them and a use case to describe the detail of how they are delivered.
This is not an exhaustive list of documents and models but gives a flavour of typical models and documents that precede use cases.
So, in summary:
- There are many stages before a use case model becomes necessary;
- There needs to be a business case to justify the project;
- Context diagrams and business processes prove very useful (even necessary!) inputs to our candidate use cases.
Useful Links
You may find the following links useful for more information regarding context diagrams and business processes:
- System context diagram defined in Wikipedia
- Brief article from blogger (Craig Borysowich)
- Context article from James Robertson (Atlantic Systems Guild)
- Full definition and history of business process modelling in Wikipedia
- Long article covering history and Business Process Modelling from Joint Information Systems Committe(!) – worth skimming through as there are some very specific slides regarding business process modelling
Related Books
Mastering the Requirements Process
Includes good section on context diagrams.