Goal
Turn wishes into verifiable requirements: who does what, under which conditions, and what counts as "done".
Inputs → outputs
Inputs
- BA document, signed SOW
- Kick-off minutes
Deliverables
- SRS (Software Requirements Specification)
- Product backlog with user stories + acceptance criteria
- Measurable NFR list (e.g. main page LCP < 2.5 s on 4G)
- Requirements traceability matrix (RTM)
Teams & roles
- Business Analysis (BA)writes SRS, user stories, RTM
- Quality Assurance (QA/QC)makes acceptance criteria testable
- Solution Architecturepins measurable NFRs
- Application Security (AppSec)security & personal-data requirements
- UX/UI Designconsulted on user flows
- Client (Product Owner / sponsor)signs off SRS and acceptance criteria
RACI matrix
R — does the work · A — accountable, final sign-off (exactly one A per activity) · C — consulted before · I — informed after.
| Activity | BA | UX | Arch | PM | QA | Sec | Ops | Client |
|---|---|---|---|---|---|---|---|---|
| Write use cases & user stories | A | C | · | · | · | · | · | C |
| Acceptance criteria (Given/When/Then) | A | · | · | · | R | · | · | C |
| Measurable non-functional requirements | R | · | A | · | · | R | C | · |
| Traceability matrix (RTM) | A | · | · | · | R | · | · | · |
| Sign off SRS & backlog | R | · | · | I | · | · | · | A |
BA = Business Analysis (BA); UX = UX/UI Design; Arch = Solution Architecture; PM = Project Management / Scrum Master; QA = Quality Assurance (QA/QC); Sec = Application Security (AppSec); Ops = DevOps / SRE; Client = Client (Product Owner / sponsor)
Quality gate
SRS approved; every first-sprint story has acceptance criteria.
Entry criteria
- SOW signed
- Client-side Product Owner appointed
Exit criteria
- SRS signed off with version number and date
- Every first-sprint story has acceptance criteria
- Every NFR has a target and a measurement method
- RTM initialised
- Spec Fidelity ≥ the agreed threshold (completeness · consistency · unambiguity · verifiability)
- From here on, every change goes through a CR
Activities
- 1.Write use cases and user stories per role
- 2.Write acceptance criteria in Given / When / Then form
- 3.Pin down non-functional requirements: performance, security, availability, backup, supported devices
- 4.Build the role-permission matrix and the system message list
- 5.Build a traceability matrix: requirement → design → test
Checklist
Tick to self-review — 0/7. Ticks stay in this browser only and are not sent anywhere.
Document templates
Markdown (.md) files: open in any editor, or paste into Word / Google Docs. Each states its purpose, who fills it in and when.
Client involvement
- Review and sign off the SRS / backlog
- Confirm acceptance criteria — they become the basis for UAT
Tools
- Jira / GitHub Projects / CT Work
- Google Docs
- Gherkin
Reference standards
- ISO/IEC/IEEE 29148:2018
- Requirements engineering — structure and qualities of a good SRS
- ISO/IEC 25010:2023
- Product quality model — a checklist for NFRs
- INVEST (Bill Wake)
- Good user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable
Common pitfalls
- Requirements that cannot be tested
- Leaving NFRs to the end → architecture rework
- SRS written once and never updated after CRs
- Mixing requirements with UI solutions
Real example
Applied to LabFlow AI: the SRS follows the SEP490 frame (Report 3) — Context Diagram, Main Workflows, Actors & Use Cases, Functional and Non-functional Requirements, Business Rules, System Messages — and each requirement is linked to a CT Work card through the RTM.
Where to learn
Subjects and courses on cuongthai.com that teach this stage’s work.