Comments on: Use case series: Formal use case http://tynerblain.wordpress.com/2005/12/19/use-case-series-formal-use-case/ Requirements, Software, Development, and Process Fri, 21 Apr 2006 00:31:50 +0000 http://wordpress.com/ hourly 1 By: Tyner Blain » CRUDdy use cases and Shakespeare http://tynerblain.wordpress.com/2005/12/19/use-case-series-formal-use-case/#comment-53 Tyner Blain » CRUDdy use cases and Shakespeare Wed, 04 Jan 2006 08:26:44 +0000 http://tynerblain.wordpress.com/2005/12/19/use-case-series-formal-use-case/#comment-53 [...] 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. [...]

]]> By: Scott Sehlhorst http://tynerblain.wordpress.com/2005/12/19/use-case-series-formal-use-case/#comment-20 Scott Sehlhorst Wed, 21 Dec 2005 06:28:07 +0000 http://tynerblain.wordpress.com/2005/12/19/use-case-series-formal-use-case/#comment-20 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 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

]]> By: Brad Kuhn http://tynerblain.wordpress.com/2005/12/19/use-case-series-formal-use-case/#comment-19 Brad Kuhn Tue, 20 Dec 2005 20:39:59 +0000 http://tynerblain.wordpress.com/2005/12/19/use-case-series-formal-use-case/#comment-19 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. 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.

]]>