Short answer
A software requirements specification is the written document defining what a system must do: functional requirements as testable statements, non-functional requirements such as performance and access control, plus constraints and assumptions. Its practical test is whether each requirement can be marked pass or fail without argument during acceptance testing.
Also called: SRS, Requirements document, Functional specification
The quality bar is testability. "The system should be fast" can be neither accepted nor rejected; "a search returns results in under two seconds on a standard mobile connection" can. The same applies to permissions, notifications and reporting, where undefined behaviour tends to resurface during acceptance testing as a disagreement about what was always meant.
Weight varies with the project rather than with the methodology. A heavy document suits regulated or integration-dense work; a lighter set of user stories with acceptance criteria suits an evolving product. What does not vary is the need for an agreed baseline recorded where both sides can read it, and an assumptions section, since late-project disputes almost always trace back to something one side assumed and never wrote down.
Common questions
Do agile projects need a requirements specification?
They need a baseline, though rarely a two-hundred-page one. User stories with acceptance criteria, a written definition of done, and a maintained backlog serve the same purpose: something specific enough to test against and to price a change from. What fails is not the format but the absence of any written record of what was agreed.
Where this comes up in our work
Related terms
Discovery Phase
A discovery phase is a short, paid engagement that precedes a build and produces the artefacts a build needs: a written scope, user flows, a technical approach, and an estimate grounded in something other than a guess.
Scope Creep
Scope creep is the gradual expansion of a project’s requirements after the scope is agreed, usually through small additions that each seem too minor to renegotiate.
User Acceptance Testing (UAT)
User acceptance testing is the stage where the people who will actually use a system verify it against the agreed requirements before launch, working through real scenarios on a staging environment.
Fixed-Scope vs Time-and-Materials
Fixed-scope and time-and-materials are the two standard ways to price software work.
Reading definitions because you are scoping a project? Skip ahead and just ask.