December 19, 2005

Use case series: Formal use case

Posted in Requirements, Use case at 6:43 pm by Scott Sehlhorst

We’ve moved to – this page is now here



  1. Brad Kuhn said,


    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.

  2. 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.


  3. […] When we write use cases, we don’t include trivial steps. For example, the precondition for a formal usc case could include the user being logged in and authenticated with the ability to access the relevant information. We would not document logging in and authentication as part of the “create a report? use case. It is (nearly) redundant information, because it is (or should be) generally understood that the user must be logged in, if the system has an ACL. The user must also be using a computer, and it must be turned on. […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: