(This is something I wrote awhile ago and is nothing new, really. It may be a topic at some brown bag chat in the future. The real issue is: how do we create an environment where change isn’t neceessary because of good design but is still possible when things get missed, which they always do? –MK)

The Impact of Change

Myth: A general statement of objectives is sufficient to begin writing programs – we can fill in the details later.

Reality: Poor up-front definition is the major cause of failed software efforts. A formal and detailed description of information domain, function, performance, interfaces, design constraints, and validation criteria is essential. These characteristics can be determined only after thorough communication between customer and developer.

Myth: Project requirements continually change, but change can be easily accommodated because software is flexible.

Reality: It is true that software requirements do change, but the impact of change varies with the time at which it is introduced. The figure below illustrates the impact of change. If serious attention is given to up-front definition, early requests for change can be accommodated easily. The customer can review requirements and recommend modifications with relatively little impact on cost. When changes are requested during software design, cost impact grows rapidly. Resources have been committed and a design framework has been established. Change can cause upheaval that requires additional resources and major design modifications, i.e., additional cost. Changes in function, performance, interfaces or other characteristics during implementation (code and test) have a severe impact on cost. Change, when requested after software is in production use, can be two orders of magnitude more expensive than the same change requested earlier.

(Excerpt from Software Engineering: A Practitioner’s Approach by Roger S. Pressman. © 1997, 1992, 1987, 1982 by The McGraw-Hill Companies.)