playbooks

home / skills / nickcrew / claude-cortex / requirements-discovery

requirements-discovery skill

/skills/requirements-discovery

This skill guides you through structured requirements elicitation, turning vague ideas into concrete PRDs, scope, and testable acceptance criteria.

npx playbooks add skill nickcrew/claude-cortex --skill requirements-discovery

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
2.8 KB
---
name: requirements-discovery
description: Stakeholder interviews, PRD structure, and scope definition for software requirements elicitation. Use when gathering requirements, defining project scope, or structuring product requirement documents.
---

# Requirements Discovery

Systematic requirements elicitation through structured questioning, stakeholder analysis, and specification development. Transforms ambiguous project ideas into concrete, measurable specifications.

## When to Use This Skill

- Gathering requirements for a new project or feature from vague descriptions
- Conducting stakeholder interviews to uncover needs and constraints
- Writing or structuring a Product Requirements Document (PRD)
- Defining project scope with clear boundaries and priorities
- Creating user stories with well-defined acceptance criteria
- Identifying non-functional requirements (performance, security, scalability)
- Resolving conflicting stakeholder priorities
- Validating requirement completeness before handing off to implementation

## Quick Reference

| Task | Load reference |
| --- | --- |
| Interview patterns, PRD structure, scope definition, user story mapping | `skills/requirements-discovery/references/elicitation-techniques.md` |

## Core Principles

- **Ask "why" before "how"**: Uncover true user needs, not assumed solutions
- **Socratic questioning**: Guide discovery through questions rather than assumptions
- **Progressive refinement**: Move from broad goals to specific, testable criteria
- **Stakeholder balance**: Integrate diverse perspectives without letting any single voice dominate

## Workflow

### 1. Discovery

Understand the problem space before defining solutions.

- Identify all stakeholders and their roles
- Conduct structured interviews with open and closed questions
- Map user personas and their pain points
- Capture constraints (technical, budget, timeline, regulatory)

### 2. Specification

Transform raw input into structured requirements.

- Draft PRD with functional and non-functional requirements
- Write user stories with acceptance criteria
- Prioritize using MoSCoW or similar framework
- Define scope boundaries (what is explicitly out of scope)

### 3. Validation

Verify completeness and alignment before implementation.

- Review specifications with stakeholders
- Confirm acceptance criteria are testable and measurable
- Baseline success metrics and KPIs
- Log open questions and follow-up actions
- Prepare implementation handoff document

## Common Mistakes

- Jumping to solutions before understanding the problem
- Treating requirements as fixed rather than iteratively refined
- Missing non-functional requirements (performance, security, accessibility)
- Failing to define what is out of scope
- Writing acceptance criteria that cannot be objectively tested
- Skipping validation with actual users or stakeholders

Overview

This skill provides a structured approach to eliciting, documenting, and validating software requirements. It turns vague ideas and stakeholder input into measurable product requirements and scoped PRDs. The goal is to reduce ambiguity, align stakeholders, and produce testable acceptance criteria for implementation.

How this skill works

I guide discovery through stakeholder identification, structured interviews, and persona mapping to surface real needs and constraints. Then I convert findings into a prioritized PRD, user stories with acceptance criteria, and explicit in/out-of-scope definitions. Finally, I run validation steps to confirm completeness, baseline success metrics, and prepare a handoff package for engineering.

When to use it

  • At project initiation to convert vague goals into concrete requirements
  • When conducting stakeholder interviews to uncover needs and constraints
  • While drafting or restructuring a Product Requirements Document (PRD)
  • To define scope boundaries and prioritize features before development
  • When creating user stories and measurable acceptance criteria

Best practices

  • Ask 'why' before 'how' to reveal underlying needs, not solutions
  • Use a mix of open and closed questions during interviews to probe and confirm
  • Apply progressive refinement: move from goals to specific, testable criteria
  • Capture non-functional requirements (performance, security, accessibility) explicitly
  • Prioritize with a clear framework (e.g., MoSCoW) and document out-of-scope items

Example use cases

  • Run a stakeholder interview series to define requirements for a new feature
  • Structure a PRD from workshop notes, including functional and non-functional specs
  • Resolve conflicting priorities between product, engineering, and compliance
  • Create user stories with measurable acceptance criteria for sprint planning
  • Validate requirement completeness and prepare an implementation handoff

FAQ

How do you handle conflicting stakeholder requests?

I surface the underlying goals, map impacts, and apply a prioritization framework (e.g., MoSCoW) while documenting trade-offs and recommended decisions for alignment.

What makes acceptance criteria 'testable'?

Acceptance criteria are testable when they use measurable conditions (specific inputs, expected outputs, thresholds) and avoid vague language like 'fast' or 'user-friendly' without quantifiers.