The Analysis Process | Requirements Analysis: From Business Views to Architecture


Team-Fly

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

	Chapter 1. A Framework for Architecture

The Analysis Process

Given the Architecture Framework, then, requirements analysis can be seen as the process of translating business owners ' views of an enterprise into an architect's view. This is always done for a specific project, whose scope was defined by those with the planner's view.

A business owner's view is usually expressed in terms of industry jargon and is about the mechanisms involved in running the enterprise today. Requirements analysis must analyze this to determine the fundamental structures and functions of the business, in order to suggest new ways that these might be addressed.

In this book, the models will be organized by column as much as possible, although several of them have implications for more than one column.

Data

Requirements analysis of data involves translating the owner's views of the things encountered every day into a model of the fundamental things of the enterprise. That is, where an owner in one division is concerned with " clients " and "suppliers" and an owner in another division is concerned with "customers" and " vendors ", the architect's model will address "people" and "organizations" and the various roles they may play in the course of the entire company's business.

An important part of the process is to capture the business owner's language. What terms are used to describe the business, and what do they mean? What facts of the business are expressed in those terms? This includes dealing with the fact that different people will use different terms for the same thing and one term to mean different things. Such discrepancies should be resolvedor, if that is not possible, at least clearly documented.

The business owners' views of data are here referred to as divergent , because there are many of them, and because they encompass many not necessarily related things. The architect's view, on the other hand, is called convergent , because it brings together all these views in what is supposed to be a coherent whole.

To the extent that the architect's model may be more abstract than the business owner's view, each one of the architect's artifacts (entities, functions, etc.) must be translatable into the business owner's language.

In addition, where the business owner sees objects in many-way relationships, which are often "many-to-many", the analyst must translate these to the architect's view of one-to-many binary relationships.

Activities

Business owners' views of enterprise activities are inevitably biased toward the mechanisms currently in use. For example, the procedures an interview will reveal may describe entry of data into the current system, transmission of faxes, and the like. The analyst's job is to determine the underlying functions being performed, without regard for the technology performing them. "Cut a purchase order, sending the white copy to the vendor, the yellow copy to accounting, the blue copy to the warehouse, and the green copy to the requester" becomes "Place an order", accompanied by descriptions of the contents of the communications to the vendor, accountant , warehouse, and requester.

Locations

The business owner sees geography as a set of offices and communications points with physical addresses. The analyst examines the roles of each of these locations and describes a functional network of those roles. More than for any other column, analysis of this column is highly dependent on analysis of the other columns at the same time. Where are the data? Where are the activities? And so forth.

People and Organizations

Traditionally, the businesses viewed their employees in terms of the people reported to and the people doing the reporting. In modern times those relationships, along with relationships to colleagues, customers, vendors, and even others in the industry, are all changing. The analyst sets the stage for business process re-engineering by determining exactly what roles are being played and what kinds of communications are required to play those roles.

Timing

The impetus for business is the set of business events in the world and the reactions required to respond to them. The analyst examines these events and translates them into criteria for better understanding data relationships, functions, and business rules.

Motivation

The mission of the organization is its motivation as expressed from the scope perspective. The business owners translate this mission into sets of objectives, goals, policies, and business rules. The analysis process is concerned with examining business policies and business rules to determine precisely how they affect data and activities.


Team-Fly

Top