The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Learning to write use cases

Do you guys(gender-neutral) know of any resources to learn about writing use cases? I have to write some and I'm at a bit of a loss.

Thanks in advance.
Stephen Caldwell Send private email
Thursday, September 01, 2005
Don't bother. They are too complex. Try user stories instead.
son of parnas
Thursday, September 01, 2005
What's so complicated about an arrow going from a stick man to a bubble with "Order Product" written in it and some supporting text?
John Topley Send private email
Thursday, September 01, 2005
I've been puzzling over the relation between UML "use case diagrams", "requirements", and "activity diagrams".

Personally I think I've decided that:

* Use case diagrams name a usage scenario (a time when and/or a way in which and/or a purpose for which the software is used), and the actor (type of user) who is doing the using. Use case diagrams don't contain much other information (except they may also show relationships between different use cases, e.g. "this 'create new user' use case includes the prior 'login as administrator' use case"). Most of their value is in associated text (don't present a coder with nothing but un-annotated use case diagrams ... use case diagrams don't contain enough detail). I see use case diagrams as being captured very early, in a pre-design analysis phase, when you're trying to map the scope of the system for which you'll need to define further details.

* Requirements are text. A use case has (or perhaps 'is realized by' or 'is traceable to') one or more associated requirements. Having a [sufficiently-complete] set of requirements is your ambition, i.e. what you need in order to begin design-and-coding. If you write some several paragraphs of text associated with a use case, this text might be reformatted as a set of requirements.

* Activity diagrams can be similar to use case diagrams, but they're more detailed: because an activity diagram can *also* define the input to and the output from each activity (I think it was the book _The Deadline_ which said something like "if a spec doesn't define a system's inputs and outputs, then it isn't a spec."); *and*, an activity diagram may define an activity's internal implementation details. Activities can illustrated as some collection of sub-activities. Personally I like "data flow diagrams" ... and UML activity diagram notation can be used to make data flow diagrams. I think that a use case can probably also be shown as an activity diagram ... an activity diagram is a mature version of a larval use case diagram ... if a use case diagram is captured at the begining of the analysis phase, a corresponding activity diagram exists later in the lifecycle, after analysis is complete and architecture/design has started.

I'd be interested to hear of other views on this topic.
Christopher Wells Send private email
Thursday, September 01, 2005
>  What's so complicated about an arrow going from a stick man to a bubble with

I have never practiced the topley use case methodology. My experience has been more with the Alistair Cockburn variety.
son of parnas
Thursday, September 01, 2005
It's not mine, it's UML!
John Topley Send private email
Thursday, September 01, 2005
An use case groups together any number of scenarios. A scenario is roughly a user story.

Use case "dressing up in the morning"
1) check yesterday's t-shirt. still reasonably clean. dress up with t-shirt.
2) check yesterday's t-shirt. t-shirt stinks. throw it on the floor. Get clean t-shirt from shelf.
3) check yesterday's t-shirt. t-shirt stinks. throw it on the floor. no clean t-shirt on the shelf. Check the pile on the floor. One t-shirt from the pile kind of works.
4) check yesterday's t-shirt. t-shirt stinks. throw it on the floor. no clean t-shirt on the shelf. Check the pile on the floor. yuck. use yesterday's t-shirt. Go at k-mart, buy 10 t-shirts. throw yesterday's t-shirt on the floor. relocate t-shirt pile from floor into the garbage bin.

More, use cases have dependencies to actors and other use cases. Since scenarios are sequences of requests/responses, actors are kind of obvious what they are: users of the UC responsible for initiating ALL scenarios in the UC. For example "geek" is an actor of the above UC.

There are dependencies between use cases: for example the above UC depends on "buy t-shirts" use case. In fact it includes that use case. Typical UC dependencies are: includes, requires, extends, ...
Dino Send private email
Thursday, September 01, 2005
UML only provides you with a handy and generally accepted graphical notation to enumerate use cases and represent relationships between them. Use cases must describe in detail the interaction between the (sub)system you build and the outside world - that is either a human user, an external system or another subsystem of the same system.

In order to write good use cases you must have a very clear idea about functionality you need. This is why use cases are best written by business experts. If you go to technical architect and tell him: we're going to build an online trading system, please write the use cases, it's not going to work. He's not the right person to be asked about that, doesn't know the trading business. If you want to build a trading system, you better ask a trader what his dream system would be. He knows the biz you want to address, he'll tell you: a useful trading system has to do this and that and that. In order to do that, I need to click on a button, provide this information to the system and the system should respond like this.....

If you want to write meaningful use cases, forget about UML in the beginning. Get a notepad and start writing down every possible thing that you'd like to accomplish with your system. If you're not a business expert yourself make sure you interview one or have the business expert write the use cases himself. Then, if you feel it's necessary, you can go  back to UML and describe the use cases the the relationships between them graphically.

Emil Kirschner
Thursday, September 01, 2005
I agree with Emil. Just write down the use cases on a notepad and forget UML.

I never really understood what UML was supposed to give you for use cases. It sure seems like they only gave you a couple of simple symbols that only allowed you to represent 10% of what you had to say and then expected you to fill in the rest with text. So what good is that?

I have always done my use cases in a simple table format with text and numbering to describe each step. I basically went that way because I could never find ANY good examples of real use cases. Everyone describes the process but no one ever gives any examples.

Stick with flow charts or simple text descriptions in table format. The idea is to help people understand the use case. Not to wow the world with notation and diagrams.
Thursday, September 01, 2005
The best resource is Alistair Cockburn's book "Writing Effective Use Cases". And keep 'em simple - communication is the key.
Marcus Price
Friday, September 02, 2005
I also recommend Alistar Cockburn's 'Writing Effective Use Cases'.  His advice in this book is very useful.

But you will need to practice writing use cases in order to 'get it'.
When use cases were new to me, I wondered how to write use cases 'the right way'.
After a while you realize there is no 'right way', but that it's important to write use cases that are easy to read and understand.

What's nice about the book is that it has some examples of use cases (text). And it shows that use cases can be writting in different ways, depending on your demands.
(formal or less formal, broad of in detail, etc)
Not an Agile guy
Saturday, September 03, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz