That requirements always change has become a common assumption and a fatal problem of the software industry. Myriad development methodologies seen in the market are merely different ways of coping with requirements growth in the process of coding. Continuous requirements change leads to continuous architectural drift in order to compensate the discrepancies between existing and new code. Every instance of rework introduces a sequential set of tasks that must be redone. For example, suppose that a team completes the sequential steps of analyzing, designing, coding and testing a feature, and then uncovers a design flaw in testing. Now a sequence of redesigning, recoding and retesting is required. What is worse, attempts to fix an error often introduce new ones. If too many errors are produced, the cost and time needed to complete the system become so great that going on does not make sense. Because requirements are fraught with errors and we need to improve them. Currently there are two ways to reduce requirements errors:

Improved testing infrastructure eliminates a third of requirements error induced costs by enabling earlier and more effective identification and removal of software defects. But investing in testing infrastructure also introduces costs. It is difficult to predict whether or how much this investment will offset the cost.

Improved requirements validation reduces requirements errors as they are created as opposed to testing the code when bad requirements are already converted into code. There are few requirements validation software tools in the market and their effectiveness is not apparent.

Both can reduce requirements errors in limited way but none claims to eliminate them while increasing significantly overhead cost. If requirements were correct by construction, that is, if requirements are correct when they are created, we could execute a software development process in a single iteration with almost no scrap and rework. The resultant economic impact could be tremendous, for instance, the cost reduction could up to 80% of development cost that is consumed in rework and testing etc.

Correctness-by-Proof takes the tack of describing requirements as knowledge that is contained in software. Logically, we shall be able to acquire and represent the entire knowledge before development. This, however, is not possible with intuition but becomes possible with science. CbyP, a scientific discipline of requirements engineering, is introduced. With CbyP, we are abele to construct, systematically and economically, a scientific theory from which adequate requirements are defined before development. It means that the problem space is precisely scoped, well structured, visualized, effectively communicated.

CbyP is claimed to be the most general methodology of all and anticipates separation of problem-domain concerns from implementation-domain concerns whereby adequate and communicable requirements can be defined before development. It offers opportunities to reconceptualize development as well as management methods for the highest possible degree of rigor and generality and many associated resulting benefits.