The largescale ineffectiveness of current systems development methodologies may be attributed to the
inaccuracy or inadequacy of their underlying assumptions concerning the systems development process. In
this paper, we propose a descriptive, alternative model of the Information Systems (IS) design process.
This model emphasizes the importance of constraints in defining the feasible design space, and of
assumptions as a vehicle for discovering constraints. Moreover, rather than assuming that design
activities occur in a logical and prescribed sequence, as the current dominant model, the Systems
Development Life Cycle (SDLC) does, the Constraints/Assumptions (C/A) Model focuses on the
interdependent nature of design activities.
The importance of developing and validating alternative models of the system design process is evident
from three sources. First, there is the paucity of empirical research on systems design, which we attribute
to a scarcity of theory to guide such research. Second, educators evince serious doubt as to our ability to
educate students in this process. Third, the widespread inability of professional systems designers to
develop systems on schedule, within budget, and providing the full set of specified functions is
disconcerting, if not appalling.
Previous research suggests that superior designs are produced when both clients and designers regard the
IS design process as a learning experience, and work to educate each other. The Constraints/Assurnptions
Model further elaborates this mutual learning thesis, by differentiating what clients learn from designers
and what designers learn from clients. The C/A Model asserts that, at any stage in the design process,
two dialogues occur simultaneously. The client/designer dialogue elaborates the design space, i.e., a set of
constraints on the design process specifying required performance and function, the organizational and
political climate, the resources available for developing and operating the system, etc. The designer/team
dialogue, on the other hand, focuses on the generation of a working solution to the design problem, its
validation with respect to technical feasibility and its congruence with the acceptable design space, and its elaboration into an implementable design. Both the design space and the working design are inputs to
each dialogue, and their interdependence results from each dialogue's ability to modify only its own
product.Information Systems Working Papers Serie