Task: Execute Rule Discovery Roadmap
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
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    		Optional:
      Outputs
        Main Description

        Rule elicitation is an ongoing activity you perform throughout the project. Collaboration with your stakeholders is critical. They will change their minds as the project proceeds and that's perfectly fine.

        The documentation of the rule may be done using different language. The natural language is initially used during business conversations to describe the rule, informally, without trying to impose any structure. SMEs express their ideas using a language very close to them, but they usually are not able to formalize their concepts in a clear and unambiguous way. Using this language we may have redundancy and inconstancy in the rule expression, in the business terms, and overall by it may not be relevant and precise enough to be able to implement the decision logic.

        Conceptualization and representation play fundamental roles in thinking, communicating, and modeling.

        A second evolution is still in natural language, and is still consumable by both analysts and developers, but, we have imposed some structure, and we made sure that they are relevant and have the right form, but may not be correct semantically. We use the rule description template to log the rule.

        The last type of expressiveness of the language to document the rule is precise and there are no ambiguities: the rule refers exactly to information system objects. This language is parse-able and non-ambiguous. Semantics of Business Vocabulary and Business Rules or SBVR from Object Management Group can be used at this stage to specify formally representations of concepts, definitions, instances, and rules in natural language.

        Steps
        Discover rule from Subject Matter Expert
        Discover rules from Subject Matter Expert using workshop sessions. There are two types of interactions: interviews and analysis workshop. For interview the typical number of people in the same room is around two or three. Workshop implies a bigger logistic with six to ten persons involved.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. When using electronic document annotate it on anything that needs some future discussion, copy and paste the business policy to the rule template to clearly isolate it for future analysis.

        One risk with this approach is 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.

        So we recommend a strong discipline to be able to achieve the following goal:

        • Get an exhaustive list of the business events under scope: log them in a table
        • Get the activities, tasks, processes that support the processing of those business events
        • Get the business motivation behind the rules
        • Get explanation on rule if they are unclear, ambiguous.
        • Try to extract the object model under scope, domain values
        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) 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.

        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
        Guidelines

        This program and the accompanying materials are made available under the
        Eclipse Public License V1.0, which accompanies this distribution.

        EPF Copyright.