11 - Requirements Traceability Matrix

Purpose

Define the operating process for converting user stories and use cases into testable requirements, then labeling and prioritizing those requirements for MVP and MSP releases.

Industry Context: Requirements Traceability

In software and IT organizations, the closest equivalent foundation is ISO/IEC/IEEE 29148 (requirements engineering), combined with audit-focused control frameworks such as SOC 2 and ISO/IEC 27001. These frameworks require teams to define requirements clearly, map requirements to implemented controls, and retain objective verification evidence for review. In education technology, FERPA and COPPA add domain-specific obligations for student data handling and parental consent, which further increases the need for traceability from user need to requirement, from requirement to control, and from control to test/audit evidence. The column structure used in this portfolio — need source, requirement statement, verification method, owner — follows that software and edtech traceability pattern.

Stripe applies the same traceability discipline to API development. Before any implementation begins, engineers write an API spec review: the exact JSON request and response shape that the feature will produce. That document becomes a binding artifact — acceptance tests are written against it, not against a description of what the feature should generally do. The requirement is expressed as an interface contract. That approach directly informs the acceptance criteria format in this matrix, where each requirement has a testable condition, not a directional statement.

Story To Requirement Workflow

1. Collect user stories and use cases from discovery interviews, support signals, tutor notes, and funnel analytics.

2. Normalize each input into a structured statement with actor, trigger, action, and expected outcome.

3. Link each story/use case to one measurable KPI movement hypothesis.

4. Translate validated stories into requirement statements with acceptance criteria.

5. Label each requirement by type, priority, release target, and critical-path status.

6. Score and rank requirements in weekly portfolio triage.

7. Commit only “ready” requirements to release scope.

Tool Implementation Examples (RTM)

Jira

• Model chain: Story -> Requirement -> Test (Xray or equivalent) -> Fix Version.

• Enforce required fields on Requirement: Priority, Critical Path, Risk Link, Release Tag.

• Use saved filters for launch control: type = Requirement AND Priority = P0 AND "Critical Path" = Yes AND status != Released.

Azure DevOps

• Model chain: Epic -> Feature -> User Story -> Requirement -> Test Case.

• Use work-item links (Parent/Child, Related, Tested By) to preserve upstream/downstream traceability.

• Use queries and dashboard tiles to surface gate blockers (Priority = P0, CP = Yes).

Jama Connect / IBM DOORS Next

• Baseline requirement sets at scope-freeze gates (for example, G1) before delivery starts.

• Maintain explicit relationships: stakeholder need -> requirement -> verification case.

• Run change-impact analysis with suspect-link review whenever a baselined requirement is modified.

GitHub

• Use issue forms that require Story ID, Use Case ID, and Requirement ID.

• Link issue -> pull request -> commit -> release tag for lightweight end-to-end evidence.

• Use GitHub Projects fields for Priority, Critical Path, Risk Link, and Release Tag.

Visual Traceability Artifacts (Agile + PMBOK)

Requirements Exist at Every Work Item Level

A requirement is a work item. The level (Epic / Feature / Story / Use Case) determines scope, not importance. Each requirement traces to its immediate upstream parent; the full chain above is maintained by parent/child links in the backlog tool.

RTM Coverage Matrix (P0 and CP Focus)

Green cells indicate complete evidence linkage. Amber indicates accepted temporary gap with mitigation owner. This supports gate-readiness conversations.

Labeling Taxonomy

• Requirement ID format: REQ-###

• Story ID format: US-###

• Use case ID format: UC-###

• Priority:

  • P0 = release blocker / hard gate

  • P1 = essential for target outcome

  • P2 = valuable but deferrable

  • P3 = optional optimization

• Requirement type:

  • FNC (functional)

  • NFR (non-functional)

  • OPS (operational)

  • CMP (compliance/trust)

  • DAT (data/analytics)

• Critical-path flag: CP-Yes or CP-No

• Release tag: MVP, MSP-R1, MSP-R2

• Requirement level: Epic | Feature | Story | Use Case

