Requirements change


As the project progresses and after completion, requirements change.  There are various causes.  They may be external, where the business needs to change after the requirements for the project have been elicited.  They may be internal, as the customers learn more about the system they may clarify their understanding of what they really want.  Misunderstandings and misinterpretations on the part of the developers may be detected and result in requirements clarified after implementation.


Changing requirements have been a serious problem for a long time.  Changing requirements are traditionally expensive, lead to code rot, and eventually to code that is so brittle it can no longer be maintained.  Yet refusing to accept changed requirements means delivering a system that will not do the desired job.

Prevention, Amelioration, Cure


There has traditionally been little in the way of good solutions to changing requirements.  The attempts to do a more thorough analysis before writing code so the code would be right first time are doomed to failure because requirements will change despite the best attempts.  Internal sources of change may be reduced but are not eliminated, and external sources of change cannot be avoided.


Two complementary ameliorating approaches to address the change resulting from changed business process have been used, ModelTheDomain allows the core part of the system to be coded in an object-oriented fashion based on Domain Invariants, aspects of the domain that do not change over time.  When this core is wrapped in a thin SessionFacade that scripts the use requirements of a UseCase, then the code that will change when business processes change is isolated in this SessionFacade code.


Where the results of IterativeDevelopment are presented to the customer to elicit feedback, some sources of ChangingRequirements are addressed and requirements that are not yet detailed are less likely to change.  The feedback helps clarify the customer’s own mind on the subject of his requirements, and aids in detecting misunderstandings and misinterpretations of the requirements by the developers.


Probably the chief drive behind modern, agile processes has been the desire for a better solution to changing requirements.  There is in general a two-pronged approach, to reduce the need for change, and to reduce the cost of change.  All XP practices work to some degree toward this end; the same applies to some degree to other agile processes.  Of particular note are working with CustomerOnSite to reduce the communications costs and difficulties and aid in eliciting requirements as late as possible thereby maximizing the amount of feedback that can be taken into consideration.  SimpleDesign and YouAren’tGoingToNeedIt means there is less code to maintain, and it is more easily understood.  ConstantRefactoring keeps the code structure fresh and counteracts code rot.  Other approaches, not explicitly mentioned here, aim to shorten the time it takes to get feedback, or support refactoring.


1. Agile Requirements Challenge #4. Project Stakeholders Change Their Minds