The document discusses challenges in specifying software systems and separating business rules from requirements. It provides an overview of capturing and documenting business rules, and using a requirements framework with traceability between rules and requirements. Process flows and use cases are examples given of where to identify business rules. The key point is that rules of decisions are not requirements, and managing them separately but traceably provides accuracy and agility.

1. Getting it Right Rules and Requirements in Software James Taylor Scott Sehlhorst

2. Agenda Challenges in Specifying Systems Business Rules Specification Requirements Specification Using them together

3. Challenges in Specifying Systems Elicitation of requirements, processes, rules is error prone

4. Challenges in Specifying Systems Elicitation of requirements, processes, rules is error prone Implementation of complex software takes too long

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. 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. The Challenges / Goals

8. The Challenges / Goals

9. The Challenges / Goals

10. Enabling Business Agility Managing Rules and Requirements Independently Enables and Encourages Easy-To-Change Solutions

11. Rules & Requirements Both capture business knowledge Both clarify customer needs and expectations Both reflect business need

12. Why Separate Rules from Requirements? Rules change independently of requirements Rules are reused throughout the requirements Isolated rules can be analyzed for accuracy and completeness Separation in documentation leads to separation in implementation Simplified approval process Reuse yields reduced work Reuse allows leverage of rules across projects Analysis can be automated Faster implementation More maintainable code Simplified change management

13. Different Models for Different Needs

14. Agenda Challenges in Specifying Systems Business Rules Specification Requirements Specification Using them together

15. What are Business Rules?

16. What are Business Rules? “ … directives intended to influence behavior.”

17. What are Business Rules? “… formal expressions of knowledge or preference, a guidance system for steering behavior...”

18. What are Business Rules? “… statements of the actions you should take when certain business conditions are true.”

19. What are Business Rules? “… heuristics or tools to make business decisions ”

20. What is a Rule? Computation Rules Inferences Process Flow Rules Action Enablers Data Edits and Constraints

21. Capturing Rules The capturing of rules can be summarized in the following steps: Document your process Identify decisions in the process Identify and validate the rules that make up each decision

22. Documenting Rules Documenting Rules Each individual rule is documented distinctly Sets of rules are combined to reach decisions Rules can have hierarchies and relationships to each other Decisions (rulesets) can have dependencies on one another

23. Agenda Challenges in Specifying Systems Business Rules Specification Requirements Specification Using them together

24. Requirements Framework

25. Agenda Challenges in Specifying Systems Business Rules Specification Requirements Specification Using them together

26. Rules and Requirements Overview

27. Rules and Requirements Overview

28. Rules and Requirements Overview

29. Rules and Requirements Overview

30. Traceability (Rules <-> Requirements)

31. Traceability (Rules <-> Requirements)

32. Traceability (Rules <-> Requirements)

33. Traceability (Rules <-> Requirements)

34. Process Candidates for Business Rules Multiple decision steps in the process Assess, Compare Calculate, Compute Check, Confirm Qualify, Decide Determine, Diagnose, Evaluate Estimate, Process Test, Validate, Verify

35. Process Candidates for Business Rules Symbolic reasoning if then unless only if is a necessary condition for is a sufficient condition for consequently therefore

36. Process Candidates for Business Rules Complex rules, decisions, multi-level reasoning risk analysis underwriting identifying allowed combinations / configurations

37. Framework for Documentation Process Documentation or Use Cases or Both?

38. Process Documentation

39. Use Cases Look for Rules in the following Description Embedded constraints Triggers Action enablers Preconditions Constraints All Flows Computations Decisions

40. Use Case: Description 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. 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 . A pilot performs an FAA mandated list of equipment and operational inspections [see FAA-1] prior to flights. A pilot performs an FAA mandated list of equipment and operational inspections [see FAA-1] prior to flights.

41. Use Case: Triggers Every Friday at 5pm Order size exceeds $1KK More than 100 orders are queued It is time to process pending orders [See BR021, Order-processing triggers ].

42. Use Case: Preconditions The amount of the loan has been identified: Loan amount is below $250K Loan represents >80% equity A maximum amount for the loan has been identified [See BR033, Determining proper loan process ].

43. Use Case: Normal Flow 1. User provides personal information. [See FR22 for details] 2. System requests loan approval Includes loan amt, down-payment amount, credit rating 3. Loan-Approval System responds that loan is approved. 4. System requests loan initiation 5. Loan-Processing System responds that loan has been created and funds are available 6. System notifies user that loan has been approved. 1. User provides personal information per BR1255 [Required Loan Application Information] 2. System requests loan approval per BR1256 [Required Loan Approval Information] 3. Loan-Approval System responds that loan is approved. 4. System requests loan initiation per 5. Loan-Processing System responds that loan has been created and funds are available 6. System notifies user that loan has been approved.

44. Review of Use Cases & Rules

45. The one slide you need The rules of a decision are not part of requirements, or of processes Decisions are important and different Managing rules, requirements and processes separately but traceably gives you maximum accuracy while retaining agility Beware of hidden decisions, hidden rules Managing rules in parallel with requirements always helps Managing rules at design and execution time, with a business rules management system, really helps with volatile rules Rules Are Not Requirements!

46. Thanks James Taylor – [email_address] Scott Sehlhorst – [email_address]

47. Resources Blogs www.edmblog.com www.ebizq.net/blogs/decision_management www.tynerblain.com/blog Wikis www.smartenoughsystems.com/wiki Articles http://www.businessrulesgroup.org/brmanifesto.htm http://wiki.ittoolbox.com/index.php/What_makes_a_good_Business_Rule? Books: Smart (Enough) Systems , Taylor and Raden, Prentice Hall Use Cases: Requirements in Context , Kulak and Guiney Writing Effective Use Cases , Cockburn Patterns for Effective Use Cases , Bramble, Cockburn, Pols, Adolph