Skip to main content
Gathering requirements, and rules

I saw this post on gathering requirements by Scott Sehlhorst today. Now I don't think requirements are the same as business rules (particularly given the nature of business rules is to change) and that one should keep them separate and linked to use cases, for example. The techniques were well summarized though so here's the list, with some comments about applying the techniques to rules.

  1. Brainstorming
    An effect way to gather rules that have not been documented or automated before such as rules of thumb or judgmental rules.
  2. Document Analysis
    Normally used on policy and procedure manuals and legislation to derive the regulatory rules.
  3. Focus Group
    Useful for gathering feedback on rule templates, designed to allow a specific group of people to manage some rules themselves e.g. a group of marketing folks and the templates for cross-promotional rules.
  4. Interface Analysis
    Not typically a major issue but could be useful for designing a rule maintenance interface that fits seamlessly with, for example, reporting and dashboards.
  5. Interview
    A way to gather expert rules and to find out what the objectives of the decision automation should be.
  6. Observation
    Not only can observation give insight into how decisions are made (what data is consulted, what questions are asked of a customer etc) it can also be used to find decision automation opportunities when applied to the process that includes the decision. When does someone executing the process have to refer a customer to someone else? Why? and so on.
  7. Prototyping
    Not generally used in rules development other than for designing rule maintenance interfaces.
  8. Requirements Workshop
    Obviously one would hold rules workshops to gather rules in a very similar way.
  9. Reverse Engineering
    As Scott notes, an exercise almost of last resort. Analyzing code for rules will almost always result in over-technical rules, rather than business rules. Mining code for rules is something best avoided unless there is code that implements something for which no policies, procedures, regulations or experts exist.
  10. Survey
    Not generally useful.

Anyway, a nice list and very helpful.

Technorati Tags: ,

related posts