Cure

---

Once development gets past the requirements phase, there are still plenty of changes and decisions regarding these requirements. Many projects have gotten themselves in trouble because of the belief that the requirements would not change later in development. Some of these changes might have been accounted for in the requirements, but others might have been unstated and unknown to the developers.

Get Feedback

The earlier a missing requirement is identified, the easier it is to fix. To this end, the earlier the customer can provide feedback on the direction application development is taking, the better. The process of obtaining feedback can be a tricky business, involving the relations between the customer and the developer, but it is very important to avoid the scenario when the end product is not what the customer wants or will pay for.

For this, an incremental development cycle is the most useful type of methodology to use. Workable versions are produced on a regular basis for evaluation and feedback. It is important for the customer to understand that these versions are only part of the final application, but the responsibility for reaffirming this generally lies with the developer. Proper presentation of the application and knowledge of future development plans can assist greatly in assuring that there is no miscommunication or unfounded fears that come out of these feedback sessions.

Similarly, individual developers should look for feedback on their tasks to ensure that the result performs within the requirements. This can also lead to the discovery of missing requirements, most often because the writer of the requirements assumed that either there were no options or the option to choose was obvious. Peer reviews and proper testing can help enforce this early feedback within the team.

Incorporate

This feedback can then be incorporated into the requirements, allowing changes to be made on a timely basis rather than as a mad scramble at the end of development. Incorporating all the feedback into the requirements before acting on it is important because the changes might interact with each other and the current design in unexpected ways. Individual developers should provide input on changes that affect their individual tasks, preventing the new requirements from missing important information. Once again, good communication is the most important method for achieving this goal.

As each requirement is added, two main design changes might be required. The first design change requires modifications to the internal implementation, but not the application behavior, to accommodate the new requirements. The second type of design change requires additions that add new functionality or constraints to the final product. These will be most directly related to the customer’s requirements, but cannot be accomplished until the internal changes are made.

Bargain

Due to technical, time, or budgetary limitations, some of the new requirements might not be feasible. It might be necessary to return to the customer with alternatives and tradeoffs if there are irresolvable conflicts. Be sure to have several options before doing this, allowing the customer to feel that they have a say in their final product. Remember that in addition to changing or removing features, it might also be appropriate to ask for more time or money to complete the new requirements if the customer must have them.

Individual programmers and developers should be particularly involved in determining if the new requirements are difficult or impossible because of time constraints or technical limitations. Most often, it is a question of time, but in essence, a large enough quantity of time amounts to the same trouble as technical unfeasibility. Once again, be sure that the communication channels remain clear and efficient.

Refactor

Unfortunately, the changes that might be required due to the new requirements can span the entire range of possible refactorings. One important guideline that can be followed, however, is to make any refactoring changes to the current code before proceeding to add the new code. This allows the proper unit and regression testing to ensure that the application’s behavior does not change.

---