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.