Many agile projects don't produce a software requirements specification in the sense of a document that lists a bunch of "shall" statements along with some assumptions and dependencies, like what is described in ISO/IEC/IEEE 29148 or DI-IPSC-81433A. That doesn't mean such a document can't be produced, though.
Often, agile projects will capture 'requirements' in the form of use cases, user stories, scenarios, or other user-centric forms. The requirements will also tend to be broken down into those being worked on in the current iteration and those that still need to be worked on - in Scrum, that's the sprint backlog and the product backlog. The only requirements that are well analyzed, validated, and estimated are those being worked on in the current iteration. The rest could change - requirements could be added, removed, or changed at any point in time.
In an essay, Scott Ambler does talk about requirements modeling in an agile environment. Karl Wiegers and Joy Beatty also discuss requirements engineering in agile in their book Software Requirements (3rd Edition).
I think one of Scott Ambler's Practices of Agile Modeling is appropriate:
Apply The Right Artifact(s). Each artifact has its own specific applications. For example, a UML activity diagram is useful for describing a business process, whereas the static structure of your database is better represented by a physical data or persistence model. Very often a diagram is a better choice than source code -- If a picture is worth a thousand words then a model is often worth 1024 lines of code when applied in the right circumstances (a term borrowed from Karl Wieger's Software Requirements) because you can often explore design alternatives more effectively by drawing a couple diagrams on whiteboards with your peers than you can by sitting down and developing code samples. The implication is that you need to know the strengths and weaknesses of each type of artifact so you know when and when not to use them. Note that this can be very difficult because you have Multiple Models available to you, in fact the Agile Models Distilled page lists over 35 types of models and it is by no means definitive.
Do you need to produce an SRS?
If yes, you're going to need to keep the document as a living document. Traditional plan-based SRS documents and formats are going to need tailoring. If you had to do this, I'd recommend keeping a running list of what requirements were allocated to what sprint and not necessarily focus on the backlog. This document becomes a description of what the software is capable of at the completion of each iteration rather than a set of requirements to go build.
If you only need to produce some requirements artifact, perhaps for compliance purposes, see if you can produce a different artifact instead of an SRS. For example, if you needed to have an audit trail for requirements changes, keeping meeting minutes of your backlog grooming sessions and requirements change requests (for adding, removing, or reordering the backlog) along with tracking what requirements go into what iterations may be sufficient.
If you don't really need an SRS, do look at other artifacts used to capture and communicate requirements that better fit into agile methods.
