Problem Frames Approach - Problem Analysis and The Software Development Process

Problem Analysis and The Software Development Process

When problem analysis is incorporated into the software development process, the software development lifecycle starts with the problem analyst, who studies the situation and:

• creates a context diagram
• gathers a list of requirements and adds a requirements oval to the context diagram, creating a grand "all-in-one" problem diagram. (However, in many cases actually creating an all-in-one problem diagram may be impractical or unhelpful: there will be too many requirements references criss-crossing the diagram to make it very useful.)
• decomposes the all-in-one problem and problem diagram into simpler problems and simpler problem diagrams. These problems are projections, not subsets, of the all-in-one diagram.
• continues to decompose problems until each problem is simple enough that it can be seen to be an instance of a recognized problem frame. Each subproblem description includes a description of the specification interfaces for the machine to be built.

At this point, problem analysis — problem decomposition — is complete. The next step is to reverse the process and to build the desired software system though a process of solution composition.

The solution composition process is not yet well-understood, and is still very much a research topic. Extrapolating from hints in Software Requirements & Specifications, we can guess that the software development process would continue with the developers, who would:

• compose the multiple subproblem machine specifications into the specification for a single all-in-one machine: a specification for a software machine that satisfies all of the customer's requirements. This is a non-trivial activity — the composition process may very well raise composition problems that need to be solved.
• implement the all-in-one machine by going through the traditional code/test/deploy process.