Weblogs Forum - Use Cases -- A minimalist's view.

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Use Cases -- A minimalist's view.

10 replies on 1 page. Most recent reply: Oct 9, 2003 2:06 AM by Deepak

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 10 replies on 1 page

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Use Cases -- A minimalist's view. (View in Weblogs)

Posted: Jul 2, 2003 7:38 AM

Summary
Use cases are a wonderful idea that has been vastly overcomplicated. The real trick to use cases is to _keep them simple_. Remember, tomorrow they are going to change.

The real trick to use cases is to keep them simple. Don't worry about use case forms, just write them on blank paper, or on a blank page in a simple word processor, or on blank index cards. Don't worry about filling in all the details. Details aren't important until much later. Don't worry about capturing all the use cases; that's an impossible task.

The one thing to remember about use cases is: tomorrow they are going to change. No matter how diligently you capture them, no matter how fastidiously you record the details, no matter how thoroughly you think them through, no matter how much effort you apply to exploring and analyzing the requirements, tomorrow they are going to change.

If something is going to change tomorrow, you don't really need to capture its details today. Indeed, you want to postpone the capture of the details until the very last possible moment.

Think of use cases as just in time requirements.

This blog is an excerpt from my latest book:UML for Java Programmers, Robert C. Martin, Prentice Hall, 2003. Click here for details.

Ernie Varitimos

Posts: 38
Nickname: erntheburn
Registered: May, 2003

Re: Use Cases -- A minimalist's view.

Posted: Jul 2, 2003 4:51 PM

...Over and over again I have seen teams sitting and spinning in their attempts to write use cass. Typically they thrash on issues of form rather than substance. They argue and debate over preconditions, postconditions, actors, secondary actors, and a bevy of other things..

This is largely due to the fact that most people don't like doing things that make them think about what they do, or do things that are outside their normal role or responsibilities. And they have a hard time believing that their involvement will actually affect the system being developed.

...
If something is going to change tomorrow, you don't really need to capture its details today. Indeed, you want to postpone the capture of the details until the very last possible moment.

Think of use cases as just in time requirements.

I'm sorry, but I simply don't agree with this notion. I do agree however that requirements change periodically, but that shouldn't shirk one's duty to capture the uses of the system the best they can in a consistent and disciplined manner. I have learned over the past 25 years of developing enterprise systems that it is the uses of the system that drive the architecture, or more specifically, it is the users use of the system that drives the architecture. Without a clear and concise understanding of the uses of the system, design is virtually impossible and development will never end.

-ernie

Marco Abis

Posts: 325
Nickname: marcoabis
Registered: Jun, 2003

Re: Use Cases -- A minimalist's view.

Posted: Jul 3, 2003 2:58 AM

I have learned over the past 25 years of developing enterprise systems that it is the uses of the system that drive the architecture, or more specifically, it is the users use of the system that drives the architecture. Without a clear and concise understanding of the uses of the system, design is virtually impossible and development will never end.

I think that what Martin wrote is just common sense: use cases will change (and users understanding too) as the system is developed so the wiser thing to do is avoid collecting and analyzing all the cases up-front. It's better to collect all the high level cases and then to delve only into cases you are going to implement in the near future (from one week to a month). Only the cases you really need to deliver the first, useful, increment of the product.

I don't really see any reason to spend a lot of time (and money, and effort) analyzing in great details all the cases up-front when you will, maybe, use them months later and they will be of course changed due to the fact that the system is growning and the users themselves are understanding much better what brings them value :)

Maurizio Turatti

Posts: 12
Nickname: mkj6
Registered: Jun, 2003

Re: Use Cases -- A minimalist's view.

Posted: Jul 3, 2003 7:51 AM

Today, after 3 weeks of development and just before releasing a stable prototype, we had to change completely the main use cases, because the customer wants a deep change in users's interaction with the system. As the use cases weren't too much detailed, we simply have not implemented many details yet, so we are not going to throw away half of the code, maybe only a quarter. Yes, use cases will change, that's for sure! YAGNI (You Arent't Going to Need It) it's often a good rule to follow...

