I do not believe that unit tests necessarily test requirements: 1) unit tests operate against very low level components (methods/classes/interfaces/et cetera) tested as stand-alone units; 2) requirements are supposed to be tested while the test engineer designs integration/system tests during the requirements design phase; 3) functionality, requirements and specifications are tested (again) once the system is in an operational state; and 4) using an iterative software development approach, many phases of the development lifecycle are revisited for tightening up requirements, design, and development -- processes that re-occur.
Why unit testing is not appropriate for testing requirements. Unit testing will not necessarily uncover a requirement issue for a number of reasons. One, if a requirement was poorly communicated, chances are the requirement was incorporated into the software design, and subsequent development; as a result, if the unit testing follows suit, correctly following an incorrect requirement, the unit testing will come up with nothing. Two, if the requirement was properly documented, and the development team misinterpreted the requirement, similar to item 1, the misintepretation will carry through to the unit testing. Three, as far my experience goes, unit testing is done by the developer, and is part of the development lifecycle -- unit testing is low-level and will not likely represent a requirement, unless each complete requirement is represented by its own method, which is very, very unlikely.
Example. Consider unit testing in terms of methods. Unit testing largely verifies that given the pre-condtions, post-conditions hold after execution of the method under test. The object of unit testing is to test/verify the methods, et cetera, of a software system, starting from the most atomic or primitive methods, progressing towards the most complex ones. By testing each low-level method, you verify whether it works, a no brainer. At this stage, the developer does not need to re-test the low-level method again as a stand-alone unit. While moving upward in complexity to higher-level methods, unit testing verifies these methods, demonstrating that the primitive methods, from which the higher-level ones are composed, work together. As far as I know, this is pretty much where unit testing stops.
How requirements are tested. In a well planned project, the test engineer (an integrated / system tester), starts designing tests while the requirements are written. Through this activity, requirements get verified, before system design, and long before a stitch of code is written. Once the system becomes available in some useable form, requirements are verified via functional/integration/system testing.