| name | sdlc-srs-workflow |
| description | Use to draft or audit SRS with requirement IDs, functional requirements, acceptance criteria, constraints, NFR hooks, and traceability. |
| metadata | {"version":"0.5","updated":"2026-07-26"} |
SRS Workflow
Use this workflow when the SDLC manager must produce or update a Software Requirements Specification before implementation.
The SRS is the software-facing contract between requirements work and development execution. It turns business, user, and product intent into precise, testable, traceable software requirements that dev agents can consume without taking ownership of upstream requirement management.
Use when
- A BRD, URS, PRD, feature brief, issue, or product scope baseline must be converted into software requirements.
- The work needs functional requirements, requirement IDs, acceptance criteria, traceability, or explicit software behavior.
- A feature affects behavior, permissions, data, interfaces, user states, error handling, or multiple modules.
- Dev needs an implementation-ready contract, not only a product narrative.
- Existing SRS content must be reviewed, normalized, or updated after an approved change.
Do not use when
- The task is direct code implementation, debugging, test execution, PR review, or release publishing.
- The user only needs business justification, user research, or PRD-level framing.
- There is no approved or clearly marked requirement source; recommend
$codex-next:sdlc-requirements-workflow or use sdlc-prd-workflow first.
- The request is to decide final architecture, implementation libraries, database technology, or repository refactor strategy. Recommend
$codex-next:sdlc-solution-spec-workflow for structured solution material and let dev handle execution.
Inputs
Prefer the most authoritative available sources:
- Scope baseline
- Approved scope
- Non-goals
- deferred scope
- target lane and modifier
- Requirement sources
- BRD
- URS
- PRD
- feature brief
- issue or customer request
- project research output
- Product behavior material
- user flows
- state machine
- field rules
- copy rules
- exception handling
- acceptance criteria
- Engineering constraints
- NFR draft
- known platform constraints
- dependency list
- existing API or data contracts
- repository map if available
- Prior decisions
- decision log
- change log
- open questions
- previous SRS versions
If required inputs are missing, continue only when the missing items do not block the requested delivery grade. Mark missing items explicitly.
Workflow
1. Establish the source baseline
Identify the current authoritative input set:
BRD / URS / PRD / issue / scope baseline / change request / research evidence
Then record:
- source document names or links
- version or date
- owner if known
- status: draft, reviewed, approved, superseded, or unknown
- scope this SRS covers
- scope this SRS does not cover
Do not silently merge conflicting source material. Record the conflict and identify which source should control.
2. Define SRS metadata
Create a document header:
| Field | Required |
|---|
| Document ID | yes |
| Feature / system name | yes |
| Source requirement links | yes |
| Owner | yes if known |
| Status | yes |
| Version | yes |
| Last updated | yes |
| Lane / modifier | yes |
| Related artifacts | as available |
Recommended status values:
draft
review-ready
baseline
change-pending
superseded
3. Normalize requirement IDs
Create stable IDs before writing detailed requirements.
Use these prefixes:
| Prefix | Meaning |
|---|
REQ | Software-facing functional, interface, data, permission, operational, compliance, or quality requirement |
VAL | Acceptance or validation item |
Q | Open question |
DEC | Durable decision |
ARCH | Architecture constraint |
DOM | Domain, ownership, data, or dependency constraint |
Rules:
- One ID means one requirement.
- Do not reuse a retired ID for a different requirement.
- Split compound requirements when they contain separate behaviors or acceptance paths.
- Link each
REQ ID to at least one source input when possible.
- If a requirement is inferred, mark it as inferred and explain the basis.
4. Separate requirement classes
Classify requirements before writing.
| Class | Description |
|---|
| Functional | User-visible or system behavior |
| Interface | API, CLI, SDK, integration, event, or contract behavior |
| Data | fields, storage, lifecycle, migration, retention, import/export |
| Permission | roles, access, visibility, editability, audit |
| Operational | logging, monitoring, support, admin, rollout, rollback |
| Compliance | legal, policy, privacy, security, audit, platform review |
| NFR reference | measurable quality constraint managed by sdlc-nfr-spec |
Keep NFR detail in sdlc-nfr-spec when the NFR is substantial. The SRS should reference NFR IDs rather than duplicating the full matrix.
5. Write functional requirements
For each functional requirement, use this structure:
### REQ-001: <Requirement name>
- Source:
- Priority:
- User / actor:
- Preconditions:
- Trigger:
- System behavior:
- Normal flow:
- Alternate flow:
- Exception flow:
- State impact:
- Data impact:
- Permission impact:
- Related SPEC:
- Acceptance criteria:
- Open issues:
Write requirements as observable behavior:
The system shall ...
Avoid vague terms unless a measurable definition follows. Do not write “fast”, “easy”, “secure”, “intuitive”, or “robust” without a linked NFR, rule, or acceptance criterion.
6. Write acceptance criteria
Each P0/P1 functional requirement must have acceptance criteria.
Recommended format:
Given <precondition>
When <actor action or system event>
Then <observable system result>
And <data/state/permission result>
Cover at least:
- normal path
- primary exception path
- permission or access path
- data validation path
- state transition path when relevant
Assign acceptance IDs:
VAL-001
VAL-002
7. Define state and lifecycle requirements
If behavior depends on status, progress, lifecycle, user session, order state, workflow state, or moderation state, include a state table:
| State | Enter condition | Allowed actions | Forbidden actions | Exit condition | Next state |
|---|
Rules:
- Every state must have entry and exit conditions.
- Every user action must be allowed, rejected, ignored, or deferred in each relevant state.
- State changes must identify data impact and user-visible feedback.
8. Define field and data-facing requirements
For user input, API payloads, stored records, forms, imports, exports, or configuration, link or draft a data requirement table:
| Field | Type | Required | Default | Limits | Validation | Error copy | Storage / display note |
|---|
For substantial data design, hand off to sdlc-spec-slice-writer for a Data SPEC.
9. Define permission requirements
If behavior differs by role, account type, ownership, tenant, plan, region, or admin status, include a permission matrix:
| Actor / role | View | Create | Edit | Delete | Export | Admin action | Audit note |
|---|
For substantial authorization behavior, hand off to sdlc-spec-slice-writer for a Permission SPEC.
10. Link NFRs and constraints
Reference quality requirements by ID:
REQ-010
REQ-011
VAL-010
VAL-011
Do not hide quality constraints inside vague prose. Use sdlc-nfr-spec when measurements, thresholds, validation methods, or release gates are needed.
11. Produce a traceability seed
Create an initial mapping table:
| Source | REQ ID | Requirement summary | VAL ID | Spec detail needed | Task candidate | Test candidate |
|---|
This is not the final RTM. It is the seed for sdlc-requirements-traceability.
12. Record open questions
Separate open questions from decisions.
| ID | Question | Blocks dev? | Owner | Needed by | Notes |
|---|
Do not convert unresolved questions into assumptions. Assumptions must be explicit and reversible.
Output
Return or write an SRS with these sections:
# SRS: <Feature / System>
## 1. Document Control
## 2. Source Baseline
## 3. Scope and Non-goals
## 4. Requirement Index
## 5. Functional Requirements
## 6. Interface / Data / Permission Requirements
## 7. State and Lifecycle Requirements
## 8. NFR References
## 9. Acceptance Criteria
## 10. Traceability Seed
## 11. Risks, Assumptions, and Open Questions
## 12. Handoff Notes
If writing into an existing repository, prefer the project’s established docs directory. If no convention exists, propose a path rather than creating files without approval.
Validation
Before declaring the SRS ready, check:
- Every P0/P1 requirement has an ID.
- Every P0/P1 requirement has acceptance criteria.
- Every requirement traces back to a source or is marked inferred.
- Scope and non-goals are explicit.
- Requirements do not silently include implementation decisions.
- NFRs are referenced or marked as missing.
- State, field, permission, and exception behavior are covered when relevant.
- Open questions are separated from decisions.
- Dev handoff readiness is stated as ready, needs revision, or blocked.
Boundaries
- Do not edit source code.
- Do not execute tests or modify repository configuration.
- Do not approve business scope.
- Do not finalize architecture when repository evidence is missing.
- Do not present assumptions as confirmed requirements.
- Do not expand scope beyond the approved baseline.
- Do not let this SRS workflow replace NFR, SPEC-slice, solution-package, or dev-handoff work when those specialized outputs are needed.
Handoff
Recommend the smallest next step. For an explicit-control workflow, return its
exact $codex-next:<skill-name> command and stop; do not begin it here.
Use the SRS to route downstream work:
| Need | Next skill |
|---|
| measurable quality constraints | sdlc-nfr-spec |
| UI/API/Data/Admin/Permission/Directory specs | sdlc-spec-slice-writer |
| HLD/LLD-oriented solution material | $codex-next:sdlc-solution-spec-workflow |
| implementation task package | sdlc-dev-handoff-planning |
| requirement-to-task/test traceability | sdlc-requirements-traceability |
| readiness judgment | $codex-next:sdlc-readiness-review |
When handing off to dev, provide:
- SRS location
- relevant REQ IDs
- related spec details
- acceptance criteria
- constraints and non-goals
- unresolved blockers
