What Makes a Good Activity Analysis?

General
The Activity Analysis form should be considered a worksheet for exploring the structure of an Activity. It is not a document to be archived, but, rather, is a convenient place for considering, in one work space, the nature of an activity, the articulation of its Functions, and the recognition of what can go right or wrong in fulfilling those Functions. The important information developed here is retained elsewhere in the Function Structure (for the Functions described) and Design Factor documents (for the insights uncovered). The form itself is expendable when its purpose has been achieved.

Originator, Contributors and Dates
Names and dates must accurately reflect the development of the Activity Analysis' content, and the last date should agree with the version date at the bottom of the form. The Date of First Version at the bottom of the form should be the date when the form was originated.

Scenario
The Scenario is a short description of what takes place during the Activity. In theater metaphor, it is the brief synopsis that is given in a playbook before each scene to set the stage for what is to come. For best effect, it should be written in present tense as if the explanation were coming live from an on-scene observer. At its best, it helps the analyst to conceive the activity fully and see it nicely as a discrete part of the collection of activities making up the system.

Users, System Components and Environmental Components
Continuing the theater metaphor, an excellent way to analyze an Activity is to take it apart and put it together as a playwright would deconstruct and construct a scene of a play. The three important components for the playwright are actors, props and set; for the Activity analyst these correspond to users, system components and environmental components.

Users are more appropriately "user roles" since individuals may readily shift roles in an activity. System components are those things used in the Activity that might be redesigned or supplanted with new products, processes or services. Environmental components are those fixed aspects of the Activity's context that probably won't or can't be changed. These place requirements upon the system components, however, and need to be considered when the insights for Design Factors are being sought. Both system components and environmental components may include non-hardware elements (processes, conditions, procedures, organizational constructs, etc.).

Important as this section is for establishing the Activity, it is not used beyond this stage-setting function. Its purpose is to bring the components of the Activity into sharp focus in preparation for the specification of Functions and Design Factors in the sections to follow.

System and User Functions
Functions are the fundamental building blocks manipulated in the Structured Planning process. They, along with Defining Statements, are also the criteria against which the system will be planned and evaluated. A good functional description is mandatory for a good conceptual plan.

For the convenience of the analyst, Functions can be described from the viewpoint of the system or the user. Because it is almost always the planner's goal to develop system, not user properties, the system viewpoint is the preferred form, but because it is difficult to think sometimes about a Function from other than the user viewpoint, this form is also available. Where possible, however, Functions should be described with neutral terminology so that they can be conceived as being performed either by system or user.

Functions should be described with verb phrases. This is done for two reasons: first, because Functions are actions, and actions are most appropriately described with verb phrases; and second, because, in Structured Planning, verb phrases are reserved for Functions, eliminating confusion about what they are. Verb phrases can range from a verb alone to a verb with object and modifiers. The best choice is the one that carries the most information, a verb with an object-and a modifier if it can add important supplemental information.

Five to ten Functions per Activity is a good goal. Too many more, and the Activity is probably too generally described, perhaps meriting division into two or more Activities of greater specificity. Any less, and the Activity is too specific to be treated as a full Activity; it and its Functions may better be reconstructed as Functions of a larger Activity.

Associated Design Factors
The Design Factor document, arguably the most important element of the Structured Planning process, most frequently begins its development as a title on the Activity Analysis worksheet.

Design Factor titles should capture in several words something of an insight about what can go wrong (or right) in performing a Function. The Design Factor document will develop the insight; what is important on the Activity Analysis worksheet is that the title be well enough worded that the insight cannot be lost between the time that the Activity Analysis is done and the full Design Factor document is written. To support this, titles should be written in "problem" format (vs. "solution" format); the focus should be on the insight, not what can be done with it.

That Design Factors are associated with Functions means that a Design Factor is concerned with observable behavior associated with specific Functions. On the form, the best way to show this is to draw a line of association between Function and Design Factor title. Either may be associated with one, many or none of the other.