Evolving concepts, or why users often don't recognize the software they asked for

When a development project delivers a software product that is not usable without modtfications, it is because the product does not serve the current needs of the product users. Since only trivial problems are fully grasped at first consideration, users will always Jind it necessary to modi~ their early concepts of what they need In the traditional linear development mode~ the early needs of users are captured during the system and software requirements definition phase, but the evolving needs of users are effectively ignored through the development phases. An improved development model will be user driven and responsive to changing requirements whenever they occur. I N T R O D U C T I O N There are two difficult problems in software development: figuring out what to do, and figuring out how to do it. Up to now, the software industry has spent nearly all of its time on the second problem: figuring out how to translate requirements into code. Pick up any popular text on software engineering, say {1], and compare the depth of material devoted to requirement capturing vs the extensive discussions of post-requirements development: planning, design, coding and test. It's not surprising that the industry has chosen to approach the problems in this order, since there would be little reason to know precisely what has to be done if it was not possible to do it. But to accomplish the task of learning how to do it, the industry has taken a stationary view of the first difficult problem what is to be done. It has regarded the concepts of system and software requirements as static and determinable at the beginning of the process, and it has used these formally determined requirements as the foundation of the software development process (See Figure 1). It formalized this view by embracing the linear software development model with its phases, milestones, reviews and COPYRIGHT 1990 BY THE ASSOCIATION FOR COMPUTING MACHINERY, INC. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and or specific permission. baselines. The linear model resists any modifications to assumptions or conclusions that have been "approved" in an earlier phase of the process. This is a development model with limited user interactions. It is a model that's responsive to a snapshot of perceived requirements taken early in the process. The result has been gradually increased productivity in the software development process, but, predictably, little increase in the usability of the products. Software products are not usable because they do not serve the current needs of the users. When the user's needs were first examined in the requirements analysis phase of the traditional process, they may have been captured in careful and explicit detail. But, as Frederick Brooks observed in [2], "Much of present -day software-acquisition procedures rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software-acquisition problems spring from that fallacy ... it is really impossible for a client ... to specify completely, precisely, and correctly the exact requirements of a modem software product before trying some versions of the product." So users rarely have well defined needs, least of all in the early stages of the product's development. Software engineering will continue to improve our understanding of the translation process, improving productivity by continuing to