It obviously depends on your code review process but personally I'd say the functional completeness of the requirement is more within the remit of the QA / Test team than the code reviewer.
That's not to say that a code reviewer shouldn't be able to pick up on problems with the functionality where they find them (assuming they have the knowledge to identify them), just that it's not their primary aim.
I'd generally see code review as looking to uncover coding errors and inefficiencies, vulnerabilities, memory leaks, that is not checking that what has been implemented is correct against the specification, but that it is "correct" within itself.
If you do want to extend it beyond this to include more of a functional review, you need to accept that that's going to have an impact on the time you need commit to it. If you want the reviewer to be fully familiar with the functional requirements and to be checking them as well, then you obviously need to allow a lot more time for reading and understanding the requirements and checking the code against them.
But it shouldn't be seen as a substitute for proper QA and testing, at most this would be an additional layer.
- Code review - is the code which has been produced efficient, secure
- QA - does it do what is outline in the specification
- UAT - does the finished application actually work within the business