Despite our best efforts we need to know what we are going to code before we write the code. And as much as we might like to test before we write the code we can't really run tests until we have some code. Agile overlaps requirements discovery and implementation so coding can start with minimal or outline requirements but there is still a sequence.
Yet when it comes to fixing a broken development process or organization starting with requirements can make the situation worse. Although counter-intuitive, the first priority should be making development more effective then focusing attention on the requirements process.
One of the problems I frequently see in an organization is a stream of business requests for features that the development groups are unable fulfil simply because there are so many requests. The result is the equivalent of trying to put a quart into a pint jug: it overflows.
Work overflows and doesn't get done; managers spend their time arguing about what should be done and why things haven't been done. Developers cut corners so the work that is done doesn't satisfy the need. Quality is sacrificed in the name of getting something - sometimes anything - shipped.
Part of this is because of the way features and requirements are requested. It is very easy to ask for a new feature. A request might be as simple as an e-mail to the development leader, in which case the cost of making the request is minimal.
Development groups often respond by increasing the price of requests. Before any work will be considered it must be formally documented and signed-off. Increasing the cost may reduce the flow of requests but it also becomes more difficult to withdraw requests that have been made.
However the request it made it is normal that satisfying the request takes more time, energy and resources than making it. Consequently there is an imbalance supply and demand. Demand is almost unlimited, the cost of asking is low and cost does not increase as more requests are made. However supply is strictly limited and very expensive. Increasing supply will actually increase costs because more co-ordination (management and technical) is required.
It is easy to see how demand builds up. Some requests are simply "good ideas" which escape into the requirements process. Others are the result of previous poor performance form IT groups, burnt by previous failures internal customers see a development project preparing to start.
Knowing projects typically arrive late and without all the promised functionality customers make more and more requests in the hope that they will get some of what they want. In response development groups respond by padding schedules, demanding more resources and implementing more gating criteria.
At the same time as making more requests customers ask for more details - project plans and schedules - and even inject themselves into the process to monitor what development does. Too frequently both sides hide behind plans and the illusion of control.
As a result it is perhaps unsurprising that Mary and Tom Popendieck  say: "Only about 20% of features amp; functions in typical custom software are used regularly." Any organization that is serious about following the Agile or Lean agenda need to throttle the requests coming in to ensure only features which are needed are implemented.
Fortunately this thinking fits with the way a lot of managers think. During management training many managers are taught the importance of doing the right thing over doing things right. This is good advice but in the case of problematic IT groups could make the situation worse.
Research from Bain amp; Company  shows that a staggering 76% of all IT organizations are neither effective in what they do nor aligned with the business needs. We can think of these two criteria as "doing things right" and "doing the right thing."
Using these two criteria - alignment and effectiveness - Bain identified four types of organization - management