Each Problem Element is given a title and number for reference.
A description of one or more context-specific functions to which
the Problem Element applies.
Keywords are used to help determine the interactions among Problem
The indices of Problem Elements interacting with this one are recorded
(If the Problem Elements are HTML documents they can be hyper-linked.)
Problem Elements interact if they should be considered together
in the problem-solving phase.
(Design Insight; Force/Tendency; Context/Misfit; Circumstance/Observation)
To get at the underlying force-tendency relationships "wanting"
to generate the form, the Problem Summary is often stated as a
loosely dependent clause using conjunctions like "if", "because",
"while", "where", or "when".
Care should be taken to not overstate the certainty, however.
Some cause-effect relationships are not all that discretely atomic
(Design Implications; Design Directives; Prescriptive Model; Pattern)
The Solution Summary isn't so much a design specification as it is a
rough scope of the solution space implied by the Problem Summary.
It is useful to think of it in terms of design directives, general
prescriptive models or patterns.
The Solution Summary often begins with "Therefore" to reinforce the
design action that would resolve the forces.
Detailed solutions are specified later as sets of Problem Elements are
considered together in the design synthesis phase.
A picture is worth a thousand words, so space is reserved to resinforce
the verbiage with visualizations: doodles, charts, graphs, diagrams,
sketches, photos, etc.
© Gary Swift, 1994
Problem Element document, page 2.