Module Overview

Module 2 is the spine of the program: the end-to-end AI-augmented SDLC framework that every other module plugs into. You learn the six delivery phases, who owns each artifact, what a real quality gate looks like, and how traceability holds the chain together — then you start producing your Week 1 artifacts. By the end you know what “done” means at the Week 1 gate before you sit down to draft.

The Four Answers

This module is the spine of the program. Once you can answer these four questions reflexively for any project, AI becomes a force multiplier instead of a wildcard.

Part 1 — Framework Foundations

The Four Principles

The Universal Working Cycle

Every AI-assisted task follows the same four steps. The artifacts change; the cycle doesn’t. When something goes wrong, it’s almost always because one step was skipped — diagnose which one, and that’s your fix.

The Five Pillars

Part 2 — The 6 Delivery Phases

Each phase has the same shape: an entry condition, key activities, an output, and a gate that must pass before the next phase starts. The training covers Phases 1–4 hands-on; Phases 5–6 are introduced so you understand the whole pipeline.

Part 3 — Quality Gates & Handoffs

Every phase ends with a gate. Passing it lets the next phase start. Failing it sends work back into the current phase — never forward. A gate is three things at once: a checkpoint (is the artifact complete?), a handoff (is the next role ready to receive it?), and a commitment (downstream work proceeds based on this). What triggers a gate is the handoff and sign-off — not the calendar. This training schedules gates on Fridays so the rhythm is predictable, but the rule is that the next phase can’t begin until the prior phase’s owner has signed off and handed over. On a real project the day moves; the dependency does not.

The Three Gates in This Training

Part 4 — Traceability

Every feature can be walked end-to-end. Every step references the one before it — the chain is unbroken.

BRD requirement
   → PRD user story
      → Architecture decision
         → Dev Task
            → code
               → unit test

How It Shows Up in Practice

Why It Matters

Part 5 — Quality Bars

Gates verify artifacts against a concrete quality bar — not gut feel. Below are the verification ladder and the Week 1 bars (BRD, PRD). Architecture/ADR/Dev Tasks bars come in Module 4; Code/Test bars in Module 5.

The Verification Ladder

Every artifact passes three layers before approval. Each catches what the others miss.

BRD Quality Bar

The BRD answers “what does the business need and why?” — in business language, not technical. Everything downstream traces back here.

Checklist

• Every business requirement has a unique numeric ID (BR-01, BR-02, …)
• Every requirement is in business language, not technical solutions
• Every named stakeholder has at least one requirement addressing their concern
• Constraints are specific and quantified (“3-month timeline” not “tight timeline”)
• Success criteria are measurable (numbers, dates, observable outcomes)
• No requirement starts with “the system shall” — that’s PRD/architecture territory
• Scope explicitly lists what’s out of scope, not just what’s in
• Assumptions and risks are surfaced, not hidden inside requirement text

PRD Quality Bar

The PRD answers “what does the product do, for whom, and how do we know it’s working?” The Tech Lead and Architect use it to break down work and design the system.

Checklist

• Every user story has a unique ID (US-01, US-02, …)
• Every user story is “As a {role}, I want {action}, so that {outcome}”
• Every user story references the BRD requirement(s) it addresses (US-05 → BR-03)
• Every user story has at least 2 acceptance criteria
• Acceptance criteria are testable (a QA reviewer can verify each one)
• Wireframes exist for the 3 most critical flows
• Non-functional requirements are quantified (“p95 < 500ms” not “fast”)
• Every BRD requirement is covered by at least one user story (no orphans)
• Out-of-scope is explicit, not just “everything else”

Cross-Artifact Traceability Check (Week 1 Gate)

Run this at the Week 1 gate — and during Wed–Thu peer review, not just Friday.

• Every BRD requirement (BR-XX) is addressed by at least one user story (US-YY)
• Every user story references the BRD requirement(s) it addresses
• No user story addresses a requirement that isn’t in the BRD (no scope creep)
• PRD constraints align with BRD constraints (no contradictions)
• The BR → US mapping is documented where a reviewer can find it quickly

Part 6 — Producing Your Week 1 Artifact

This is where AI does the work. The Evaluate → Plan → Apply → Validate cycle applies to artifact production. Below are the prompt sequences for the BRD (Solutions Designer) and PRD (Product). Other roles produce review notes — see the role table.

Producing the BRD (Solutions Designer)

Before you start (setup — do this yourself, don’t paste it)

1. Set up the agent. Load solarch-brd-generator as your system prompt — create a Claude.ai Project or Gemini Gem and paste the agent into its instructions (copy it from the agent browser), or @solarch-brd-generator in Claude Code. The Project/Gem persists; set it up once.

2. Load context. For the sample project, the inputs live in sample-project/source-docs/: rfp.md (the client’s RFP), estimation-sheet.csv (scoped features and estimates from pre-sales), and solutions-document-example.md (the reference for the Solutions Document the SA writes first). The flow is: SA writes the Solutions Document from the RFP, then feeds the Solutions Document + Estimation Sheet into the BRD agent. For your reference quality bar, use the completed BRD in source-docs/demo-output/BRD/ (from the training repo github.com/strat-training/ai-sdlc, at sample-project/source-docs/demo-output).

3. Then send the prompts below, one at a time.

Send — Evaluate

Producing the PRD (Product Mgr / Designer)

Before you start (setup — do this yourself, don’t paste it)

1. Set up the agent. Load product-manager as your system prompt — a Claude.ai Project or Gemini Gem with the agent pasted in, or @product-manager in Claude Code.

2. Load context. The approved (or in-flight) BRD, UX research, and the RFP in source-docs/. For your reference quality bar, use the completed PRD in source-docs/demo-output/PRD/ (from the training repo github.com/strat-training/ai-sdlc).

3. Then send the prompts below, one at a time.

Send — Evaluate

Week 1 Deliverable by Role

Same exercise, different artifact per role. All branches feed Friday’s gate review. BRD and PRD owners use the prompt sequences in Part 6; reviewers produce notes committed to docs/reviews/.

The Week 1 Deliverable

Self-Check

• I can name the four principles and explain why each matters.
• I can list the six phases in order and name the gate at the end of each.
• I know which artifact my role owns at each phase — and which I review.
• I can trace any feature in the reference chain (source-docs/demo-output/) from BRD to deployed code without gaps.
• I understand gates are real handoffs — passing one means the next phase can start.
• I know the verification ladder (self-check → peer review → gate review) and what each layer is for.
• I can run the BRD and PRD quality checklists and land on a verdict.
• I know how the Week 1 traceability check (BRD ↔ PRD) is run and where the sign-off form lives.
• I can load minimum-viable context without over-stuffing, and I know when to start a fresh session.
• I’ve identified my Week 1 deliverable and know what good looks like.