© Conrad Weisert, Information Disciplines, Inc., November 1, 2003
NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.
(IDI's Issue of the Month for November, 2003)
Supporters of various methodologies are arguing with growing vigor about not only the structure and content of users' requirements documentation, but also whether projects need to specify rigorous requirements at all. Four years ago I pointed out a serious requirements crisis, and recently in response to readers' requests I've begun proposing specific guidelines for documenting and packaging such requirements.
On the other hand proponents of some iterative and incremental methodologies argue that gathering and documenting requirements is not just unnecessary, but actually harmful to an application system project. Michael Schrage's article "Lies, Damned Lies, and Requirements" in a recent CIO Magazine takes an extreme position:
|"Most clients neither know what they want nor truly understand what they really need. They're ignorant. They don't quite 'get' IT, and their grasp of their own internal processes is uncertain. If a little knowledge is a dangerous thing, then these clients are lethal. They'll destroy any chance IT has of bringing a significant software-based initiative in on time, on budget, and please excuse the irony on spec."|
Here was a 3-page article about requirements that never mentioned the role of the systems analyst at all! A decade ago, that would have been unthinkable, but today it no longer amazes readers who see just that misconception repeated in trade journal articles and presentations from well-known methodology gurus.
Of course naive end users can't prepare a rigorous requirements package on their own. No knowledgeable software development professional ever expected that they should do so. Clients are far from "ignorant" of their own organization but they have little or no experience in gathering, documenting, and organizing formal requirements for a system. Why should they?
The role of Systems Analyst evolved specifically to fill the gap between user clients and software designers. A systems analyst discovers the user organization's needs by interviewing key people, observing business processes (the old system), and examining relevant documents. He or she then documents the requirements for a new system in a form that can be understood both by the responsible client organization participants and by the developers (or vendors). That process is usually iterative; user representatives don't create requirements documentation, but they have to understand and approve it.
The accompanying role definition specifies what a professional systems analyst typically does. (Let me have your feedback if you're a practicing systems analyst or if you work with systems analysts. What would you add or change?)
Back in the 1960s many organizations, believing that systems analysis is a higher-level activity than programming, began to promote their best senior programmers to become systems analysts. Most of the time those organizations just lost a good programmer and gained a bad analyst. The skills and interests required by the two roles are entirely different. There are individuals who possess both abilities, but they're the rare exceptions.
The structured revolution of the late 1970s helped to clarify analyst's role. Courses and textbooks began to appear, and universities recognized a systems analysis discipline in their business schools or in their computer science departments.
But then we started slipping backwards. Courses and textbooks began to address "Analysis and Design", hopelessly confusing the two disciplines. Tools designed for modeling an internal system design got twisted around in misguided attempts to apply them to defining requirements. When that didn't work, some fell back on the 1960s style of requirements as an unstructured discrete feature list supplemented by narratives (now called "use cases"). It's clear that Schrage has that view of requirements:
|"I've made a comfortable living advising software development groups to stop gathering requirements after the first 20 to 25 . . . "|
IDI offers courses in various aspects of systems analysis. They're aimed not at senior programmers, but at people who have strong people skills and interest in how application systems support an organization
An organization that lacks in-house expertise can successfully engage contract consultants to act as systems analysts on a project. Such consultants must work primarily on site having strong interaction with the sponsoring user community. Systems analysis is never a candidate for offshore contracting.
Some of the biggest and most complicated development projects don't develop a conventional application system for a sponsoring user organization but rather produce a software product to be sold in a competitive market. Since very few vendor companies are willing to fund such a development effort without a clear idea where it will lead, the need for complete and unambiguous requirements is especially critical for such projects.
When there's no sponsoring user organization, someone still has to play the client role in dialogues with systems analysts. Whether such user roles are played by in-house domain experts or by a friendly customer, the systems analyst's critical role is very much the same as for a custom application development project as are the criteria for rigorous requirements deliverables.
Return to IDI home page
Return to Systems analysis information
Return to Management articles