What is a software requirements specification?

Software requirements specifications are known from classical project management: There, you work in phases, create the entire document at the beginning of the project and develop a software product based on it. Sounds simple, but it has grave disadvantages: at the beginning of a project, all the requirements are not yet known, and these often result from existing system components or architecture. Apart from this, changes will occur throughout the project because, for instance, the goals of the customers or stakeholders are always changing.

Agile projects, on the other hand, proceed iteratively to determine requirements. That means that you process requirements in an interplay with development instead of creating detailed requirements specifications from the get-go. So is a software requirements specification useful for agile development?

Absolutely. Because an initial, documented plan creates security for your clients and contractors. The expected expenses and workload have to be estimated, so software requirements specifications also have a place in agile project management. The initial detail is transformed: First, you just specify the requirements for the first release in a software requirements specification, develop the first prototype of based on it and derive more requirements from this first prototype. The software requirements specification grows from release to release and changes over the course of the project, and always provides an explicit reference point in the case of misunderstandings or disagreements.