After the initial set of deliverables is completed in Step 2 (as discussed last month), they need to be reviewed, assessed, and analyzed as a whole.  This next step — Step 3 — requires a lot of heads-down desk work.

Step 3 — Analyze and Refine

The goals of this step	Review deliverables as a whole Refine terminology Resolve anomalies Simplify whenever possible
Responsible parties	Business Analysts —specify, model, organize, and analyze Business Stakeholders —validate
Techniques and methodology	Concept modeling Business rules specification techniques Decision structuring techniques Business rule and decisions techniques Identification and resolution techniques for conflicts, subsumptions, redundancies, and similarities Exception analysis

Figure 1.  Sample grouping of deliverables.

Figure 1 shows a sample grouping of deliverables.  These deliverables need to be reviewed as a whole.  Their content needs to fit together. 

The above deliverables consist of the following:

Business Process Model:^[1]  The business process model shows tasks and roles required to complete a business event from beginning to end.  Business process models always flow.  They always do (transform) something.

Validation suggestions:

• Each major business event has a supporting business process model.
• Each business task within the business process model has business rules guiding behaviour.
• Each decision task is identified and supported by one or more decision structures.
• Input and output of each task is represented in the concept model.

Decision Structure (Q-chart):^[2]  When a process task needs to determine an outcome from a list of possible choices, you have a decision.  For any complex decisions, analyze and model that decision by dividing into sub decisions.  The result is a decision structure.  In BRS IPSpeak™, we phrase each decision into a question (because each decision answers a question).  Our decision structure is a Question Chart (Q-Chart™).  But do keep in mind that not all process tasks require a decision.

Validation suggestions:

• Each Q-Chart supports one or more tasks in a business process model.
• Each decision on the Q-Chart is represented in a Q-COE.

Q-COE™:^[3]  For each of the questions in the Q-Chart, a Q-COE is used to brainstorm key elements of a decision.  Q-COE™ is a graphic representation indicating what question ("Q") is being asked, and usually one or more of the following:  considerations ("C"), outcomes ("O"), and exceptions ("E").  

Validation suggestions:

• Each Q-COE is identified in a Q-Chart.
• Each Q-COE has one or more decision tables outlining the decision logics.
• The question, consideration, and outcome of each Q-COE are represented in the corresponding decision table.

Decision Tables:^[4]  For each Q-COE™, one or more decision tables need to be created to show the detailed logic of how an outcome is determined.  A decision table is structured means of visualizing decision rules in rows and columns.  It is a great technique for modeling a set of rules with the same considerations.

Validation suggestions:

• Each consideration and outcome in a decision table is represented in the concept model.
• Each question, consideration, and outcome aligns with the corresponding Q-COE.

Business Rules Statements:^[5]  Business rules are captured to guide behaviour, shape judgements, or make decisions.  These business rules statements need to be organized and managed.

Validation suggestions:

• Each business rule uses the terminology specified in the concept model.
• Each business rule guides one or more tasks or is part of one or more decisions.
• Each business rule is unique.

Concept Model:^[6]  A vocabulary model for the entire scope of the project.  This set of vocabulary is important to ensure consistency, precision, and accuracy of all deliverables.  The business vocabulary (concept model) is the glue that holds the deliverables together.

Validation suggestions:

• A term in the concept model is used by at least one of the deliverables above.
• All deliverables above use consistent terminology defined in concept model.

The above validation suggestions are for validation across different deliverables.  You also need to validate within a deliverable.  A couple of examples are provided below.

Figure 2.  Example of a review of a set of business rules. 

Figure 2 shows four business rules all using the term relating to 'finish date'. 

• Business rule 'Series 001' uses 'finish date'.
• Business rules 'Series 002' and 'Series 004' use the term 'actual finish date'.
• Business rule 'Series 008' uses the term 'forecast finish date'.  

Should 'actual finish date' or 'forecast finish date' be used in business rule 'Series 001'?  Precision is required in these business rule statements.

Figure 3.  Example of a review of a decision table. 

Figure 3 shows an initial decision table of four considerations and five business rules (i.e., each column is a business rule). 

• The consideration 'Vaccine Dose Administered Volume < Preferable Vaccine Volume?' has value 'yes' for rule 1 (first column).
• The consideration 'Vaccine Dose Administered Volume < Preferable Vaccine Volume?' has value 'no' for rule 2 (second column).
• The consideration 'Vaccine Dose Administered Volume < Preferable Vaccine Volume?' has value '-' (does not matter) in the rest of the rules.
• The outcome for rule 1 and for rule 2 is the same.

Essentially, the consideration 'Vaccine Dose Administered Volume < Preferable Vaccine Volume?' makes no impact to the outcome.  It is not needed in this decision table. 

These examples show only two of the several kinds of analysis required.  Other required analyses include gap analysis, conflict analysis, and redundancy analysis on all deliverables.

Just Remember…

Plainly speaking, here are some of the main things you need to remember:

• Each deliverable serves a distinct purpose:  providing the structure to ask the right question at the right time.
  
  
• All deliverables need to work together cohesively to provide a complete solution.
  
  
• Validation across deliverables enables you to spot gaps, conflicts, and inconsistencies.

For further information, please visit BRSolutions.com     

References

[1]  Building Business Solutions:  Business Analysis with Business Rules by Ronald G. Ross with Gladys S. W. Lam.  www.BRSolutions.com  

[2]  Decision Analysis:  A Primer… How to Use Decision Speak™ and Question Charts (Q-Charts™) by Ronald G. Ross.  www.BRSolutions.com  

[3]  Decision Analysis:  A Primer… How to Use Decision Speak™ and Question Charts (Q-Charts™) by Ronald G. Ross.  www.BRSolutions.com  

[4]  Decision Tables:  A Primer… How to Use TableSpeak™ by Ronald G. Ross.  www.BRSolutions.com  

[5]  Business Rule Concepts by Ronald G. Ross.  www.BRSolutions.com  

[6]  Business Rule Concepts by Ronald G. Ross.  www.BRSolutions.com  

# # #