Business Rules and Requirements

1. Business Rules and Requirements © Ed Green Penn State University All Rights Reserved

2. Stating the Challenge • Provide information solutions of exceptional quality • Meet the changing needs of the enterprise • Respond to organizational culture and its changing nature • Reduce costs • Improve productivity and profitability Business Rules and Requirements

3. Concept of Business Rules • Set of underlying principles that provide enterprise governance and guidance • Allows for variations across enterprises • Many points of similarity • External forces • Common goals Business Rules and Requirements

4. Critical Issues • Normal performance level of IT would be appalling and sub-standard in every other major industry • Inability to produce software in a well-ordered way costs several billion dollars (US) annually • Current culture emphasizes programming • Majority of software problems emanate for specification errors • Often a communications problem • Programmers programming the wrong thing Good design may save poor programming, but exceptional programming will never save bad design Business Rules and Requirements

5. What Is A Business Rule • Compact statement about some aspect of a business • Expressed in terms directly related to the business • Simple, unambiguous language that is common to all stakeholders • GUIDE“a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. Business Rules and Requirements

6. Developer Tester Building Software – Current Process Business Descriptions (Redefine Operational System Deploy Evaluate, Use Interpret (Redefine Interact Business Owner System Administrator Deployment Constraints Integrate Interact Analyst Interact Software Modules Code Errors Define Test Define Interpret Structured System Descriptions Create, Refine Source Code System Development Generate Business Rules and Requirements

7. Issues With Current Development Process • Business owner – person who needs software, is underwriting the costs, has business but not technical acumen • Process contains implicit acceptance of frailty • Process relies on descriptive materials requiring interpretation • Exacerbates communications gap between end users and developers producing a“I heard what you said but not what you meant!!”mentality • Process is labor intensive • Process is slow • Process does not address risk management/mitigation naturally Developing software is risky, slow, and expensive Business Rules and Requirements

8. System Development Vision Evaluate, Use Operational System Deploy (Redefine Business Owner Review Structured Business Descriptions Human Readable Views Structured Deployment components Manage (Redefine Software Modules Generate Machine Readable Views Generate Generate System Development Business Rules and Requirements

9. Implications of the Vision • Reduced system development time following requirements stabilization • Staffing profile shift • Fewer programmers and testers • More software analysts and software engineers • Significantly improved software quality • Somewhat lowered software performance efficiency Business Rules and Requirements

10. Practicality of the Vision • Software code generation is an inhibited technology • Perception – subservient to manual programming • Current modeling technology do not provide for requisite information richness needed for automation • Lack of standardized approach to expressing business and technical architecture needs • The problem is difficult • Realistic steps • Increase structure for describing business needs • Improve structure for describing computing environment • Generate code fragments from enhanced business descriptions • Focus development on refinement/extension of generated code vis a vis creation. Accept, within limits, some degree of inefficiency • Package developed software in component form; simplify subsequent management/deployment; focus on interfaces; hide implementation details • Emphasize process improvement; use the best people; quantify, measure and continually review the process. • Reduce common system elements to manageable/reusable templates. Increase levels of commonality. Move differentiators into rule sets. Business Rules and Requirements

11. Defining Business Rules Business Rules and Requirements

12. Defining Business Rules • Rule statements • Forming rule statements • Construction rules Business Rules and Requirements

13. Rule Statements • Characteristics • Business Aspects of Rule Statements • Rule Contents • Expression Levels • Rule Definition Options • Culture Impacts Business Rules and Requirements

14. Characteristics of Rules • Constraints – • Define conditions that MUST hold true in specified situations • WHAT must be the case rather than HOW it came to be • Define the desired logic of the business • Conditions to be detected • Actions required to establish a state of “TRUE” • Characteristics • Atomic – elementary and essential; beyond (further) decomposition • Unambiguous – single, clear meaning not subject to interpretation • Compact – tightly worded without fluff or flourish • Consistent – logically connected to others of its kind • Compatible – common language with the business model and the environment • Power of business rules • Business-level statements translatable into requirements for an operational system • Combinational so that the value of the whole is greater than the sum of the individual requirements Business Rules and Requirements

15. Business Aspects of Rule Statements • Concerns • Reducing/minimizing risks • Improving customer service • Optimizing utilization of (corporate) resources • Controlling/managing workflow Business Rules and Requirements

16. Rule Content • Defines what the case should be • Does not prescribe • Who invokes the rule • When the rule is executed • Where the rule executes • How the rule is implemented • Two issues • Why is a rule important • When failure occurs, why did it happen? Business Rules and Requirements

17. Levels of Expression (Rules) • Informal – colloquial or natural language • Technical • Structured data references • Operators • Constrained natural language • Formal – statements conforming to a more closely defined syntax with mathematical properties Business Rules and Requirements

18. Low-technology Rule Definition Fact Model Rule Text Rule Structure Implementation Analyst Developer Designer Business Signoff Business Rules and Requirements

19. Developer Designer Business Signoff Controlled Rule Definition Implementation Code Generator Fact Model Test Rule Structure Fact Definer Fact Definer Analyst Rule Template Rule Text Business Rules and Requirements

20. Business Definition Long Term Objective For Business Rule Definition Othermodel elements Code Generator Implementation Fact Model Rule Structure Fact Definer Rule Definer Rule Template Rule Text Business Rules and Requirements

21. Cultural Impacts • Nature of work will change • Increased computer and technology literacy • Increased business knowledge • Evolution of the information technology workforce • From guildsman and artisans • To engineers using commonly accepted standards and processes • Changing job descriptions • Increasing job challenges and opportunities Business Rules and Requirements

22. Forming Rule Statements • Overview • Pattern conventions • Rule patterns Business Rules and Requirements

23. Rule Statements and Relationships UML Classes Implementation View of Translates to Defines terms for Equates to Fact Model Business Rule Statement Formal Expression Stored in Rule Template Rule Database Defines structure for Stored in Business Rules and Requirements

24. Pattern Conventions (1) Business Rules and Requirements

25. Pattern Conventions (2) • Language elements • Taken together, with rules for usage, create a grammar • Rule patterns • Basic constraint – direct statement of condition • List constraint – use one or more items from a list • Classification – establishing a definition for using elements of the fact model • Computation – establishes a relationship between terms in the fact model to allow determination or establishment of a value • Enumeration – establishes a range or set of values that can be taken by an element in the fact model Business Rules and Requirements

26. Fact Models • Shows artifacts with persistent values • Business objects • Relationships among business objects • Attributes of business objects • Differentiate between items of business record versus operational artifacts with transient values Business Rules and Requirements

27. Rule Construction • Using facts • Simple constraints • Quantification and qualification • States and events • Actors • Verb utilization • Structure and consistency Business Rules and Requirements

28. Using Facts • Utilize a fact model • Visible elements • Relate rule to elements in the business model • Question basic assumptions; simplify by reducing any associated qualifications • Question terminology; be specific; do not generalize • Establish explicit relationships so that constraints are clearly defined • Avoid facts and terms not adequately qualified • Use the “necessary and sufficient” standard • Avoid vague terms Business Rules and Requirements

29. Simple Constraints • Avoid unqualified terms that explicitly or implicitly grant permissions • Remember that the purpose of a rule is to define mandatory and/or prohibited conditions • Do not elaborate • Keep rules succinct and concise • Make every word count • Do not use an ‘OR’ construct • Decompose into multiple atomic rules • Use an ‘AND’ construct if and only if BOTH conditions must define truth • Avoid complexity and emphasize simplicity • Every rule should be atomic and elementary • Never use an ‘IF THEN ELSE’ construct in a business rule Business Rules and Requirements

30. Quantification and Qualification • Ask assessment questions • Necessary • Appropriate • Correctness of ranges • Correctness of specific values • Specified elsewhere • Avoid using plurals of terms in rules • Use ‘EACH’ and/or ‘EVERY’ where appropriate Business Rules and Requirements

31. States and Events • A business event is a state • Not a business action • Cause rules to be evaluated • Not subject of a rule • Be clear and unambiguous • Terminology • Time frames and time lines • Avoid conditionals statements • ‘IF’ constructs • ‘WHEN’ constructs Business Rules and Requirements

32. Actors • Be certain that actors are needed and clearly defined and described • Do not make actors the subject of rules Business Rules and Requirements

33. Dangerous Verbs • Command verb forms • Action verbs • Create unclear definitions • CRUD words • Create • Read • Update • Delete Business Rules and Requirements

34. Computation • Make the computational result the subject of the rule • Avoid embedded computations Business Rules and Requirements

35. Structure and Consistency • Identify missing rules • Are all situations covered? • Check for overlap • Boolean intersection  • Identify duplicate rules • Multiple rules saying the same things • Be wary of inverted expression • Use straight forward wording • Validate that rules do not conflict • Multiple rules producing contradictory results • Verify references among rule statements Business Rules and Requirements

36. Discovering Business Rules Business Rules and Requirements

37. Discovering Business Rules • Sources of Rules • Kinds of Rules • Information Sources • Indicators • State Transition Theory • Decision Trees • Finding Rules • Static Analysis • Interactive Sources • Automated Discovery Business Rules and Requirements

38. Sources of Rules • Anywhere in the enterprise or extended enterprise • Anyone in the enterprise or extended enterprise • Any time something is happening • Any place something is happening Discovery can happen without warning . . . . . . never, ever be surprised Business Rules and Requirements

39. Kinds of Rules • Structural • Describe constraints and/or relationships among the elements of the enterprise • Behavioral • Define a course of action to be followed or process to be executed • Add detail to the process model (process architecture) • Common features in workflow and information flow environments • Define recognition of and response to business events • Definitional • Provide a (set of) value(s) that explain terminology and/or relationships associated with elements of the enterprise Business Rules and Requirements

40. Information Sources • Documentation • Causal elements/agents • Explanatory/supportive materials • History and relevancy • Tacit know-how • Intellectual property • Automation systems • Program source code • Business records • Due diligence Business Rules and Requirements

41. Externally-defined features and/or mandates Systematic variations among organizational units Entities with multiple states Specializations Subclasses Automated decision making Boundary definitions Time-centricity Quality standards and specifications ISO 9000 Significant discriminators Event-based activities Definitions, derivations, and calculations Indicators in the Discovery Process Business Rules and Requirements

42. State Transition Theory • Describes conditions and outcomes • Identifies • Prior state • Action • Succeeding state • State Transition Diagram documents flows across an environment • Enterprise • Information system Business Rules and Requirements

43. State Transition Diagram Nest State (Alternative 1) Action 1 Action 2 Current State Next State (Alternative 2) Action 3 Next State (Alternative 3) Business Rules and Requirements

44. State Transitions Action Prior State 1 • Current state can be reached from multiple prior states • Actions on prior states likely to be dissimilar • Transition from current state to next state not usually dependent on arrival from prior state Action Prior State 2 Current State Prior State 3 Action Business Rules and Requirements

45. Decision Trees • Pictorial depiction of thought processing • Network based on decisions and uncertainty analysis • Probabilistic • Risk-associative • Howard Raiffa, Decision Analysis: Introductory Lectures on Choices under Uncertainty, 1970, Addison-Wesley, Library of Congress Catalog 68-31436 Business Rules and Requirements

46. Decision Tree Schematic Any of these statesare possible p Following statedetermined bypreceding eventsand decisions Probability of each state is p p Given this state p Business Rules and Requirements

47. Finding Rules • Organizing Approaches • Static analysis • Interactive sessions • Automated rule discovery Business Rules and Requirements

48. Static Analysis • Types of source documents • Internal • External • Analyzing documents • Get an electronic copy • Develop a system and follow it • Read carefully (usually between the lines) • Focus on early correctness; worry structure, traceability, and cross-referencing later. • Align with current business model; identify conflicts and disconnects; demand clarity • Focus on stakeholder understanding; keep political constraints in sight • Identify open issues; assign action items Business Rules and Requirements

49. Interactive Sessions • Participatory session involving both technical and business practioners • Involves dialog and sharing • Two forms • Structured interviews • Analysis workshops • Characteristics Business Rules and Requirements

50. Structured Interviews Research and understand interviewee Observe usual courtesies Keep careful notes Make records Provide feedback Analysis Workshops Define the goal and the approach Prepare, prepare, prepare! Facilitate the workshop session Execute follow-up actions and requirements Review Interactive Sessions Business Rules and Requirements