Introduction and Principles

Welcome to my first posting on the DRA blog.  I hope you find it interesting and useful.  I am planning to publish these ideas soon in a book, but first I wanted to share them with you - colleagues, friends and anyone with a common interest - and collect your feedback.  Please feel free to comment, criticize or argue, and to contribute your own ideas.

I have been building rule-based systems now for over twenty-five years, and in my experience the most difficult problems with rules projects are rarely technical;  they are to do with management and communication.  For example:

• How can you discuss the required decisioning at a high level with the client?
• How can you define the scope clearly at the outset of the project, before any rules have been collected? 
• How can you implement the project in stages without the need for extensive rework?
• How can you avoid nasty surprises half-way through (e.g. the need to integrate with an extra source of data)
• How can you divide the development tasks between multiple teams or locations and be sure the components will integrate properly?
• How do you know when you've finished?

Decision Requirements Analysis (DRA) is the approach I have developed as a response to these problems.