An SRS document is appropriate for the traditional software development methodology where you start and finish without iterations as you do in Agile. With Agile, requirements come up, get removed, get changes, etc, with each iteration or sprint. Jira is great for Agile, and it allows listing of these user stories/use cases and their requirements. However, that is not a formal document. If someone comes around and wants to buy the software and its code to fully own it, what do you present to them to show the full requirements and details of the software. In other words is there any formal list of requirements that is meant to be maintained aside to whatever is being used for Agile e.g. Jira?
Agile is a mindset and as Ashok mentioned earlier, one of the values recognized by Agile teams, is prioritizing working software over comprehensive documentation. If said SRS or any formal documentation is needed for business ore compliance reasons, it can be created as part of the user stories / or tasks within a story. Be mindful however not to go down the path of creating documentation for the sake of documentation, ask who and why needs it and see if self-documenting code, or any of XP practices aren't sufficient for that.
Not everyone recognizes the power of agile approach, but the first question I would ask is what is the purpose of such documentation, and who, how and how often will use it. Once we understand the need we can address it.
I've done more research. And from the resource below, it sounds like it is something that is not part of agile (since in Agile you are not bound to any strict list of requirements from start to finish), but can be incorporated into it if required.
If you really need to have a formal SRS, then keeping it alive would be the way forward, with a list of requirements for each sprint.
Working software over comprehensive documentation
One of the four main declarations made in the Manifesto for Agile Software Development is:
...we have come to value: ... Working software over comprehensive documentation
If I were the buyer, I will rather take a copy of the Jira (or other issue tracking software) than an SRS (Software Requirements Specification) document because:
- Jira gives my dev team context specific documentation for each feature.
- SRS documents tend to focus on the "what" and rarely on the "why". User stories, if properly written in the "As a [user], I want [feature] so that [reason]." format will let my team know why a feature was built. This is very valuable insight.
- The acceptance criteria is even more valuable because these are the true objective, measurable, testable requirements.
- Jira will also give my dev team additional insights into Epic -> stories, dependence and linkages between stories...etc.