On Roles of Models in Information Systems - Intentional Perspectives on Information Systems Engineering - page 24

There were two major approaches to information systems engineering and soft-
ware engineering, the deductive approach [20] and the process oriented approach,
e.g., data flow oriented techniques [6] . Basic to the deductive approach is the
assumption that problem formulation can be separated from the problem's software
solution, much in the same way that the solution of mathematical problem is sep-
arate from the problem formulation. This line of thinking is consistent with the
recommendation of keeping requirements specification separate from the software
specification (the “think-first-program-later” approaches). Basic to the process ori-
ented approach is that problem formulation and problem solution are intertwined,
that the solution to a problem at one level of detail serves as the formulation of a
problem on the next level of detail.
During the 1980s and 1990s there were substantial efforts in the software engi-
neering community in developing specification languages at the algorithmic level
of detail, see [ 11] . Early successes in applying first order logic for problem formu-
lations encouraged the ambition of being able to verify the correctness of problem
specifications prior to programming. These “problem-oriented” approaches rest on
the principle that designing effective solutions requires a detailed understanding
of the problem. Only for problems of limited size is it possible to precisely and
completely define the problems up-front. The problem oriented approaches did not
sufficiently recognize the need for prescribing a gradual and continuous refinement
of a problem description in order to identify new or previously missed context
elements and requirements.
The problem specification languages that were proposed, e.g., Z and VDM, were
based on set theory. They were not executable, that is, software that satisfied the
specifications had to be expressed in appropriate programming languages. These
specification languages did not enjoy success. There may be several reasons for
their lack of success. One reason was that it was very time consuming to develop
in parallel problem specifications and solution specifications to the same level of
detail. The verification facilities of the problem specification languages were not
powerful enough to defend the extra resources needed to develop the problem spec-
ifications. The executable solution specification was seen as being enough for most
problem types. The only fields were verification approaches seem to have been
used to any extent, is for system critical software, that is for software where the
cost of breakdown is very large, e.g., for nuclear facilities, for airplane control sys-
tems. In the clear light of hindsight it may be said that these approaches were not
enough concerned with the elicitation and validation of problem statements, and the
transformation of problem statements into design solutions.
It is now widely recognized that for large and complex information systems
architectural solutions and requirements need to be co-developed [25] . Large and
complex information systems have to be stratified and described at levels of increas-
ing detail. Increasingly it is necessary to specify both what the systems is expected
to do as well as what it is expected not do [ 30] . Often the complexity demands that
different facets have to be treated separately [ 22, 25] . At each level it is common
to develop a system architecture that provides a solution to all of the required func-
tionality of all of the facets at that level. Central to this are co-design processes for