Currently, I am drafting a SRS ( Software Requirement Specification ) doc for an agile project, and the samples are the ones used in a waterfall project. I did google a lot but couldn't find any right one. I have been part of an agile project before as a developer and also understand the working mechanism but never made the document before. Especially, areas like the scope which varies in terms of sprints.

My question is if some body can share any sample SRS for Agile projects? What kind of details need to be presented from agile project perspective in the scope and milestone section?

Update: Although the SRS is not mandatory but we have a fixed price project that needs to have a fixed timeline on the basis of the effort application. Hence need to document the requirements that need to be worked out along with the possible timelines. Apart from all this, the project needs to be executed from an Agile approach as discussed with the management hence it will most probably be a subsequent transition to a complete agile approach from the approach that we are executing currently. Having said that under current circumstances should I go for an SRS doc or something custom


2 Answers 2


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.

  • 1
    Thanks for the elaborate response but under the current circumstances as updated in the description what type of documentation should I go for
    – Mudassar
    Jul 13, 2015 at 11:21

If you have a prototype, a vision document, Personas and some PBI depending on your project I dont think you need SRS. for more complex or enterprise applications you may want to add a UML doc but I think creating a SRS doc is a lengthy process and just an additional layer of complexity that can be avoided.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.