Colin Davis

Posts: 1
Nickname: davco9200
Registered: Jul, 2003

Re: Use Cases -- A minimalist's view.

Posted: Jul 3, 2003 1:16 PM

I have to disagree as well.

The main objectives (as a project manager) that I see of Use Cases are
1) To establish a baseline to prevent scope creep (No, Bob, 'Advanced Search' wasn't included in your original request. Just basic search.) As clients knowledge increases, they forget (I think sincerely) what they originally asked for especially if the project spreads out over many months.
2) To get the client to think through processes. Most of the time clients have an overly simplistic view of the problem they are trying to solve. They don't think through questions like how should reports be updated, what are the error messages, what is required and what is optional, what do you have to have done before you can do this particular step and so on. The formal rigor required by use cases usually forces the client to think through the entire application as a whole not merely a "just in time" view.

I think that that most documentation is overkill and thus not used -- but that a coherent set of docs BEFORE coding starts seems to protect everyone from doing work and ahving to re-do it once the client re-freshes their mind.

And if they do, charge 'em. :-)

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Use Cases -- A minimalist's view.

Posted: Jul 3, 2003 1:18 PM

> ...
> If something is going to change tomorrow, you don't
> really need to capture its details today. Indeed, you
> want to postpone the capture of the details until the very
> last possible moment.
>
> Think of use cases as just in time requirements.
>
> I'm sorry, but I simply don't agree with this notion. I do
> agree however that requirements change periodically, but
> that shouldn't shirk one's duty to capture the uses of the
> system the best they can in a consistent and disciplined
> manner.

I quite agree with you. The requirements of the system must be captured in a consistent and disciplined manner. The issue is <i>when</i> that capture should take place. It is my position that the best time to capture the details of a requirement is just a few days before you implement it.

> I have learned over the past 25 years of
> developing enterprise systems that it is the uses of the
> system that drive the architecture, or more specifically,
> it is the users use of the system that drives the
> architecture. Without a clear and concise understanding of
> the uses of the system, design is virtually impossible and
> development will never end.

Again, I agree. However, it is my position that design is not a phase that is separate from implementation. Design and implementation are performed simultaneously, and are both driven by use cases.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Use Cases -- A minimalist's view.

Posted: Jul 3, 2003 1:50 PM

> I have to disagree as well.
>
> The main objectives (as a project manager) that I see of
> Use Cases are
> 1) To establish a baseline to prevent scope creep (No,
> Bob, 'Advanced Search' wasn't included in your original
> request. Just basic search.) As clients knowledge
> increases, they forget (I think sincerely) what they
> originally asked for especially if the project spreads out
> over many months.

I think "scope creep" is a bogus term. Customer's don't really know what they want until they see something working. Asking them to sign off on requirements that they haven't seen working isn't really very fair.

I understand the motivation. How can you tell them how much it will cost if they don't tell you what they want? The problem is that they can't really tell you what they want. Moreover, delivering what they asked for, when it's not what the really want, is not a solution.

So, I let the scope creep. I let the customers make any changes they want. I let them know how much each change will cost and I encourage them to make as many changes as they need.

> 2) To get the client to think through processes. Most of
> the time clients have an overly simplistic view of the
> problem they are trying to solve. They don't think through
> questions like how should reports be updated, what are the
> error messages, what is required and what is optional,
> what do you have to have done before you can do this
> particular step and so on. The formal rigor required by
> use cases usually forces the client to think through the
> entire application as a whole not merely a "just in time"
> view.

Again, the problem is that the processes change as the customer's view of the application changes. The best time to determine what the processes for a certain feature are, is when we best understand that feature -- and we best understand the feature immediately before we implement it.

