Writing Better Requirements - Key to Success or false hope?

Some email traffic today made me wonder about "good" requirements. Is improving the quality of requirements always worthwhile? Well, perhaps not. 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.

What is needed, instead, is a way to let those who understand the need for these changes to make the changes themselves. So, 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. This removes the impedance of requirements and coding but could result in an unstable system. Indeed this was brought up in a recent review of Blaze Advisor, Business Rules Meet the Business User , written by Lou Agosta. The solution to this problem lies in developers and architects thinking about the kind of rules that users must create and maintain. Carefully designed templates can allow business users to "fill in the blanks" to create even quite sophisticated rules without risk that they will break the system in the process. Clearly in most systems this does not mean you don't need to have test environments, release management etc. It just eliminates the impedance mismatch between fast moving requirements and coding.

This reminds me of the old analogy about teaching someone to fish - much more effective in the long run than simply giving them fish to eat...