1) Nothing has been forgotten.
2) Nothing has been added.
It is obvious that if something is forgotten, the correct product has not been delivered. Is does, however, happen all too often, that requirements are overlooked somewhere in the development process. This costs money, time, and credibility.
On the surface it is perhaps not so bad if something has been added. But it does cost money and affect the project plan, when a developer - probably in all goodwill - adds some functionality, which he or she imagines would be a benefit for the end user.
What is worse is that the extra functionality will probably never be tested in the system and acceptance test, simply because the testers don’t know anything about its existence. This means that the product is sent out to the customers with some untested functionality and this will lie as a mine under the surface of the product. Maybe it will never be hit, or maybe it will be hit, and in that case the consequences are unforeseeable.
The possibility that the extra functionality will never be hit is, however, rather high, since the end-user will probably not know about it anyway.
Validation during the development process is performed by analysis of trace information. If requirements are traced to design and code it is an easy task to find out if some requirements are not fulfilled, or if some design or code is not based on requirements.
The ultimate validation is the user acceptance test, where the users test that the original requirements are implemented and that the product fulfills its purpose.
Verification, the other quality assurance activity, is the assessment of whether the object fulfills the specified requirements.
Verification answers the question: "Are we building the product correctly?"