- About Requirements Analysis
- From Analysis to Design
- About This Book
This chapter is from the book
This chapter is from the book
This chapter is from the book
About This Book
This book addresses requirements analysis in terms of two different conceptual structures:
The System Development Life Cycle: the set of steps required to build and implement a system
The Architecture Framework: the perspectives of the players in the development process, and the things they will see from those perspectives
System Development Life Cycle
Many methodologies are organized around the "system development life cycle"—the set of steps required to develop systems. The names vary, but in principle the steps are these:
Strategy: The view of the enterprise as a whole. What is the overall systems-development effort going to look like? What are the overall things of significance to a business? What parts of the business should be addressed with new information systems? What priorities apply to those things?
Requirements Analysis: The detailed examination of a particular area of the business. In that area, what are the fundamental, underlying structures, what are the information-processing gaps, and what kinds of information technology might address these? What data are required, when, and where, for each function to be performed? What roles perform each function, and why? What constraints are in effect?
Design: The application of technology to address the gaps identified during the requirements analysis phase. Here, for example, the data structures become database designs or object classes and the function definitions become program specifications. At this point, in the interest of defining the behavior of a prospective system, attention is also paid to the human interface.
Construction: The actual building of the system.
Transition: The implementation of the system to make it part of the new infrastructure of the organization. This involves education, training, definition of new organizational structures and roles, and the conversion of existing data.
Production: The ongoing monitoring of the system to make sure that it continues to meet the needs of the organization.
In terms of the system development life cycle, then, this book is concerned with the analysis phase of this process, along with descriptions of that phase's relationship with strategy on one side and design on the other.
Architecture Framework
In 1987 John Zachman published his ideas about the structure of the body of information that constitutes the systems development effort. In his "Framework for an Information Systems Architecture", he made two important observations about the system development life cycle:
First, rather than the "phases" or "steps" in the effort, he is interested in the perspective of each set of players in the development process. It is as important, he asserts, to recognize that systems are developed by distinct groups with different points of view as it is to see the movement of systems from one step to another. These views correspond approximately, but not exactly, to system-development life-cycle phases.
Second, he addresses more than data and functions. He establishes a matrix that encompasses, for each perspective, not only data and function but also location, people, time, and motivation.
The framework for system architecture, then, is a matrix of rows and columns, where the rows are the different perspectives and the columns are the things to be viewed from each perspective.
The framework is described in more detail in Chapter 1. Briefly, the perspectives are the following:
The first is the planner's view, which is of the enterprise as a whole. This also defines the boundaries of specific projects to be undertaken as well as the relationships among them.
The business owner's view is that held by the people who run the business, with their particular jargon and technology.
Row Three is the architect's view.7 The architect attempts to understand the fundamental underlying structures of the business. These structures will be the basis for any new systems-development effort.
The designer's view is the first one concerned with the technology of new systems. The designer looks at the structures the architect describes and the information requirements they imply, and he applies his knowledge of technology to design new systems.
The builder's view is the perspective of the person actually dealing with the nuts and bolts of designing the system.
The final view is that of the production system—that is, the view of the new world created by the system analysts, designers, and builders.
The columns in the matrix represent what is seen from each perspective. Mr. Zachman began with data, activities, and locations. Then, with John Sowa in 1992, the frustrated journalism student in him recognized that he had addressed only three of the journalistic interrogatives: what, how, and where. There were three more: people and organizations (who), timing (when), and motivation (including business rules) (why).
It turns out that the entire body of knowledge currently available in the information-processing world fits into the cells of this matrix. It also turns out that the most passionate arguments occur because different people are viewing things from different perspectives. In the data column, the designer is interested in the design of a database, while the architect is trying to build a conceptual model of the business data. The business owner, on the other hand, is concerned with the tangible things that come up every day. If they all understand the differences in perspective, they can translate. The people who argue most violently are those who do not recognize these differences in perspective.
The Framework and Requirements Analysis
In terms of this framework, then, requirements analysis can be seen as the process of translating the business owners' views of an enterprise into an architect's view that can be the basis for future systems development. That is, the models and techniques in this book will be concerned with describing what actually happens in a business and with the inherent structures that underlie what happens.
The book will cover all the columns of the framework. Many methodologies address only activities, data, and sometimes timing, but most do not address network locations, people and organizations, or business rules. All of those will be covered here.
By the way, "Un petit . . ." when read in French, sounds a lot like "Humpty . . ."