Requirements Definitions identify the results expected from a would-be system.  Their whole purpose is to limit the size of the problem system developers have to tackle.  They are intended to limit the informational scope of a system ... to limit informability before a system is even really begun.  

There is a misperception that requirements definitions are system specifications.  This is simply not true!  Asking the users of a proposed system for the results they expect from it is like demanding a would-be car buyer identify every place a car will ever be driven before it can be built.  Nobody would mistake a list of routes and destinations for an automobile specification.  They are at best only the reasons for buying a car, not a technical specification.

After buying a car designed to satisfy the routes and destinations we happened to think of before the car was built, we would be rightfully upset to discover the car had to be returned to the dealership to be re-programmed every time we wanted to go someplace new.  Or that we had to buy a new car, not to replace the one we have, but in addition to it, needing different cars for different trips. 

Requirements definitions are the equivalent of specifying that the car we want has to make a right turn at Fifth and Broadway followed three blocks later by a left at Fifth and Elm ... that every turn and stop has to be individually anticipated and identified ... and individually programmed. The bigger picture of providing a steering wheel so we can go where we want to go when we want to go there is beyond the scope and intent ... the imagination ... of conventional system development.  We build "trips," not "transportation." 

This is exactly how systems based on requirements definitions work.  The requirements definition only identifies the reasons for a system.  But, because of the way we perceive and build systems, they are imposed as the limits of the system.  When change occurs the system vehicle has to be re-programmed.  The perspective on conventional systems of which requirements definitions are only a part, has us building limited informational possibilities. 

No matter how hard we try it is impossible to say beforehand every place we ever want to drive a car.  Efforts at broadening requirements definitions are faced with the same problem; we cannot anticipate every way in which we want to use an organization's unique information.  We can't, that is, when we're stuck in the routes and destinations mind-set of requirements definitions. 

As a result, we get specific results but at the expense of capability ... at the expense of using information to its full potential.  IT customers cannot use their own bought and paid for data "to go someplace new" as needs arise.  Though the information would support it, the rudderless system does not; the penalty of planning only to the limitations of requirements definitions.

In addition to which there are some informational necessities that never show up in requirements definitions.  No manager is likely to require, for example, that their system manage information within context or that it cover all information dimensions and vectors; requirements that show up in real specifications for information management.