Tutorials for writing Use Cases (with complex, real-world examples) ?

Hi,

I'm trying to learn how to write Use Cases.

(I'm an experience code-writer, but I don't have much experience with formal product specification).

I've been reading books, tutorials, even took an academic course...

Unfortunately, they all focus on silly "toy" examples (like "Elevator" or "Withdraw money from bank" )...

I feel I'm missing a lot of info before I can apply this to complex "real world" projects !

Just to demonstrate, consider a Use Case for "withdrawing money from the bank":

The "toy" Use Cases are usually 5-10 lines. At best, they'd do some validity checks ("exceptions" table).

In the real world, a *precise* description could be 200 lines... it might involve: Communication between banks / branches; Special permission to exeed overdraft limit (it happens in my country); Moving money between saving accounts and checking accounts (which might have complex rules of its own), etc...

I was hoping to find a tutorial that could answer "real-world" questions such as:

- Should my Use Case describe all the subtle details, or should it be kept short and readable, even at the price of missing some details ?

- Are there guidelines for breaking my 200-line UC into various sub-UseCases ? What's the recommended size for such sub-UC (kind of like the way programming books recommend that java methods don't exceed 20 lines of code... just a rough estimate, but it's something to start from)

These are just examples, to demonstrate why a 10-line example doesn't prepare me to the real-world...

So, could anyone please recommend a *realistic* tutorials (books / web sites), with real-world, complex examples ?

Thanx very much

[1746 byte] By [solmyr72a] at [2007-10-2 11:03:16]
# 1

I know you were asking for concrete examples, but if I may say so, you seem to be overly concerned with how this or that book would define Use Cases.

In essence, you should just be concerned with: does this formal text provide enough input for the next stages in development. If it does, it's well written; otherwise it isn't.

Who is going to read your written spec and go on to design and implement it? Would a developer with average experience be able to start from it? Do I have a lot of beginners in my team and if so, would they be able to start from it?

The decision of how much detail to specify should be based on experience; evaluate this after a first iteration. Usually I try to keep specifications for Use Cases or User Stories as short as possible while still providing a full formal definition of what is to be done. Past a certain level of detail it becomes a thought experiment about things that don't really need or can't be decided in advance; also the human factor is important and overly long specifications are simply not read through with full attention by most developers, in my experience.

I'm sorry I can't link you to anything directly; I've read quite a few texts on formal specification but none provide satisfactory final guidelines. The most important factor in real life for me is: what exactly am I trying to accomplish in this document, and who will be reading it? If you constantly re-evaluate your specification in this light, you will end up with the middle ground you were looking for.

Lokoa at 2007-7-13 3:35:49 > top of Java-index,Other Topics,Patterns & OO Design...
# 2
Thanks :)Your message was most useful and informative... too bad none of my books took the trouble of mentioning any of the useful points you've just brought up :)
solmyr72a at 2007-7-13 3:35:49 > top of Java-index,Other Topics,Patterns & OO Design...