Function Hierarchies

Team-Fly    

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

Function Hierarchies

The simplest way to represent a business's operations is with a hierarchy of boxes. The top box of this function hierarchy contains the mission of the enterprise. Determine the six, seven or eight principal activities that are required to carry out the mission. Put each of these in a box attached to the top box. Then, for each of these, determine the six, seven or eight activities required to do it that continue this process for as long as seems reasonable.

Typically, this is done to represent functions (Architecture Framework Row Three), not current physical processes (Architecture Framework Row Two). A first pass at the steps in development of the hierarchy may begin with physical activities, but after that first pass it is important to define the activities without regard to current mechanisms: "Place order", not "Fill out purchase order". And, at least at the higher levels, these are functions rather than processes, although as you get further down the hierarchy, you may be inclined to show specific processes (with their implied sequence) rather than functions.

A good way to create a function hierarchy from your interview notes is to use a pad of sticky notes. For each verb in your interview notes, write a function sentence on a sticky note and place it on the wall. When all the sentences have been thus recorded, move the notes around to arrange them into a hierarchy. Insert functions as necessary to collect them together.

Add as the root of the hierarchy the mission of the enterprise, discussed in Chapter 8 of this book. Also add at the first few levels of the hierarchy the enterprise's strategies and tactics (also discussed in Chapter 8). Each function identified should be directly contributing to one of these.

Note that, to make the hierarchy comprehensible, you should arrange functions such that between five and nine functions appear on any level. In 1956 G. A. Miller published a paper, "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information" in The Psychological Review . In it he observed that the human mind can hold only about seven plus or minus two things in active memory at once. This turns out to be significant, because it is an excellent measure of complexity. More than nine things together constitute something hard to grasp or remember. Fewer than five constitute something so simple as to be uninteresting. To make the function hierarchy interesting, make sure that each level is a set of seven plus or minus two functions. It should be possible to easily comprehend the functions at each level and how they relate to each other.

It is also important for the set of seven plus or minus two functions to be parallel and coherent . Of course they must all be components of their parent function, but they should also be at roughly the same level of detail. If the function is "Take an order", it is appropriate to have subfunctions such as "Receive call", "Record customer information", and so forth, but not "Pick up pencil from the desk".

There are actually four ways you can break down a function [Feldmann, 1998, pp. 150155]:

  • Decomposition The components are themselves functions, in the sense that they do not refer to time or sequence, but rather are simply things that are done to accomplish the parent function.

  • Sequence This conveys the sense that processes are carried out as sequential steps to accomplish the parent function or process. Even if they are kept technologically neutral, there is a strong sense of the means by which the parent function is carried out.

  • Organization Here the parent function or process is broken into the organizational units that carry out parts of it. This is clearly not a good idea, since the objective of the model is to determine what is done, not how it is done or who does it. This does not reveal the true nature of the function itself.

  • Split by Type This is the case where a function or process may be carried out in more than one way. For example, the function "Fabricate product" may be done differently in each of 10 different work centers. Each work center is then broken out in its own right, revealing its component functions or processes. In a function hierarchy this is acceptable, but it is not quite the same kind of thing as a functional decomposition.

The lowest level should consist of elementary business functions or, in the language of the UML, "actions". These are the most atomic and indivisible functions or processes you can find. In 1992 Richard Barker and Cliff Longman defined an elementary business function as one which "when triggered must either be completed successfully, or, if for some reason it cannot be completed successfully, must 'undo' any effects that it had up to the point of failure" [Barker and Longman, 1992, p. 40]. Similarly, in the UML, an action is "an atomic computation that results in a change in the state of the model or the return of a value... it cannot be terminated externally" [Rumbaugh, et. al ., 1999, p. 122].

Stephen McMenamin and John Palmer, on the other hand, are less concerned with what is absolutely the most atomic activity. As will be described below (p. 162), the lowest level of interest to them is the "essential activity"the complete response to an external event. This might comprise more than one atomic activity. It could be either an "essential process" in a data flow diagram, or an "essential function" in a function hierarchy. The same criteria apply.

While an essential activity may not be quite as atomic as an elementary business function or a UML action, it is more useful in understanding the nature of the business and it is more amenable to defining a specific process for achieving that understanding. For these reasons, this essential activity approach is described in more detail below.

Figure 4.2 shows a sample function hierarchy.

Figure 4.2. A Sample Function Hierarchy.

graphics/04fig02.jpg


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