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

taking the different facets into consideration when proposing architectural solutions
and associated requirements on the appropriate levels of specification detail [25] .
The system architectures are usually expressed in terms of solutions to the stated
requirements. Each part of a system solution at one level of detail serves as a require-
ment to the system architecture at the next level of system detail. At the most
detailed level we should be able to formulate the system specifications in terms
of executable specifications, or in terms of pre-existing solutions. Process oriented
approaches seem to fit very well with this line of thinking.
3.4 Formal and Informal Specification
Data and data processes are usually associated with computer programming.
Information and information processes are associated with the use of data by peo-
ple. Information systems designers have to relate to both computers and people, to
data as well as meaning. People mostly communicate through natural language but
also through drawings and sketches of system structures. Computers communicate
through binary numbers. To make sense out of messages, be they uttered in language
or as numbers, the messages must be related to a model of what the messages are
about. This model of “the real world” must be shared among the communicating
parties if misunderstandings are to be avoided. Computer systems will break down
if the various digital components do not share a common model of “reality” and a
common model of data representation. People may be able to discover misunder-
standings prior to a system breakdown and to take corrective actions, computers
cannot.
During the initial phases of systems design the ideas about the system-to-be are
usually both imprecise and vague. Requirements to the system-to-be are usually not
well thought through. Desired system properties may be unrealistic. An important
aim of the initial project phases is to develop a consensus among the interested
parties about whether and how desired system properties can be achieved. The level
of ambition for desired properties must be balanced with the availability of resources
for building and operating the system-to-be.
The usual form of communication is through natural language, spoken and writ-
ten, through informal sketches of various system architecture proposals, and through
more or less formal descriptions of existing solutions to systems similar to the one
being discussed. Only when “the dust has settled” and agreement has been reached
on the major parameters of the system-to-be comes the time for adding formality to
the systems descriptions.
Formality of systems descriptions is needed in order to understand every detail
in the proposed solutions. When sufficient formality cannot be achieved for a rea-
sonable cost one has to rely on designers' experience. When technology is not well
enough developed one has to rely on handcraft. Even if formality is achievable there
is a long way to go from the initial informal specifications to the formal expressions
that make up the specifications of the final system details.
A desirable property of a specification language would be that it lends itself both
to the informal and formal tasks. Unfortunately there is no such language. What