What Makes a Good Function Structure?

General
The Function Structure is the primary organizational tool of the analytical portion of the Structured Planning process. It is used to capture what must be covered to achieve a high-quality solution to a system problem. Done well, it breaks up the system to be designed into cohesive components that naturally reflect the actions performed or to be performed and their categorizations.

It is a tree-structured hierarchy, consisting of four or more levels, each of which has a distinct form of action description depending on its position, from general at the top to specific at the bottom. A good Function Structure will display thorough, balanced coverage at each level and will scrupulously maintain the linguistic format appropriate to description at each level.

System Level
The System Level is the top of the Function Structure. The name of the system to be developed should be the sole entity at this level.

Mode Level
Modes are major conditions of system operation or behavior. To distinguish them from other action entities in the Function Structure, they should be named to suggest "classes" of operation. The suffix -tion frequently is used to specify a Mode (e.g., Production as opposed to Producing, but other noun forms work equally well-Transport, Storage, Use, Repair, Retirement, etc.). The key to good naming at the Mode level is to find word forms that imply process, but treat it more as a class of actions than one dynamic at the moment. Production is a class of actions; Producing is an action going on now. Modes should usually be expressed as one word, but multiple words can be used as long as the "class" quality is preserved (e.g., Preparation to Initiate Proceedings or Fire and Disaster Protection).

There may be Submodes under Modes. If so, they should have the same characteristics as Modes: they should naturally break down what goes on in a Mode into two or more balanced "class" categories, and they should be named using the same convention used for Modes.

Activity Level
At the Activity level, the naming convention changes to fit a different kind of conception of action, one that brings the analysis to a more dynamic level and closer to specific action descriptions. Activities are "purposeful performances". Much like scenes of a play, they identify discrete collections of actions that build toward a specific goal.

Activities should be named using the gerund form of verbs (i.e., verbs with -ing endings that turn a verb form into a noun form that gives the action duration). Producing is an Activity for Structured Planning, where Production is a Mode. Activities should usually be single words but, as with Modes and Submodes, word pairs may be used if they improve the specification (e.g., Table Setting or Food Processing under the Submode Food Preparation).

Function Level
Functions are the reason the Function Structure exists. At this level, actions should be described specifically enough that they can be used as the requirements for the project: a good system solution will be able to perform well all the Functions identified as being required for its full range of operations.

As for all levels, the Function level should show balance and coverage within each Activity. By appropriate choice of level of detail, the number of Functions should be limited to from five to ten per Activity. If significantly more seem absolutely essential, the Activity is probably too broadly specified.

For form, a Function takes a verb phrase. As the most specific form of action in the analysis, the verb phrase is best to capture necessary detail. Good Functions should provide as much information as possible without necessitating too many Functions for the Activity. Usually, this means that multiple word Functions are better than single-word (e.g., for a Cooking activity, Heat is not as good as Distribute heat evenly).

Functions can be of two types: (1) System Functions (performed by the system), or (2) User Functions (performed by the user in working with the system). Of the two forms, the first is preferred because it is more directed toward the planner's need to describe the system, so, when possible, the form of the Function should be made to be system-oriented or neutral (in the sense that it can be just as easy to think of the system doing it as a user doing it). Given a choice of phraseology between Read recipe and Process recipe, the latter is a better choice because it is more neutral-it is easier to think of the system processing the recipe than reading it, but it is possible to think of the user processing it also, so the planning team may just as easily think of reserving recipe processing to user or system as the developing concept dictates.

Action Analysis forms are used to analyze Activities. Once identified using them, Functions are transferred to the Function Structure to present the functional analysis fully.