From Analysis to Design | Requirements Analysis: From Business Views to Architecture


Team-Fly

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

	Introduction

From Analysis to Design

It is important not to confuse requirements analysis with system design. Analysis is concerned solely with what some call the problem space or the universe of discourse : What is the nature of the enterprise and how does it use information? Design, in the solution space , is the specific application of particular technology to address that enterprise.

In other words, analysis is concerned with what is to be done, not how to do it.

The models developed during analysis must be technologically neutralmodels that describe the business without regard for the technology that may be used to address them. This allows the designers to come up with solutions that otherwise might not have occurred to them when the project started.

There is a common tendency for designers, when they are analyzing requirements, to construct the analysis results in terms of a particular technology that they wanted to apply before they started. They go into the effort with preconceptions of what the solution space is going to look like, so they seek out problems they already know how to solve. ^[6]

^[6] This is an example of the old maxim , "When all you have is a hammer , every problem looks like a nail."

The "object-oriented analysis" referred to above is an example of this. The idea here is that analysis should be conducted with the understanding that the solution will probably be a set of object-oriented programs, so the models should be biased to reflect that.

In my view this is wrong. I take this position, you should understand, in the face of considerable opposition . Martin Fowler, for example, in the October 1999 issue of Distributed Computing [Fowler, 1999, pp. 4041] argues for merging analysis and design. He begins by asserting that, however it is done, an analysis model is an artifact constructed by the modeler. "We try to abstract, and thus simplify our analysis models, yet such abstractions are constructed you can't really say they are in the world . Can we, should we, be passive describers when we analyze? And if we are not, are we really doing design rather than analysis?"

Of course it is true that analysis is all about constructing artifacts. The whole point of this book is to describe the artifacts analysts create as they move from the business experts' views of things to what will here be called "the architect's view". That is, the analyst will indeed construct artifacts, but the purpose of these artifacts is to describe the fundamental structures and concepts behind the world that the business people see. This is not the business owner's view, and it is not the designer's view, either. The architect's view is of structures and concepts without regard for technology. To move from the architect's view to the designer's view will require a second translation.

Mr. Fowler recognizes this and points out that there is then a cost associated with transforming a technologically neutral analysis description of the business "to the technology we eventually build with, and if we want to keep the analysis picture up to date we will pay an ongoing cost". This is true, just as there was a cost to translating the business owners ' views into the architects ' views in the first place. But the benefit of making the steps explicit is that the process can be better monitored and controlled.The position taken in this book is that the translations are well worth their costs.

If a programmer speaks to a business expert and then turns around and produces a system, he or she has just done those two translationsunconsciously. The problem is that no one is in a position to evaluate the quality of either translation. There has been no publication of either the business owners' views or the architect's views. If (dare it be said?) errors were made in either or both translations, they will not be evident until the final product is created.

Imagine, for example, an analyst who looked at an airline with the assumption that any new system would be concerned with issuing paper tickets. That analyst would completely miss the opportunity to issue electronic tickets instead. (Indeed that analyst's client would be left in the dust when its competitors did just that.) The analyst, however, who recognized that the problem was getting passengers on the planenot the issuance of ticketswould be in a much better position to help the client lead the way into the new marketplace .

What is the cost of the wrong system? What is the cost of a system that is built of technology that becomes obsolete quickly? What is the cost of myriad systems that don't communicate with each other very well? These costs should be considered when evaluating the costs of analyzing requirements first.

Mr. Fowler goes on: "My view is that the key to the usefulness of an analysis model is that it's a communication medium between the software experts and the business experts. The software experts need to understand what the model means in terms of building software, and the business experts need to understand that the business process is properly described so the software experts are understanding the right thing."

In this he is absolutely correct. But that is precisely the point of organizing our efforts around a framework that recognizes differences among the perspectives of the various players. These perspectives must be addressed, and the two translations to get from the business experts' views to the designer's view must be made explicit. For the translations to reside only in the heads of programmers is very dangerous indeed.

The models used during analysis, then, are different from the models that will be used in design. On the data side, for example, entity/relationship models or business-object models must be translated into table designs or computer-object classes. In processing, a business data flow diagram or function hierarchy chart must be translated into one or more program structure chartsand so forth. In both cases, the translation may be straightforward, but even if it is not, there must be a translation. The points of view are very different.


Team-Fly

Top