Freigeben über

The Usefulness of the Use Case?

  • Artikel

I'm a big fan of use cases.  Great for describing how software is used, and puts context around the use of functionality that helps software developers to create solutions that will actually fit into human activities.  On the other hand, are there drawbacks to using use cases for flushing out requirements?

Use cases are a 'common denominator.'  They are used to elicit requirements from business users, so use cases need to be understandable to a business user.  They are used to create a picture of functionality for software developers, so use cases need to be useful to a developer.  Use Cases sit in the middle as an excellent and understandable "bridge" between these roles.

However, due to the nature of the 'story' or 'flow' implicit in a use case, there is a type of requirement that may not be well suited to use cases: business rule elicitation. 

In this discussion, I'm not proposing a "hard and fast" definition of a business rule.  I will say that a business rule is a constraint or enabler against the relationships expressed in the conceptual information model.  I'll go into more detail in another post.  All this is based on the efforts of a co-worker, and I'd like to give him due credit and reasonable accuracy.  An example of a relationship in a conceptual model may be "Customer places Orders", whereby a business rule would constrain or enable that statement. 

Key concept here: a business rule can be tested, against the system or information in it, at any time.

Examples of reasonable rules: 

  • A customer with a credit rating of less than 5.0 has a credit limit applied to their outstanding balance. 
  • A customer with a credit limit may only place orders up to their credit limit before payment is received.

But what do business rules have to do with use cases?

Answer: nothing.  That is the problem.

If we use the use case as the only mechanism for the elicitation of requirements, we run the risk of writing a "business rule" that includes the context of a business process, when the rule itself needs to transcend the process.  In other words, if we are describing a purchase process, we could, mistakenly, associate the business rules with the purchase activity itself.

An example of "process pollution" would be:

  • when inserting an order, verify that the order does not cause the total outstanding balance to exceed the credit limit for customers with a credit rating of 5.0 or less.

This does not create a "rule" in the sense of creating a constraint that can be tested, at any time.  It can only be tested when the order is inserted.  But what about orders that are increased?  What if a customer places an order for 10 widgets, and later decides to increase the order to 500 widgets, when the company has no assurance that they can pay for the first 10?  Shouldn't we stop that increase?  With the "polluted" business rule, we might miss it. 

There is a process, based on published work, that describes how to create clean and useful rules, and I'll see if I can post bits of it in another post.  The point of this post: beware of using the use case as the sole mechanism for eliciting and describing requirements... because you may pollute your business rules with context that the rules do not need.  Remember: the quality of a system is directly proportional to the quality of the requirements that describe it.

 

Technorati Tags: Requirements Gathering,Analysis,Use Case,Business Rule

Comments

  • Anonymous
    June 17, 2008
    The comment has been removed

  • Anonymous
    June 17, 2008
    Hello Guy, I'm going to recommend the following book on reputation alone.   Caveat: I have not read it (yet... I plan to): "Business Rules Applied: Building Better Systems Using the Business Rules Approach" by Barbara Von Halle I hope this helps. --- Nick

  • Anonymous
    June 18, 2008
    The comment has been removed

  • Anonymous
    June 18, 2008
    It's interesting, Evan, that you appear to regard the process of eliciting business rules as a step between use case analysis and design.  Many folks argue that business rules elicitation occurs BEFORE the use cases are described.  I believe that these two steps are concurrent.  Perhaps it doesn't matter? I'm on the fence about the usefulness of separating rules into "business logic" and "application logic" as you describe.  I understand what you are doing, but I'm not sure that doing it increases quality.  I'd love to see actual experiments along those lines. Anyway, I appreciate the discussion.  Thank you for contributing your insight and experience.

  • Anonymous
    June 18, 2008
    Much agreed, Use Cases can not do it all. I have presented on this topic a few times, and wrote the following: http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1252666,00.html?track=NL-498&ad=588081&asrc=EM_NLN_1374391&uid=3080496# Business Rules are a big deal, see http://www.businessrulesgroup.org/home-brg.shtml for the first and last word on Business Rules. I recommend Ron Ross as an author of several books on Rules.