sdlc-srs-workflow

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:

1. Scope baseline
   • Approved scope
   • Non-goals
   • deferred scope
   • target lane and modifier
2. Requirement sources
   • BRD
   • URS
   • PRD
   • feature brief
   • issue or customer request
   • project research output
3. Product behavior material
   • user flows
   • state machine
   • field rules
   • copy rules
   • exception handling
   • acceptance criteria
4. Engineering constraints
   • NFR draft
   • known platform constraints
   • dependency list
   • existing API or data contracts
   • repository map if available
5. 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:

1. SRS location
2. relevant REQ IDs
3. related spec details
4. acceptance criteria
5. constraints and non-goals
6. unresolved blockers