The complete guide to requirements analysis for every system analyst and project team member.

Thousands of software projects are doomed from the start because they're based on a faulty understanding of the business problem that must be solved. The solution is effective requirements analysis. In Requirements Analysis: From Business Views to Architecture, David C. Hay gives you a comprehensive overview of the world's best requirements analysis practices, organized coherently to help you choose and execute the best approach for every project. In addition, he guides you through the process of defining an architecture—from gaining a full understanding of what business people need to the creation of a complete enterprise architecture.

Practical solutions will help you:

• Focus more clearly on the goals of requirements analysis

• Represent the fundamental structures and systems environment of any enterprise more accurately

• Identify key information processing gaps and discover which information technologies can best address them

• Clarify the goals of your new system and reflect them more accurately in your models

• Understand crucial people-related issues that impact requirements

• Plan smooth transitions to new systems

Requirements Analysis: From Business Views to Architecture provides the complete process of defining an architecture—so that you can build a rock-solid foundation for your next software project.

Amazon.com® Reader Reviews (Ranked by Helpfulness)

Average Amazon.com® Rating:  Based on 9 Ratings

It will broaden your horizons, but it is not a cookbook. - 2003-11-14
Reviewer Rating:
_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.

Good on data modeling, but little else - 2003-03-19
Reviewer Rating:
I had a good book on OO analysis and the UML, but though it weak on data modeling and business rules. So I went looking...

I read the 4 reviews on this page and purchased the book. Given the reviews and the fact that it was just published, I thought I would be getting a book that unifies a broad sweep of modern analysis techniques (OO, UML, Data Modeling, Design Patterns, Business Rules, Requirements Gathering Techniques, Iterative Development, etc.).

On the contrary, I received a book that is 90% data modeling biased and steeped-in analysis techniques of the pre-OO era, such as data flow diagrams (people still use these?). This looks like a book I had in school 10 years ago.

There are passing and, at best, cursory references to UML modeling approaches, but that is all that is in this book with respect to modern OO approaches.

There is absolutely nothing said with regards to Design Patterns nor an iterative approach to building systems and mitigating risk. I find this lack of coverage absolutely incredible in a software requirements analysis book published in 2003. Unbelievable!

Ten years ago, this book might have been considered a good benchmark. Not today. This author's sole idea of architecture is the data model and functional decomposition. Ugh.

If you are weak on relational data modeling, this book has redeeming value. Otherwise, if you are trying to figure-out how to elaborate requirements and transform them into a working OO system using UML, Design Patterns, and an iterative approach, I highly recommend Craig Larman's top-notch "Applying UML and Patterns: ...". It really sets the standard.

The Larman book is weak on data modeling and business rules - which I thought Hay's book would address better (and is why I bought it sight unseen). It does, but at the expense of everything else.

Giving the Zachman framework a new lease on life - 2003-04-16
Reviewer Rating:
'Rather than reviewing requirement analysis from the perspective of a particular implementation of technology, this book views it as fundamentally an architecture process. This books premise is that requirements analysis is the translation of a set of business owners' view of the enterprise to a single, comprehensive architectural view of that enterprise'

David inspired by the Zachman framework shows how various methodologies and techniques can be organised for a omprehensive requirements analysis approach leading to an architecture solution. This book really brings forward the briliance of the Zachman framework. It gives a new perspective on Zachman and brings the framework back into the contempory enterprise strategies framework.

David shows not only how to avoid the common mistake of building an architecture from a single business view but also how to integrate various views into a common architectural view.

The book keeps to it focus on "Requirement analysis" and the reader is not really helped to go beyond the requirement analysis phase into the design and implementation phases. A good reference to have for people with an appetite for enterprise architecture strategies

aggreed there is no OOA - 2005-08-28
Reviewer Rating:
OOA is some "super magic" that uml people found it for commercial reasons.As Mr.Hay mentions there is no OOA.there is only "analysis" of the bussiness.
I am a bussiness owner and a coder for a long long time.The concept that david hay is talking about will take developers life time period to understand.
The most simple explanation is for the reviewer to look at his/heer database tables and see the replication places as they had no abstraction in mind when they were coding the "thing"(prefered design over analysis).
David Hay's,Len Silverstone's and Martin Fowlers(analysis patterns) should be read over and over again.it is like swimming u do not pick it up in the first try.
PS:These books are for an analists who can understand the meaning of polymorfism
PS2:By the way OO people even could not agree about compostion over aggregation ,method over operation.Keep in mind UML is a design tool should not be used like a "golden hammer"

Excellent textbook - 2006-06-21
Reviewer Rating:
As my headline suggests, this book is more suitable for the classroom environment than for the professional systems analyst or systems developer.

What the author did was to basically take the Zachman Framwork with all the columns and rows and explain every possible combination by using the usual modelling techniques (UML, DFDs, IDEF0, ERMs, CRUD matrix etc.). You therefore get a very - and I really mean VERY - broad overview over many of the current, state-of-the-art methods available to systems analysts (from data normalization to analyzing objectivied relationships).

I recommend you to read this book if you are someone from the academic world who wants to get a very good overview of the Zachman Framework. Especially if you are specifically interested in data analysis you will find this book to be very helpful.

Browse Similar Topics

Top Level Categories:
Software Engineering

Sub-Categories:
Software Engineering > Requirements and Specifications