Requirement¶

Purpose¶

Provide concrete, interview-ready examples that demonstrate how ABC converts real customer problems into user stories, use cases, requirements, priorities, and release decisions.

Industry Context: Story Framing as Architecture¶

User story rewrites often reveal fundamental information architecture decisions that the original framing obscured. Outschool discovered that parents search by topic and age band, not by tutor credential. Their story evolved from “As a parent, I want to find a qualified tutor” to “As a parent, I want to find a class on Ancient Egypt for my 8-year-old this Saturday afternoon.” That reframe changed the site’s entire search and browse structure — filter taxonomy, tutor profile layout, session card design, and home page hierarchy all followed from the new story, not from a separate design process.

Duolingo’s story for the streak feature was: “As a learner, I want to pick up where I left off after missing a day without feeling punished.” Without the phrase “without feeling punished,” the solution would have been harder enforcement of daily completion — the opposite of what was built. The clause carrying the emotional constraint determined the requirement. Streak freeze and forgiveness mechanics were not a softening of the original requirement; they were the correct implementation of it.

The stories in this portfolio follow the same discipline. US-003 (tutor continuity) and US-004 (progress visibility) were derived from the most consistent signal in parent churn feedback — not from internal product preferences or benchmarking exercises. The actor, trigger, and desired outcome in each story were taken from interview evidence before any solution was considered.

Tool Representation Of Example Chains¶

Use the same example chain (US-001 -> UC-001 -> REQ-001) in each platform so interviewers can see implementation portability.

Jira: Story (US-001) links to Requirement (REQ-001) and linked test cases; release tied through Fix Version.
Azure DevOps: User Story links to requirement work item and Test Case; delivery tracked via sprint and release pipeline stages.
Jama Connect: user need and use case items link downstream to requirement and verification artifacts with review workflow.
IBM DOORS Next: requirement modules store baselined statements and link sets to validation evidence.
GitHub: issue form captures IDs, linked pull request references implementation, milestone references release window.

Visual Story-To-Requirement Flow (Agile + PMBOK)¶

Story Decomposition Pipeline

Agile decomposition from intent to testable commitment. PMBOK quality control is represented by explicit test and gate linkage.

Example A Risk and Priority Snapshot

Use this quick risk-priority lens during sprint planning to protect critical conversion requirements first.

End-To-End Example A: Free Intake To Paid Enrollment¶

Problem Signal¶

Funnel analytics show high drop-off between landing page and completed free-session booking.
Parent interviews report friction in time selection and unclear next steps.

User Story¶

US-001: As a parent, I want to book a free intake session quickly so I can evaluate fit without friction.

Use Case Specification¶

Field	Value
Use Case ID	UC-001
Name	Free intake to paid enrollment
Primary actor	Parent/guardian
Supporting actors	Growth funnel, scheduling service, payment service, support
Preconditions	Parent is on booking flow and service area is supported
Trigger	Parent clicks “Book free session”
Success outcome	Parent completes intake and enrolls in paid plan

Main flow:

Parent selects preferred days/times.
System proposes tutor availability windows.
Parent confirms intake slot.
Intake session occurs and tutor completes learner profile.
Parent receives recommended plan and expected milestones.
Parent selects plan and submits payment.
System confirms enrollment and first paid session.

Alternate flows:

No suitable slot found: system offers waitlist and callback.
Parent abandons booking: system triggers reminder sequence.
Payment fails: system offers retry and support handoff.

Derived Requirements¶

Req ID	Type	Requirement Statement	Priority	Release
REQ-001	FNC	Booking flow must complete in <=3 minutes median.	P0	MVP
REQ-001A	FNC	Booking form must require <=5 fields before confirmation.	P1	MVP
REQ-001B	DAT	Track step-level drop-off with event IDs and timestamps.	P0	MVP
REQ-001C	OPS	Abandonment reminder sequence must trigger within 2 hours.	P1	MVP
REQ-001D	CMP	Parent consent must be captured before child account activation.	P0	MVP

Acceptance Criteria (Gherkin)¶

Feature: Free intake booking

Scenario: Parent completes booking in one pass
  Given a parent enters the booking flow
  When they provide required information and select an available slot
  Then the system confirms the intake appointment
  And stores booking analytics events for each funnel step

Scenario: Parent abandons booking
  Given a parent exits before booking confirmation
  When 2 hours pass
  Then the system sends a reminder message with a resume link

Prioritization Breakdown¶

