Foreword

Team-Fly    

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

Once upon a time, my son was five years old. Like most five-year-old children, he was very curious about the world around him. As I was reading Dave's book, one of my son's curious moments came to mind. While our family was cruising in a small boat, he questioned how it was possible for the boat to float in the water, instead of sinking to the bottom of the bay.

To put this moment of childhood curiosity into proper context, it is important to know that my husband is a civil engineer by background. I am a mathematician by training. So, this is exactly the kind of question we enjoy pursuing with our children. In fact, our enthusiasm for my son's question led to our brilliantly delivered revelation of Archimedes Principle, complete with an explanation of its input and output parameters.

Now, those of you who are familiar with five-year-old children already know how this turned out. Not only did my son begin to squirm immediately, but also he was quite unimpressed with Archimedes. Rather, he was interested only in knowing whether something about the boat made it float in the water, or whether it was something about the water that pushed on the boat.

This was one of those puzzling parenting moments. We were speechless. What kind of question is this? Indeed, what kind of answer does it deserve?

Of course, John Zachman's Framework provides insight into the source of our confusion. John's framework teaches us that there are as many as six different perspectives of the same phenomenon . The business expert sees the world differently from the information architect, who in turn sees things differently from the system designer. More importantly, each perspective is legitimate in its own right.

Typically, a spectator views the boat's behavior in terms of the perspective that is most intuitive to that spectator. It was painfully obvious that my son felt most comfortable with an immediate, concrete perspective, where he perceived that the objects are in control. My husband and I simply felt more comfortable with the perspective concerned with the underlying laws of science (or business policies and parental rules!) that are running the show.

But, both perspectives (and others) were at play in floating the boat, even if we weren't explicitly aware of them.

The confusion over these perspectives has tormented information professionals for decades. Today, with the Zachman Framework as a foundation, we now know better. That is, we now know that if two people discussing a prospective system cannot understand each other, it is probably because they are each operating in a different cell of the Framework. Neither professional is necessarily incorrect or incomplete, but simply viewing the same problem space from a different perspective.

But, the total architecture is the holistic view of how individually organized deliverables relate to each other in a blueprint (not unlike a musical score, as Dave writes in his introduction) and how they interact with each other in the working world.

It is no easy task to create such a blueprint. The Zachman Framework is elegant in pointing out the breadth and depth of the challenge. But, as a practitioner, how do you navigate through it? Until now, you were on your own, but Dave's book is an excellent directory for this journey. Specifically, Dave provides a comprehensive survey of techniques for the Framework cells that defines the path from vision to architecture.

The value of this book is three-fold . First, the book is appropriate for both newcomers and old timers because it is historical and tutorial in nature. Second, the book has something of value for every reader, whatever a reader's emotional attachment to a particular systems development paradigm. That's because the book graciously incorporates techniques from well-known to the lesser known disciplines. It includes proven insights from structured systems analysis to information engineering to object-orientation and to the most recent, a business rules approach. It is destined to become the authoritative source for defining roadmaps from vision to architecture. The book is articulate (a natural strength of Dave's) and to the point. We can be grateful for Dave's opinions on this subject and his generosity in sharing them in a serious, but entertaining way.

Third, and most important of all, this book elevates (necessarily again, thank goodness!) the importance of the requirements analysis process. Why is this so important?

Dave points out that in our business, painfully, we operate most often without a score to follow. We are the epitome of improvisation. Bob Giordano of Knowledge Partners Inc indicates that this is not new. He states, "We have always employed iterative approaches to development. It is just that in the 70s and 80s, each iteration took years and cost millions because monolithic systems morphologically coupled everything to everything else."

Today, the iterative phenomenon is more obvious, prevalent and perhaps exaggerated, with the recent trend toward iterative development methods and extreme everything. Without a doubt, these trends are useful for specific aspects of systems development, for those pieces that are uncertain or that are discretionary. But, is there a hidden cost to sacrificing the fundamental elements of analysis? Perhaps so.

Dave points out that analysis is needed in order to see simplicity, and to avoid the development of unnecessarily complex systems. Analysis is also needed to understand the elements of change. We live in a world of accelerating change and uncertainty. Therefore, change should not stop when the system goes into production. The ability to change should be designed into the system so that incremental change is the name of the game forever, at a reasonable price. Otherwise the business will march in place and possibly go backwards .

You are setting the pace and direction of business change through information technology. You ought to have a score by which an uncertain future can unfold in an orderly way. Use this book as a roadmap for creating that score.

Time has passed. It has been many years since my son's question about floating boats. Supposedly, he has long forgotten the question. Hopefully, he is old enough to have a greater appreciation for Archimedes' role in the boat's behavior.

What is the answer to my son's question? I still don't know because I don't understand the whole picture, only parts of it.

But, if I wanted to know the answer to my son's question, I could find the answer in the score or blueprint.

It would all be so elegant. It would also seem simple because someone took the time to make it so. As you can see, the score or blueprint is a valuable investment because it represents solid analytical thinking. This thinking has one eye focused on simplicity and another looking to enable change. When these two properties are present (simplicity and agility), the blueprint (or score) should stand the test of time. If you skip Requirements Analysis, you miss this thinking. Dave helps you rediscover it.

Barbara von Halle


Team-Fly    
Top
 


Requirements Analysis. From Business Views to Architecture
Requirements Analysis: From Business Views to Architecture
ISBN: 0132762005
EAN: 2147483647
Year: 2001
Pages: 129
Authors: David C. Hay

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net