Epics are Placeholders
In just about an Agile methodology the concept of Epics would be as much as you should need for a Requirements Specification, place holders is what you need at that level. Those entries will be prioritized constantly, any more detail is wasted effort if the requirement gets low priority for a long time, or never even gets implemented. Documenting it and managing the documentation around it would be a complete waste of time. YAGNI extends to requirements activities as well as coding activities.
Tools are your friend!
If you use a proper tool to collect and manage the user stories, then you can generate the Requirements Specification from them. A requirements specification is an temporal artifact document anyway, it isn't a living document, it is a snapshot of requirements in time. And is never in sync with reality.
Automatically Generate Artifacts
User stories that can be exported from a proper tool are way more valuable than any static artifact document anytime. Personally I prefer Pivotal Tracker to track User Stories, I even wrote a suite of MoinMoin plugins in Python to publish all the various Stories and their states in the Wiki ( which contained detailed developer notes and the like about the stories ), live data is always better than static data.
The Wiki became a live document of all the stores/requirements and their state of completion and priority with details and comments and other meta data.
Way better than a huge Word document in Sharepoint that just gets emailed around constantly and never updated, guaranteeing that everyone has a different version and is out of sync with everyone else!
User Stories are Richer than Use Cases
The Use Story is much more valuable than a Use Case because they say WHY.
The User Story format:
As a [ROLE] I [ACTIVITY] so that [WHY] is much more expressive than Use Cases that are like
The System [shall/shall not/may/must] perform [action] ( where action is a flow chart ).
With a User Story, you have WHO wants to do something, you have WHAT they want to do ( which can point to a more detailed diagram/document for complex tasks ) and you have the most important part WHY they want to do this activity.
If you have the first, the second is completely redundant, and just noise at best. A traditional formal requirements specification from a Waterfall methodology has no place in an Agile environment.
In the End
If your management isn't committed to change you aren't going to be successful with a new methodology. I have worked for a 100+ billion dollar a year company, they didn't take baby steps in moving to Agile/SCRUM, they just said, the entire company is moving to this, here is the new way of doing things, here is when your training on the new way is going to start, here are the new tools we are going to use, here is the date we start doing things this way. It worked for them in less than a year. I have worked on implementing this in smaller companies with the same success.
baby steps implementations, regardless of what the change is, is a recipe for failure. It is a code word for management that they quietly don't agree and are passively aggressively setting you up for failure. They are saying I don't believe in this enough to commit to it, so I will let you do just enough to fail/not succeed, that way they can say they tried and it didn't work and they way they were managing worked just fine all along. Partial commitment ultimately leads to failure.
In your case, they probably quietly don't believe in the User Stories, and after a while of doing both they will start to claim it is the User Stories that are useless and not the SRS, and will push to stop writing the User Stories, which will just lead you backwards not forwards.