Item	Reach	Impact	Confidence	Effort	RICE	Priority Band
REQ-001	10	8	8	3	213.3	P0
REQ-001B	10	7	9	2	315.0	P0
REQ-001C	8	6	7	3	112.0	P1

Critical-path note:

REQ-001 and REQ-001B are CP-Yes because MVP launch KPI proof cannot be measured without them.

End-To-End Example B: Tutor Continuity Preservation¶

Problem Signal¶

Early churn interviews cite tutor changes as a trust breaker.
Continuity metric drops below target during demand spikes.

User Story¶

US-002: As a parent, I want my child to keep the same tutor so progress feels consistent and trust is maintained.

Use Case Specification¶

Field	Value
Use Case ID	UC-002
Name	Tutor continuity preservation
Primary actor	Tutor Operations Manager
Supporting actors	Scheduling engine, tutor roster, support
Preconditions	Learner has assigned tutor and active plan
Trigger	Tutor availability conflict or planned leave
Success outcome	Learner stays with same tutor or transitions with minimal disruption

Main flow:

System detects upcoming tutor availability conflict.
Tutor Ops reviews conflict severity and duration.
System proposes slot reshuffle options first (same tutor).
Parent is offered options with clear explanation.
If no same-tutor option is feasible, curated backup tutor is proposed.
Parent confirms option and schedule is updated.

Alternate flows:

Parent declines all options: case escalates to success specialist.
Transition accepted: warm handoff with shared learner notes is required.

Derived Requirements¶

Req ID	Type	Requirement Statement	Priority	Release
REQ-002	OPS	Continuity score must stay >=85% for active learners.	P0	MSP-R1
REQ-002A	FNC	Conflict detector must alert Tutor Ops >=72 hours before impacted session.	P1	MVP
REQ-002B	OPS	Backup tutor handoff must include standardized learner brief.	P1	MSP-R1
REQ-002C	DAT	Continuity metric must be visible daily by cohort and tutor.	P1	MVP

Priority And Risk View¶

Req ID	Risk Link	Risk Description	Mitigation
REQ-002	RSK-CP-02	Tutor capacity shortfall can delay MSP launch	Maintain backup tutor bench and forecast buffer
REQ-002A	RSK-OP-04	Late alerts create support overload	Add alert SLA and audit exceptions weekly

End-To-End Example C: Failed Payment Recovery¶

Problem Signal¶

Renewal losses include avoidable payment failures.
Families complain that retries and support are unclear.

User Story¶

US-008: As a parent, I want a simple payment recovery flow so my child’s sessions continue without interruption.

Use Case Specification¶

Field	Value
Use Case ID	UC-005
Name	Billing failure handling
Primary actor	Parent/guardian
Supporting actors	Billing service, support, success operations
Preconditions	Active paid plan and scheduled sessions
Trigger	Payment attempt fails
Success outcome	Payment is recovered and schedule continuity is preserved

Main flow:

Billing service records failed payment reason.
Parent receives clear notification with retry and update card options.
Automatic retries execute on configured cadence.
Support case is auto-created if retries fail.
Success specialist contacts parent before session interruption threshold.

Derived Requirements¶

Req ID	Type	Requirement Statement	Priority	Release
REQ-008	OPS	Failed payment workflow must execute retries and parent notifications automatically.	P1	MSP-R1
REQ-008A	OPS	Support case must be created within 15 minutes after final retry failure.	P1	MSP-R1
REQ-008B	DAT	Recovery funnel must track retry success by reason code.	P2	MSP-R1

Example Backlog Ticket Breakdown¶

Level	ID	Example Title	Description
Epic	EP-10	Improve free intake conversion	End-to-end funnel improvements from click to enrollment
Story	US-001	Parent books free intake quickly	Parent completes booking with minimal friction
Use Case	UC-001	Intake to paid flow	Operational scenario specification
Requirement	REQ-001	Booking in <=3 minutes	Testable requirement tied to KPI
Task	ENG-442	Implement slot-picker optimization	Engineering delivery task
Test	QA-190	Booking completion timing validation	Verifies acceptance threshold

Requirement Quality Checklist¶

Atomic: one requirement expresses one behavior.
Measurable: threshold and measurement method are explicit.
Traceable: linked to story/use case, KPI, owner, and release.
Testable: acceptance criteria can be validated.
Prioritized: has P0 to P3 label and critical-path flag.

Common Interview Talking Point¶

“I do not treat stories as requirements. Stories capture customer intent; use cases capture operational context; requirements capture testable commitments. The traceability matrix ensures strategy, execution, risk, and release decisions stay connected.”