SRS (Software Requirements Specification)

The SRS is the bridge between what the business asked for and what the engineers build. If the BRD says 'we need to manage customer referrals', the SRS says exactly what fields are captured, what happens when a duplicate is detected, who can edit what, and how the system behaves at every branch. Most disputes about delivered software are really disputes about what the SRS did or did not specify.

What It Is

A Software Requirements Specification is a detailed, technical description of what the system must do — every function, input, output, error condition, and constraint, specified precisely enough that a developer can build it without guessing and a tester can verify it without asking. It decomposes BRD capabilities into functional requirements (what the system does) and non-functional requirements (performance, security, availability, usability — often called the '-ilities'). Well-written requirements are individually testable, unambiguous, and traceable: each one can be linked back to a business requirement and forward to a test case.

Why It Matters to You

You will rarely write an SRS, but you should know when one is inadequate, because inadequate specifications become change orders. Warning signs: requirements written as vague narratives ('the system should be fast') rather than measurable statements ('95% of searches return within 2 seconds'); missing non-functional requirements, which is where budget overruns hide; and no traceability, which makes acceptance arbitrary. The gap between a BRD and an SRS is also where vendors quietly narrow scope — comparing the two documents line by line before development starts is one of the highest-value reviews an executive can commission.

When You'll Meet It

Immediately after BRD approval, before development begins. Vendors on fixed-price contracts treat the SRS as the definition of deliverable — approve it only as carefully as you would a contract.