> I think that that most documentation is overkill and thus
> not used -- but that a coherent set of docs BEFORE coding
> starts seems to protect everyone from doing work and
> ahving to re-do it once the client re-freshes their mind.

In my experience, knowing the requirements up front doesn't protect us from changes. The customer's want changes almost immediately.

> And if they do, charge 'em. :-)

Certainly!

Chris Dailey

Posts: 56
Nickname: mouse
Registered: Dec, 2002

Re: Use Cases -- A minimalist's view.

Posted: Jul 3, 2003 6:00 PM

So, I let the scope creep. I let the customers make any changes they want. I let them know how much each change will cost and I encourage them to make as many changes as they need.

But how do you know to charge them more if you don't already know what the baseline is?

Customer: "This is supposed to be included."

Developer: "But it's not in the original scope."

Customer: "Of course it was in the original scope. I shouldn't have to pay any more for that feature -- I've already paid for it!"

I think there are some issues at work here.

1. Is the CFO (either client or provider) going to sign off on a contract for $100,000 if the scope is not known? What is he/she signing that $100,000 for? Is it for $50K of work or $150K of work? Does it solve a real business problem?

2. What role do use cases play? My experience is that they are a tool to help define the scope of the system and find what was missing in the requirements document.

Sometimes, a price is decided upon, and then negotiation happens in the follow-up stages to decide how much that price really buys.

