Task: Execute Rule Discovery Workshop
This activity or task includes the three types of rule discovery: business users and experts workshop session, document study, legacy code mining. Even if the main source of rules are documents or code, it is still important to come back to a SME to get feedbacks on the team findings.
Disciplines: Rule Discovery
Purpose
Discover the business rules from the different sources
Relationships
Main Description
Steps
Discover rule from Subject Matter Expert
Discover rules from Subject Matter Expert using workshop sessions. The requirements workshop is perhaps the most powerful technique for eliciting requirements. It gathers all key stakeholders together for a short but intensely focused period. The use of an outside facilitator experienced in requirements management can ensure the success of the workshop. Brainstorming is the most efficient techniques used during the sessions.
Discover rule from documentation
Discover rules from legal document or from policies description. This elicitation method is a less efficient to extract the rules. The main reasons are that the reader is making his own interpretation of the context, the document may not include all the cases and rules, it is some time difficult to get some of the business motivation.
Discover rule from code

Discover rules from current application code. This elicitation method is time consuming and does not lead to great results. The analyst needs to study a lot of line of codes, and procedures (most of the time in old computer language like Cobol) to find some if statement that are linked to business decision. Depending of the design and code structure of the application this work can take time. It is important to do not forget the context of execution of the application when the if statement is executed, some variables have can be set that may change the implemented “business rules”. The different variable names set for a concept may lead to difficulties to understand a rule.

Code mining tools exist on the market which help to extract if statement and the variables meaning. It is important to keep in mind that rule written in the past may not be relevant any more.

Discover term, facts and the logical data model

From all the information captured in the artifacts developed in the previous steps, we can identify the Terms and Facts and business entities.

Terms and facts are important for designing a business object model and a data model. From the terms and facts, we should be able to design a first cut of the logical object model.

 

The fact has to be analyzed to understand how the application will support it. It can be through use case implementation, business rule, relation between objects …

Fact

Description

How to support it

Customer can place order

 

Use case: application flow + panel on the web

+ relation Customer – order 0 to many

One or more customers can apply for mortgage loan product.

For multiple customers, it would be a joint application.

Some control of the profile of the customer may be implemented on business rules.

Loan products will be selected by looking at customer profile and Loan application. This logic will be done in business rules

A mortgage loan application can be applied for multiple mortgage loans.

 

Same as previous

A scorecard is assigned to a mortgage loan.

 

Relation between scorecard and loan 0 to 1

 

It is important to verify that the business terms and entities are present in the implemented logical object model. If there is some issue the analysis team needs to look at if the business term is not represented differently, or if we can add it to the logical data model.


Logical Data Model is used to explore the domain concepts, and their relationships, of the business domain. We may use simple diagramming techniques to layout a Logical Data Model, even a UML class diagram (without method signatures) can be efficient.


Document the business rules with some first level of meta data

Use template for writing rule description during the discovery phase.

To document the rule try to use the language of the business ("problem domain") rather than the language of the technology ("solution domain")

The following rule is as stated by a business user in a car rental industry:

“Each driver authorized to drive a car of group K must be over 29”

 

A rule developer may better think to document the rule as

If the age of the driver is less than 29 and the requested group of the reservation is K, modify the authorized attribute of the driver accordingly

More Information