use cases

Use Case best practice: Test your Use Cases with real data

Quite often when I’m asked to review a 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.

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. IMHO, the best use case definition was created in the early 1980s, long before Jacobson mentioned the term.

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.

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.

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: