Use Case Writing Question

[Gary W.]

Hi,

I'm mentoring a group of 4 BA's, none of which have much experience with the more modern methods (i.e. anything using UML).

I've successfully moved them off of function decomposition, too-high policy descriptions, and too-low system interaction descriptions.

However, as they got deeper into Use Case writing, I saw examples of related (but not directly relevant to the use case goal) behavior, or re-usable behavior that is part and parcel of multiple (base) use cases.

So, I introduced <include> and just recently, <extend>.  But now I see in their UC diagrams a whole spider-web of things.  I see hints of 'screen navigation', but also hints of 'functional decomposition' creeping back in.

The client won't allow state transition diagrams, or 'special requirements' sections in the Use Case template; or indeed, even in the overall Analysis document.

I acknowledge that there are aspects of 'screen navigation', and 'business rules' that require documenting, but they're cluttering up the Use Case text!

I've got the BA's to put such content into a 'notes' section of each Use Case, but now the Notes is 2-3 pages long (while the UC main flow and alternate flows are only 1-2 pages long).

I just introduced the 'system boundary' box, which allows them to group related use cases together.  They STILL want to put <extend> between them, as it "... helps them to see how they interrelate...".

Any advice?     :-/


Thanks,
gary

P.S.  Can anyone direct me to any good and up-to-date "use case writing" discussion forums and/or mailing lists?

[«Midnight»]

Check this forum - use the search function and be persistent - for an ongoing thread regarding this. I think the thread subject may have mentioned Java, but the content is general.

There are many other threads here dealing with this. Search and see.

[sargasso]

...or, pick one culprit and kill him. In front of the others.  

They are not analyzing, they are designing.... and worse still from preconceived notions of what the solution is going to be.


To be serious....  
Try a morning session of "No more extensions and inclusions"
followed by a 1 hour max, group grope of factoring common behaviours.  Let no common behaviour be defined further than a sketch. Then get them to go back and reduce the morning's work by adding extends and includes and cutting the main text into their own personal version of the skeletons.  The reconvene and compare the different versions.

Goal: Get them (or at least the remaining three) to understand how to use UML to SHORTCUT, not EXTEND and CONFOUND, the effort of producing a concise view of the ....


...wait for it....


behavioral [glb]requirements[/glb]

of the system.



