Rules and requirements - what do YOU think?

Scott Sehlhorst and I are presenting at Business Rules Forum this year on rules and requirements and thought we would use our blogs (his is here) to carry out a public discussion/presentation development process! He got it started with Business Rules And Requirements - Early Thoughts and already has a couple of comments so I thought I would open it up here too.

I regularly blog about things like the other thing CIOs should know about requirements and digging yourself out of the requirements tarpit in the requirements section of the blog. But now it's your turn (please). how do you manage rules and requirements? How do you help people determine rules separate from requirements or do you? What about processes - how do they fit? Any and all comments/thoughts welcomed. Scott and I are going to synthesize them and work an example between the blogs over the coming months so this should get interesting.

Technorati Tags: business agility, business rules, Business Rules Forum, requirements, Scott Sehlhorst, Tyner Blain

Comments

[David Wright]

Hi James, and Scott too:

(Before anything else, I can finally say that after attending the Business Rules Forum for the last two years, including a fun time presenting last year, I will not be attending this year. So, keep that in mind that those of us in absentia will want to hear how the week goes!)

I have chatted with Scott already about how one can see that Rules and Requirements are separate/different things that are still often 'discovered' at the same time. What I am thinking now, though, is we may need to come up with a common definition of a Requirement, something I have always found to be elusive; otherwise, participants in this discussion may think they are discussing the same thing when they mean something different.

If we can get to that point, we should reinforce it with some real examples. I think that both together will help us in the long run.

In contrast, the definition of Business Rules is pretty much already set, with the work of the original Guide project, and now the Business Rules Group. For anyone new to Rules, loook up the group for its definition and its Manifesto on Rules.

So, does working on a definition of a Requirement seem to be the next step?

[Craig Brown]

Don't forget constraints, which may or may not be related to rules...

[Stephan Meyn]

For me business rules are a part of requirements.
What is important is the way to discover business rules. The average business user has little conceptual understanding and, if asked to list business rules, will come up with a haphazard set of rules - often amounting to little more than data entry validation rules.
My approach is not to engage the user openly in discovering business rules. Instead I generate a conversation with the user about how they intend to use the system. The basis for this is the development of use cases. While doing this many other issues become apparent. It is then up to me to discover likely business rules and to discuss them in the context of the use case. This is immensely useful because the user always has context within which they can formulate and refine the business rule.
"Never confuse the user!" is my motto.