DRAW

DRAW (Decision Requirements Analysis Workshop) is a structured workshop technique for defining the decisioning requirements for a rules project, using the DRD described in my last posting.  There are two typical contexts for DRAW:

• It can be carried out as a self-contained activity, to establish the resources required for a potential rules project (e.g. to establish feasibility, to prioritise alternative projects or to produce a road-map for multiple deliveries)
• It can be carried out in the first few days of a rules development project, to define the decisioning requirements (as a Requirements task in waterfall, or an Inception task in RUP).

The DRD

People are much better at extracting information from pictures than from words, which is why diagrams are used in every professional sphere.  IT is especially blessed with diagrams, UML alone providing 13 different types.  Unfortunately, I have found none of these to be much use for defining decisioning requirements.  Use case diagrams are intended for use in requirements definition, but treat the system as a black box rather than exposing the structure of its decisioning .  ERDs can be used for capturing knowledge structure (as Barb von Halle and Larry Goldberg have elegantly shown in their Decision Model) but are more useful at the design stage.  The subject of this posting is the Decision Requirements Diagram (DRD), which I use as a tool for capturing the scope and structure of the required decisioning at the very outset of a rules project, before any rules are discovered.   This diagram, with its associated documentation, is central to the DRA method.

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.