In my opinion, every single requirement in an SRS (system requirement specification) should be a test requirement. If it is not testable (verifiable) it doesn't belong in the SRS. You may have requirements in a high-level business requirements document which do not apply to your specific system if you are in a multi-system corporate solution.
Very generally speaking, here's how you could model the test cases after the requirements. The SRS includes the system rules that may be phrased like "If W then the system shall do X." If so, your first test cases will be "perform W. verify that the system does X." Then you may have other test cases like "perform Y. verify that the system does not X."
Bear in mind that an SRS is a Software Requirements Specification. A SyRS is a System Requirements Specification. Thus two different things.
With that, however, I agree with the others: requirements should be quantifiable and capable of being tested. That is the main question to ask yourself with each requirement in a document like an SRS: how can I test this? In other words, how can I prove that this requirement has been fulfilled? If you cannot think of way to prove it to yourself, you will not be able to prove it to others either. And it means that you will not be certain that the requirement has been implemented correctly.
Also remember that requirements should be concise, complete, unambiguous, verifiable, and necessary. That is one context that you can use. When requirements have said characteristics, generating test cases from them becomes much easier. Your test case is a certain input applied to a certain action that generates a given output. Thus the requirement should be stated in such a way that you can imagine various inputs that will be given to the action and various outputs that will be derived from that. That will form the backbone of your test case effort.
Performance requirements should also go into an SRS which means that Service Level Agreement's should be stated in here as well and that can factor into your test cases.
Finally, as the others said: make sure that you are testing the document itself. Not just the requirements that are there; be on the lookout for things that are missing. Sometimes this will be elements of requirements and other times this will be entire requirements themselves that have been left out.
QA should review the SRS before it is accepted as "the" SRS. And if there are any untestable requirements, they should be rewrittent to be testable, or moved to another section of the document. You eliminate a lot of potential bugs by carefully reviewing the requirements before the testcases are created.
Here we have Section 5 of the SRS as our requirement section - all other sections are background, outline, etc.
Software QA Engineer Lead