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: business rules, requirements