For example: the mission of a company changes rarely and is a requirement for virtually everything the organization does. This mission leads to company objectives, slightly more open to change. The objectives in their turn lead to yet more volatile requirements.

A categorization of requirements by their propensity to change will most likely reveal a hierarchy of policies, processes, and requirements of increasing volatility as the detail of the requirement increases.

This categorization by frequency of change could be a useful instrument to help understand whether the right level of detail is achieved at different stages of the requirement gathering process. If the requirement seems stable enough to last for several years, it probably is not detailed enough to code against. For example: I need a monthly revenue report.

I called out the temporal nature of requirements because I think it is an often overlooked structuring device. I imagine a kind of Venn diagram of the overlapping requirements, where the company’s values are one circle, the laws of physics another circle, federal laws yet another, etc. Our business processes exist in the intersection.

But it is not the only useful categorization. There is an important distinction between policy and process that is based on the importance of the requirement. Requirements such as adhering to our values, obeying laws, etc, are best expressed as policies – simple rules that must always apply. Our procedures can never be changed to violate a policy. I can imagine a tool that enables the business to create or modify procedures interactively, with a BPMN editor for example, but have an edit time or run time check for policy violation that prevents any new process from being implemented that violates a policy.

So in answer to your question, changing requirements that are best expressed as policies can cause fundamental changes to the arena in which our procedures play out. Changes to contingent goals of a given process do not have the same import.