What comes before the use case model?

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).

Example of a context diagram

Example of a context diagram

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.

Example of a business process

Example of a business process

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

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

robertson2

Mastering the Requirements Process Includes good section on context diagrams. Also deliver an excellent course.

It's only fair to share...
Share on Facebook3Digg thisBuffer this pageShare on LinkedIn0Share on Google+0Share on VKTweet about this on TwitterShare on Tumblr0Pin on Pinterest0Share on Yummly0Flattr the authorShare on Reddit0Print this pageShare on StumbleUpon0Email this to someone

About Alex Papworth

8 Responses to “What comes before the use case model?”

Read below or add a comment...

  1. Ihave been surfing on-line greater than 3 hours lately, but I by no means found any attention-grabbing article
    like yours. It is lovely worth enough for me. In my opinion, if
    all webmasters and bloggers made good content material as you did,
    the internet will be much more helpfuul than ever before.

  2. Mark S. says:

    One word: Visualization!

    See http://www.onespring.net/articles/iaird_form.html, for more info…

  3. Lakeisha says:

    Deep thought! Thanks for cntoribuintg.

Trackbacks

  1. […] information in graphical forms, produce  business object models, conceptual data models, process models […]

  2. […] For more on what comes before you start use case modeling, see Use Cases – what comes before? […]

  3. […] information in graphical forms, produce  business object models, conceptual data models, process models […]

  4. […] If you would like to read more about use case modelling and how it fits in with business processes and context diagrams, see Use Cases – what comes before? […]

  5. […] For more on what comes before you start use case modelling, see Use Cases – what comes before? […]



Leave A Comment...

*