Comments on: Use Case Basics: Keeping it Simple http://practicalanalyst.com/2009/07/28/use-case-basics-keeping-it-simple/ Practical Insight for Business Analysts and Project Professionals Wed, 01 Sep 2010 05:50:29 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Slávek Rydval http://practicalanalyst.com/2009/07/28/use-case-basics-keeping-it-simple/comment-page-1/#comment-8091 Slávek Rydval Fri, 28 Aug 2009 14:23:25 +0000 http://practicalanalyst.com/?p=1787#comment-8091 <span class="topsy_trackback_comment"><span class="topsy_twitter_username"><span class="topsy_trackback_content">http://jdem.cz/bzns5 Use Case Basics: Keeping it Simple #UseCases</span></span> http://jdem.cz/bzns5 Use Case Basics: Keeping it Simple #UseCases

]]> By: JB http://practicalanalyst.com/2009/07/28/use-case-basics-keeping-it-simple/comment-page-1/#comment-6654 JB Thu, 27 Aug 2009 03:42:05 +0000 http://practicalanalyst.com/?p=1787#comment-6654 I appreciate the comment, Bernie. You make a good point. I do like the naming/numbering technique. As I said, it's a good practice to extract the rules from the use cases, but you still want your use cases to be as useful/usable as possible so you want those rules to be easy to get to for those that are going to be using the use cases to design and build. To that end, I've heard it argued that some designers and developers prefer the rules embedded in the use case steps because that way they have it all right in front of them. Of course, you lose the stability I mentioned above and maintaining the use cases could become a chore for the BA, but if that's the trade-off an organization wants to make in order to get a good product out the door as quickly as possible, then I'm not going to knock it. When you get down to it, the use case is just a technique - another tool in the toolbox - to help facilitate creation of a good product. I appreciate the comment, Bernie. You make a good point. I do like the naming/numbering technique.

As I said, it’s a good practice to extract the rules from the use cases, but you still want your use cases to be as useful/usable as possible so you want those rules to be easy to get to for those that are going to be using the use cases to design and build.

To that end, I’ve heard it argued that some designers and developers prefer the rules embedded in the use case steps because that way they have it all right in front of them.

Of course, you lose the stability I mentioned above and maintaining the use cases could become a chore for the BA, but if that’s the trade-off an organization wants to make in order to get a good product out the door as quickly as possible, then I’m not going to knock it.

When you get down to it, the use case is just a technique – another tool in the toolbox – to help facilitate creation of a good product.

]]> By: JB http://practicalanalyst.com/2009/07/28/use-case-basics-keeping-it-simple/comment-page-1/#comment-6653 JB Thu, 27 Aug 2009 03:29:47 +0000 http://practicalanalyst.com/?p=1787#comment-6653 Not late at all, Charu. Thanks for the comment, and for the sound advice. Use cases are the most intuitive way I've come across (so far) for identifying the alternate scenarios, exceptions and business rules in context. Not late at all, Charu. Thanks for the comment, and for the sound advice.

