<-Prev Next->

If we deliberately decide not to resolve a failure, we interpret this as a requirements change. This is true because the user has explicitly or implicitly noted that allowing the failure to continue to occur is acceptable (its nonoccurrence is no longer a requirement), at least for the present. The requirements change may be only for this release - the failure may be addressed in a subsequent release. We may not fix some faults because the failures associated with them occur infrequently or they may not be severe. The cost of failure of a particular fault may thus be small with respect to the cost of removing it or the cost of delaying delivery to allow it to be removed.
Sometimes the issue comes up as to whether a failure exists if system behavior doesn’t violate any written requirement. In our experience, insisting that a written requirement be violated for a failure to exist is a self-defeating proposition, except in the case where extremely serious consequences are likely in admitting to a failure, such as loss of a vital legal action. In almost all cases you should interpret general dissatisfaction with behavior by the user community as a failure. We refer to “user community” rather than “user” dissatisfaction to imply that there is a considered consensus of expectations of users and their managers who are funding the product and not simply desires of a very small number of unreasonable users.
If you experience multiple failures associated with the same fault…

s