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.

 

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

5 thoughts on “The Usefulness of the Use Case?”
  1. Very insightful, this is very much in line with what I am working on right now, I agree with you completely.

    What is the name of the "published work" that defines the process for creating clean and useful business rules?  I’m interested in looking into it…

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

  3. We have to remember that the Use Case is only good for analysis.  Juval, Fowler, etc all agree that the functional decomposition provided by the Use Case yields the worst design possible when translated directly to code.  Even Parnas argues that a functional decomposition is a very poor design.

    Knowing this, it’s up to us to take the functional decomposition (which was used to analyze and understand the problem and desired solution) to create a proper design.

    During the process of design (even if it only occurs inside my head), I break "business rules" or "business logic" into two categories: application logic and business logic.

    The roots for both come from Fowler and Evans (DDD), where application logic might be something like: Send an email to the customer after accepting their order.    Business logic is more along the lines: Calculate sales tax on orders shipping to CA or NY.  The application logic represents a workflow that occurs (with/without any workflow framework) during the execution of a business goal (ConvertCartToOrder) and exists in the Service Layer facade (Fowler).  The business logic exists in the domain model and is part of the emulation that occurs to manipulate the state space (objects/data) to work out the desired effect.

    And that’s basically it in a nutshell.

    So, back to your original question.  Are Use Cases useful?  Yes, but only for gaining understanding by analyzing the problem space.  Translating them beyond that is a known anti-pattern (which is agreed upon by multiple schools of thought).

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

Leave a Reply

Your email address will not be published. Required fields are marked *

five + 3 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.