How to identify candidate use cases

Sherlock Holmes

This article will define a candidate use case.  It will identify the resources you can use as the source material to identify your use cases.  It will also explain what techniques you can apply to generate source material. Finally it will explain how you can validate your candidate use cases.

 

Definition

A candidate use case is nothing more than a first guess at a use case that is relevant in the problem domain. It may ultimately remain or be rejected in consultation with the stakeholder(s).

 

You’ll also need to identify the actors alongside the use cases.

 

Context

The business analyst may be identifying candidate use cases in a number of different contexts:

  • existing business process is being changed for some benefit (e.g. cost reduction)
     
  • brand new system is being created in support of a new business or new business unit
     
  • new business process to satisfy regulatory changes
     
  • new business process to exploit an opportunity (e.g. provides an opportunity for profit)
     
  • existing system is being replaced by new technology platform

This list is not exhaustive but should cover the majority of scenarios.

 

Source material

source-material

There will be different source materials available depending on the scenario above:

  • As is (current) business process and To be (future) business process
     
  • To be business process only
     
  • Existing system – training material, operational manuals

 

In addition, in the absence of process documentation, and as a further aid in identifying candidate use cases:

  • scope document including high level functions or capabilities
     
  • regulatory documentation
     
  • marketing material describing opportunity

 As a general rule, larger organisations will have more source materials (s0metimes too much!) and smaller organisations will have less. You may have next to nothing to work with – just a request from your boss to start working on a project. Even if there is nothing immediately available, you must  investigate to find source material that wasn’t immediately obvious. Talk to everyone who might know before you assume there is no more material.

 

Techniques for generating source material

There are a number of techniques you can apply if you don’t have enough source material which describes the system:

  • Interview users of existing system
    Ensure you put the interviewee at ease – explain the impact of the proposed system. Ask open questions initially to understand their behaviour at a high level. Ask more specific, closed questions to get more detail. Ask about activities that are undertaken to identify use cases and ask about the parties responsible to identify the actors.
     
  • Observation of user(s) of existing system
     
  • Interview sme’s (subject matter expert) for new business process
    As you will have some information to start with, your questions may be more specific if the business process is quite detailed.
     
  • Workshop
    Not recommended for generating source material as it can be hard work. Workshops are always best when you have a straw man or initial use case model that you can walk through

For all of these techniques, think about support activities (or use cases) – these involve anything that doesn’t involve the customer directly or involve problem resolution.

what happens when the customer calls to complain about the service/product?

what activities are necessary to monitor the service/product?

what happens when the service/product fails?

are their activities which indirectly impact the product? (e.g. change in business policy)

Don’t forget to ask questions in these areas.

 

Identifying candidate use cases

Once you have your source material, it is relatively easy to identify use cases. You should always remember that a use case yields a result of observable value to a user. Either identify the actor and look for activities for which he/she is responsible or identify activities and then determine who is responsible.

The following details how you should search for candidate use cases and actors:

  • business process
    Business processes consist of manual steps and automated steps – use cases will support automated business steps. The actor should be the individual executing the step (may be customer, may be employee).
     
  • scope document, results of interview or observation
    capabilities or ‘functions’ may well be listed which suggest use cases.
     
  • marketing material
    look for active phrases referring to individuals. e.g. You can receive SMS alerts from your bank at a time and frequency to suit you.
     
  • training material/operational manuals for existing system

 

Verifying candidate use cases

Example use case diagram

Example use case diagram

 

The best method for verifying candidate use cases is a workshop where all interested parties (or stakeholders) are brought together and you walk through your candidate use case model. The use case model does not need to be complete at this stage as we are only trying to determine that we have all the use cases.

 

You will need the following:

  • use case diagram(s)
    There may be several if it is too complex to show on one diagram. Try to group them in a logical way that is meaninigful to the stakeholders.
     
  • use case narrative for each use case
     
  • use case narrative needs a name, brief description and basic flow at this stage. The basic flow need only illustrate the purpose of the use case – it does not need to be complete

 

Conclusion

This article explained what is meant by candidate use cases and detailed the types of projects. It explained the source material that you may have and techniques for generating your own source material.
It concluded by explaining how you will create the candidate use cases and how to verify them with the stakeholders.
It's only fair to share...
Share on Facebook1Digg 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

3 Responses to “How to identify candidate use cases”

Read below or add a comment...

  1. Very good article, excellent on sourcing material but a little light on subject of your article “How to identify candidate use cases”. The line “You should always remember that a use case yields a result of observable value to a user” is the closest you came to providing the how of identifying candidate use cases which I found wanting.

    By focusing on the “What” or the action words, one should be well on his way to identifying candidate use cases.

    • Alex P says:

      Thanks Zechariah.

      I was focussing on the potential source material as it can vary so much depending on your particular circumstances. I’d agree that looking for action words or verbs is a good place to start. Could form a follow up article maybe?

      Alex

Trackbacks

  1. […] 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 […]



Leave A Comment...

*