wood burning stoves 2.0*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Identifying  use cases Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Identifying  use cases" Watch "Identifying  use cases" New topic
Author

Identifying use cases

Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

how to identify use cases?


Groovy
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
This is the heart of analysis.
Talk to users and other domain experts. If there is an existing procedure or system (manual or otherwise) in place, read its documentation, and talk to support and QA (test) staff. Study the problem the system is intended to solve.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Wilfried LAURENT
Ranch Hand

Joined: Jul 13, 2001
Posts: 269
A lot of books are dealing with this matter. Most of UML related books have a chapter dedicated to use cases:

UML Distilled (Chapter 3)by M. Fowler (This chapter was formally available on-line as sample chapter, but it seems that it is no more the case. Has somebody still an active link?)
Writing Effective use cases by A. Cockburn
for example to name the majors.
W.
[ September 16, 2002: Message edited by: Wilfried LAURENT ]
Hari babu
Ranch Hand

Joined: Jun 25, 2001
Posts: 208
Hi,
IMHO, as the name suggests, find how the system/application is going to used and the who uses the system, depict the same.
Hari
Wilfried LAURENT
Ranch Hand

Joined: Jul 13, 2001
Posts: 269
A sample of Alistair Cockburn's book is available on-line on his site.
If you read this sample, be careful. After reading it I bought the paper version
W.
Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
Hi Pradeep,
First you will need either a Software Requirements Specification document ( or similar) or someone who knows the problem domain to tell you what the proposed system needs to do.
Then find the roles of people or systems that will interact with your system. These are called actors.
For each actor determine what they want the system to do for them (in only a few words). These are the use cases.
Regards,
Fintan

Originally posted by Pradeep Bhat:
how to identify use cases?
Dilip kumar
Ranch Hand

Joined: Oct 16, 2000
Posts: 360
Most of the projects will be developed based on Technical Specification and Functional Specification documents. How was wondering how Use Cases will add value to this process.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
If your specification documents already discuss how a user will interact with the software, and the results of user actions, then they already include some form use cases. If your specification documents don't cover this, then you probably need extra use cases to fully specify the interface and behaviour of the system.
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
Wilfried,
Thank you much for the link to Alistair Cockburn's book (draft 3). I'll be up all night reading it, but I'll be glad I did so two or three days from now when I've caught up on some sleep. (Can sleep be caught?)


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920

John Lindwall
Ranch Hand

Joined: May 29, 2002
Posts: 31
I sometimes wonder how detailed to get. For example one example that users can do in our system is CRUD (create, retrieve, update, and delete) a "Patient" record.
Is this one use case, ie "Manage Patient Data" or 4 ("Create Patient", "Retrieve Patient", etc)?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by John Lindwall:
I sometimes wonder how detailed to get. For example one example that users can do in our system is CRUD (create, retrieve, update, and delete) a "Patient" record.
Is this one use case, ie "Manage Patient Data" or 4 ("Create Patient", "Retrieve Patient", etc)?

Remember that Use Cases (like any other form of formal and non-formal documentation) is for communication between people.
So ask yourself: Who will read those use cases? Will they know what you mean by a "Manage Patient Data" use case? If not, could they easily ask someone or find the info somewhere else? With other words: which granularity will be most valuable to the target audience?
Sorry, but I don't think that anybody in this forum is better suited to answer your question than you yourself...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Ilja, while your point is strictly true, there are some guidelines that apply generally. Remember that a Use Case represents a specific conversation between a computer and an actor. "Manage Patient Records" isn't a conversation. You can't write out a dialogue for it. On the other hand "Add a new patient" or "Remove an incorrect patient record" are things you can write dialogues (and thus use cases) for.
Kyle
P.S. You will get a LOT out of the wonderful new book by Steve Adolophe and Paul Bramble (with Alistair Cockburn) called Patterns for Effective Use Cases. It's loaded with example Use cases and guidelines on writing your use cases.


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Kyle Brown:
Ilja, while your point is strictly true, there are some guidelines that apply generally. Remember that a Use Case represents a specific conversation between a computer and an actor. "Manage Patient Records" isn't a conversation. You can't write out a dialogue for it. On the other hand "Add a new patient" or "Remove an incorrect patient record" are things you can write dialogues (and thus use cases) for.

I disagree. A Use Case is an abstraction of a bunch of related Use Case Scenarios ("conversations"). The needed granularity of Use Cases will depend on how many details you have to put into them. The less details are needed, the more scenarios can get lumped together under one common heading.
In some projects, only writing down the main scenario in one to two sentences might totally suffice (A. Cockburn likes to call this "two bit precision Use Cases") - in such a case "Manage Patient Records" might be a reasonable thing to write down. The details might be communicated by direct conversation and/or automated test cases, for example.
Wilfried LAURENT
Ranch Hand

