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.

Do the Right Things

Name: Do the Right Things
Type: Process
Status: final
Version: 2007-09-04

Gist: to provide verification for a feature of a product, a plan of actions concerning the development of a product, or concerning the development of real options.
Note: you can apply this process on various levels of problems and or solutions.
Note: This process optimizes the success in the success equation

stakeholder differentiating: a function or property of the product (or an action of a plan) adds to the overall capability to satisfy the main stakeholders
Note: This means you have to have some notion who the product's main stakeholders are. The stakeholders will accept the product more if the product helps them reaching their goals.
Note: YOU could be the main stakeholder. Then differentiating means options for a wealth of future situations.

mission critical: a function or property of a product (or an action of a plan) is mission critical if the stakeholders will reach one or more of their goals only if the product has it (or the plan caters for it)
Note: This means you have to have some notion of the stakeholder's goals. The stakeholders will accept the product more if the product helps them reaching their goals.
Note: careful, you might presume that some way is the only way.

S1: produce a 2-dimensional space using the above dimensions (mission critical/not mission critical, stakeholder differentiating/ not stakeholder differentiating). This gives you 4 quadrants.
S2: for each feature or sub-feature of the planned product (or action of your plan, or possible step towards your personal goal), ask and answer the following questions: "is it stakeholder differentiating? y/n" and "is it mission critical= y/n".
S3: place it in the quadrants of the space you created in Step 1. You may express more continuous answers than y/n along the axises of your space.
S4: The verfification rules for the four quadrants are:

stakeholder differentiating AND mission critical:
invest and excel. you should do lots of things. put your main effort here. provide the most inner quality.
Note: this is the place where the rewarding things to do yourself are. It is nice to harvest the options you .
stakeholder differentiating AND NOT mission critical:
"good enough" will do. use Pareto. do cheap and easy things.
Note: Will you have the option anyway, whether you do a lot now or not?

NOT stakeholder differentiating AND mission critical:
find a quality partner. use your partner's services. don't do it on your own
Note: Do not expect that your partner gives you many options. However, it is nice to share success (with a business partner or some other partner). Be honest and thankful.

NOT stakeholder differentiating AND NOT mission critical:
do nothing about it. don't waste time and or money
Note: You can use the options that lie here anyway.

10 Principles for UI Design

Title: 10 Principles for UI Design
Type: principles
Status: final
Version: 2007-09-03

Gist: to support good user interfaces. These principles can be used in an attempt to test UI very efficiently without doing usability studies.
Note: In one of my projects we designed a user interface for a handheld device running Windows Mobile. It seemed apparent that it is not useful to mimic a Windows-like UI with windows, tabs and long lists. After the fact I read a lot of 'our' ideas in Jakob Nielsen's article. Thank you!

Source: Jakob Nielsen, thanks to Scott Selhorst


P1 interacting: Does the system provide information about its status? [”Please wait while the system is updating”]
P2 familiar: Does the system use terms and language that are familiar to the user?
P3 oops-tolerant: Can mistakes easily be undone? [”Undo” and “How do I get back to where I was from here?”]
P4 consistency: Does the system use controls (buttons, links, words) to enable actions consistently [”Yes” vs. “OK” vs. “Apply”]
P5 error preventing: Does the system help prevent common user errors?
P6 obvious: Is it easy for users to see what they can do, versus being forced to remember what they can do?
P7 user differentiating: Are there ways for expert users to be more efficient than novice users?
P8 minimal information: Are users forced to filter out irrelevant information (minimalist design)?
P9 useful on errors: Do error messages help users to resolve the errors?
P10 documentation: Is the documentation searchable, task-centric, and precise with “how to” steps?

Kick-ass or at least suck-less Design

Title: Kick-ass or at least suck-less Design
Type: principles
Status: final
Version: 2007-09-03
Gist: to explain how to design kick-ass products (or at least suck-less products)
Source: Michael Shrivathsan, with some minor addition on my side. Thanks to Scott Selhorst for bringing me this stuff.


P1: Start With the User Interface - because this is the only thing your user will see.
P2: Work Closely With UI Designers - because of R1
P3: Pay Attention to Details - because it's part of the success of Apple Computers :-)
P4: Simpler is Better - because more features are worse
P5: Be Brave - because you need something that differentiates your product from the rest
P6: Be passionate about your own product - because if you're not, chances are nobody is.

Means and Ends again

Title: Means and Ends again
Type: citation
Source: Kathy Sierra

What good does it do to master a tool if we haven't understood (let alone mastered) the thing we're using the tool for?

Stripping User Stories for Incremental Development

Title: Stripping User Stories for Incremental Development
Type: Rules
Status: final
Version: 2007-09-03

Gist: explain how to strip down (thin) user stories in order to have more, smaller user stories instead of few, large ones. This is a way to simplify planning releases, as core features can be added to the product earlier than the nice-to-have features. However, keep in mind that product users might like the product for its nice-to-have features.

Note: I find this kind of technique very valuable when being pressed to release. It is relatively easy to apply AND easy to argue about: "with this little time left, we can only provide the really necessary things." My managers liked the idea of getting the basic stuff, but being sure that they will get it far better that the usual "we will do it" and "oh, we couldn't do it" afterwards.
Note: Have you noticed how frequently used yet odd the term "really necessary" is?

Source: Jeff Patton (Agile Development Outside-In), some minor adjustments from my point of view. Thanks to Scott Selhorst for bringing this stuff to me.

R1 Necessity: Find the basic characteristics (course of event) of the user story that is absolutely necessary for the user. It may not be very comfortable, safe, flexible. Make it an own user story. You might want to mark it "Necessities".

R2 Flexibility: Find all options in the original user story that might make the feature more applicable in different situations. Make a user story each. You might want to mark it "Useful options".
Note: There really is no point in combining independent options into one story just because you don't want to have "so many stories".

R3 Safety: Find all the little features that add to increased data quality, prevent inappropriate actions, prevent trouble downstream from the spot. Make an user story each. Sometimes it is easy to combine these kind of topics into one user story with one common business value, like "ensure data quality". This business value can also serve as a name tag.

R4 Comfort, Performance: Find things that make it easier for the user to use the product. Also consider the next occurrance of the user story in the user's life (like if I can save these settings now, I can use them again later). This is where Kano's exciters come in. Products win usability awards here. Add a user story each. You might want to mark it "Added Comfort" or "Improved Performance".