Use Case Scenarios

[nifsmith]

I have recently been on a UML course. This course taught that Use Case Descriptions (Basic, Alternate and Exceptional) are different from Use Case Scenarios in that Scenarios are instances of Use Cases.

For example if I have a basic path and an exception point in that path. I would write the Use Case as follows.

Basic Path ---
Buy stamp
Lick stamp
Stick on item to be sent

Exception--
At lick stamp the stamp has no adhesive
Return stamp
Recieve new stamp
Continue at Lick stamp

A Scenario would be
Bob buys a £1 stamp.
Bob licks the stamp
Bob sticks the stamp on the postcard

Another would be
Bob buys 50p stamp
Bob licks stamp but stamp has no adhesive
Bob returns stamp
Bob gets another 50p stamp
Bob licks stamp
Bob sticks stamp to letter

If the above is the correct way to write Scenarios and Use Cases. How do I assign the Use Case Description and the Scenarios against a Use Case artifact.

Currently I am putting the Use Case Descriptions in the Scenarios section of the property box. I have created word docs for all my scenarios and I intend to attach as linked files.

Does anyone have any coments on the suitability of the above or can anyone explain how they differentiate between Use Case and Use Case Scenario.

TYIA

[Ilja Kraval]

Hi TYIA,

the difference between USE CASE and his SCENARIO is the same as the difference between some “BUTTONS” on a café-automat and the WIRES inside an automat. Every BUTTON has its label (USE CASE has its name), it is a deal, convention between circumambience and system. At this point of “external” view, USE CASE brings some use, some profit, benefit for circumambience (… push the button “GET CAFÉ”!… or “LOGIN TO SYSTEM”!).
The SCENARIO is like an implementation of operation, something what is implemented inside the system under the BUTTON. Analysts find the BUTTONS first (what is needed) and behavioral under these buttons (how it works), it means they find the USE CASES and SCENARIOS.
We are preparing USE CASE EDITOR for EA as its ADD-IN now, it will be connected to WORD as “round-trip” from EA to WORD. It will be released in October this year.

The concepts like BASE PATH, ALTERNATE PATH, EXCEPTION PATH and so on are only intended for good visible structure of SCENARIO (programmers like to see these structures, they see only parts which are needed at this certain time).

[sargasso]

AAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRGGGGGGGGGHHHHHH!!!  

Use case : Apply postage to envelope.
===========================
Is this a use case?  
a) Does it achieve an outcome of value to the actor?  I dont think so.
b) Is it complete? I dont think so.  Would you sit around on a Saturday afternoon and stick stamps on envelopes?

Use case: Mail letter to Grandma
=======================
Is this a use case?
a) Is it generalised and repeatable?  Only if you only ever correspond with Grandma.

Use case: Write and send a letter
========================
Much better - of value and complete.

Basic path: write, fold, insert, address envelope, apply postage, goto mailbox, post
Alternate path: write, fold, insert, address envelope, goto postoffice, buy stamp, apply postage, goto mailbox, post.
Alternate path: write, fold,insert, address envelope, borrow stamp off Mary, apply postage, goto mailbox, post.

N.B. All these paths have a single outcome - letter mailed.

From the above paths we can get 2 scenarios "have a stamp" and "dont have a stamp".  Since we are writing use cases and not designing the system yet both alternate paths can be collapsed.  IOW, I dont care (at this point) how we get the stamp - just that there exists a path that involves getting a stamp somehow.  Maybe "get a stamp" an extension use case, maybe not - I'll worry about that later.

Actors involved: writer, mailbox and stamp-supplier.
Justfy!
Writer - obvious, primary actor, initiates use case.
Mailbox - not obvious, does not actively participate, BUT, the use case cannot complete without it.
Stamp-supplier - optional, until we realise that the writer can also act as the stamp supplier.
Pen, paper, envelop, etc etc - possible but not significant.

Finally, are there any "failure" scenarios of interest?  Since we have defined an outcome - letter mailed - is there any significant ways thet the letter cannot be mailed.  Note well the use of "significant", the event "Venusians kidnap writer" is probably not significant.

Off the top of my head, "cant get a stamp" is probably the only significant failure.  

In summary:
1) create a use case name.
2) ask yourself whether it has a unique outcome of value to the primary actor. (if not try again)
3) walk through some obvious success paths - rationalise them.
4) review the actors
5) look for failure (or alternate) outcomes.

bruce

[Paolo F Cantoni]

Onya bruce!!!

Getting this stuff right is ONE of the keys to successful systems building.

However, a couple of questions...

Whilst we are NOT designing the system, we DO have to be aware of the system boundaries.  Isn't it the case, for a UseCase to complete, there must be some interaction from the primary actor to the system and an interaction from the system to (at least) a secondary actor.

