individual-entry-BA-Blog

« New Podcast with Donald Light of Celent | Main | Book Review: The Long Tail »

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: ,

First time on the EDM blog?
Subscribe to the EDM blog feed or check out some other recent posts:

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83451629b69e200d8343083ed53ef

Listed below are links to weblogs that reference Gathering requirements, and rules:

» Requirements oder Business Rules? from Regelwerk
Weder noch. Manchmal ist es sehr wichtig, die Dinge auch begrifflich gut auseinanderzuhalten. Krzlich wollte ich erklren, dass Requirements nicht mit Business Rules zu verwechseln sind, und kam dabei gelinge gesagt ins Schwimmen. Also nochm... [Read More]

Comments

Post a comment

Comments are moderated, and will not appear on this weblog until the author has approved them.

If you have a TypeKey or TypePad account, please Sign In.

Search Site


  • dmblog.fico.com

Subscribe

  • enter your email

Upcoming Events

  • FICO Tools & Analytics User Forum 2012
    BERLIN: September 11-12, 2012 LONDON: September 18-19, 2012 Gain new insights for improving business performance through advanced analytics and decision management tools.