Andrew Johnston comes away from the 2008 Enterprise Architecture Conference in London worried about A Shortage of Analysts.
One of the major causes of project failure is that the requirements aren't properly understood and communicated, but this isn't exactly a new problem. What is new is that emerging development paradigms, from SOA to outsourcing, affect the opportunities for requirements analysts to learn their craft. In the past, analysts and developers typically worked together in the same organization - developers consumed and actively critiqued the work of the analysts. (When I was a programmer, I asked so many awkward questions of the analysts they decided to make me an analyst instead.)
However, although the experience of collaboration between analysts and developers is undoubtedly useful in the acquisition and refinement of analysis skills, and it is important that analysts have an appreciation of "making it work", I am not sure I agree with Andrew that analysts need to have a development or equivalent background. Someone might equally argue that analysts should have a systems testing background - "making it not work" - because that would give them a strong sense of what can possibly go wrong with an apparently simple idea for business improvement.
Twenty or thirty years ago, it may have made sense to recruit business analysts from the ranks of developers. After all, they were the only people in the organization who understood IT, they were often better educated than the "end-users" (in those days we were mostly dealing with automating administrative systems, so the end-users were mostly clerks), they could think logically, and they had a kind of intellectual curiosity that had lured them into IT in the first place.
But these assumptions no longer hold. Intellectual ability and IT literacy are certainly not unique to the IT department - in some organizations nowadays the IT department comes a long way behind the "user" departments in these qualities. And it is in the user departments that managers have experience of making a business process work - surely this is more relevant to business requirements analysis than making a computer system work?