More on requirements gathering

Another great post on requirements from Scott over on his blog - Types of requirements gathering. Worth reading as good background for anyone gathering requirements and rules (which are not the same, remember). A couple of rules-centric comments first:

• Rules derived from regulations and policies are probably going to fall in the "known" category
• Always add the original policy manuals and regulations to your document search - there's often a ton of rules there
• When using existing systems it is really important not to blindly extract rules as you will end up with very technical ones, not business rules
• You might find some rules or rule types using the "unknown" requirements techniques but you will likely do better if you focus on types of rules and let the development and evolution of rules happen later (by empowering business users to make their own rule changes) - this will better support change-time and business agility

As for analytics:

• Replacing existing analytics is the only way they are likely to show up as "known" requirements
• Using analytics to add value in a new way is almost certain to be an unknown requirement - people will need to be poked to come up with new analytics. "What if you could predict this, would it help?"
• You can try watching experts and see what reports they use. Asking them why they use that report, what they get out of it, can be a good way to find new analytics too

In general you need also to keep asking "what decisions are you making" or "what decisions is the system making" to find the decision services you will need.

Technorati Tags: analytics, business agility, business rules, knowledge management, predictive analytics, requirements, Tyner Blain