About the Book | Requirements Analysis: From Business Views to Architecture


Team-Fly

	Requirements Analysis: From Business Views to Architecture By David C. Hay
	Table of Contents

	Preface

About the Book

Rather than viewing requirements analysis from the perspective of a particular implementation technology, this book views it as fundamentally an architectural process. Specifically, it sets out to answer the question: How do we identify and understand the architecture of an enterprise, so that whatever systems we build for it can truly support that architecture? To do this, it attempts to bring together as many as possible of the best techniques and approaches from the entire history of systems development (including some that originated in the object-oriented world), and it will argue the relevance of all of these in developing object-oriented and other kinds of systems.

Merriam Webster defines "architecture" as "a unifying or coherent form or structure" [ Merriam Webster , 2001]. When the present book describes an architecture for requirements analysis, it is describing the structure of the entire requirements process. The book is informed by the work of John Zachman, who has described the architecture of systems development as a matrix, with the perspectives of the players in the development process as rows, and the things to be seen from each perspective as columns . The various techniques presented are organized in terms of the cells in such a matrix.

This book's premise is that requirements analysis is the translation of a set of business owners ' views of the enterprise to a single, comprehensive architectural view of that enterprise. After some introductory chapters, there is a chapter on each of the dimensions (what, how, where, who, when and why) of the two perspectives.

While the book's focus is on these two rows, attention must be paid to the "scope" perspective that puts all our efforts in perspective. Also, where it is useful to our understanding (notwithstanding the remarks above), reference is occasionally made to the implications for technology designers of what we learn.

While, in one sense, this book will cover ground explored by others, it is unique because it describes in one place the full range of artifacts that can be delivered in an analysis project. This should give the book a completeness not found in most. It addresses not only analysis of data and process, but also the analysis of data networks, people and organizations, events, and motivation.

This is not the kind of book that you can read through like a mystery novel . The Introduction and Chapters 1 and 2 provide an overview of the field and should be read first. The remaining six chapters provide both a roadmap and a reference guide. The roadmap describes 12 of the 36 cells in the Architecture Framework and how they relate to each other. The reference guide is to the myriad of techniques that are available for each cell . If there is a technique you've heard of and you would like to know both more about it and how it fits into the general scheme of things, you should be able to find it here.

Note that Mr. Zachman's great insight was to provide a framework for organizing what we know. That we don't know everything equally well becomes quickly apparent when we try to populate the matrix. You will observe as you go through the book that the various chapters do not describe each area of knowledge equally well or equally completely. Indeed, the chapters are of very different lengths. Moreover, each is written in a somewhat different style, depending on the kinds of information available for that column.

We've had a lot more experience modeling data, for example, than we have in modeling locations or even people and organizations. Mr. Codd gave us a mathematical basis for modeling data that does not exist for any of the other columns. For the others, we are trying to establish discipline, but it doesn't come easy.

A colleague of mine once remarked that he would like a book "to assist people like me who don't have time to learn anything that's not new". I would like this to be such a book. It will show you what's already been invented and point you in the direction of things that have not.

It is the joy and aggravation of our times to have the opportunity to be in on an industry that is building itself before our very eyes. At its best, this book is no more than a snapshot of what we know in the year 2002 of the modern era. With luck, future editions will have a great deal to add. The homework assignment for every reader of this book is to be diligent in expanding this body of knowledge.


Team-Fly

Top