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.
If you want to see the how a project fits into the larger context of a business, you should read The big picture
What comes first?
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 business analyst, who is hooked into the corporate strategy, may well be particpating 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. 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.
The example below is taken from the Atlantic Systems Guild website who are authors of Mastering the Requirements Process (mentioned in Requirements Engineering – an Introduction).
It is helpful to further develop the idea of placing the project in the wider business context. 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 it’s own right.
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’ (see more on this in Use Cases – an Introduction) 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
You may find the following links useful for more information regarding context diagrams and business processes:
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
Mastering the Requirements Process Includes good section on context diagrams. Also deliver an excellent course.