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

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

Challenges in Specifying Systems

Business Rules Specification

Requirements Specification

Using them together

Introductions James Taylor Smart Enough Systems Blogs: www.edmblog.com www.ebizq.net/blogs/decision_management Book: Smart (Enough) Systems with Neil Raden Scott Sehlhorst Tyner Blain Blog: www.tynerblain.com/blog

James Taylor

Smart Enough Systems

Blogs:

www.edmblog.com

www.ebizq.net/blogs/decision_management

Book:

Smart (Enough) Systems with Neil Raden

Scott Sehlhorst

Tyner Blain

Blog:

www.tynerblain.com/blog

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

Challenges in Specifying Systems

Business Rules Specification

Requirements Specification

Using them together

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

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

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

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

The Challenges / Goals

The Challenges / Goals

The Challenges / Goals

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

Both capture business knowledge

Both clarify customer needs and expectations

Both reflect business need

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

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

Different Models for Different Needs

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

Challenges in Specifying Systems

Business Rules Specification

Requirements Specification

Using them together

What are Business Rules?

What are Business Rules? “ … a directive intended to influence behavior.”

“ … a directive intended to influence behavior.”

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

“… a formal expression of knowledge or preference, a guidance system for steering behavior...”

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

“… statements of the actions you should take when certain business conditions are true.”

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

“… heuristics or tools to make business decisions ”

What is a Rule?

What is a Rule? Data Edits and Constraints

Data Edits and Constraints

What is a Rule? Computation Rules

Computation Rules

What is a Rule? Inferences Process Flow Rules

Inferences

Process Flow Rules

What is a Rule? Action Enablers

Action Enablers

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

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

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

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

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

Challenges in Specifying Systems

Business Rules Specification

Requirements Specification

Using them together

Requirements Framework

Requirements Framework Define Scope Define Vision Define Goals Identify Use Cases Map to Goals Prioritize Use Cases Nonfunctional Req’s. Map to Goals Release Planning

Requirements Framework Define Scope Define Vision Define Goals Identify Use Cases Map to Goals Product Backlog Prioritize Use Cases Release Planning Nonfunctional Req’s. Map to Goals Sprint Backlog

Requirements Framework Define Scope Define Vision Define Goals Identify Use Cases Map to Goals Per Release Product Backlog Prioritize Use Cases Release Planning Use Case & Req’s Nonfunctional Req’s. Map to Goals Review Implement Sprint Backlog

Requirements Framework Define Scope Define Vision Define Goals Identify Use Cases Map to Goals Per Release Product Backlog Prioritize Use Cases Release Planning Use Case & Req’s Nonfunctional Req’s. Map to Goals Review Implement Sprint Backlog Iterate

Traceability (Within Requirements)

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

Challenges in Specifying Systems

Business Rules Specification

Requirements Specification

Using them together

Rules and Requirements Overview

Rules and Requirements Overview

Rules and Requirements Overview

Rules and Requirements Overview

Traceability (Rules <-> Requirements)

Traceability (Rules <-> Requirements)

Traceability (Rules <-> Requirements)

Traceability (Rules <-> Requirements)

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

Multiple decision steps in the process

Assess, Compare

Calculate, Compute

Check, Confirm

Qualify, Decide

Determine, Diagnose, Evaluate

Estimate, Process

Test, Validate, Verify

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

Symbolic reasoning

if then

unless

only if

is a necessary condition for

is a sufficient condition for

consequently

therefore

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

Complex rules, decisions, multi-level reasoning

risk analysis

underwriting

identifying allowed combinations / configurations

Elicitation

Framework for Documentation Process Documentation or Use Cases or Both?

Process Documentation or Use Cases or Both?

Process Documentation

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

Look for Rules in the following

Description

Embedded constraints

Triggers

Action enablers

Preconditions

Constraints

All Flows

Computations

Decisions

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.

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.

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 ].

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 ].

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 ].

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 ].

Use Case: Normal Flow 1. User provides personal information. [See FR22 for details] 2. System requests loan approval 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 BR1266 [Loan Initiation Requirements] 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. [See FR22 for details]

