An interesting but inadequate systems analysis textbook
Reviewed by Conrad Weisert, May 1, 1999

Arthur M. Langer: The Art of Analysis , 1997, Springer-Verlag, ISBN 0-387-94972-0, 177 pages.

The search for a textbook

Looking for a satisfactory treatment of systems analysis, either for a course textbook or for self-study is a source of frustration year after year. Nearly every systems analysis book exhibits one or both of these serious flaws:

The Art of Analysis exhibits neither of those shortcomings. Arthur M. Langer, Columbia University, steers a balanced course, drawing the best documentation practices from structured analysis, relational data modeling, and object-oriented analysis He frankly assesses the pluses and minuses of alternative approaches. His opinions are soundly based and his presentations are clear and perceptive.

Scope, structure, and style

What's here is fine, but there isn't enough of it. Brevity is a virtue but Langer's explanations stop short of conveying to the reader exactly how to apply a particular technique. His examples, despite claims in the preface, lack both substance and continuity.

The sequence of topics fits neither the chronology of systems analysis tasks nor the structure of the systems analysis deliverables. Each chapter is like a separate article, useful and interesting, but out of context.

In addition to presenting the techniques of systems analysis, Langer discusses aspects of the project and organization milieu

The practicing or prospective systems analyst will find The Art of Analysis easy to read and may get a few new insights from it. It's too shallow and disorganized, however, to be useful as a primary course text.

Data representation confusion

One area students and other readers should disregard is the unnecessary material on data representation (example on pp 44-45). Data definition belongs to systems analysis; choosing data representations is part of system design.

Even if the systems analyst insists on choosing internal data representations, this is definitely the wrong place to do it. Invoice_Date is an instance of a Date type; the choice of representation should go with the type definition not with each of dozens of different instances.

Recommended as an overview, but not a tutorial or reference

Return to book reviews.
Return to IDI home page.

Last modified February, 2000