Use cases are the most intuitive way I’ve come across (so far) for identifying the alternate scenarios, exceptions and business rules in context.

]]> By: Bernie http://practicalanalyst.com/2009/07/28/use-case-basics-keeping-it-simple/comment-page-1/#comment-6651 Bernie Tue, 25 Aug 2009 19:23:25 +0000 http://practicalanalyst.com/?p=1787#comment-6651 All very useful advice. Thank you. I would add to the discussion about breaking out Business Rules that I agree that a business rule should not be embedded in a step, but I do find it useful to provide a specific unique reference to the business rule at the applicable step, regardless of whether the rule is documented in a separate rule section of the use case or is in a rule repository. This removes any ambiguity about which rule should be applied and when, but keeps the use case 'clean' and readable, just as Jonathan wisely recommends. The rule can still be updated independently without impacting the use case steps. I have found it best to give each rule a unique number and brief name (e.g. BR0053 Online Customer Validation). Keeping numbers unique may not be possible if you don't have a corporate-wide rule repository, but you can at least keep them unique within a project, or perhaps a domain. All very useful advice. Thank you. I would add to the discussion about breaking out Business Rules that I agree that a business rule should not be embedded in a step, but I do find it useful to provide a specific unique reference to the business rule at the applicable step, regardless of whether the rule is documented in a separate rule section of the use case or is in a rule repository. This removes any ambiguity about which rule should be applied and when, but keeps the use case ‘clean’ and readable, just as Jonathan wisely recommends. The rule can still be updated independently without impacting the use case steps. I have found it best to give each rule a unique number and brief name (e.g. BR0053 Online Customer Validation). Keeping numbers unique may not be possible if you don’t have a corporate-wide rule repository, but you can at least keep them unique within a project, or perhaps a domain.

]]> By: Charu http://practicalanalyst.com/2009/07/28/use-case-basics-keeping-it-simple/comment-page-1/#comment-6648 Charu Mon, 24 Aug 2009 21:47:05 +0000 http://practicalanalyst.com/?p=1787#comment-6648 Jumping in quite late into this ....but it is a nice article on use cases. I am great supporter of use cases and in my point of view, it is good to invest some time writing up all the exceptions and alternatives, especially in complex projects. My suggestion will be start with the business use cases initially. Then as we proceed with each business use case, complete the functional use cases. As part of the functional use cases, when we do write up all the main flow criteria, all exceptions and alternatives, it gives a good chance to weigh them against the probablity of occurrence and then prioritize them. During the technical design stage, we may take a decision to not implement some of them - but that should be a calculated decision based on the possibility of occurrence and the its prioprity from business point of view. Jumping in quite late into this ….but it is a nice article on use cases.
I am great supporter of use cases and in my point of view, it is good to invest some time writing up all the exceptions and alternatives, especially in complex projects.
My suggestion will be start with the business use cases initially.
Then as we proceed with each business use case, complete the functional use cases.
As part of the functional use cases, when we do write up all the main flow criteria, all exceptions and alternatives, it gives a good chance to weigh them against the probablity of occurrence and then prioritize them.
During the technical design stage, we may take a decision to not implement some of them – but that should be a calculated decision based on the possibility of occurrence and the its prioprity from business point of view.

]]> By: JB http://practicalanalyst.com/2009/07/28/use-case-basics-keeping-it-simple/comment-page-1/#comment-6612 JB Fri, 31 Jul 2009 02:42:59 +0000 http://practicalanalyst.com/?p=1787#comment-6612 Thanks for the comments. Scott, I really appreciated your article on extracting business rules as reference. Matt, appreciate the comment - BTW, I'm giving the latest Case Complete a test drive at home just because I'm a geek like that. Seems like a really nice product. Ellen, you're welcome to "rant" as much as you want on this blog. I really value your feedback. Your comments on use cases for agile projects are especially interesting to me as I've never really worked in a truly "agile" methodology. I'll have to read up on that. Any references to recommend? Thanks for the comments.

Scott, I really appreciated your article on extracting business rules as reference.

Matt, appreciate the comment – BTW, I’m giving the latest Case Complete a test drive at home just because I’m a geek like that. Seems like a really nice product.

