On listing cost as a negative for formal use cases, what I should have said was “relative cost” as compared to informal or story/scenario style use cases. Because we have to go through the process of sorting out information into different buckets (alternates, exceptions, main course), that takes a little time – the documentation of alternate and exception courses also takes extra time, because we have to apply the effort to make sure that we aren’t specifying design. Thanks for your link – I’ve added the template you developed to the post as well.

Whether “more information” is better or worse depends on the information added.
Since use cases are meant to be used as a basis for design, test and user documentation, I always ask myself the questions:
- Does the designer need this information to make the design for the desired system?
- Does the tester need this information to verify that the desired system was built?
- Does the person making the user documentation need this information to document the desired system?

If all three need the information, I suggest you include the information in the Use Case (if this information applies to this Use Case only) or in Supplementary Requirements document. The latter can be indirect, as in “The System must adhere to the companies User Interface Guidelines (with reference to that document)”.
If not all three parties need the information, include the information in other artifacts like Designs or Guidelines. (As Scott Ambler says: By referring to other artifacts, instead of embedding the information in your use cases, you reduce the chance that you’re writing Use Cases of Mass Destruction.)

A sample Use-Case specification is available at http://blogs.infosupport.com/harryn/archive/2006/01/04/3341.aspx.
It relates to the formal Use-Case specification written by Scott W. Ambler in Introduction to System Use Cases. Please feel free to compare the styles used by Scott and by me.

The template we use is originally written in Dutch, but I translated it for this discussion and upcoming discussions on my own blog.

December 21, 2005 at 12:28 am · Edit

I went back and forth on including training as a con for formal use cases. I’ve been trying not to list anything that’s true of all the use case models, and I started with the presumption that training was required to use any of them, so I didn’t break that out as a differentiator. I think the training needed to do use cases well is roughly the same cost, regardless of which format people use. Although it’s much easier to imagine a pointy-haired manager saying “What training cost? Just write a paragraph. You can write a paragraph, can’t you?” If you show said manager a template with 20 fields, “You’re gonna need to be trained to fill out that form” is more likely.

Thanks, Brad, and please let us know your thoughts on the other posts in the series as I get them out.

Scott

December 20, 2005 at 2:39 pm · Edit

Tyner-

Nice series so far on Use Cases – a few comments:
- On the “cons” side firms should consider training costs as well. Not everyone is going to be comfortable writing and using Use Cases day one. Not that training is a big cost – just need to budget time to take care of it. Of course, Use Cases are no different than any other artifact of software development – and believe me, it’s a lot easier to teach someone to read a Use Case and get feedback from them than to read a functional spec.
- Maintenance is certainly a factor when collecting a lot of detail. And once you go into Design, you know things are going to change. One option is to use Use Cases to bootstrap the project – get everyone on the same page and get rolling into requirements, then drop them. Of course, you don’t get the benefit of using Use Cases in the future that way (e.g. Test Scripts, starting point for future projects/enhancements).
- I like the IMS link, never came across that one before. Interesting idea, though there’s not a lot there yet.