The Usefulness of the Use Case?
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.
