Guideline: Recurring Problem Analysis
This guideline describes the main areas which should be considered when performing a recurring problem analysis.
Relationships
Main Description

Analyzing and structuring software problems is a task that is often given little formal structure and attention. In the face of external pressures such as competitive pressures, time-to-market pressures, and so forth, the development organization may short cut this effort.

However, it is understood by most that the nature of the problem must be understood before the proper solution is established. And yet getting time on the project schedule to have a formal description of the problem and to verify its existence and the existence of the solution is a difficult task.

Before that can be overcome the enterprise needs some formalism for describing problems that can be understood at multiple levels. To help with this the enterprise should establish artifacts and models that will be used to describe the problem and the solution.

This can include using context diagrams, scenario diagrams, and object diagrams. With these kinds of models and diagrams the architect or developer is often prone to generalize the problem or the context too soon.

The method for arriving at the real nature of the problem is to continue to ask ‘why'. The architect or developer [or other asset producer] should continue to drill into the real issue through a succession of ‘why' questions in an attempt to go beyond a description of the features and tease out the relevant issues.

As this is performed, the Asset Specification is updated to reflect the description of the recurring problem and the proposed solution for this.