In this case, the primary actor is the writer, the final actor is the mailbox (as the interface to the mail delivery system - which might be considered the "real" secondary actor).  So where are the system boundaries?

Is the act of writing the first action in the UseCase and therefore the boundary is "to the left"?

Similarly, since the stamp-supplier is an actor, then they must be outside the system.

Maybe Kevin can add some insight here?

Inquisitively,
Paolo

I've often said (though no so far in this forum) that it is the discipline of adhering to the correct formalism that provides the way through the maze...
So Thomas, there's a new aphorism...
Discipline, Discipline, Discipline! ^TM

[sargasso]

Agreed, agreed, agreed.

(Since you seem to adhere to the three headed policeman model   )

In the above I "assumed" there was more to the model and was just looking at the one use case.  One could assume for instance that the mail delivery system was of interest.  On the other hand consider the fellow marooned on the desert island with an unlimited supply of paper, pens and bottles.  The "send message in bottle" use case is complete in itself, the tidal-message-delivery system is beyond the scope of interest.

More seriously, "purchase groceries" completes at the check out.  The remainder of the grocery chain enterprise architecture may include inventory. purchasing, marketing, rostering, accounting, tax etc etc etc systems.  If we are designing a solution to the Saturday morning check out queue problem all of these systems may safely be ignored.  So as you say, the system boundary is important.  I will even expand that to the business system bouindary is equally important.

bruce

[Paolo F Cantoni]

[size=13][SNIP][/size]
More seriously, "purchase groceries" completes at the check out.  The remainder of the grocery chain enterprise architecture may include inventory. purchasing, marketing, rostering, accounting, tax etc etc etc systems.  If we are designing a solution to the Saturday morning check out queue problem all of these systems may safely be ignored.  So as you say, the system boundary is important.  I will even expand that to the business system boundary is equally important.

bruce

Thanx, bruce,
I'm still trying to ensure I understand correctly...
"Purchase groceries" is a UseCase for the queueing system (since all the other systems can be ignored).  
Since the system is a queueing system, does the UseCase actually start when I enter the queue?
Primary actor is me, first contact with system is entering the queue, last contact with system is receiving receipt?
Or is "purchase groceries" only that segment of a larger UseCase (exit store) that corresponds to arriving at checkout, unloading groceries, tallying costs, paying and receiving receipt?

I think that it is necessary to determine what the system IS, before defining UseCases for it.  In other words, a UseCase has no meaning on its own, only within the context of the system it is referring to.  As a consequence of what a UseCase is, it is necessary for a UseCase to be "complete" for the primary actor to have an initial contact with the system and a final contact with the system (effectively the entry and exit points).

I believe that making sure you can locate these points can be very useful in analysing the UseCase.  What say you?

Paolo

[sargasso]

No, I have been extremely unclear here.

"purchase groceries" is, in what I am trying to say, in fact the (business) system boundary.

I was trying, as usual, to use a real world example to illustrate the need to get away from "design" when first starting out with use cases.

To continue the metaphore and hopefully communicate more better.

A grocery business SuperMegaGreenFresh Inc perceives a business problem - customer dissatisfaction invoked by the time taken to complete the purchase of groceries on Saturday mornings.  Detailed analysis by an extremely highly paid consumer psychology consultant has revealed that the cause is localised in the final activity, that is, they don't like standing in the checkout queues.  The time wasted locating the desired items in the totally illogically designed aisle layout, the time wasted waiting for a moronic 16 year old delicatessen attendant with advanced post nasal drip to weigh 140gms of fresh fetta (when he has finally located it) and even the time wasted sorting through 200 prepacks of onions trying to find one that has onions of relatively even size pale into insignificance compared to the gigajoules of stress arising from the 20 minute totally non-productive wait in the queue.  

As a progressive, forward thinking, altruistic organisation with absolutely no motives other than superlative customer service, SuperMegaGreenFresh Inc has commissioned your company UML-R-US to determine the requirements for a new system that will totally annialate the Saturday queues.

