From SmartEnoughWiki
[edit] Overview
Business rules can be used very effectively to improve the process of gathering requirements and then developing a system to meet them. However, it requires that business rules be managed as unique entities and not just hidden in requirements documents. Reasons for this include:
- It may not always be worth improving the quality of requirements. 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.
- Customers Don't Know What They Want. Stop Expecting Customers to Know What They Want
Joel on Software article - The Iceberg Secret, Revealed
- Sloppy requirements can derail projects. However, the requirements may be sloppy because they embed the rules that change and evolve. The use of business rules to manage decisions in this way also helps with scope creep as the rules can evolve and change and get more complex without impacting the main software development project or requirements scope. All of this helps with schedule slippage and budget overrun as one of the prime drivers for these two is the constant flux inherent in business rules. Separating them out and managing them separately helps avoid problems in them.
TechRepublic on 10+ things that can send an IT project off the rails.
- Poor documentation and poor communications - if the business participants in a project cannot see from the documentation what is being built and are not communicated with, the project will have problems. The use of business rules to specify decisions means that business users can read and understand the business logic being proposed and even implemented, resulting in better documentation and stronger communication between the two sides.
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. The business users don't need to know what they want. Instead, they can figure it out over time or, more specifically, over time once they have a working system (before which they will just be guessing anyway).
[edit] Elicitation
Many techniques work well for collecting both rules and requirements including:
(Elicitation Techniques for Processes, Rules, and Requirements this post on gathering requirements by Scott Sehlhorst )
- Brainstorming
An effect way to gather rules that have not been documented or automated before such as rules of thumb or judgmental rules.
- Document Analysis
Normally used on policy and procedure manuals and legislation to derive the regulatory rules.
- 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.
- 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.
- Interview
A way to gather expert rules and to find out what the objectives of the decision automation should be.
- 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.
- Prototyping
Not generally used in rules development other than for designing rule maintenance interfaces.
- Requirements Workshop
Obviously one would hold rules workshops to gather rules in a very similar way.
- 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.
- Survey
Not generally useful.
[edit] Additional Material