Buy it from Amazon.com
Buy it from Amazon.co.uk

Other Reviews

Hay presents a clear but very particular take on analysis. The book is based squarely on John Zachman's framework for the architecture of computer-based systems, so if you were hoping for something wider you'll be disappointed. Hay 'has been developing interactive, database-oriented systems since the days of punched cards, paper tape, and teletype machines'. It sounds like the age of ammonites and dinosaurs, but was in fact only thirty years ago. How times have changed, and language with it.

Hay is well-informed on analysis, including the entire new field of object-oriented analysis and design, and the Unified Modeling Language (UML) that goes with it. Big names from the data-processing world like Codd and Date, Zachman and DeMarco, are treated with some reverence; but Jacobson and Cockburn are there too, holding the flag for objects, use cases, and the UML. As you might expect, Hay is a little sceptical of the claims of object modelling to be entirely different from data modelling, and his lucid comparison of entity-relationships and object or class relationship modelling certainly shows up strong similarities. What is more, he points out that UML in fact reintroduces flowcharting with its activity diagrams, despite its much-vaunted focus on objects rather than activities. What goes around, comes around.

The Zachman framework, if you don't know it, consists of a table with 6 Columns that define aspects of systems:

1. Data,
2. Activities,
3. Locations,
4. People,
5. Time,
6. Motivation;

and 5 Rows that define people's perspectives on the development project:

1. Planner,
2. Business Owner,
3. Architect,
4. Designer,
5. Coder.

Each cell of the table is dealt with in a chunk of the book, so there is a satisfying pattern -- an answer to every question of the form 'What should be created to enable person Y to understand aspect X?'

For instance, the cell at row 2 column 6 explains why the business wants each function: it defines the business rules and policies that the system must obey. Similarly, the cell at row 4 column 4 explains the technology that the designer thinks should be applied to meet the people's needs: it defines the user interface and security approach. As a final example, row 3 column 1 shows the system architect's view of the data: it defines a complete entity-relationship model of the data to be held.

And that is the basic structure of the book. Chapter 1 introduces the Zachman framework; chapter 2, entitled 'Managing Projects' talks through the details of that structure in terms of seven processes that each project is supposed to follow for its analysis activities: Define Scope; Plan the Analysis; Gather Information (i.e. meet the stakeholders); Describe the Enterprise (i.e. map out your 6 dimensions to answer the what, how, where, who, when, and why questions of the X-axis); Take Inventory of Current Systems; Define What is Required of a New System (i.e. write the requirements); and Plan for Transition -- because whatever you do, you will surely change people's work and probably the organization as well. All the remaining chapters are named simply Column 1, Column 2 etc, as they step through in detail all the artefacts -- documents and models -- that projects must produce.

Now this has some important advantages. It is certainly prescriptive, but it is quite independent of technology -- if it works for Cobol it will work for C and Java; if it works for OS/360 it will work for Unix. Hay is careful and systematic about language differences; he plainly doesn't think it matters a bit whether you draw your Entity models in one notation or another, though it is certainly important to define the data structures consistently. There is no hint of the 'wars of religion' between rival notations. That brings us neatly to UML. Hay begins his Preface with the words:

The Inspiration for This Book: Object-Oriented Analysis

Object-oriented programming has, in recent years, radically reduced the amount of time and effort required to build systems... Numerous books on "object-oriented analysis" have appeared, and the UML has come on the scene as a technique for supporting this... There are three attendant problems:

1. ... focus on the technology of producing programs;
2. ... ideas developed from information engineering and other sources are ignored as though they were irrelevant to the object-oriented world;
3. ... [and] the third problem comes from .. including "object-oriented features" in the requirements process. "Control objects" and "interface objects" are artifacts from object-oriented design, but they are often (inappropriately) described as part of the requirements analysis process.

   The fact of the matter is that the process of identifying requirements is fundamentally different from the process of applying technology to address those requirements.

This is sound Texan common sense applied to the software domain. Hay has written a book that cuts through the nonsense to describe a set of processes that certainly work. The emphasis is indeed on analysis, but as should be clear from the description above, the related processes of defining business requirements and of designing systems also get some coverage.

What the book does not do -- and it is admirably comprehensive within its chosen domain -- is to say much about several topics that requirements people might find important:

• There isn't much about the scenarios that show what people want to be able to do and what results they expect from systems, though there is a concise section on Cockburn use cases, and in fact Hay is quite good on using Natural Language to describe sequence in 'structured natural language' based on Carmen McClure and James Martin, though he doesn't connect that with 'scenarios'. This is surely a matter of background.
• The book doesn't really discuss how to tailor the processes to different domains; questions like 'what would I do for the control software in a railway signalling system?' don't find an answer.
• The role of testing in analysis isn't examined; the value of thinking at specification time whether and how you'll be able to verify your requirements isn't mentioned.

However, if you have a software project and you want to know what models to build and how to make sure they fit together properly, this is a splendid book. It is clear, comprehensive, practical, and well-illustrated with examples. Practitioners will find it helpful; students will find it invaluable both for its coverage and for its comparisons of techniques.

© Ian Alexander 2003