Write down the user requirements for the software based upon the interviews of knowledgeable users and management. The customer must sign off on this document before any work can begin. Minimizing the number and impact of requirements changes can be critical to the success of a software project. This is why a significant effort should be made to interview the users and come up with the requirements.
According to Facts and Fallacies of Software Engineering by Robert L. Glass under Fact 25 – Missing requirements are the hardest requirements errors to correct:
- The most persistent software errors – those that escape the testing process and persist into the production version of the software – are errors of omitted logic. Missing requirements results in omitted logic.
- After studying errors on a large project, the following was noted:
- Errors of omitted coding logic made up 30% of all the errors found on the project.
- Regression errors, which are new errors introduced by fixing older errors during the maintenance process made up 8.5% of all errors.
- Documentation errors, which are errors that someone thinks is an error but not really due to poor documentation made up 8% of all errors.
Not all missing logic paths can be attributed to a missing requirement, since the requirement may actually exist, but the developer failed to implement it due to an oversight. So, the actual percentage of missing requirements must be somewhat less than 30%. Other estimates for missing requirements have been estimated at 25%, which means that only 75% of the necessary requirements for a software project are typically found on the first try.
The schedule should take this into account. Some changes should be allowed during the first 50% – 70% of a phased delivery software project. At some point though, no further changes should be allowed because it would put the delivery at risk. Those requirements should then be put into the next phase, unless the requirement is critical in which case the schedule may have to be slipped.