General Process Model

System development usually starts with a natural language problem specification consisting of an initial set of requirements that is supplied by the customer ("Customer NLPS" for short). Since natural language has no unique semantics (for instance, what is the meaning of "In case of a hazardous condition, the windows must be closed"? Does "must be closed" describe a state or an action? If it is an action, when must it be taken?) these requirements should be formalized by the system developer, yielding a formal problem specification (FPS).

As a result of this formalization, existing ambiguities of the natural language description are resolved in one particular way, which may differ from the original intentions of the customer. Therefore, the customer needs to check whether his intentions are correctly expressed in the FPS. Since the customer may not have a background in FDTs, we propose to translate the FPS back to natural language resulting in a further document called "Developer NLPS" (see Figure 1). Since this natural language description is directly translated from a formal specification, we assume that it is more precise than the original Customer NLPS. The Developer NLPS may now serve as a basis for customer and developer to reach agreement on the system requirements.

If agreement is reached, the Developer NLPS replaces the previous Customer NLPS and serves as the basis for the acceptance of the final implementation. As another benefit, the new Customer NLPS already has a corresponding formalization, namely the FPS, which can be used as the starting point for subsequent development steps.

If agreement is not reached, the customer supplies a modified Customer NLPS based on the Developer NLPS, and another cycle of the problem specification development is started. Thus, the development of a problem specification is an iterative process: