From the Business Owners View to the Architect s View

Team-Fly    

 
Requirements Analysis: From Business Views to Architecture
By David C. Hay
Table of Contents
Chapter 4.  Column Two: Activities

From the Business Owners ' View to the Architect's View

Figure 4.1 shows the Framework with Column Two highlighted.

Figure 4.1. Architecture FrameworkActivities.

graphics/04fig01.jpg

The Row One scope effort for the enterprise should have defined the scope of this project in terms of, among other things, the sets of activities to be addressed: "process control", "facility management", "order processing", and so forth.

Business owners view processes in very concrete terms. Fill out a purchase order. Operate a lathe. Receive a shipment. Most descriptions include at least an implied mechanism for carrying out the activity. The business owner is observing the flow of materials as much as the flow of data. Physical data flow diagrams (page 161) and process models of the sort used in business process re-engineering (page 185) are suitable for presenting this view.

The architect's view is of functions or essential activities. An architect is interested only in what actions must be taken to carry out the company's objectives and policies. By definition, if this is done in the context of a system requirements analysis, it is expected that current technology will be replaced with new technology, so we need a description of the underlying functions that is not dependent on the technology involved. This is the realm of the function hierarchy and the essential data flow diagram.

All of this is not to say that functions are not suitable as a representation of the business owner's view. They should be described in natural language and validated by subject-matter experts. Their expression of what the business does without regard for technology, however, makes them fundamentally elements of the Row Three perspective.

In summary, then, the analyst must evaluate each physical process to determine what underlying function is being performed. Some processes do not address a corporate function at all but are simply a means for dealing with inadequate current technology. (An example might be "Re-enter customer data".) Some processes are done simply because "we've always done it that way". Thus one of the tasks is to determine which processes are truly "value added" in that they contribute to the effective operation of the enterprise. (See "A Word About Business Process Re-engineering" on page 185.)

The business owners see the activities being performed by current systems. The architects ' view is of the functions being performed by those systems, so they can see how new systems might perform the same functions. The designer will design new processes to carry out those functions.

Table 4.1 compares the terms "process", "function", "activity", and "essential activity".

Table 4.1. Activities, Processes, and Functions
 

Processes

Functions

Activities

Essential Activities

Include Mechanisms?

May or may not

No

May or may not

No

Show Relative Time?

Yes

No

May or may not

Yes

Atomic?

May or may not be

May or may not be

May or may not be

Yes

The techniques described here have been evolving since the mid-1970s. Because most of them predate it, they vary in the extent to which they address Rows Two and Three of the Architecture Framework. Some are more suitable for one or the other, and others can be used to represent both. Because the interrelationships among the tools and their history is important, they are presented here in historical order, rather than by the rows they address. In each case, the row(s) addressed will be discussed.


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