Author Topic: Describing use cases.. which way to go?  (Read 2122 times)

mhdhallak

  • EA User
  • **
  • Posts: 43
  • Karma: +0/-0
    • View Profile
Describing use cases.. which way to go?
« on: May 30, 2006, 02:21:05 am »
Hi everybody

I'm facing little delimma deciding which is the most appropriate way for me to describe my use cases in full details. I know this has been the topic of a previous thread (Recording Detailed Use Cases) but I'm still unsure of the most appropriate and efficient method to capture the innerworking of my use cases.

I have checked the EAExample project (that's shipped with EA) and quite frankly it's a bit confusing because it lacks consistency in the way it describes its use cases. Sometimes it does so by a communication diagram, other times by a sequence, and others by Activity diagrams.

My question is: which is the most appropriate diagram for describing the usage scenarios? Given the fact that textual description of use cases is unwanted as it's implementation in EA is very lacking, I'd like to stick to diagrams for this purpose.

Any help would be appreciated.

Thanks alot.

AL
« Last Edit: May 30, 2006, 02:23:49 am by mhdhallak »
Thanks

AL

thomaskilian

  • Guest
Re: Describing use cases.. which way to go?
« Reply #1 on: May 30, 2006, 04:25:12 am »
Well, of course it depends. Communication diagrams are also called Robustness diagrams in this context. You give an overview on how the Actors and business objects communicate with each other. An Activity Diagram can be used as replacement/supplement for the scenarios. There is one thread where one of the users tells that he does not wirte UC scenarios. But instead Activity diagrams are drawn and the docu is genarated using an add-in. As I sayed, it depends. Speaking for myself, I perfectly lived without any diagramming by just writing UC text. Until now this proofed to be the best way for me. Others have different opinions. So my advice: just give it a try and do not stick to any paradigm except those you found to work for yourself.

mhdhallak

  • EA User
  • **
  • Posts: 43
  • Karma: +0/-0
    • View Profile
Re: Describing use cases.. which way to go?
« Reply #2 on: May 30, 2006, 04:47:09 am »
Well thomaskilian that's exactly my concern. I have quite alot of use cases and if I were to go wrong in the first place there'll lots of redoing and rewriting which time won't allow.

On the other hand, are you suggesting that I try out a couplee of different techniques on a small scale (say like 2 or 3 use cases) and see which technique will do best for me and stick to it ?
Thanks

AL

thomaskilian

  • Guest
Re: Describing use cases.. which way to go?
« Reply #3 on: May 30, 2006, 06:30:42 am »
You never can avoid pitfall, that's one law of nature. My suggestion would be to stick to writing the UC either in Word or by using some of the previously disucssed techniques. Additionally you can add Activity diagrams where appropriate if this makes things clearer.

Creating a Robustness diagram (aka Communication) is (from my point of view) a must, since it clarifies much in the use of the whole system. You might start to sketch that as you evolve your UC documentation.

And yes: you should start with a few UC and see how things go on. You really need the right feeling - which you can't buy somewhere.

mhdhallak

  • EA User
  • **
  • Posts: 43
  • Karma: +0/-0
    • View Profile
Re: Describing use cases.. which way to go?
« Reply #4 on: May 30, 2006, 06:48:12 am »
I see. Well wadda hell I'll give a shot. My problem is I'm too hesitant trying to do things the right way the first time. But as you said, I can't always avoid pitfalls. So I'm willing to take the risks.

I already got some idea on how to approach this and I'll see where it goes.

Thanks alot.

AL
Thanks

AL

thomaskilian

  • Guest
Re: Describing use cases.. which way to go?
« Reply #5 on: May 30, 2006, 09:47:43 am »
Don't hesitate to ask on how to climb out of a pitfall whenever you fell in.

Weedman

  • EA User
  • **
  • Posts: 33
  • Karma: +0/-0
    • View Profile
Re: Describing use cases.. which way to go?
« Reply #6 on: May 30, 2006, 01:43:46 pm »
Al,

We do not write Use Cases any more. We do Activity diagrams. and generate Use case reports for the diagrams.

Of course we have defined what our use case report looks like, and put the appropriate text for goal statement, pre and post conditions, primary actor, dercription in the properties of the diagram and intial state of the activity diagram.

Each step in the diagram is numbered/identified so a bsaic/main flow is output. The Alternate flows are numbered/identified differently so they appear after the main flow and grouped together.

You can even pull in sub-activity diagrams where called in the main activity diagram, pull in screen shots, tables for additional details, link in requirements from your requirements view and have them appear where appropriate in the report.

Our BA's and users find this much eaiser to do than writing use cases. You can change a model/diagram much faster and easier than text. You can generate a report anytime you want and it reflects exactly what is in the model.

The report is genereated from a template so the same look and feel is achived for all use cases in the enterprise. Its also easier to control the level of detail includeed in the generated report for various audiances.


«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: Describing use cases.. which way to go?
« Reply #7 on: May 30, 2006, 02:05:25 pm »
Weedman,

When you say you "generate" the report from a "template" are you referring to generation from EA? If so, is this via the RTF report function, some other generation, or an add-in?

David
No, you can't have it!

Weedman

  • EA User
  • **
  • Posts: 33
  • Karma: +0/-0
    • View Profile
Re: Describing use cases.. which way to go?
« Reply #8 on: May 30, 2006, 02:54:32 pm »
David,

Its via EA at the moment. We are busy creating our own Use Case Report Template verses what is supplied by EA.

Jeff Weedman

«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: Describing use cases.. which way to go?
« Reply #9 on: May 30, 2006, 03:51:14 pm »
Jeff,

Will you still be reading the background information from the EA model, perhaps through an automation interface?

The reason I ask is that a while ago (version 4.1) I needed to build a small automation application to generate some complex document components in a business analysis context. I can see this happening again, but have not had the time to fully "grok" newer EA features in this light. I'm hoping to pick your (collective) brain here in order to save some 'crunch time' when decision time comes.

Thanks much,
David
No, you can't have it!

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Describing use cases.. which way to go?
« Reply #10 on: May 30, 2006, 04:40:05 pm »
Quote
I'm facing little delimma deciding which is the most appropriate way for me to describe my use cases in full details. I know this has been the topic of a previous thread (Recording Detailed Use Cases) but I'm still unsure of the most appropriate and efficient method to capture the innerworking of my use cases.


I've said this before and no doubt I will say it again and again.

1. There is no best way.

2. You do NOT have to describe each and every use case the same way.


3. IMO IMO IMO! The first thing to do is to LIST the success outcomes of the use case. Then list the relevant not successful outcomes.  If the use case is simple little else is needed, if its not simple then perhaps lots of accompanying models, documentation etc etc may be needed.

<begin parable>
OUATIALFFA there was a widget factory.  Most of the factory was automated but the actual packing of widgets into boxes for delivery was done manually.  The workers who made up the boxes were in one building and the workers who packed the widgets were in another.  Most orders were shipped in one or more of a set of standard boxes.  However there was the occassional order that required special individual packing.
Usually, the packers would yell across the path to the boxmakers something along the lines of "Hey Morg, I need 20 size KA's today."  But when a particularly difficult to pack order came in, the packer would have to fully describe to Morg exactly what they needed in order to pack the order.  This involved specifications, drawings and sometimes even prototypes.  An efficiency expert once suggested that each and every request for boxes be done in a standard and prescibed manner.  They laughed at him.
<end parable>

hth
bruce
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.