SuperMegaGreenFresh Inc has just finished a gazillion dollar grocery chain ERP project that has revolutionised the behind the scenes operations (that's revolution as in violence and overthrow of the ruling class - the prior IT manager was tarred, feathered and ridden out of town on a rail). So don't even dream of suggesting any changes that go beyond front of house.

The CEO has made it absolutely clear that any and all solutions are viable - change the business model if necessary (Vegetables-Over-IP?)

So you pack Jerome Wizkid off down to do the use case modelling.  Let's hope he returns with something better than
UC1: Enter store
UC2: Walk Aisles
UC3: Select groceries (extends Walk Aisle)
etc
and lets also hope he returns with something better than
UCx:
Scenario 1: Buy peas
Scenario 2: Buy ham
Scenario 3: Buy asparagus
Scenario 4: Buy peas and ham
Scenario 5: Buy ham and asparagus
.....

that's all


bruce

[Ilja Kraval]

For level of abstraction Analytical Modeling is also used short title „ analysis", but it can make confusions: At some time underneath concept analysis hides so - called enterprise modelling, i. e. BUSINESS MODELING (BM). Also in this case we say "modeling", but it differs from the analytical modeling AM in principle in subject of modeling, i. e.  what as a matter of fact modeling: BM = the subject is enterprise (business), AM (with USE CASES) = the subject is system. The "USE CASE MODELING" is about system, not about business. The relation from UC to BM is only one - in answer "how USE CASE (of system) supports BUSINESS PROCESS (from business)". We must be very carefull in recognicition "where we are" - in BM or in UC modeling.

It is important question, what is BUSINESS PROCESS (business area) and what is USE CASE (system area) in the first question from "nifsmith".

[nifsmith]

Oops seem to have opend a wound with this one.

I may not have explained myself properly in my first post. The examples I used were not even close to being real.

I was trying to discuss the relationship between a Use Case Description and a Use Case Scenario as I had been taught.

The detail I should have highlighted was that a Use Case Description is all about the User, the System (abstract descriptions) and a Use Case Scenario is all about, Bob and £1.00s and Whiskers the Cat (real life examples, values) which can be used to test the Solution.

In the event that this is standard practice (maybe!) how should I record this in EA. Would it be better to contain the abstract Description in the Notes and the Use Case Scenarios in Scenarios. Or I was toying with the idea of putting the Scenarios in a test case which <<tests>> the relevant Use Case.

Contrast and discuss.

TYIA

nifsmith

[thomaskilian]

The detail I should have highlighted was that a Use Case Description is all about the User, the System (abstract descriptions) and a Use Case Scenario is all about, Bob and £1.00s and Whiskers the Cat (real life examples, values) which can be used to test the Solution.

Not correct, still. A UC description is an abstract of the use case (about the Actor(s) and what they ought to do). A UC Scenario is the same with each and every detail (still the Actor, not Bob!). You have the sunny way (basic path) and a lot of alternatives/exceptions. I personally use the scenario tabs in the UC and some home brew script to get the description as text for the 'users' (aka Actors).

Bob and his 1 Pound are for Test Cases.  Here you actually name and quantify things.

[sargasso]

We must be very carefull in recognicition "where we are" - in BM or in UC modeling.  

me culpa!

but IMO the distinction between the two in practical terms is often lost due to the project environment, culture and history.

While this industry may preach structured methodology, economic constraints on an endeavour usually exist and the first victim is a structured approach to requirements definition.  
A system cannot exist without a business context.  Yet the first assumption made is that the business model need not be formalised for the benefit of the system designers, usually as a result of the "it is intuitively obvious to even the most casual of observers" syndrome.

IMO it is not.  I have two recent experiences of this.  In my current environment, the workplace practices have developed to cope with the inadequacies of the existing system to the point that the formal Business Rules Manual represents around 20-25% of the usage rules of the system.  The remainder is legislated in "folklore", process and procedural rules passed down from senior to new users as and when the situation arises that requires a folkrule to be applied.
As a result, the replacement system design - contractually constrained and quoted from the Business Rules manual - has re-implemented the same level of business solution.  Further, due to the features of the new system, certain folkrules cannot be enacted by the users.  Result - the new system is "worse than" the old one.  Business response - the designers got it wrong!  Outcome - re-analysis of existing workplace practices with view to re-formalising the  system requirements.  Cost overrun - 60%.  Note well - they are still not formalising the business model!  They have just expanded the scope of the system model analysis to include research into what really happens at the shop floor level.

Previously, at another place, with both a business spec and a system spec that appeared bulletproof there was an example where the designers and builders implemented the formally expressed truth.  However, I as the acceptance manager just sensed that "something was wrong" in one particular area.  I spent some time tracking down the one person in the organisation that knew the real truth, not just the formal truth and yes, something was wrong.  It was not only wrong at the system level, it was wrong at the business and in fact at the industry level.  The industry had formalised an event notification diary - this was used to cut over from one pricing methodology to another.  The structure, use and method of applying the diary was well documented across both the industry and the business.  The real truth, as expressed by the one person that knew, was that the event notification only happened at the occurrence of the event and no prior notice was given.  The system, on the other hand, needed to know a minimum of 24 hours ahead and preferrably several weeks ahead.  This fact was "fudged" into the existing system manually by this person - in fact it was done the same way that she had done it in all the systems
she had worked with in the industry - in fact the same way "everyone" in the industry did it.  I repeat, the business and system specs were bulletproof, and the new system implemented them as spec'd.  I asked her informally why she didn't raise objection when she first saw the system spec's (as she was a reviewer) - her reply, "It didn't seem important".  Result - a significant portion of a $4m development project was spent implementing functionality that would never be used, and which was in fact legally right but logically wrong.  Outcome - no change.  I guess they'll do it again next time too!

So, although I agree, Ilja, I really cant see that you can ever separate the two as clinically as you suggest.

bruce

[Ilja Kraval]

Hi bruce,

I agree , but it is a little misunderstanding.

I assert, that the two models BM and UC must be strictly separated like two models in UML in 2 PACKAGES.  One is about business, the second is about system. Only one connection is by way of diagram, where Dependence occurs among some BP and some UC (see whitepapers EA pages ). However both separated models BM and UC is necessary to create at the same time in "one’s second":  "what is happening in BM" and "what asks system - UC" is determined together and in one moment. Two models rise step by step together. I have very bad experience from practics "first do great BM" (for example 2,3, 6- months for great enterprise) and then create UC. On the contrary: Two models are separated, but must be created at the same time. Otherwise very much work  in BM will go out on ruin.  

Two reasons exist for those matter: First, it is strong feedback between BM and UC. According to of what we accept as solution in UC, so by return it will strongly influence to BM (in behavioral of business).  Second: Creating BM without UC is able to give us to very many uninteresting blind streets irrelevant for future SW system.

[Paolo F Cantoni]

Ah... Grasshopper,

Yes, there exists a Business Model and System Model but both must exist in a World Model...

When one has contemplated the World Model one can come to the conclusion that most management and domain experts have some knowledge of their own area, but precious little outside it.  Also, get three domain experts in a room and you'll have 5 views...

Consequently it is not possible for them to correctly describe their needs and requirements in the context of the world.

My experience has been to:
1) Model the world (to get everyone to agree what they see out of the window)
2) Check the business view (what I call business imperialism) against the model and help the business folks adjust their distorted view to reality.
3) Check the system view against the refactored business view.