As a side note, do you know that Myers-Briggs personality type indicator test? The one with the four letters (e.g. I'm INTJ)? I think some of the aspects of deliberation in this thread are due to the last letter. P is perceptive, J is judgemental, which don't mean perceptive and judgemental. P tends to feel, "I don't want to decide now, because I limit my options.". J tends to feel, "I want to have things planned out and decided.". Things are usually okay with 2 Ps working together (though I think they would tend to be late), or with two Js working together (though the result would tend to be appealing feature-wise), but with a mix of the two ... there is some conflict.

Imagine a P and a J going on vacation. J: "We should stop at place X on this day, see the sites A, B, C, go to place Y the next day." P: "But what if we find out something cool in place X? Does that mean we have to go on to place Y?"

J: "Plan the work. Work the plan."
P: "Flexibility is king."

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Use Cases -- A minimalist's view.

Posted: Jul 4, 2003 9:10 AM

> So, I let the scope creep. I let the customers make any
> changes they want. I let them know how much each change
> will cost and I encourage them to make as many changes as
> they need.
>
> But how do you know to charge them more if you don't
> already know what the baseline is?

<ul>
<li>Charge by time and materials.</li>
<li>Charge a low time and materials rate punctuated by large milestone payouts.</li>
<li>Negotiate at the time of the change.</li>
</ul>
>
> Customer: "This is supposed to be included."
>
> Developer: "But it's not in the original scope."
>
> Customer: "Of course it was in the original scope. I
> shouldn't have to pay any more for that feature -- I've
> already paid for it!"

If you have a fixed bid contract with a customer that you don't trust, then you have to have the tightest requirements document you can get. i.e. those documents need to be in the form of automated tests.

On the other hand, if you trust the customer, and if the customer trusts you, then you don't need nearly the precision and formality. You can negotiate each misunderstanding in situ.

Here's another conversation.

"The system doesn't do what I want."

"Yes, but the system does what you specified."

"True, but it's not what I wanted, so I need it fixed."

"You'll have to pay for the change."

"Like hell I will. You're the expert. You should have known."

Getting a client to sign in blood for his requirements is no guarantee that you will build the right system, or that you will please the customer in the end. Pleasing the customer is a matter of establishing on-going trust.

> 1. Is the CFO (either client or provider) going to sign
> off on a contract for $100,000 if the scope is not known?
> What is he/she signing that $100,000 for? Is it for $50K
> of work or $150K of work? Does it solve a real business
> problem?

It is not uncommon for companies to sign T&M contracts, or contracts that have small T&M payments coupled with milestone payouts.

> 2. What role do use cases play? My experience is that
> they are a tool to help define the scope of the system and
> find what was missing in the requirements document.

They can be very good for that.

> Sometimes, a price is decided upon, and then negotiation
> happens in the follow-up stages to decide how much that
> price really buys.
>
> As a side note, do you know that Myers-Briggs personality
> type indicator test? The one with the four letters (e.g.
> I'm INTJ)? I think some of the aspects of deliberation in
> this thread are due to the last letter. P is perceptive,
> J is judgemental, which don't mean perceptive and
> judgemental. P tends to feel, "I don't want to decide
> now, because I limit my options.". J tends to feel, "I
> want to have things planned out and decided.". Things are
> usually okay with 2 Ps working together (though I think
> they would tend to be late), or with two Js working
> together (though the result would tend to be appealing
> feature-wise), but with a mix of the two ... there is some
> conflict.
>
> Imagine a P and a J going on vacation. J: "We should stop
> at place X on this day, see the sites A, B, C, go to place
> Y the next day." P: "But what if we find out something
> cool in place X? Does that mean we have to go on to place
> Y?"
>
> J: "Plan the work. Work the plan."
> P: "Flexibility is king."

I hate these systems that put people in labeled cubby holes. There are things I like to plan, and there are things I like to be flexible about. My wife and I usually want to plan different types of things and be flexible about different types of things. That makes for a good combination since we balance each other.

Guido Zockoll

Posts: 1
Nickname: mehrcurry
Registered: Jul, 2003

Re: Use Cases -- A minimalist's view.

Posted: Jul 9, 2003 4:36 AM

Use cases are a wonderful idea that has been vastly
overcomplicated. Over and over again I have seen teams
sitting and spinning in their attempts to write use cass.
Typically they thrash on issues of form rather than
substance. They argue and debate over preconditions,
postconditions, actors, secondary actors, and a bevy of
other things that just don't matter.

The real trick to use cases is to keep them simple.
Don't worry about use case forms, just write them on
blank paper, or on a blank page in a simple
word processor, or on blank index cards. Don't
worry about filling in all the details. Details aren't
important until much later. Don't worry about capturing
all the use cases; that's an impossible task.

It depends on the expirience off the use case writers. The first time you come i contact with writing use cases you will need a good use case form to guide you. If you get more and more comfortable with writing use case, of course a blank paper will do.

This is because of the stages of learing.
1. unconscious incompetence (never heard of use cases)
2. conscious incompetence (ohh, there are use cases, how could i use them)
3. conscious competence (have had a training, whats to write frist use case)
4. unconscious competence (have written use cases for years)

In the third phase (conscious competence) people start with big tool evaluation projects, are designing use case forms, use case database etc.

The one thing to remember about use cases is: <i>tomorrow
they are going to change.

In deed, it will! But there is a big danger using this fact as an excuse not to talk to the users. I have seen so many software developers saying: "I know what they do!". So, yes, keep it simple is even good for writing use cases. But remember: Success = Quality * acceptance. So with out acceptance your success will be null. To get acceptance you have to talk to the users.

Deepak

Posts: 1
Nickname: deepsurt
Registered: Oct, 2003

Re: Use Cases -- A minimalist's view.

Posted: Oct 9, 2003 2:06 AM

why use cases work? because they let u think about the system
in a systematic manner in terms of user interactoin.

why they dont work? because humans typically are still in
the mould of big up front. however big upfront doest work at all..

now we all forget that it is impossible for a small human mind
to divluge all that he wants from a system at one go. as such
big up front fails. on the other hand the same mind can divluge
all what the needs in small steps. and this is precisley what
iterative development allows.

so the same concept: divluge in small steps applies to use cases
also. as such it becomes useless to write in detail.

use cases i believe can be best used if: we agree that they hold
requiremnts as understood by me, the devloper and he, the user at a point
of time but we both are willing to let it change.

Flat View: This topic has 10 replies on 1 page

Previous Topic

Next Topic