Time to bring back Systems Analysts?

I’ve had a number of discussions with directors and project managers since my posts on Agile vs. Waterfall methods of development (see Agile vs. waterfall methods and Agile methods for package enhancements?) and there has been two common themes of those discussions – the capture of requirements and production of an overall design.

For developments using Agile methods, it would appear that where these go wrong is, typically, in the collection of an overall set (not necessarily 100% complete) of requirements. Where development teams include senior end users (full- or nearly full- time) who understand the overall requirements fully, the risk of problems diminishes (but definitely doesn’t disappear) – but when the end user involvement is limited (either in time or level of seniority/experience), the risk of problems increases greatly.

Meanwhile, in waterfall developments, whilst the capture of an overall set (again, not necessarily 100% complete) of requirements usually seems fairly good, it is the next design stage that seems to be skimped on, and in some cases even not carried out. (If necessary, see my post Requirements vs. specifications for an explanation of the difference).

Several of my contacts have rued the passing of the old “Systems Analyst” role, pointing to the current rise in the use of Business Analysts who focus more on requirements rather than system design, and “Analyst/programmer” roles who really focus on the programming and technical aspects, rather than overall system design – leaving a systems design gap between requirements and coding stages.

Perhaps it’s time to re-emphasis the systems analysis and systems design role, and bring back good old fashioned Systems Analysts......