Improve Reusability of Use Cases by Extracting Business Rules

Type: Process
Sources: Scott Selhorst on Tyner Blain; Business Analysis Body of Knowledge, Version 1.6; James Taylor's Decision Managment; my own experience; also see see Wikipedia, Business rule (nice best practices!) (as of Jan. 30, 2009, 08:04 GMT),

There is a longer version of this, including examples, at
There is a presentation (in German) supporting this process with economic arguments!


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 change-robust 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 design 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
  • Constraint - mandated criteria such as "accessing the X-files requires Mulder's or Scully's privileges", "the applicant must not be a felon",
  • Guideline - suggestions such as "a retired postalcode should not be re-activated for 1 month", "the applicant should not have been rejected previously",
  • Action Enabler - rules that initiate or trigger behavior, like "after 3 consecutive unsuccessful logins, …", "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″, "on the waiting list, move the customer up two positions" or
  • Inference - the canonical "if…then" statements

Entry Conditions

E1: Use Cases have been written (and validated by subject matter experts (SMEs))
Sometimes it's easier for SMEs to validate business rules when they see them already seperated from the rest. Sometimes not.

E2: You are prepared to document the extracted business rules properly.
Be it as a seperate part of the use case template (simple) or in a list of business rules for all use cases (advanced, and far better for more than 5 use cases or so).

Steps and Notes

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 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". 'Be careful here, make sure that the statement is true, i. e. validate it.

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

S4: In every section find statements that describe computations. Look for factors and divisors, formulas in general. Look for keywords = {assess, compare, calculate, compute, check, confirm, qualify, decide, determine, diagnose, evaluate, estimate, process, test, validate, verify}
'What else can be named a computation?

S5: In every section find statements that describe symbolic reasoning: Look for {if … then, unless, only if, is a necessary condition for, is a sufficient condition for, consequently, therefore}.

S6: In every section 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.
'This also helps with finding the essential steps in a use case.

S9: For every sentence fragment 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 for reference purposes.

S10: Make sure your Business Rules can be clearly distinguished from the rest of the specification.
'By putting them in an extra chapter of your specification. If you're using a word processor consider using references, so that you only need to write each rule once, and display it in full many times.

S11: Consider writing an explicit requirement that requires some robustness concerning changing of these rules.
'You will have to predict in which way and to what extent you expect the rules to change

Exit Conditions

One may exit the process, when you are sure there are no more Business Rules hiding in the use case. You can do this by using the above definition of Business Rules as a checklist for sifting through all use cases.


With some practice you can use steps S2 through S8 to form questions for interview purposes.


find one

Related Pages

rating: +1+x

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License