For each of the functions the system must perform there are a number of real and potential problems, i.e., forces that must be resolved by the system's form.
The forces may be directly observed, derived from literature search, inferred from constraints presented by the system's environment or context, or generalized from observations about people using similar systems.
As elements of the problem space, they constitute design insights that have been variously called
"misfit variables",
"requirements",
"problem elements", or
"design factors".
Regardless of what they may be called (this document will use the term "Problem Elements"), they are individually recorded on 1 to 2-page documents along with ideas that might resolve the forces.
The documents are written in a language that expresses the insight in terms of force-tendency relationships, requirements of fitness within the functional context, or at least a circumstance-specific observation, and in a common format so that they can be related to one another.
In this way the data is reduced to real information; it has heuristic value for generating design solutions because it describes the underlying forces that must be resolved in operational terms.
The team should be careful to cover all the users of the system in all its modes of behavior, and in all its various operational environments.
There are more and less rigorous methods to discover Problem Elements.
Charles Owen[1]
proposes Action Analysis documents that describe the system's functions at an elemental level.
These are systematically used to generate the Design Factors (a.k.a. Problem Elements).
A less systematic approach may be employed, especially for smaller, less complex design problems, but in any case the team should be careful to cover all the users of the system in all its modes of behavior, and in all its various operational environments.
Moreover, as the goal is problem identification and analysis,
Problem Elements are often based on (and may cite) information generated from the use of
"left brain"
or
"glass box"
methods and tools.
See our Problem Element document template, annotated with descriptions of the content for each section.
Footnote (1) -- Design For Integrity , Charles Owen, Illinois Institute of Technology, Institute of Design
Design Matrix home page
Table of Contents >>