_{Other than that, just kill the lot of 'em.}

bruce

[thomaskilian]

So, I introduced <include> and just recently, <extend>.  But now I see in their UC diagrams a whole spider-web of things.  I see hints of 'screen navigation', but also hints of 'functional decomposition' creeping back in.

Silly you.

Go and buy them Bittner/Spence Use Case Modeling. On page 17 they will find why it's not UC Analysis but Synthesis. It takes some time to digest it, though.

[Gary W.]

Silly you.

Yes, you are correct in your assessment.  

Luckily, I had forewarned them that I might revise the instructions if they complicated matters rather than moved the analysis forward.

So, I met with them today and took away the <extend>, but allowed them to link a use case to another if it was REQUIRED to satisfy the goal of the base use case (i.e. <include>).  I reiterated my earlier instruction to use a 'system boundary box' to group related use cases together, but since they cannot use <extend>, these UC bubbles will be unconnected.

They heard me this time and it sunk in (yes, everyones' advice to threaten bodily harm worked GREAT).  

Go and buy them Bittner/Spence Use Case Modeling.

I recently googled "Use Case Modeling" by Kurt Bittner and Ian Spence, and it looks good.  I've been using Alistair Cockburns book, and apparently Bittner/Spence is compatible with Alistair's approach.

I'll pick up the book for future reference, as it'll be too late to apply to my current situation.  As for asking them to read it now, well, they're already behind the eight-ball and in fact wanted to skip over some things just to make their deadline.  So... I'll wait until they pass their deadline before suggesting this.

Check this forum - use the search function and be persistent - for an ongoing thread regarding this. I think the thread subject may have mentioned Java

I'll try again.  The search facility doesn't seem to recognize double-quotes around 'exact match'.  So putting in
"use case" java

... treats it as three distinct words.  Putting in "use case" as a phrase is better but then I don't get the "java" keyword in there.

I will try again.. one thread "Re: UML book recommendations?" looks promising but I'll have to be get back to this later on in the week.

Thanks to everyone for their help.. it made a difference.  

gary

[thomaskilian]

Hi Gary, I think you're on the right track And regarding the forum search: this is getting a PITA. There are likely too many forum entries to be handled correctly by YABB. I often did not find my own threads, *knowing* they must be there. So good luck in searching the forum and of course with your analysts.

[«Midnight»]

I'll pick up the book for future reference, as it'll be too late to apply to my current situation.

Fortunately (or unfortunately, rather) this is the kind of situation that will come up again. You'll get your money's worth.

As to your crew, they'll end up saving big money by rushing if they're lucky. But it'll never be enough to offset what it is costing them. [Sorry, just my Project Manager experience causing me to vent a bit there.]

David

[sargasso]

  Good on ya!

A final clue, keep a chainsaw under your desk.  When they walk in and say "but how am I supposed to specify this piece of the design/UI/function" .....

Getting the basics, i.e "What is this system suposed to do?"  Is the hardest lesson I have had to learn.  But, once you learn it, it flows, it just flows, through the entire dev cycle. Twice in my life (as a test manager) I have been "blessed" with a decent, comprehensive model of what the heck it is that this thing is supposed to "do".  Every other time , (> 99^3) I/we (the testers) have had to create some sort of model of the same.

At (99^3)-3 project, we started with 30 unique (well analysed) use cases. On delivery, we found that we only had  21 to test. (Analysis: a) 1 "non-use-case" due to a poor expression of a function that was precluded by the system design, and b) 8 pieces of non-delivered functionality.    

By test cycle 4 there were ~60 use cases!  WHAT?  Yes,60. It happened because the non-delivered functional requirements actually generated the doubling of the use cases. Further, it ahppened because the requirements "were too hard to analyse and design at the same time"  (This is an actual quote from the software development organization's project manager!!!!!)

best of luck

bruce

[uniq]

It seems to be a problem of figuring out what use cases are in scope vs. how to write them. A lot of reading at this stage will confuse and slow down most of BAs.

Tell them to make sure that each concrete use case has a business goal that is complete. This will allow to easier spot partial use cases, i.e. decompositions. Start with the goal and keep the goal in mind all the time, like a target, while writing a use case.

Alex

[Gary W.]

It seems to be a problem of figuring out what use cases are in scope vs. how to write them. A lot of reading at this stage will confuse and slow down most of BAs.

Well, both "in scope" and "how to write" are (part of) the problem.

And, some people just are too set in their ways.  Of the team 's original 4 members, one was transferred out because it turned out he had little Analysis experience *period*, let alone Use Case writing.  

Another one, when offered (by his manager) a 'checklist of things to keep in mind' (e.g. like your 'keep the goal in mind all the time' advice) acted like it was beneath him and said '.. don't need it....'.

Sigh...
gary

[thomaskilian]

I recommend always to read DeMarco. That makes me laugh instead of sigh about that kind of things...

[jeshaw2]

Another one, when offered (by his manager) a 'checklist of things to keep in mind' (e.g. like your 'keep the goal in mind all the time' advice) acted like it was beneath him and said '.. don't need it....'.  

I was mentoring a project team who had a similar arrogant analyst.  He rejected all of my advice and went his own way. After all, HE had read Jacobson's first book on use cases written way back when... To my dismay, senior management, thinking him to be a "good ole boy", knowingly allowed this to happen!  As a direct result, the project was a total disaster and failure;  the client ultimately sued for and won $6 mill in damages.

[PaulH]

The other book I find useful is Use Case Patterns - similar vein to Cockburn, but a bit more chatty.

Paul

[«Midnight»]

I too have had a look at 'Patterns' and concur with Paul. It makes a good match with Cockburn, which it uses extensively as background material.

David

[Gary W.]

The other book I find useful is Use Case Patterns -

Do you mean "Use Cases: Patterns and Blueprints" by Overgaard & Palmkvist?  Or did you mean "Patterns for Effective Use Cases" by Bramble & Cockburn & Pols?

FYI, since I started this thread I should update everyone  that the team (of 3 now, not 4) is doing much better at writing use cases.  Even the guy that didn't initially accept advice is on-board now.. .we've teamed him up with one of the more senior BA's and they're writing *his* use cases together.

We still get slight differences in writing style between the 3 BA's but I don't see how this can be avoided.  We'll fix this up later where *one* senior BA skims through all the text and looks for inconsistent sentence structure or inconsistent terms.   As a bonus, they've finally agreed to draw up a 'glossary of terms';  it was a no-brainer to me to have such a glossary, but this team had to be convinced of its value.

Thanks again to everyone who contributed to this thread,
Gary