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

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

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

Managing Rules and Requirements Independently

Enables and Encourages Easy-To-Change Solutions

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? “ … directives intended to influence behavior.”

“ … directives intended to influence behavior.”

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

“… formal expressions 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? Computation Rules Inferences Process Flow Rules Action Enablers Data Edits and Constraints

Computation Rules

Inferences

Process Flow Rules

Action Enablers

Data Edits and Constraints

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

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

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

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.

Review of Use Cases & Rules

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