Purpose
Turn vague, outcome-language business goals captured in a sales or discovery conversation into a structured, implementable technical requirement set — with functional requirements, non-functional requirements, dependencies, acceptance criteria, and the open questions that must be resolved before scoping. Eliminates the gap between what a customer said they want and what an engineering team can actually build against.
When to Use
Invoke this skill when the user asks to:
- Convert discovery-call notes or meeting summaries into technical requirements
- Translate a customer's business objective into something engineering can scope
- Prepare a requirements section for a proposal, SOW, or RFP response
- Structure a stakeholder's wish list into functional and non-functional requirements
- Identify hidden technical dependencies behind a stated business goal
- Surface the assumptions and open questions that need confirmation before a quote
Inputs Required
Before starting, collect:
- Business goals: The plain-language goals as the customer stated them (paste raw notes, quotes, or a summary)
- Product context: What the SaaS product does and the modules/capabilities relevant to this deal
- Customer profile: Industry, company size, and technical maturity (e.g., has a dev team / no internal IT)
- Existing systems: Tools the customer already uses that may need to integrate (CRM, ERP, identity provider, data warehouse, etc.)
- Constraints: Known budget, timeline, compliance, or platform constraints mentioned in the conversation
- Stakeholders: Who voiced each goal and their role (so requirements can be traced and prioritized)
If customer technical maturity or existing systems are unknown, generate requirements assuming a mid-maturity buyer and flag the missing detail explicitly in the Open Questions section.
Instructions
Step 1: Extract and Restate Each Business Goal
Parse the raw input and isolate each distinct business goal. For each one:
- Restate it in one clean sentence as an outcome ("The customer wants to reduce manual order entry time")
- Tag the business driver behind it: cost reduction / revenue growth / risk & compliance / customer experience / operational efficiency
- Note who said it and any urgency or priority signal
Do not yet translate — the goal here is a clean, deduplicated inventory. Merge overlapping statements; split compound goals into separate items.
Step 2: Translate Each Goal into Functional Requirements
For each business goal, derive the specific system behaviors required to achieve it. Each functional requirement must be:
- Written in the form "The system shall [specific capability]"
- Tied back to the goal it serves (traceability)
- Concrete enough to build against — not "the system shall be user-friendly"
A single business goal typically produces 2–5 functional requirements. Example: "reduce manual order entry" → automated order ingestion from email/API, field-level data validation, exception queue for failed records, audit log of automated entries.
Step 3: Derive Non-Functional Requirements
For each goal cluster, identify the quality attributes implied but rarely stated by the customer. Cover the relevant categories:
- Performance: throughput, latency, concurrent users, data volume
- Security & compliance: authentication method, data residency, regulatory standard (SOC 2, HIPAA, GDPR)
- Availability & reliability: uptime expectation, recovery objectives
- Scalability: expected growth in users/records/transactions
- Usability & accessibility: skill level of end users, accessibility standards
- Maintainability & integration: API needs, configurability, admin control
State each as a measurable target where possible ("99.9% uptime," not "high availability"). If the customer gave no number, propose a defensible default and mark it as an assumption.
Step 4: Map Dependencies and Integrations
Identify what must connect or exist for the requirements to be satisfied:
- Integration points: each external system, the direction of data flow, and the likely mechanism (native connector / REST API / webhook / file import / iPaaS)
- Data dependencies: source-of-truth systems, required data fields, migration or sync needs
- Identity & access: SSO/SAML, role-based access, provisioning
- Sequencing: which requirements depend on another being delivered first
Flag any dependency that relies on something outside the SaaS product's control (e.g., customer must expose an ERP API).
Step 5: Write Acceptance Criteria
For each functional requirement, write 1–2 testable acceptance criteria in Given/When/Then form. These define "done" and become the basis for UAT. Keep them binary and observable — a tester must be able to mark each pass or fail without interpretation.
Step 6: Capture Assumptions and Open Questions
- Assumptions: every inference made to fill a gap (defaults, unstated standards, presumed system access) — listed so the customer can confirm or correct
- Open Questions: the specific things that must be answered before scoping or quoting, each phrased as a direct question to ask the customer, ordered by how much they affect scope or risk
Output Format
- Structure: Requirements traceability matrix (table) linking each business goal to its functional requirements, followed by structured sections for non-functional requirements, dependencies, acceptance criteria, assumptions, and open questions
- Length: 800–1,400 words depending on goal count
- Format: Goal-to-requirement matrix as a table; functional and non-functional requirements as ID-prefixed lists (FR-1, NFR-1); acceptance criteria in Given/When/Then; assumptions and open questions as numbered lists
- Sections: Goal Inventory → Requirements Traceability Matrix → Functional Requirements → Non-Functional Requirements → Dependencies & Integrations → Acceptance Criteria → Assumptions → Open Questions
- Tone: Solution architect — precise, neutral, implementation-grounded. No sales language, no hype.
Quality Checklist
Before delivering output, verify:
- [ ] Every functional requirement traces back to a specific business goal (no orphan requirements)
- [ ] Every business goal produced at least one functional requirement (no dropped goals)
- [ ] Requirements are written as testable system behaviors — none read as vague qualities like "intuitive" or "robust" without a measurable target
- [ ] Every non-functional requirement that lacks a customer-stated number is marked as an assumption with a proposed default
- [ ] Each functional requirement has at least one Given/When/Then acceptance criterion
- [ ] Open questions are phrased as direct, askable questions and ordered by scope impact
Notes
- The highest-value output is often the Open Questions section — surfacing what wasn't said is what separates a real scope from an optimistic one
- Watch for goals that quietly imply an integration the product can't natively support; flag these early as the biggest scope and timeline risk
- When a customer states a solution ("we need a dashboard") rather than a goal, trace it back to the underlying outcome before writing requirements — the stated solution is often not the best fit
- Use stable requirement IDs (FR-/NFR-) so the output can drop directly into a proposal, SOW, or backlog without renumbering
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills