Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Getting It Right

3,815 views

Published on

Why and how to separate business rules, and business requirements

Published in: Business, Technology

Getting It Right

  1. 1. Getting it Right Rules and Requirements in Software James Taylor Scott Sehlhorst
  2. 2. Agenda <ul><li>Challenges in Specifying Systems </li></ul><ul><li>Business Rules Specification </li></ul><ul><li>Requirements Specification </li></ul><ul><li>Using them together </li></ul>
  3. 3. Challenges in Specifying Systems Elicitation of requirements, processes, rules is error prone
  4. 4. Challenges in Specifying Systems Elicitation of requirements, processes, rules is error prone Implementation of complex software takes too long
  5. 5. Challenges in Specifying Systems Elicitation of requirements, processes, rules is error prone Implementation of complex software takes too long Changing existing applications takes too long
  6. 6. Challenges in Specifying Systems Elicitation of requirements, processes, rules is error prone Maintenance costs are excessive Implementation of complex software takes too long Changing existing applications takes too long
  7. 7. The Challenges / Goals
  8. 8. The Challenges / Goals
  9. 9. The Challenges / Goals
  10. 10. Enabling Business Agility <ul><li>Managing Rules and Requirements Independently </li></ul><ul><li>Enables and Encourages Easy-To-Change Solutions </li></ul>
  11. 11. Rules & Requirements <ul><li>Both capture business knowledge </li></ul><ul><li>Both clarify customer needs and expectations </li></ul><ul><li>Both reflect business need </li></ul>
  12. 12. Why Separate Rules from Requirements? <ul><li>Rules change independently of requirements </li></ul><ul><li>Rules are reused throughout the requirements </li></ul><ul><li>Isolated rules can be analyzed for accuracy and completeness </li></ul><ul><li>Separation in documentation leads to separation in implementation </li></ul><ul><li>Simplified approval process </li></ul><ul><li>Reuse yields reduced work </li></ul><ul><li>Reuse allows leverage of rules across projects </li></ul><ul><li>Analysis can be automated </li></ul><ul><li>Faster implementation </li></ul><ul><li>More maintainable code </li></ul><ul><li>Simplified change management </li></ul>
  13. 13. Different Models for Different Needs
  14. 14. Agenda <ul><li>Challenges in Specifying Systems </li></ul><ul><li>Business Rules Specification </li></ul><ul><li>Requirements Specification </li></ul><ul><li>Using them together </li></ul>
  15. 15. What are Business Rules?
  16. 16. What are Business Rules? <ul><li>“ … directives intended to influence behavior.” </li></ul>
  17. 17. What are Business Rules? <ul><li>“… formal expressions of knowledge or preference, a guidance system for steering behavior...” </li></ul>
  18. 18. What are Business Rules? <ul><li>“… statements of the actions you should take when certain business conditions are true.” </li></ul>
  19. 19. What are Business Rules? <ul><li>“… heuristics or tools to make business decisions ” </li></ul>
  20. 20. What is a Rule? <ul><li>Computation Rules </li></ul><ul><li>Inferences </li></ul><ul><li>Process Flow Rules </li></ul><ul><li>Action Enablers </li></ul><ul><li>Data Edits and Constraints </li></ul>
  21. 21. Capturing Rules <ul><li>The capturing of rules can be summarized in the following steps: </li></ul><ul><ul><li>Document your process </li></ul></ul><ul><ul><li>Identify decisions in the process </li></ul></ul><ul><ul><li>Identify and validate the rules that make up each decision </li></ul></ul>
  22. 22. Documenting Rules <ul><li>Documenting Rules </li></ul><ul><ul><li>Each individual rule is documented distinctly </li></ul></ul><ul><ul><li>Sets of rules are combined to reach decisions </li></ul></ul><ul><ul><li>Rules can have hierarchies and relationships to each other </li></ul></ul><ul><ul><li>Decisions (rulesets) can have dependencies on one another </li></ul></ul>
  23. 23. Agenda <ul><li>Challenges in Specifying Systems </li></ul><ul><li>Business Rules Specification </li></ul><ul><li>Requirements Specification </li></ul><ul><li>Using them together </li></ul>
  24. 24. Requirements Framework
  25. 25. Agenda <ul><li>Challenges in Specifying Systems </li></ul><ul><li>Business Rules Specification </li></ul><ul><li>Requirements Specification </li></ul><ul><li>Using them together </li></ul>
  26. 26. Rules and Requirements Overview
  27. 27. Rules and Requirements Overview
  28. 28. Rules and Requirements Overview
  29. 29. Rules and Requirements Overview
  30. 30. Traceability (Rules <-> Requirements)
  31. 31. Traceability (Rules <-> Requirements)
  32. 32. Traceability (Rules <-> Requirements)
  33. 33. Traceability (Rules <-> Requirements)
  34. 34. Process Candidates for Business Rules <ul><li>Multiple decision steps in the process </li></ul><ul><ul><li>Assess, Compare </li></ul></ul><ul><ul><li>Calculate, Compute </li></ul></ul><ul><ul><li>Check, Confirm </li></ul></ul><ul><ul><li>Qualify, Decide </li></ul></ul><ul><ul><li>Determine, Diagnose, Evaluate </li></ul></ul><ul><ul><li>Estimate, Process </li></ul></ul><ul><ul><li>Test, Validate, Verify </li></ul></ul>
  35. 35. Process Candidates for Business Rules <ul><li>Symbolic reasoning </li></ul><ul><ul><li>if then </li></ul></ul><ul><ul><li>unless </li></ul></ul><ul><ul><li>only if </li></ul></ul><ul><ul><li>is a necessary condition for </li></ul></ul><ul><ul><li>is a sufficient condition for </li></ul></ul><ul><ul><li>consequently </li></ul></ul><ul><ul><li>therefore </li></ul></ul>
  36. 36. Process Candidates for Business Rules <ul><li>Complex rules, decisions, multi-level reasoning </li></ul><ul><ul><li>risk analysis </li></ul></ul><ul><ul><li>underwriting </li></ul></ul><ul><ul><li>identifying allowed combinations / configurations </li></ul></ul>
  37. 37. Framework for Documentation <ul><li>Process Documentation or Use Cases or Both? </li></ul>
  38. 38. Process Documentation
  39. 39. Use Cases <ul><li>Look for Rules in the following </li></ul><ul><ul><li>Description </li></ul></ul><ul><ul><ul><li>Embedded constraints </li></ul></ul></ul><ul><ul><li>Triggers </li></ul></ul><ul><ul><ul><li>Action enablers </li></ul></ul></ul><ul><ul><li>Preconditions </li></ul></ul><ul><ul><ul><li>Constraints </li></ul></ul></ul><ul><ul><li>All Flows </li></ul></ul><ul><ul><ul><li>Computations </li></ul></ul></ul><ul><ul><ul><li>Decisions </li></ul></ul></ul>
  40. 40. Use Case: Description <ul><li>A pilot performs an FAA mandated list of equipment and operational inspections prior to every flight. All inspections must pass before the flight is allowed to take off per corporate policy. </li></ul><ul><li>A pilot performs an FAA mandated list of equipment and operational inspections prior to every flight. All inspections must pass before the flight is allowed to take off per corporate policy . </li></ul><ul><li>A pilot performs an FAA mandated list of equipment and operational inspections [see FAA-1] prior to flights. </li></ul><ul><li>A pilot performs an FAA mandated list of equipment and operational inspections [see FAA-1] prior to flights. </li></ul>
  41. 41. Use Case: Triggers <ul><li>Every Friday at 5pm </li></ul><ul><li>Order size exceeds $1KK </li></ul><ul><li>More than 100 orders are queued </li></ul><ul><li>It is time to process pending orders [See BR021, Order-processing triggers ]. </li></ul>
  42. 42. Use Case: Preconditions <ul><li>The amount of the loan has been identified: </li></ul><ul><ul><li>Loan amount is below $250K </li></ul></ul><ul><ul><li>Loan represents >80% equity </li></ul></ul><ul><li>A maximum amount for the loan has been identified [See BR033, Determining proper loan process ]. </li></ul>
  43. 43. Use Case: Normal Flow <ul><li>1.  User provides personal information. [See FR22 for details] </li></ul><ul><li>2.  System requests loan approval </li></ul><ul><ul><ul><li>Includes loan amt, down-payment amount, credit rating </li></ul></ul></ul><ul><li>3.  Loan-Approval System responds that loan is approved. </li></ul><ul><li>4.  System requests loan initiation </li></ul><ul><li>5.  Loan-Processing System responds that loan has been created and funds are available </li></ul><ul><li>6.  System notifies user that loan has been approved. </li></ul><ul><li>1.  User provides personal information per BR1255 [Required Loan Application Information] </li></ul><ul><li>2.  System requests loan approval per BR1256 [Required Loan Approval Information] </li></ul><ul><li>3.  Loan-Approval System responds that loan is approved. </li></ul><ul><li>4.  System requests loan initiation per </li></ul><ul><li>5.  Loan-Processing System responds that loan has been created and funds are available </li></ul><ul><li>6.  System notifies user that loan has been approved. </li></ul>
  44. 44. Review of Use Cases & Rules
  45. 45. The one slide you need <ul><li>The rules of a decision are not part of requirements, or of processes </li></ul><ul><li>Decisions are important and different </li></ul><ul><li>Managing rules, requirements and processes separately but traceably gives you maximum accuracy while retaining agility </li></ul><ul><li>Beware of hidden decisions, hidden rules </li></ul><ul><li>Managing rules in parallel with requirements always helps </li></ul><ul><li>Managing rules at design and execution time, with a business rules management system, really helps with volatile rules </li></ul><ul><li>Rules Are Not Requirements! </li></ul>
  46. 46. Thanks James Taylor – [email_address] Scott Sehlhorst – [email_address]
  47. 47. Resources <ul><li>Blogs </li></ul><ul><ul><li>www.edmblog.com </li></ul></ul><ul><ul><li>www.ebizq.net/blogs/decision_management </li></ul></ul><ul><ul><li>www.tynerblain.com/blog </li></ul></ul><ul><li>Wikis </li></ul><ul><ul><li>www.smartenoughsystems.com/wiki </li></ul></ul><ul><li>Articles </li></ul><ul><ul><li>http://www.businessrulesgroup.org/brmanifesto.htm </li></ul></ul><ul><ul><li>http://wiki.ittoolbox.com/index.php/What_makes_a_good_Business_Rule? </li></ul></ul><ul><li>Books: </li></ul><ul><ul><li>Smart (Enough) Systems , Taylor and Raden, Prentice Hall </li></ul></ul><ul><ul><li>Use Cases: Requirements in Context , Kulak and Guiney </li></ul></ul><ul><ul><li>Writing Effective Use Cases , Cockburn </li></ul></ul><ul><ul><li>Patterns for Effective Use Cases , Bramble, Cockburn, Pols, Adolph </li></ul></ul>

×