As Ilja is saying (I think) - ALL of these models need to be developed simultaneously - since what appears to be OK in one will be "found out" in another.

Keeping them all in synchronisation is the key...

In the case of the world model, after a while you don't need to recreate this from scratch since it doesn't change that much.  I have some models that haven't changed much over ten years.

I can empathise with bruce's experiences.  Often times, I've viewed my role as a conceptual modeller not so much as doing things, but of stopping others doing the wrong things.

In my experience most projects and systems fail not due to technological issues, but ill formed requirements and failure to consider the ultimate user well.  See bruce's excellent examples.

Management is always trying to keep things simple - but only end up making things simplistic - note carefully the difference in those two words.  Many people can't tell the difference and use simplistic to mean simple.

Rather, listen to the Einsteinian dictum:  "Keep things as simple as possible - but no simpler!"

You need a good world model to do it right.  From my experience, the triple model (there it goes again bruce! ) is the only mechanism that works...

Model, Model, Model ^TM

Paolo

Sorry for the diatribe, but I'm currently taking a few days off at New Norcia - Australia's only monastic town... http://www.newnorcia.wa.edu.au and the contemplative nature of the place must have got to me...
BTW: this is coming up on a satellite uplink and response is pretty good!

[sargasso]

Also, get three domain experts in a room and you'll have 5 views...

Actually there are 9.




bruce

[Paolo F Cantoni]

Actually there are 9.

 

bruce

Ah  bruce... you've (correctly) added the ones that change over time...

But seriously, and this is particularly for those who are new to this lark.  We can (and do) debate about which is the best methodological, epistemological, syntactical and other 'ical approaches to the problem of creating a system that works (once you define what works means... ).

But as bruce has so cognently reminded us, it really comes down to asking the right people the right questions at the right time and understanding the import of what they say  - even if they don't!

So are there any tricks of the trade?  Well, in my view, yes!

From my tag line and signature (and my postings herein), you'll see I stress the importance of consistency.  Whenever you find an inconsistency - investigate it until you have restored a suitable (you'll have to be the judge of that) degree of consistency.

In my experience, there are levels of inconsistency that are markers for where and when to look:
Multiplicity of associations:
Business model says one-to-many world model says many-to-many.
Business model says binary association, world model says n-ary.
Business model says requires n attributes will generate a unique domain key, system model indicates you'll need n+x attributes to achieve identity.

I'll let others add some more if they wish.  The key point I want to re-iterate is that by creating all three models at (about) the same time and trying to keep them in synchronization you stand the best chance of getting to the bottom of the "truth".

Finally, if the model fails "first principles" then it's most likely wrong...

Here endeth the lesson...
Paolo

(It must be all these bendictine monks... )