2. System requests loan approval

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 BR1266 [Loan Initiation Requirements]

5. Loan-Processing System responds that loan has been created and funds are available

6. System notifies user that loan has been approved.

Functional Requirements Use Case Normal Flow Step 1. User provides personal information. Functional Requirements The system shall require the user to input the following information: Name Social Security Number Age … . Use Case Normal Flow Step 1. User provides personal information per BR1255 [Required Loan Application Information] Functional Requirements The system shall require the user to input information per BR1255 [Required Loan Application Information]

Use Case Normal Flow Step

1. User provides personal information.

Functional Requirements

The system shall require the user to input the following information:

Name

Social Security Number

Age

… .

Use Case Normal Flow Step

1. User provides personal information per BR1255 [Required Loan Application Information]

Functional Requirements

The system shall require the user to input information per BR1255 [Required Loan Application Information]

System Approaches Formality of RMS … should be consistent with your rules-management approach

Formality of RMS

… should be consistent with your rules-management approach

Review of Use Cases & Rules

Good Reasons for Business Rules Management Regulations and compliance are issues Decisions change often Many rules Complex rules or complex interactions between them Domain expertise is required to understand the rules Business user want or need control Highly variable business process Automation of rule execution makes compliance automatic Rules are easier to change than code A repository of rules can be navigated and managed Rule engines handle (some of) the complexity Business users can manage the rules directly Decision Points add variability to a stable process

Regulations and compliance are issues

Decisions change often

Many rules

Complex rules or complex interactions between them

Domain expertise is required to understand the rules

Business user want or need control

Highly variable business process

Automation of rule execution makes compliance automatic

Rules are easier to change than code

A repository of rules can be navigated and managed

Rule engines handle (some of) the complexity

Business users can manage the rules directly

Decision Points add variability to a stable process

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!

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!

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

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

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

Example Situation: Insurance Agent Sign-Up Vision: Provide affordable life insurance Goal: Grow client base by 10% Strategy: Increase # agents by 20% Scope: Simplified agent signup process Use Case: New Agent Application Processing

Vision: Provide affordable life insurance

Goal: Grow client base by 10%

Strategy: Increase # agents by 20%

Scope: Simplified agent signup process

Use Case: New Agent Application Processing

Use Case: New Agent Application Processing [UC04] Triggers Agent application received Preconditions Completed agent application has been submitted [ BR22, Required application data ] Normal Flow System validates agent data [ BR23, Agent rejection criteria ] System assigns manager [ BR25, Reporting hierarchy rules ] System updates commission allocation data [ B77, Commission structure ] System notifies user that application has been processed System sends welcome letter [per Welcome letter template ] Alternate Flow A3 Non-commissioned agent A3.1 System requests salary data from hiring manager … Exception Flow E1. Agent rejected E1.1 System notifies user of rejection reason [per Rejection letter template ] Post-conditions New agent is active in the system

Triggers

Agent application received

Preconditions

Completed agent application has been submitted [ BR22, Required application data ]

Normal Flow

System validates agent data [ BR23, Agent rejection criteria ]

System assigns manager [ BR25, Reporting hierarchy rules ]

System updates commission allocation data [ B77, Commission structure ]

System notifies user that application has been processed

System sends welcome letter [per Welcome letter template ]

Alternate Flow

A3 Non-commissioned agent

A3.1 System requests salary data from hiring manager …

Exception Flow

E1. Agent rejected

E1.1 System notifies user of rejection reason [per Rejection letter template ]

Post-conditions

New agent is active in the system

Functional Requirements FR01: The system shall notify active agents on the same business day that their application is processed. FR02: The system shall notify rejected agents of rejection [per Rejection letter template ] FR03: Rejection notice shall include rejection reason [ BR23, Agent rejection criteria ]

FR01: The system shall notify active agents on the same business day that their application is processed.

FR02: The system shall notify rejected agents of rejection [per Rejection letter template ]

FR03: Rejection notice shall include rejection reason [ BR23, Agent rejection criteria ]