Frequent pairing of different disciplines violates fundamental life-cycle principle.

"Analysis and Design" Considered Harmful

© Conrad Weisert, Information Disciplines, Inc.
February, 1999

NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.

Bookstore shelves are being flooded with more and more texts on systems "analysis and design", now often "object oriented". That compound term almost always indicates that the author doesn't really understand the purpose or practice of systems analysis.

There is no such discipline or activity as "analysis and design". Furthermore, a clear distinction between the two is absolutely essential to any large software development project.

It's certainly possible, although uncommon, for a single individual to be skilled at both systems analysis and system design. It is then perfectly acceptable for him or her to do systems analysis some of the time and system design some of the time. It is never acceptable, however, to do both or some sort of mixture of the two at the same time.

The introduction of structured analysis in the 1970's came about partly as a reaction against the then common practice of mixing the two. Why did so many projects mix the analysis and design? Partly because many systems analysts were former programmers, who felt more comfortable designing files and programs than determining and documenting what the users needed.

DeMarco had it exactly right when he called his now-classic book Structured Analysis and System Specification. So did Gane & Sarson in their Structured Systems Analysis. The highly-regarded courses offered by Yourdon and others stressed that crucial difference.

The most enlightened of the mainsteam phased life cycle methodologies also stressed that distinction by calling for separate phases with well-defined results (deliverables). The differences, oversimplified here, are summarized in the following table:

One of the two most common causes of project failure1 is the lack of a complete, unambiguous, and understandable system specification (alternatively called functional specification, detailed user requirements, business system design, or external system design). For non-trivial projects that principle remains true whether you follow a formal phased life-cycle or a so-called "rapid application development" (RAD) methodology.

Many in the object-oriented analysis (OOA) community are the worst offenders, and the proof comes practically every week when we hear about yet another giant object-oriented fiasco.

I have a great deal of respect for the creators and promoters of the UML (Unified modeling language , now a standard blessed by the Object Management Group), so long as they keep referring to it as a tool for object modeling rather than as a tool for doing systems analysis. The UML actually has very little to do with systems analysis as understood here.

So what about all those courses and books on "analysis and design"? Are they worthless?

The courses mostly are. I have yet to see an "analysis and design" course I'd recommend to anyone who wants to learn in depth how to do either. On the other hand, some of the books are worthless and some aren't, but I'd consult none of them for wisdom on how to do systems analysis. For example, Grady Booch's well regarded Object-Oriented Analysis and Design with Applications (second edition, 1994, Benjamin/Cummings, ISBN 0-8053-5340-2) is full of useful concepts and techniques for design and (surprisingly) programming. Booch reveals his narrow view of the role of systems analysis on page 161:

". . . the products of development, including data-flow diagrams, are not ends in themselves; they should be viewed simply as tools along the way that aid the developer's comprehension of the problem and its implementation."

That emphasis on the developer is echoed in countless presentations in which it's clear that the speaker views the UML exclusively as a tool for developers to use in communicating among themselves. When questioned about communicating with the sponsoring end users, they rarely have a good answer. Some go as far as to suggest that the systems analyst may need to prepare a separate package of documentation aimed at the non-technical audience. That, of course, is an invitation to put all the project's eggs in a basket where omissions and inconsistencies won't become obvious until the late stages of the project.

Return to IDI home page.


1 The other common cause of project failure is the lack of sufficient detail in the project plan to permit early detection of slippage or overrun.