THE CONSTRAINTS AND ASSUMPTIONS INTERPRETATION OF SYSTEMS DESIGN: A DESCRIPTIVE PROCESS MODEL

Abstract

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.