A "hard core" approach would be to build some "negative" tests that will be used to "prove" that the functionality is NOT there. Of course, folks tend to fuss that time is wasted in building or running such tests.
Hey, if it is in the requirements, I am going to do everything that I can to test it or write it up as untestable.
Very interesting points of view all right.
Personally we do not test for functionality not in scope.
Analysis is based on the requirements. So what is not in scope is not further analysed (not functional, not technical) and so does not reach the programmers.
A step that we still must include is that for every change request a check against the scope must be done.
If the change request was considered out of scope, but the client insists that it is necesary, an impact analysis takes place (impact on budget, time, etc.)