I saw this piece by Carey Schwaber of Forrester today - The Root Of The Problem: Poor Requirements. My regular readers will know that I have strong opinions about requirements, so much so that I have a whole section on them. Anyway, here's the Forrester summary of the paper (my emphasis):
The quality of software requirements is a limiting factor on the success of software development projects. And it's the rare IT organization that couldn't improve its requirements practices. When it comes to getting requirements right, companies struggle on two primary fronts: requirements definition and requirements management. But the market places a disproportionate emphasis on tools for requirements management. The real opportunity for improvement lies in requirements definition and in how different development methodologies treat changing requirements.
Now in general I am of the opinion that fixing requirements problems is a false hope and that attempts to fix the problems of agility and fit-to-purpose that are epidemic in our systems will need to do more than just make another attempt to solve the problem of managing requirements. In particular I think that the key requirement for agility is the effective management of business rules - the policies and procedures that guide how the system should work - and that these are not the same as other kinds of requirements and that IT and business people have very different perspectives on this kind of thing. To the extent that this means considering business rules management as a different approach to define requirements this would align with Carey's premise (I don't know if she agrees with this or not). It is particularly essential to handle rules differently to cope with the reality that the time most systems spend changing dramatically exceeds the time spent being developed. Indeed I have heard it argued that successful systems will be forced to change more, not less, as successful systems will be used and the reality of the world means that systems being used will have to change as the world changes. Thus how to handle changing requirements is key as Carey notes. I believe that the "requirements" that are really business rules will change all the time. As such the system should be isolated from them as much as possible, by externalizing them in a business rules management system, and managing them should be handed over to the business users if at all possible. This will allow the business users to focus on "requirements" that are not about design but about the business and IT to focus on requirements about performance, integration and other elements of design and implementation.