James Taylor's Decision Management

Roeland had an interesting post this week on the need for a new approach to requirements and BPM's role in that. He outlined the three classic causes of problems with projects (Lack of User Input, Incomplete Requirements & Specifications, Changing Requirements & Specifications) and discussed how a BPM approach can help with that.
Not only do I agree with him, I would argue that exactly the same rationale drives a need to keep rules out of requirements. Process definitions are not the same as requirements. They change on different schedules, have different regulators/policy setters and involve a different degree of business user involvement at various times. Similarly neither process definitions nor requirements are suitable for capturing the rules behind decisions. All of these, like data, need to be described separately and referenced to each other if you are to build a model of the solution that can be built and then modified over time.
So lay out your process, working with your users and use use cases and other requirements tools to capture requirements while keeping the rules that drive your decisions out of both but linked. If you use a BPMS to manage the process and a BRMS to manage decisions you can even ensure that the flexibility and agility you need will be there.
Scott Sehlhorst wrote a nice piece on separating rules and requirements to which I responded here.