Print Glossary FAQs
Case Studies Resources

send to a friend

GEMI Contact Info:

1155 15th Street, NW
Suite 500
Washington, DC 20005
Phone: 202-296-7449
Fax: 202-296-7442

About GEMI

Printer Friendly Page          
Business Rules


Business Rules describe each process identified during Process Mapping, the goal being to identify the specific tasks necessary to meet existing and new compliance and business drivers.

 Key Concepts  
  • Business Rules are the basis for automating the business processes. Correctly defined and documented, Business Rules allow systems developers to translate the processes into computer code so the resulting applications provide the information the users need.
  • Business Rules cannot be completely defined without input from the cross-functional team.
  • Evaluating tools and methods is key to illustrating existing capability and defining enhancements.
  • Business Rules are complex and may be easier to show or demonstrate rather than write down. Defining, testing, and eliciting feedback on a set of Business Rules helps bridge the gap between the drawing board and the working computer system.

    (See example Business Rules Flowchart - Title V Certification Process)

     Practical Advice  
    • Define the Business Rules before attempting to develop or purchase software. This will save significant project resources and help speed up the development process. Moving forward without business rules is not advisable and could result in solutions that do not meet the HSE-MIS Plan objectives.
    • Consider sending the non-HSE project managers and/or developers to HSE subject matter training so that they can better understand HSE processes. It may also be beneficial to help HSE team members become more familiar with information technology processes and approaches.
    • When communicating your business rules to software developers or evaluators:
      • Use demonstration tools such as a proof-of-concept system (a snapshot of the future--whether it is a working model used as a basis for the future system), flow charts, and real examples to demonstrate and validate Business Rules. These tools provide the user with an idea of how the system will look and feel.
      • Whatever you choose as a tool, make sure it fits with the Business Rules.
      • [Add link to the Title V flowchart]
    • When using a proof-of-concept system determine up front if the proof-of-concept system will be part of the final solution.
    • Demonstration tools are most useful when business requirements are not clear or well understood or the business rule tools and necessary data are readily available to build working systems.
    • Dedicate resources to document the system requirements. The use of demonstration tools does not preclude the need to have formal documentation. Documentation aids integration into other existing and planned systems.
    • Ensure that the use of demonstration tools is not done in isolation from a complete system development process. These processes are most commonly known, in MIS terms, as the System Development Life Cycle. They should include the life cycle steps necessary for proof-of-concept.    
    • Use Business Rules to separate "must-have" functionality from "would be nice to have." Make sure to assess any costs associated with non-essential system components or enhancements.
    • Once defined, test and demonstrate the Business Rules. Ensure the Business Rules follow current or desired function and critical path.

      Case Studies  


    About Contact Us Site Map Credits Disclaimer
    All contents © GEMI Inc., All Rights Reserved.