Ellen, you’re welcome to “rant” as much as you want on this blog. I really value your feedback. Your comments on use cases for agile projects are especially interesting to me as I’ve never really worked in a truly “agile” methodology. I’ll have to read up on that. Any references to recommend?

]]> By: Ellen Gottesdiener http://practicalanalyst.com/2009/07/28/use-case-basics-keeping-it-simple/comment-page-1/#comment-6611 Ellen Gottesdiener Fri, 31 Jul 2009 01:02:10 +0000 http://practicalanalyst.com/?p=1787#comment-6611 Nice summary of key points, Jonathan. thanks. Your bit about business rules, and also so nicely focused on by Scott in his article you reference is soooo critical. embedding rules (and data) inside use cases ends up being the bane of the entire delivery team. a while back (2002?!) i wrote a 2-parter for IBM's Rational Edge on top 10 misuses of use cases. there i also rant a tad about the need to separate out rules...(http://ebgconsulting.com/Pubs/Articles/Top10MisusesOfUseCasesPart1-Gottesdiener.pdf). the thing is: rules operate across many use cases. and change, potentially a lot. your advice to keep it simple is essential. in practice, spending time elaborating use cases specifications is not a good investment; many of the steps and variations and exceptions don't end up being get implemented. spending time on use case specs is, as dare say, as sinful as writing requirements specs cuz the template and process says so! We also just plain forgot what we meant in those specs; what was that i meant when i wrote that months ago? hmmm...ends us as muda, waste. better to be lean with these use cases (if used). on agile projects, they can be useful for what i refer to as "big view" and perhaps "preview" of requirements (product and release levels). not a good idea for the "now" (iteration) level. anyway, thanks for the blog, and forgive me mini-rant ;-) ~ ellen Nice summary of key points, Jonathan. thanks.

Your bit about business rules, and also so nicely focused on by Scott in his article you reference is soooo critical. embedding rules (and data) inside use cases ends up being the bane of the entire delivery team.

a while back (2002?!) i wrote a 2-parter for IBM’s Rational Edge on top 10 misuses of use cases. there i also rant a tad about the need to separate out rules…(http://ebgconsulting.com/Pubs/Articles/Top10MisusesOfUseCasesPart1-Gottesdiener.pdf).

the thing is: rules operate across many use cases. and change, potentially a lot.

your advice to keep it simple is essential.

in practice, spending time elaborating use cases specifications is not a good investment; many of the steps and variations and exceptions don’t end up being get implemented. spending time on use case specs is, as dare say, as sinful as writing requirements specs cuz the template and process says so!

We also just plain forgot what we meant in those specs; what was that i meant when i wrote that months ago? hmmm…ends us as muda, waste.

better to be lean with these use cases (if used). on agile projects, they can be useful for what i refer to as “big view” and perhaps “preview” of requirements (product and release levels).

not a good idea for the “now” (iteration) level.

anyway, thanks for the blog, and forgive me mini-rant ;-)
~ ellen

]]> By: Daily Links for Thursday, July 30th, 2009 http://practicalanalyst.com/2009/07/28/use-case-basics-keeping-it-simple/comment-page-1/#comment-6610 Daily Links for Thursday, July 30th, 2009 Thu, 30 Jul 2009 11:34:46 +0000 http://practicalanalyst.com/?p=1787#comment-6610 [...] Use Case Basics: Keeping it Simple : Practical Analyst [...] [...] Use Case Basics: Keeping it Simple : Practical Analyst [...]

]]> By: CaseComplete http://practicalanalyst.com/2009/07/28/use-case-basics-keeping-it-simple/comment-page-1/#comment-8092 CaseComplete Wed, 29 Jul 2009 19:54:16 +0000 http://practicalanalyst.com/?p=1787#comment-8092 <span class="topsy_trackback_comment"><span class="topsy_twitter_username"><span class="topsy_trackback_content">Use Case Basics: Keeping it Simple (from Practical Analyst) http://bit.ly/B8Saw</span></span> Use Case Basics: Keeping it Simple (from Practical Analyst) http://bit.ly/B8Saw

]]> By: Scott Sehlhorst http://practicalanalyst.com/2009/07/28/use-case-basics-keeping-it-simple/comment-page-1/#comment-8093 Scott Sehlhorst Wed, 29 Jul 2009 19:28:17 +0000 http://practicalanalyst.com/?p=1787#comment-8093 <span class="topsy_trackback_comment"><span class="topsy_twitter_username"><span class="topsy_trackback_content">RT @jonbab1: Blog Post: Use Case Basics: Keeping it Simple : Practical Analyst http://bit.ly/B8Saw #baot [commented on it]</span></span> RT @jonbab1: Blog Post: Use Case Basics: Keeping it Simple : Practical Analyst http://bit.ly/B8Saw #baot [commented on it]

]]>