Skip to content
Beta Multi-model support (OpenAI, Gemini, and more) launching soon.
RBA RBA Skills

requirements-workshop

Installable Ships in discovery-synthesizer — or copy the raw skill below.
Open Claude.ai

Paste into Claude Code, Claude.ai, the desktop app, or the browser extension — ⌘/Ctrl+V.

ExperimentalNo security review

Requirements Workshop

Turn discovery insights into a structured, prioritized requirements register that bridges the gap between "what we learned" and "what the platform needs to do." Output is a markdown register the team can evolve through the envision phase and hand off to engineering.

When this skill applies

  • User has a discovery insights report, themed findings, or a set of opportunity areas and wants requirements
  • Post-discovery workshop: translating whiteboard outputs into a structured register
  • Pre-envision alignment: producing a requirements package for platform evaluation or vendor shortlisting
  • Mid-project discovery: adding requirements from a new stakeholder group to an existing register

Workflow

Step 1 — Load and orient

Read all provided discovery material. Extract:

  • List of themes or findings (with confidence ratings if present)
  • Opportunity areas (JTBD framing preferred)
  • Persona set (if available)
  • Stated constraints (technical, timeline, budget, regulatory)
  • Explicit requirement statements made by stakeholders ("we need," "it must," "the system has to")

Separate explicit requirements (directly stated by stakeholders) from inferred requirements (derived by the team from themes and opportunity areas). Track this distinction throughout — it affects priority and defensibility.

Step 2 — Draft the requirements

For each requirement, produce:

Requirement ID: Kebab-prefixed format — REQ-[area]-[sequence]. Areas: CONTENT (content creation/management), AUTH (authentication/permissions), INTEG (integrations), SEARCH (search and navigation), PERF (performance), GOVERN (governance/workflow), PERSON (personalization), ANALYTICS (reporting/analytics), ACCESSIBILITY (WCAG/a11y), MIGRATION (data/content migration).

Source type: Explicit (directly stated by a stakeholder) | Inferred (derived from themes) | Standard (RBA best-practice default for this platform type)

Statement: One-sentence functional requirement. Format: "The system must / should / could [verb] [object] [condition]."

  • "must" = Must-have (MoSCoW M)
  • "should" = Should-have (MoSCoW S)
  • "could" = Could-have (MoSCoW C)
  • Avoid "would" in statements; use "Won't-have this release" as a separate flag

Rationale: 1–2 sentences connecting this requirement to the evidence. Cite the theme or stakeholder quote that drives it.

Persona(s) affected: Which persona(s) this requirement primarily serves.

Dependencies: Other requirements this cannot be delivered without.

Acceptance criteria stub: 2–3 testable conditions that define "done." Use Given/When/Then format.

Step 3 — Apply MoSCoW prioritization

For each requirement, assign a MoSCoW band:

Must-have (M) — the release has no value without this; a launch blocker if absent. Criteria:

  • Explicitly stated by a sponsor-level stakeholder as non-negotiable
  • Legally or regulatorily required (WCAG 2.1 AA, GDPR cookie consent, etc.)
  • Core platform functionality without which primary personas cannot complete their primary JTBD

Should-have (S) — important but the release is viable without it if there is time pressure. Criteria:

  • High-confidence finding from discovery (3+ participants)
  • Delivers significant value to a primary persona
  • Can be delivered in a follow-on sprint without structural rework

Could-have (C) — desirable if scope and time allow. Criteria:

  • Medium-confidence finding or inferred requirement
  • Enhances an existing capability rather than enabling a core workflow
  • Often features that appeared in "wish list" language during interviews

Won't-have this release (W) — explicitly out of scope for this delivery. Document these — they capture decisions and prevent scope creep re-litigation. Criteria:

  • Explicitly deferred by the sponsor
  • Technically dependent on a system or integration not in scope
  • Discovery surfaced the need but it does not map to a Must or Should for any primary persona

Step 4 — Flag conflicts and risks

After drafting the register, scan for:

Conflicts: Two requirements that cannot both be satisfied simultaneously (e.g., "content must be editable by authors without IT involvement" vs. "all content changes must be approved by IT before publishing"). Surface explicitly — do not resolve without stakeholder input.

Dependency risks: A chain of requirements where one high-priority item depends on a lower-priority item or on an integration not yet confirmed. Flag and escalate.

Gold-plating risks: Should-haves or Could-haves that crept into the Must-have band without strong evidence. Challenge these. A common pattern: "We've always had this feature" is not a discovery finding.

Accessibility gaps: Flag any functional area where an ACCESSIBILITY requirement is absent or only a Could-have. WCAG 2.1 AA compliance requirements are always Must-have for RBA-delivered digital experiences.

Platform-specific risks: For each flagged platform, note requirements that are in tension with the platform's architecture:

  • Sitecore: headless vs. Experience Editor authoring requirements that may conflict
  • Optimizely: content graph vs. traditional rendering requirements
  • Umbraco: SaaS (Umbraco Cloud) vs. self-hosted constraints
  • Composable: integration complexity when multiple best-of-breed platforms are involved

Step 5 — Produce the requirements register

Full register format (see templates.md for full markdown):

ID Area Priority (MoSCoW) Source Statement Rationale Personas Dependencies Status
REQ-CONTENT-001 Content M Explicit The system must allow authors to publish content without IT involvement for standard page types. Senior Content Author: "Right now I have to file a ticket for every publish." Content Author REQ-GOVERN-003 Draft

Acceptance criteria register (separate table):

ID Given When Then
REQ-CONTENT-001 Given an author has edit access to a page When they click Publish Then the content goes live within 60 seconds without IT involvement

Step 6 — Produce the executive summary

One page covering:

  • Total requirements: N (M: X, S: X, C: X, W: X)
  • Primary personas served
  • Top 3 Must-have requirements and their evidence base
  • Conflicts requiring stakeholder resolution (with recommended owner and deadline)
  • Open questions the requirements register cannot answer from current discovery

Step 7 — Self-check before returning

  • Every Must-have requirement has an explicit or high-confidence source
  • Accessibility requirements are present and Must-have
  • Conflicts are surfaced, not resolved by assumption
  • Dependencies form a directed acyclic graph (no circular dependencies)
  • Won't-have items are documented with the reason for deferral
  • The register is in a format that can be handed to a BA or solutions architect for estimation

Reference and template files

  • reference.md — MoSCoW calibration guide, acceptance-criteria writing guide, requirements decomposition (epic → story → acceptance criteria)
  • templates.md — full register markdown, executive summary template, and user story card format
Technical details
Plugin
discovery-synthesizer
Author
Dakota Smith
Skill name
requirements-workshop
Maturity
experimental
Security review
No security review
Owners
  • strategy
Argument hint
[paste insights report, themes, or @file-path] [--platform sitecore|optimizely|umbraco|composable] [--moscow] [--format register|user-stories|acceptance-criteria|all]
Allowed tools
  • Read
  • Write
  • Glob
Source
plugins/discovery-synthesizer/skills/requirements-workshop/SKILL.md

Edit this skill on GitHub — opens GitHub's web editor. No git knowledge needed.