use cases

UML Use Case examples

Summary: A collection of UML Use Case examples (software requirements examples), based on a "real world" project.

I've been taking a little time lately to document a lot of what I know about UML Use Cases, and today I thought I'd take a few moments to link up to Use Cases I wrote for a client back in 2004. The client graciously allowed me to reprint these on this website, as long as I removed their name from all the documentation.

The best UML Use Case definition I know

Every time I read an article or book about UML "Use Cases" I cringe a little bit. Every author says something like "Jacobson left the definition of a Use Case too open", and then they try to work through some elaborate scheme of what a Use Case means to them. I actually happen to think there's a very good Use Case definition, which I'd like to share here.

A good UML Use Case definition

Here's the best Use Case definition I know:

UML Use Case best practice - Test your Use Cases with real data

Quite often when I'm asked to review UML "Use Case" that someone else has written, I ask "Have you tested your Use Case with real data?" Sadly, the answer is usually "no". I don't know why people don't do this, but they don't, and it seems like a very logical thing, essentially a unit test for Use Cases.

Too many use cases

I don't know if you've ever had UML use case burnout, but I think I just hit the wall. Here's a link to some use case prose that shows I've written way too many use cases recently.

Maybe this is a good way to know when you need a vacation?

 

Using UML - The usefulness of UML diagrams

Following a speech two days ago, I'm struck by how very little we use the Unified Modeling Language (UML) on our software projects. Occasionally I'll create some activity diagrams to model how users get their tasks done, but that's about it. Typically when we create a software requirements specification this is what we deliver:

UML - Use Case best practices

I've been working on a document for one of my customers named "Use Case Best Practices", but then I decided to search the Internet to see if I could find anything similar to what I was thinking.

The best thing I've found is this Coad Letter on Borland's web site. There is enough meat here that I'm scrapping my plans and just suggesting they read that document instead. Kudos.

 

Use cases, requirements, and state (Fri, Jan 21, 2005)

One of the things I learned (or was reminded of) is that -- properly done -- Use Cases really bring out some state-related issues that you can't get from plain old requirements.

I'm working with a client on fixed price software development (and have been doing so for nearly two years now), and this brings a lot of risk to my side of the table, so I'm very careful that we all understand exactly what's being developed.

Wed, Apr 28, 2004 (A large requirements example)

Here's a link to a sample 242-page requirements document. This is a real world example, full of use cases, requirements, and a few other things.

Tue, Dec 2, 2003

There are dates/times like last night, and again this morning, that my unified theory of software development seems to be coming together. My latest concepts, documented here just so I won't forget them :), involve:

UML actors and requirements

Here's a simple but interesting quote from a "Use Case" book I was reading last night: 

"If the actor is not part of the system, then the requirements cannot be a part of the system."

This statement seems obvious, but reflecting on some of my own work I can see where I have occasionally strayed in this direction, and having reviewed the work of other people, I have often seen these types of requirements in requirements documentation.

Syndicate content