Joined: Jul 13, 2001
Posts: 269
I think Ilja is right. Use cases can be found at different level of analysis.
You could start with a coarse use case "Manage patient data" to describe a bulk activity, only with the main flow of events (For example for communication purpose between the client and the specification team
Then this use case can then be rewritten at a finer level of details for communication between the with the integration team for test purpose.
W.
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Arrggh... This is a horrific use of use cases. The problem is that good intentions NEVER work out in practice. Use cases should ALWAYS start out specific. Here's my main question -- do you people draw the pretty little bubble diagrams, or do you do the TEXT (the ACTUAL honest-to-goodness USE CASE) first? If you're doing the bubbles first, you're totally backwards.
Just as in design, abstraction in use cases should proceed bottom-up, NEVER top-down. Do the specific cases first. If you decide you want to refactor it into a higher-level scenario later, that's OK, but please don't say that "Manage Patient Records" is a use case in the first place! The value is in the text -- not in the little bubble-and-arrow diagrams!
Kyle
Wilfried LAURENT
Ranch Hand

Joined: Jul 13, 2001
Posts: 269
At least we agree on one point . The Use case UML Notation is totally useless and misleading.
Sorry if I misunderstood. I was not talking about top-to-bottom refinement in use cases, while staying at the same level of analysis. I was evoking the different scope (Don't know if this is the right word... The shell, the fish, the waves in Cockburn notation) of use cases.
What I meant is that you do not use the same vocabulary if you use "use cases" to communicate with your client or if you use "use cases" for intrateam communication.
W.
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Thanks for the clarification Wilfried. Yes -- I think that we're getting back to the original question now. We all seem to agree that you start with concrete things, and that the abstract will emerge from the concrete over time. I think we also agree that there are different levels of detail for different groups.
So to get back to our original question:
"Manage Patient Accounts" is probably something that won't (or shouldn't) be a use case you'd initally try to find. It might emerge later, but the kind of thing you'd initially look for are the more active scenarios like "Take on a new Patient", "Issue a bill to an existing patient" and so on...
Kyle
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112

Just as in design, abstraction in use cases should proceed bottom-up, NEVER top-down.

Why?

The value is in the text -- not in the little bubble-and-arrow diagrams!

The real value is in the understanding you get from the use cases, so it seems to me. I totally agree that bubbles don't add much to the understanding. But there are projects where text doesn't add much, too - where the main value comes from the *conversation* accompanying hammering out use cases.
It also depends on how much information is needed at which point in time: For example to implement a use case you need much more information than to estimate its complexity. If you can easily access that additional information later, it wouldn't be necessary to put it into the use case.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Ilja Preuss:

Just as in design, abstraction in use cases should proceed bottom-up, NEVER top-down.
Why?

Let me elaborate my question: For me, the most effective (and most natural) way to analyze requirements (wether by use cases or by other means) is to go from the well-known to the unknown. The important thing at the beginning is to get started fast - you can adjust granularity later, while you learn what information you really need and which just adds clutter, so it seems to me.
What am I missing?
[ September 26, 2002: Message edited by: Ilja Preuss ]
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Originally posted by Ilja Preuss:

Let me elaborate my question: For me, the most effective (and most natural) way to analyze requirements (wether by use cases or by other means) is to go from the well-known to the unknown. The important thing at the beginning is to get started fast - you can adjust granularity later, while you learn what information you really need and which just adds clutter, so it seems to me.
What am I missing?
[ September 26, 2002: Message edited by: Ilja Preuss ]

Well, unless you are a domain expert in a particular field when you start your analysis, you will inevitably discover the real abstractions only after trial and error. If you try to identify the "general" cases first you will always miss the exceptions to the rules that make the rules you assumed would work fail.
Proceeding from the known to the unknown is fine, but you can't go from "general principles" to specifics. In most cases have to start with the specifics and then derive the general principles from them.
Kyle
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Kyle Brown:
Well, unless you are a domain expert in a particular field when you start your analysis, you will inevitably discover the real abstractions only after trial and error.

Yes, having as direct access to domain knowledge as possible is critical.
If you try to identify the "general" cases first you will always miss the exceptions to the rules that make the rules you assumed would work fail.

So you shouldn't assume that they work, but consider that they are not much more than rough first guesses at the beginning. Does that constitute a problem in your eyes? Do you see any value in having a bunch of high level use cases at hand early?
Wilfried LAURENT
Ranch Hand

Joined: Jul 13, 2001
Posts: 269
Ilja wrote:
So you shouldn't assume that they work, but consider that they are not much more than rough first guesses at the beginning. Does that constitute a problem in your eyes? Do you see any value in having a bunch of high level use cases at hand early?

Sometimes when you get requirements from the client (or the marketing department), they are -um- quite tiny. You start with this specifications, trying of course, Kyle, to be as specific as authorized by the given spec. So, it is highly possible that, at first, you can not get further than a "Manage patient data" use case (it may that the terminology "use case" in that case not adequate). So what does the marketing or the client mean by this specification?
Then it is while discussing with client and expert domains, that you can make some points clear, avoid traps and discover exceptions to the rule.
W.
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Ah, but that's the problem. If all you have is the phrase "Manage Patient Data" you do not have a use case. You have a placeholder for a use case. Only in the case that you actually have the description do you really have a use case...
Kyle
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Kyle Brown:
Ah, but that's the problem. If all you have is the phrase "Manage Patient Data" you do not have a use case. You have a placeholder for a use case. Only in the case that you actually have the description do you really have a use case...

My point is that it doesn't have to be a *problem*. Wether you call it a use case or not, there are cases were writing down "Manage Patient Data" totally suffices for the moment.
Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
Originally posted by John Lindwall:
I sometimes wonder how detailed to get. For example one example that users can do in our system is CRUD (create, retrieve, update, and delete) a "Patient" record.
Is this one use case, ie "Manage Patient Data" or 4 ("Create Patient", "Retrieve Patient", etc)?

Hi John,
Unfortunately, the answer is it depends!
When I started doing Use Cases I put all CRUD into one use case, e.g. Maintain Patient. I chose one of the CRUD cases as the Basic Flow ("Happy Path"). Normally it was the update as that is the most complicated, but it does not have to be. The other 3 were detailed as Alternative Flows.
Recently, we had a specification where the team found itself going around in circles trying to fit the CRUD use case into one use case. Guess what? We split it into 4.
Nothing is cast in stone,
Fintan
Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
Originally posted by Kyle Brown:
Just as in design, abstraction in use cases should proceed bottom-up, NEVER top-down. Do the specific cases first.
...
The value is in the text -- not in the little bubble-and-arrow diagrams!
Kyle

Hi Kyle,
Do you write your code before you do your design because the value is in the code and the code is more specific
The answer to this "bubble first then text" approach is FEEDBACK. Do your General cases first and when you discover something that you had not considered go back and rethink! This way you have a workable starting point and a framework for discovering more of the specific cases. When you have discovered more specific cases you can change the "bubble diagram".
I find that even when the use cases are finished (during test planning and design) that scenarios that have been overlooked in the use cases can crop up. We make changes and follow them through. (Admittedly, it would be ideal if we got every single scenario right first time, but then not everyone is Einstein )
Regards,
Fintan
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Do you write your code before you do your design because the value is in the code and the code is more specific?
I don't know if Kyle does, but I know that I often do! This is the heart of something called test-driven development (TDD).
The way it works is essentially:
  • Get some sort of requirement or user story. Choose one aspect of it that you wish to implement.
  • Write the simplest test you can think of to test some of the desired behaviour. Note that this test will almost always fail - there is no code to make it work yet!
  • Write the quickest and simplest code you can to make that test pass, even if it means cut-n-paste or returning hard-coded constants. Book this in to your version-control system; you have added a feature!
  • Using the test from (2) (and all previous tests) as "scaffolding", refactor the whole system to simplify and remove duplication. Book this in to your version-control system; you have made the system maintainable again!
  • go back to (1).


  • Note that the "design" happens a little bit at stage (2) as you decide what the public interface for your new feature will be, but mostly at stage (4) as you improve the implementation until you can't make it any better.
    Did you mean your original comment sarcastically ?
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Just some additional comments on test driven development as presented by Frank:

    Write the simplest test you can think of to test some of the desired behaviour. Note that this test will almost always fail - there is no code to make it work yet!

    In a statically typed language like Java, the test might even refuse to compile, as the classes/methods tested even don't exist...
    Write the quickest and simplest code you can to make that test pass, even if it means cut-n-paste or returning hard-coded constants. Book this in to your version-control system; you have added a feature!

    ... therefore this might be a four-step process: first make the test compile by providing minimal stubs of the used classes/methods; second experience the test run, but fail; third fill in the minimal implementation to make the test pass; finally experience the test passing.
    Did you mean your original comment sarcastically ?

    I didn't understood it to be sarcastic, though I suspect he expected Kyle to answer with "no"...
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Fintan Conway:
    Do you write your code before you do your design because the value is in the code and the code is more specific

    As might already be obvious, *I* do both at the same time, in a similar way to Frank...

    The answer to this "bubble first then text" approach is FEEDBACK. Do your General cases first and when you discover something that you had not considered go back and rethink! This way you have a workable starting point and a framework for discovering more of the specific cases. When you have discovered more specific cases you can change the "bubble diagram".

    Though I agree with the fundamental idea of this paragraph, I think that there are much more effective means than "bubble diagrams" for this stage of analysis.
    For example, by replacing each bubble by an index card, you can get a much more dynamic process of analyzing requirements - it is very easy to remove cards, add new ones, shift them around on the table, sort/group them by different means etc.

    Admittedly, it would be ideal if we got every single scenario right first time [...]

    Would it???
    It seems to me that that implies that
    - you didn't learn something about the project while implementing it
    - the users didn't learn something about their requirements or enhanced their vision by seeing/using an early version of the product
    Does sound like a boring project to me, and also not like a rewarding one...
    [ October 11, 2002: Message edited by: Ilja Preuss ]
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: Identifying use cases
     
    Similar Threads
    Business Use Cases versus System Use Cases
    Question in Part II
    Use Case Preparation.
    Requirements clarification
    Test-Driven Development