Improve Reusability of Use Cases by Extracting Business Rules

Name: Improve Reusability of Use Cases by Extracting Business Rules
Type: Process
Status: final
Version: 2007-11-21
Source: Scott Selhorst on Tyner Blain; Business Analysis Body of Knowledge, Version 1.6; my own experience, also see Wikipedia

Gist: write use cases that do not have to be edited if business rules change. write use cases that can be reused for various purposes, where the purpose is determined by business rules. write use cases that consist of essential, implementation independent statements (as opposed to concrete and implementation dependent). implement solutions that separate volatile rules from the rest of the code.
Note: It requires an explicit decision within the architecture or the design to implement things that way! However, in an agile development, you might not designg for this kind of flexibility unless you are sure it has a business value. This should not keep you from writing the requirements with business rules separated! Writing business rules separately may prod you towards a respective refactoring step.

A business rule
- describes a policy, guideline, standard, or regulation upon which the business operates.
- determines business decisions.
- defines or constrains some aspect of the business.
- is intended to assert business structure, or to control or influence the behavior of the business.
- is atomic, that is, it cannot be further decomposed.
- is not process-dependent, so that they apply at all times.
- normally has a significant impact on business processes, business data and business systems.
Example: "Only users with Level 3 clearance may access the XY-logs".

business rule IS EITHER a
Constraint - mandated criteria such as "the applicant must not be a felon",
Guideline - suggestions such as "the applicant should not have been rejected previously",
Action Enabler - rules that initiate or trigger behavior, like "when the customer's card has been rejected, it must be confiscated",
Computation - the embodiment of calculations, like "pay 1.5 times the wager for a two-card total of 21″, or
Inference - the canonical "if…then" statements

S1: Assume you have a use case with sections of some sort for a description, triggers, preconditions and normal / other flows.

S2: In every section go find statements that constrain the use case. Look for the keywords "must be", "must have", "make sure that", and also "always", "every", "never", "no", "all", "may", "can". 'careful here, make shure that the statement is true, i. e. validate it.

S3: In every section go find statements that enable actions. Look for the keywords "when", "if", "as soon as", "in case", and time triggers.

S4: In every section go find statements that describe computations. Look for factors and divisors, formulas in general.

S5: In every section go find statements that describe inferences: Look for "if ... then".

S6: In every section go find statements that describe default values. ' A classical rule to be implemented as a parameter.

S7: Especially in the flow sections, look at every decision or branch and find the rules that govern the decision making in this particular spot.

S8: Search the Normal, Alternative and Exception Flow Parts for concrete values like keywords, number ranges, states. Their abstractions are the business rules.Note: this also helps with finding the essential steps in a use case.

S9: For every statement found, see if you can extract it into a whole new sentence AND rewrite the remaining part of the description by using a reference to that new sentence. If you can, you have probably found a business rule in that statement. Give it a name and or a number.

S10: Make sure your Business Rules can be clearly distinguished from the rest of the specification.

S11: Consider writing an explicit requirement that requires some robustness concerning the change of these rules.