individual-entry-BA-Blog

« Analytics + CRM = Happiness | Main | High Performance Marketing: Justifying Your Analytic CRM Investments »

Writing Better Requirements - Key to Success or false hope?

Some email traffic today made me wonder about "good" requirements. Is improving the quality of requirements always worthwhile? Well, perhaps not. What happens when the requirements change all the time? When competitive pressure or market movements or regulatory requirements change so often that the requirements for a system never really stabilize. In those circumstances it may be a false hope to try and improve the final system by improving the requirements.

What is needed, instead, is a way to let those who understand the need for these changes to make the changes themselves. So, rather than invest in ever more detailed requirements, invest in identifying the kinds of things the system must do (rules) and make it possible for the business users of the system to create, modify and delete business rules. This removes the impedance of requirements and coding but could result in an unstable system. Indeed this was brought up in a recent review of Blaze Advisor, Business Rules Meet the Business User , written by Lou Agosta. The solution to this problem lies in developers and architects thinking about the kind of rules that users must create and maintain. Carefully designed templates can allow business users to "fill in the blanks" to create even quite sophisticated rules without risk that they will break the system in the process. Clearly in most systems this does not mean you don't need to have test environments, release management etc. It just eliminates the impedance mismatch between fast moving requirements and coding.

This reminds me of the old analogy about teaching someone to fish - much more effective in the long run than simply giving them fish to eat...

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/6a00d83451629b69e200d8348f3f1969e2

Listed below are links to weblogs that reference Writing Better Requirements - Key to Success or false hope?:

Comments

David Locke

How do you write a set of requirements that don't encode any business rules?

Barbara von Halle

If I can jump in, let me share what we have found to be practical when capturing requirements so that they don't encode business rules.

(1) If using Use Cases, we do "BR-lite" by decomposing the use case into steps and putting an anchor point into those steps that should be "powered by rules." The rules are not stored with the step or use case, they are stored in source rule repository, accessible via the anchor. In this way, the Use Case can stay the same but the rules can change independently, as an agile approach would want. Also, the rules for such steps need not be developed at the same time as the use case itself. Rule harvesting can occur later, perhaps based on priority or availability of experts and it can have parallel tracks (assign teams to different anchor points behind the use case steps). Also, in this way, maintenance of rule changes is much simplified and the rules are easily reusable across use cases. (The best case is if you discover that someone else has already developed the rules you are looking for because you find them in your source rule repository, how cool would that be?).
(2) While we have used requirements tools as a source rule repository, this is not optimal because these tools are for technical people and they provide little traceability to other interesting rule metadata. Also, rules are best not treated the same as other requirement types because they can have a shorter change cycle.
(3) Finally, when not writing use cases but documenting requirements and numbering them, we typically keep rules out of the requirements by saying, "the requirement is - there must be a means for determining if a primary care physician is appropriate for a member on a healthcare policy" but the rules are elsewhere (source rule repository). The requirement may stay the same over time, but the rules behind it may change a lot. Thus, requirements and rules are not really the same kind of thing, after all.

Does that help anyone? (Some of this is in our book Business Rules Applied).

The comments to this entry are closed.

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.