• Traces To: the ID of the immediate upstream work item at that level (EP-###, FT-###, US-###, UC-###)

Work Item Hierarchy and Requirement Levels

A requirement is not a separate artifact that sits below the work item hierarchy — a requirement is a work item, and it exists at one of four levels: Epic, Feature, Story, or Use Case. The level determines the scope of the requirement, not its importance.

Req Level	Scope	Typical Requirement Type	Example
Epic	Business objective or program-level mandate	Compliance, architectural constraint, cross-cutting NFR	All events must be instrumented before launch (EP-006)
Feature	Delivery container for a capability	Performance SLA, behavioral rule that spans multiple stories	Session must support 25-min cadence under degraded network (FT-003)
Story	A single user need expressed as acceptance criteria	Functional behavior with a measurable threshold	Booking flow completable in ≤3 min with ≤5 fields (US-001)
Use Case	A discrete scenario with defined trigger and outcome	Scenario-specific behavioral or compliance condition	Verifiable parent consent required before session activation (UC-006)

The Traces To column in the RTM identifies the immediate upstream work item at that level. The full chain above it (Feature → Epic, Story → Feature → Epic) is maintained by the parent/child relationships in the backlog tool and does not need to be repeated on every row.

Epic Catalog

Epic ID	Epic Name	Business Objective	Release Horizon
EP-001	Learner Acquisition & Onboarding	Reduce booking friction; increase free-to-paid conversion rate	MVP
EP-002	Tutor Operations & Continuity	Improve tutor quality, stability, and learner-tutor fit	MSP-R1
EP-003	Learner Experience & Retention	Improve attendance adherence, session quality, and long-term retention	MVP + MSP-R1
EP-004	Revenue & Commercial Model	Expand plan mix, recover billing failures, and launch group product line	MSP-R1 + MSP-R2
EP-005	Compliance & Trust	Enforce COPPA, FERPA, and SOC 2 controls at launch	MVP
EP-006	Data & Analytics Infrastructure	Instrument all critical funnel and lifecycle events; enable data-driven PM decisions	MVP

Feature Catalog

Feature ID	Feature Name	Parent Epic	Owner	Target Release
FT-001	Intake & Booking UX	EP-001	Growth + Eng	MVP
FT-002	Tutor Match Engine	EP-002	Tutor Ops	MSP-R1
FT-003	Session Reliability	EP-003	Engineering	MVP
FT-004	Progress Reporting	EP-003	Product	MVP
FT-005	Lesson Planning Tools	EP-002	Curriculum + Tutor Ops	MVP
FT-006	Subscription Management	EP-004	Revenue + Eng	MSP-R1
FT-007	Attendance & Rescue Automation	EP-003	Success	MVP
FT-008	Billing & Payment Recovery	EP-004	Revenue Ops	MSP-R1
FT-009	Child Consent & COPPA Controls	EP-005	Legal + Engineering	MVP
FT-010	Event Instrumentation	EP-006	Product Ops	MVP
FT-011	Tutor Fit Change Flow	EP-002	Tutor Ops + Support	MSP-R1
FT-012	Group Tutoring Launch	EP-004	Product + Revenue	MSP-R2

User Story Backlog (Structured Inputs)

Story ID	Epic	Feature	User Story	Source Evidence	KPI Hypothesis
US-001	EP-001	FT-001	As a parent, I want to book a free intake session quickly so I can evaluate fit without friction.	Funnel drop-off at booking steps	Increase booking completion rate
US-002	EP-002	FT-002	As a parent, I want my child matched with a stable tutor so progress feels consistent.	Early churn reasons mention tutor inconsistency	Improve tutor continuity and month-3 retention
US-003	EP-003	FT-003	As a learner, I want short and engaging sessions so I can stay focused four times per week.	Session completion analysis by duration	Improve attendance adherence
US-004	EP-003	FT-004	As a parent, I want clear weekly progress updates so I know tutoring is working.	Support tickets ask for clearer progress evidence	Improve retention and NPS
US-005	EP-002	FT-005	As a tutor, I want structured lesson objectives so sessions stay consistent and effective.	Tutor QA variance review	Improve learner on-track rate
US-006	EP-004	FT-006	As a parent, I want flexible plan options so I can commit at the right pace and budget.	Plan selection interviews	Improve paid conversion and plan mix

Use Case Catalog

Use Case ID	Epic	Feature	Scenario	Primary Actor	Trigger	Expected Outcome
UC-001	EP-001	FT-001	Free intake to paid conversion	Parent	Intake complete	Enrollment in paid plan
UC-002	EP-002	FT-002	Tutor continuity preservation	Tutor Ops	Tutor unavailability risk	Reassignment only when necessary
UC-003	EP-003	FT-007	Attendance rescue	Success	Two missed sessions in one week	Attendance recovers next week
UC-004	EP-003	FT-004	Progress communication	System + Tutor	Weekly cycle complete	Parent receives clear progress digest
UC-005	EP-004	FT-008	Billing failure handling	Billing + Support	Payment failure	Recovery or graceful downgrade
UC-006	EP-005	FT-009	Child privacy consent handling	Parent + System	New account creation	COPPA-compliant consent captured

Requirements Traceability Matrix

Each row is a requirement work item. Req Level is the level in the hierarchy where the requirement lives. Traces To is the immediate upstream parent work item — the full chain above it is maintained by parent/child links in the backlog tool.

Req ID	Req Level	Traces To	Requirement Statement	Type	Priority	CP	Risk Link	Owner	Target Release	Verification
REQ-001	Story	US-001	Free-session booking flow must be completable in <=3 minutes median with <=5 required fields.	FNC	P0	CP-Yes	RSK-CP-01	Growth + Eng	MVP	Funnel analytics and usability test
REQ-002	Feature	FT-002	Tutor matching service must maintain >=85% tutor continuity for active learners.	OPS	P0	CP-Yes	RSK-CP-02	Tutor Ops	MSP-R1	Weekly continuity dashboard
REQ-003	Feature	FT-003	Session experience must support 25-minute lesson cadence with stable reconnect behavior under degraded network.	NFR	P0	CP-Yes	RSK-CP-03	Engineering	MVP	Load/reliability test and incident trend
REQ-004	Story	US-004	Parent dashboard must publish weekly progress digest with growth signal and next-step recommendation.	FNC	P1	CP-Yes	RSK-CP-04	Product	MVP	Adoption and CSAT measurement
REQ-005	Story	US-005	Tutor lesson plan tool must include objective, activity sequence, and mastery checkpoint for each session.	OPS	P1	CP-No	RSK-OP-01	Curriculum + Tutor Ops	MVP	QA rubric score
REQ-006	Feature	FT-006	Subscription catalog must support monthly, 3-month, 6-month, and annual options with pause/resume support.	FNC	P0	CP-Yes	RSK-CP-05	Revenue + Eng	MSP-R1	Billing acceptance tests
REQ-007	Use Case	UC-003	Attendance rescue automation must trigger reminder + reschedule flow after two misses in seven days.	OPS	P1	CP-No	RSK-OP-02	Success	MVP	Attendance recovery rate
REQ-008	Use Case	UC-005	Failed-payment workflow must retry, notify, and route to support within SLA.	OPS	P1	CP-No	RSK-OP-03	Revenue Ops	MSP-R1	Recovery rate and SLA audit
REQ-009	Use Case	UC-006	New child accounts must enforce verifiable parent consent before session activation.	CMP	P0	CP-Yes	RSK-CMP-01	Legal + Engineering	MVP	Consent audit trail
REQ-010	Epic	EP-006	Event instrumentation must capture booking, enrollment, attendance, and progress publication events.	DAT	P0	CP-Yes	RSK-CP-06	Product Ops	MVP	Analytics QA checklist
REQ-011	Feature	FT-011	Tutor fit-change request flow must resolve within 72 hours for >=90% of cases.	OPS	P1	CP-No	RSK-OP-04	Tutor Ops + Support	MSP-R1	Support SLA reporting
REQ-012	Feature	FT-012	Group tutoring plan must launch with cohort rules and eligibility guardrails.	FNC	P2	CP-No	RSK-GTM-01	Product + Revenue	MSP-R2	Launch KPI readout

Prioritization Rules

1. P0 is automatically assigned when legal/compliance, payment integrity, or launch-blocking reliability is impacted.

2. P1 is assigned when measurable KPI movement is expected within current quarter.

3. P2 and P3 are deferred if they displace any P0 or P1 critical-path item.

4. No requirement enters active sprint without source traceability (US or UC) and explicit verification method.

Definition Of Ready For Requirements

• Requirement has unique ID and owner.

• Req Level is set (Epic / Feature / Story / Use Case).

• Traces To parent work item ID is identified and the parent exists in the backlog.

• Acceptance criteria are testable (a human can run the verification and get a pass/fail).

• Priority, release tag, and CP flag are set.

• Risk link is assigned.

Traceability Governance

• Weekly: Update requirement statuses and priority changes.

• Monthly: Audit matrix completeness and stale requirements.

• Quarterly: Re-baseline requirements to roadmap outcomes and release gates.