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.
|