Phase 2 — Requirements
Software Requirements Specification (SRS)
Functional requirements with teeth — measurable, testable, unambiguous
2 min read · Document 5 of 30
What is this document?
Where the PRD says what the product does, the SRS says exactly how to verify it is done correctly. It contains the non-functional requirements — latency, availability, security, accessibility, data retention — each with a number and a test method.
Every SRS item traces back to a PRD requirement and forward to at least one test case.
Why does it matter?
- Without an SRS, “done” is whoever’s opinion is loudest.
- Performance and security targets set late are expensive to retrofit.
- Traceability shows which tests protect which promises.
What's inside?
- Non-functional requirements — Latency, uptime, scalability, accessibility and security targets.
- Traceability matrix — Requirement → test mapping.
- Measurement methods — How each target is tested and monitored.
PRD requirementSRS targetTest methodMonitoring
How CREAH generates it
CREAH builds this document from your Stage 0 answers and interview. Questions that shape it include:
- How fast must the slowest important screen respond?
- What uptime does a paying customer expect?
- Which accessibility standard must the product meet?
Example excerpt
## NFR-4: Interview Response Latency
P50 latency for an interview turn: < 2,000ms
P95 latency: < 4,000ms
Measured from answer submission to the next question shown
Test method: load test with 50 concurrent interview sessions