I have seen software requirements specification (SRS) documents which contain both functional and nonfunctional requirements as well as diagrams, but I assume you have a document that is entirely textual and describes sentence-by-sentence, paragraph-by-paragraph what the application should do. There are a few things you might be able to do, but I would probably not spend a lot of time trying to convert the SRS into use cases.
The issue here is how to convince the team that there are better ways to gather requirements than writing an SRS. Writing use cases, building prototypes or simulations, etc.
There is no direct route from SRS to use cases, they are each a different way of capturing similar information. If you have a detailed SRS that someone spent a lot of time writing, I would suggest you use it for this project and try to keep track of the areas where the requirements are ambiguous, or parts of the document that generate a lot of conversation. A lot of conversation probably means that the requirements are not well understood.
This was first published in January 2008