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

One of my other posts - Writing Better Requirements - Key to Success or false hope? - prompted David Locke to ask me "How do you write a set of requirements that don't encode any business rules?"

Well the key thing is to develop your list of requirements and rules in parallel. So, assuming you want to use a UML approach and are using use cases, the use cases representing requirements refer to the rule list but don't encapsulate them.

Remember, rules are only requirements (for IT) if they are to be transformed into some other format. Rules that are also automatable are not really requirements, but business statements, period.

A good reference for this approach, using Use Cases, is Requirements in Context. This book does a good job of describing use cases and keeps the business rules separate.

Barbara von Halle, author of Business Rules Applied has also posted a response - thanks!