Chapter 4. Column Two: Activities

Team-Fly    

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


The activities dimension of the Architecture Framework is concerned with what the enterprise does . Specifically, what kinds of transformations of material and information take place in the course of doing business? What are the enterprise's activities in carrying out its mission? The modeling of an enterprise's activities is somewhat less coherent than the modeling of its data, because there are many very different ways of viewing activities.

The object-oriented world tends to view the activity and data columns together. Certainly in object-oriented design the activities are designed as adjuncts to the code which defines the data in object classes. In analysis, that is possible to some degree, although it is still useful to address business activities in their own right. These tend to be discovered when you interview someone and ask "What do you do?" Once activities have been modeled separately, a function/entity type matrix (showing what activities create, retrieve, update, or delete occurrences of each entity) can be used to determine which activities go with each entity.

Unfortunately the terms "process", "function", and "activity" are often used interchangeably, and worse still, different authors define the terms slightly differently. The following definitions, however, are close enough to most people's usage to be satisfactory for our purposes. These definitions will be the basis for the rest of this book.

  • Activity is a general term to describe something that is done. It is used when more specific definition is not available.

  • A process is an activity performed by the enterprise to produce a specific output or achieve a goal. It may or may not be described in terms of the mechanisms used. Processes are usually represented in terms of their timing relative to each othereither in sequence or in paralleland they also are usually described in terms of their inputs and outputs. An example of a process is "issue purchase order". Row Two descriptions of activities are typically in terms of processes, although processes may also be terms for Row Three descriptions. These processes may be viewed at a high level or in atomic detail.

  • A function is a type of activity to carry out an objective of the enterprise. It is described solely in terms of what it is intended to accomplish, and without regard for the technology used to carry it out. This is also described without reference to time. An example of a function is "order material". Functions are used to describe the business in Row Three terms, but they are usually accessible to business owners as well. Functions also begin from a global perspective (what is the mission of the enterprise?) and may be broken down to reveal a considerable amount of detail.

  • An essential activity is either a fundamental activity that performs a task that is part of the enterprise's stated mission or a custodial activity that establishes and maintains the system's essential memory by acquiring and storing the information needed by the fundamental activities [McMenamin and Palmer, 1984, pp. 17-20]. In other words, like a function, an essential activity is without reference to technology used, but like a process, it is positioned in relative time. It may also be described in terms of its inputs and outputs. Essential activities are elements of the Row Three perspective. An essential activity might be "Receive shipment", or "Place order".

    Data flow diagrams and function hierarchies may break activities into activities more detailed than an essential activity, but by definition the essential activity is at the lowest level of detail that describes an inherent function of the enterprise. Any lower-level activities are described in terms of the particular way the function is carried out in this enterprise.

So, while this chapter might be thought to be about "process modeling", to be more rigorous here it will be called "activity modeling".

This chapter will describe several different approaches to modeling processes and functions. A summary of the different characteristics of each technique is provided at the end of the chapter. It would be nice to be able simply to adopt the best features of each, but unfortunately, use of any of these techniques requires a graphic tool (a "CASE" tool). Tools are available for almost all the techniques described here, but no one tool supports more than one or two, so it is not currently possible to adopt a superset. Invariably you will be required by circumstances and corporate politics [1] to use only one of the techniques and endure its shortcomings. From this book you will at least be able to tell what those are in advance.

[1] OK, occasionally by reasoned judgment.


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