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

physical systems, e.g., electricity networks, but is not generally possible. For soft-
ware engineering problems the calculations are usually not decidable or even not
semi-decidable.
The decomposition of systems into subsystems stop when existing solutions are
found for the system, or the system is simple enough to be understood without fur-
ther decomposition. For physical systems there are large offers of commercially
available system components which are specified according to agreed standards.
The most detailed level of physical system design is the level of standardized com-
ponents. Solutions are developed as assemblies of available standard components.
Knowledge of the properties of available standard components influence designers
in formulating system requirements, so that there will be a preference for formu-
lating requirements that can be met, rather than being unrealistic and reach for the
moon.
The information systems field has traditionally been short of universal product
standards. There are many proprietary standards competing for market share, e.g.,
the standard for writing apps for recent mobile phones. Some of the company stan-
dards succeed in becoming universal, e.g., the standard for offering Java code to the
world. The lack of a standards regime which is comparable to engineering standards
for physical systems makes software solutions more often to come in the form of
complete solutions than in the form of components. There are large collections of
software solutions available as Open Source Software, see [ 35] for discussion and
overview.
3.3 Requirements and Solutions
Information systems have always been built in order to satisfy some purpose. The
first information systems were built from scratch. Computers were expensive and
the required software most often had to be built for one purpose alone. Faced with
limited budgets most of the effort in the information system projects were spent on
making programs, and too little was spent on clarifying the purpose which the sys-
tem should serve. This “program-first-think-later” approach resulted in information
systems of low quality that did not live up to expectations.
The user centric approach to information systems development which emerged
during the 1970s came as a reaction to the many failed software projects of the time.
The user-centric approach recommended that user requirements were thoroughly
analyzed prior to building software. Requirements analysis became a standard
part of every information system project. “Late binding” was often recommended,
meaning that programming was deferred to the later project phases: first get the
requirements right, then design and program the software and the databases. It
followed from this that requirements specification and software specification is
kept separate, and that software specifications should be derived from the require-
ments. This recommendation was at times overdone. Sometimes one became so
obsessed with developing requirements specifications that one did not come down
to programming. Many projects produced many requirements and few solutions.