Approach to identifying use case

I guess the most popular approach to discovering use cases is the Actor Goal model where you identify the
actors and their interests in the system, then come up with the use cases.

I also read from Mastering the Requirements Process by Suzanne Robertson who recommends business
event-business use case-product use case approach. Bascially her approach is driven by business event, then
identify business use case responding to the event. Finally you work with SME to come up with product use
case to support the business use case (business/product use case is similar to Rational's business/system use
case in my opinion)

The two approaches have some similarities and they share the same goal which is to identify use case to
satisfy user goals. To me, the actor goal approach works in a sequence of 'inside to outside', and Suzanne's
approach works from 'outside to inside' or what is the business response to the external.

What do you think of the two approaches?

or maybe they are in essence the same?
What approach do you use to identify use case?

Would like to hear your thoughts on this.

Happy new everyone!

Many approaches

Actor-goal and business event are a couple of ways to identify use cases. I don't have a problem with them,
except that too often the focus is too specific - on a specific actor or specific event. That is OK at some
points in time, but a narrow outlook often leads to reproducing the current way of doing things, which may
not be the optimal outcome.

Look for the information that is used in the business. Where is the information produced, modified,
consumed? Kind of like a business event, but I am not looking for specific events here, rather general
information flow. What information do we use? How do we use it? How else can we use it? Do we really
need it? Once I know those things, I can define the actors and use cases needed to manage that information.

Play a game - Luke Hohmann has done some great work on games to stimulate finding out information for
marketing purposes. I use the same kind of games to find requirements. See his book Innovation Games. I
am in the process of writing a paper showing specifically how the games relate to discovering project
requirements.

Look for overall what the customer wants to achieve, the success criteria. Once I know the success criteria, I
can explore what it will take to achieve that success, and define actors and use cases appropriately.

I think the best use cases (and other requirements) come out of looking at the big picture and the
relationships between the parts, rather than starting by focusing on one actor or one event.

But then, I'm more of a top-down thinker and used to working on really large projects. Other situations call
for different approaches.
Geri

Nouns and Verbs technique

My approach is simple.

I review the "artifacts" in front of me and look for noun and verb combinations.

For instance, I may notice combinations such as "post resume" or "review job applicant qualifications".

Generally any noun / verb combination is a use case candidate.

After you've created your candidates, review and refine them with stakeholder input.

Use Cases and the true data

There is none. Think about this, we've all been using use cases for the last few years, and the requirements
issue is not exactly getting better. It take more than just Use Cases, it takes the visual inspection and the
ability to collaborate within the project/management team to make this issue better. A little company that you
should all put on your radar is finally addressing this issue, their management is mostly the old rational
guard.
www.ravenflow.com and look at what their doing, you'll like what you see.

levels of activity

i stress this whenever i train/teach/mentor folks on use cases.

generically, a use case is a description of a set of steps which helps realize some goal, be it a busines, system
or user level goal.

and each process has something that kicks it off. as dwright stated, at the business level, it's usually
something like "a customer comes into the repair shop and says that their dowhichie is not flibaritzing like it
should." at the user level, it's usually something like "the user decides to ..." at the component or class level,
it's usually like "object a sends object b the xyz message." each has their trigger, pre-conditions, steps, and
post-conditions.

it's just that "use case", to many people, means "user level". abstract the thought at it applies to any level.

in 2005, i facilitated a series of 10 business process modeling workshop meetings where we described the
business process with some but very little mention of applications. i would ask [not just naively, since i didnt
know the business domain] "in order to accomplish that, what do you do now and what would you like to do
in the future?" they would answer something like "well, first we validate the submitted data and then we
approve it for the next step in the process, making sure we record when that happens, ...." rarely did they
mention exactly how they validated the data. but you know there were lots of systems and applications
behind those statements.

read the use case books by Cockburn for a good discussion of levels of abstraction/details. the Catalysis book
by Desmond D'Souza and Alan Wills [Objects, Components, and Frameworks with UML] also introduces
these levels. [disclaimer: i worked for desmond for about 3 yrs]. this is where i learned that, regardless of the
amount of detail, a business process, a system use case, an interaction between components, and an
interaction between classes are really the same thing - description of behavior. [check out
http://www.catalysis.org/, tho not updated much these days]

i've started from the outside as well as from the inside. sometimes, even from the middle. the trick is to make
sure the any proposed process ties back in someway to a business or stakeholder need. otherwise, it might be
cool and all that, but it may not help solve a business' or stakeholder's need.

to represent the process desc, i've used flowcharts, activity diagrams, post it notes, free form text, etc. i work
w/ the folks to brainstorm and then fill in the details later, checking for consistency of terminology and
common process steps.

btw, Suzanne Robertson's book and Ellen Gottesdiener's books are great. [suzanne is at
http://systemsguild.com ellen is at http://www.ebgconsulting.com] ellen's _Requirements_by_Collaboration_
book is one of the best on how to elicit requirements [one-on-one, focus groups, workshops, etc.].

requirements - they're not only inevitable, they're necessary!

Events spawn Business Processes

The business people I have been working with recently are comfortable describing their response to business
events as executions of a Business Process. Within those processes, you will find steps where use of system
occurs,what you may be referring to as a product use case, but I also seen called system events to
differentiate them from business events; the latter may be "receive order", while the former would be "record
order details", for example.

So, I always look at existing Business Process diagrams/maps as a source of system event use cases, or draft
a process diagram to assist me.

re:Events spawn business processes

Do you also use actor-goal approach as well? what's your comment on that?

Thanks,

Use Actor-Goal?

I have not used that approach specifically... the other good thing about using Process Maps is if they have
swim-lanes, as that usually defines the resource/actor performing the steps.

I've always used Actor-Goal

...for whatever it's worth.

The advantage of the actor-goal approach is that it forces you to identify what the desired outcome of the use
case is, which a business event approach does not.
the two approaches complement each other

I think the two approaches complement each other, maybe we need to consider using both in use case
identification. IMHO, they are two things that serve the same purpose: get something done or "What I (the
business) should do in response to that event". The desired outcome mentioned in actor-goal is also an
outcome desired by the external system.

The concern I have for actor-goal approach is that basically you are relying on the knowledge of your SMEs.
If for any reasons they do not mention some of the goals, then you will probably miss some use cases.
Complementing it with business event approach, you basically extend the perspective to the outside world,
and force the user to think about questions like "oh, if that happens, what I am gonna do with it?"

Use each technique where appropriate

I also share the view that the two approaches complement each other, but also feel that knowing and
recognising when to use each one at a particular stage of the requirements phase is key.

We used the 'business event' approach at PricewaterhoseCoopers, and it proved to be very effective in
providing some structure to our workshops and getting user involvement early. We basically organised
stakeholder groups, and walked through each business event encountered by a stakeholder group and their
current/expected response to this event... response being manual or system task. We found people related far
better to every day events and scenarios that they encounter on a day-to-day basis then diving straight into
use case modelling.... we called it the difference between dreaming up use cases and deriving use cases. We
used an event-response matrix to record our workshop findings and used these to derive both our business
processes and identify business use cases.

Saying this, there are many situations where as a BA you recognise that the above approach is overkill, and
using the Actor-Goal approach is more appopriate. Either way, you will end up doing Actor-Goal modelling
use case modelling... as Simon says, one supports the other.

Anyway, just thought i'd share my thoughts and experience :-)

Thanks for sharing your experience

I sometime think event-driven approach is an overkill as well. However the thing is : as you mentioned,
stakeholders respond to it really well, it's so much harder for people to sit there to dream up (or brainstorm)
something without a structured approach. Anyway, we just need to balance it out a bit in reality.