systems analysis and design

_Requirements Analysis_ is just the opposite of a book like Craig Larman's _Applying UML and Patterns_ or Ed Yourdon's _Modern Structured Analysis_. Both of those books--in fact, most books on analysis--present a single methodology and a single set of tools and notations, then walk you through the steps of the analysis process according to DeMarco or according to Jacobson or whatever.

David Hay is after larger fish in this book, or at least more fish: in these 400 pages, you will find a survey of more techniques and models than you probably could have dreamed of, from the very old to the very new, from the flashy to the obscure: data flow diagrams, UML, Object-Role Modeling, cybernetics, business rules, IDEF0, and on and on. This book will teach you a little bit about a whole lot of analysis techniques and what they can accomplish.

The material is all organized and discussed from the point of view of the Zachman Framework, a beautiful and expansive system that shows us how various techniques fit in to the "total picture" of the who, what, when, where, why and how of enterprises and information systems. It gives us a broader perspective, and often shows us where we are focusing too much on one or two aspects of a system, to the detriment of the others.

But this book is not a cookbook or a procedural guide to performing analysis. There is very little prescriptive advice, and relatively little on the nuts and bolts of what you should do and when. I don't want to suggest that is a shortcoming: it is intrinsic in the very nature of a survey-type book. If you have done some analysis work or studied one or more particular methodologies, this book will give you context and perspective and introduce you to new possibilities you probably weren't even aware of before.

But if you are approaching analysis for the first time, you need guidance more than you need options, and you may find this book more confusing than useful. You might, instead, want to look at _Applying UML and Patterns_(Larman) if you are approaching analysis from an object-oriented programming perspective; _Modern Structured Analysis_ (Yourdon) if you are coming from a more traditional Data-Flow and Entity-Relationship shop; or _Mastering the Requirements Process_ (Robertson)for a more generalized, but still procedural, perspective on requirements definition. Then, in six months or a year, open Mr. Hay's book and feel the horizons rushing back from your eyes. This is basically what I have done, and I'm very happy I did. David Hay has given me a larger context at a time when I can start to appreciate it, and new options at a time that they can be useful to me.

I should point out that I feel the book is not without its shortcomings.

--Mr. Hay gives pretty short shrift to Use Cases, which are emerging as a really useful technique for discovering and capturing functional requirements. This book talks about use cases, but clearly considers them of secondary value, burying them in a fairly obscure corner of the Framework. Craig Larman, Alistair Cockburn, Ivar Jacobson and Doug Rosenberg all have good titles out that place Use Cases in a more central role.

--Certain object-oriented techniques seem to have a pretty low opinion of Analysis work, or call things "analysis" that are more properly considered design. Mr. Hay makes some good points in response, but I can't help feeling he's going a little too far when he says things like "there is no such thing as object-oriented analysis." No less a figure in the world of methodology than Ed Yourdon would seem to disagree, unless the title of his book, "Object-Oriented Analysis," is some kind of very subtle joke. You may want to pick up an OO title or two, and see what conclusions you come to.

--Last of all, I found the treatment of some of the areas of the Framework to be esoteric and difficult to follow. Most notable here is the discussion of business rules that makes up the book's treatment of the Motivation, or "why," column. I realize that business rules thinking is still in its infancy, but the presentation in the book is too nebulous, academic and abstract to come to any kind of grips with--it was like trying to learn the UML by looking at the "meta-model" documents. Another example is in the People, or "who," column, which consists of a very academic treatment of the science of "cybernetics." Intriguing, but darned if I got much of practical use out of it. Shouldn't the People column have something to do with characterizing and categorizing users, their preferences, environments, levels of experience? Perhaps all the stuff on cybernetics _does_ that, but it was all a little too rarefied for me to follow.

In summary, this was a very valuable book for me. I'm a better analyst for having read it, and I have a whole list of new things to think about and learn about (including the above-mentioned business rules and cybernetics). I can't recommend this as a _first_ book on analysis, but I can heartily recommend it to anyone who wants to learn _more_ about analysis.

It OK(!) that you answer another reviewer, but giving yourself 5 stars... What a shrewdness

So I think my single star will balance the equation again
5+1 = 3

I realize that it is a little irregular for an author to review his own book, but I feel compelled to respond to the reader from Centerville, GA who said that my analysis book was "Good on data modeling, but little else." It is important for anyone buying this book to understand what it is and what it is not. A very important point made in the book, which was apparently missed by our "reader", was that analysis is fundamentally different from design. Analysis is about understanding the true nature of the enterprise. Design is about specifying artifacts, using a particular technology, to do useful work. The two are not the same.

This book is a compendium of techniques for analyzing the nature of a business. It is not concerned with object-orientation for the simple reason that object-orientation is an approach to design. It does not address "object-oriented analysis" because there is no such thing. There is only "analysis" of an enterprise. The results of that analysis may be used for designing object-oriented systems, COBOL systems, or any other kind you wish. The book describes UML, but it points out that only a sub-set of the notation is appropriate for analysis. UML was originally intended to support design.

The book is organized around my version of the Zachman Framework, which means that it addresses not only data modeling, but also the modeling of activities, locations, people and organizations, timing, and business rules. In each case, it characterizes analysis as the process of translating a set of business owners' views of the enterprise into a single, coherent architectural view. It is true that the state of the industry now is such that there is much more to say about data than there is for any other subject, but I did make an honest attempt to describe as many modelling techniques as I could find for all of them.

The book is an attempt to present a comprehensive picture of requirements analysis. If you are looking for a book on object-oriented design, this is not the book.