SRS — requirements

The SRS step turns the approved scope into an IEEE 830 Software Requirements Specification: a numbered set of testable requirements, the regulatory frameworks they touch, the system features that own them, use cases, business rules and analysis diagrams. It is the busiest step in the pipeline — up to six agent calls on a good run — and everything after it traces back to the requirement ids it creates.

What you get

A Markdown document titled Software Requirements Specification, assembled by the bridge from four parts the agent writes plus two sections the bridge writes itself:

Because the bridge writes the catalogue from the validated requirement data, every requirement id is in the document by construction — the agent never retypes hundreds of rows.

Each part must carry its own headings before it is accepted:

Part 3b's diagrams are a use-case overview, a logical data model (erDiagram) and a key state machine (stateDiagram-v2), plus data-flow and sequence diagrams where they help.

Before you run it

• The scope must be approved. Until it is, /srs is locked with "Approve /scope to unlock this".
• The project state must hold the scope document and a project name. If it does not, the run stops with "artifacts.scope missing — run /scope first."

How it works

The run has three reasoning stages, each with its own checks and up to three attempts.

Drawing diagram…

1. Requirements

The sdlc-business-analyst skill receives the approved scope — overview, objectives, in and out of scope, deliverables, stakeholders, timeline, risks, constraints, assumptions, tech stack, delivery model, integrations and non-functional baseline — and returns requirements[]. Each requirement is atomic and testable, written as "The system shall …", with a MoSCoW priority (must, should, could, won't) and at least one Given/When/Then acceptance criterion. Non-functional requirements carry a category: performance, security, scalability, usability, compliance or availability. The set is sized to the real scope — a small application can correctly have only a handful.

An empty list, or any requirement that fails the requirement schema, is sent back as a correction.

2. Compliance flags

The sdlc-compliance-checker skill scans the requirements against every framework definition shipped with Alara Code — AAOIFI, CBUAE 2024, GDPR, ISO 27001, PCI DSS 4, PPRA 2024, SAMA 2024 and SBP 2024. A flag is raised when one of a control's keywords appears in a requirement's title, description or acceptance criteria; each flag records the framework, control, triggering requirement, severity and required evidence, with status "pending-review". Requirements that triggered a flag are tagged with the frameworks that apply. Zero flags is a valid result for an unregulated project. The reply is validated against the compliance schema, and the requirements and flags are then saved to the project state.

3. The narrative, in four parts

The sdlc-srs-narrative-writer skill is called four times, two at a time:

• Stage 1 — parts 1 and 2 in parallel. Part 2 also returns the feature list: each feature's id, name, description, owned requirement ids, related requirement ids and primary actors.
• The ownership check — every functional requirement that is not "won't have" must be owned by exactly one feature: none left unowned, none owned twice.
• Stage 2 — parts 3a and 3b in parallel, only once stage 1 passes. They receive the list of real feature ids, because every use case must name the feature it belongs to.

If any check fails in either stage, all four parts are written again with the problems quoted, up to three rounds. So a narrative that fails twice before succeeding costs twelve calls.

The run panel shows: Checking project state, Extracting requirements, Validating requirements, Running the compliance check, Persisting to project state, Writing the narrative, Assembling the document, Writing the Markdown document.

Ids this step owns

Requirement ids are zero-padded and sequential per type. From here on, every document cites them: design components list the requirements they implement, and test cases the requirements they verify.

Reviewing it

This is the most consequential review in the pipeline. Check that:

• every in-scope item from the scope is covered by requirements, and nothing was added that the scope does not support;
• priorities are right — the design must cover every requirement that is not "won't have", and "must" requirements drive test priorities and the proposal's win themes;
• acceptance criteria are concrete enough to test;
• the compliance flags make sense for your market; a flag is a keyword match, not a finding, and the full assessment comes later in Compliance;
• the TBD List captures what the scope left open.

When you approve the SRS, every requirement's status moves from draft to approved.

Request changes runs the whole step again with your change list as additional notes: the analyst extracts the requirements again and all four narrative parts are rewritten. The agent does not see the previous draft, so name ids and exact changes — "Downgrade REQ-FUNC-027 priority to could", "Fix the blank BR-001 statement" — and re-check the parts you did not mention.

When it fails

Under the hood

• The driver is bridge/src/services/srsPipeline.service.ts; document rules are in bridge/src/lib/documentSpecs.ts.
• Written to the project state: requirements (with empty traceForward links for design components, test cases and cost items, filled in by later steps), complianceFlags (appended), systemFeatures, and the SRS constraints and assumptions that the SDS step reads. Each requirement's ownerFeatureId is set from the feature list.
• The document is .sdlc/artifacts/srs-vN.md, registered as artifacts.srs. The assembled draft is kept in .sdlc/tmp/srs-data.json while under review.