Requirements Elicitation & Specification
Input: $ARGUMENTS
Interpretations
Before executing, identify which interpretation matches the user’s input:
Interpretation 1 — Discover requirements for a new project: The user has a project idea or goal and wants to systematically surface ALL requirements — functional, non-functional, constraints, and hidden assumptions — before building. Interpretation 2 — Audit requirements for an existing system: The user has a system or product and wants to check if the requirements are complete, consistent, and well-specified. Interpretation 3 — Resolve conflicting requirements: The user has identified requirements that conflict or compete and needs to prioritize and reconcile them.
If ambiguous, ask: “I can help with discovering requirements for a new project, auditing existing requirements, or resolving conflicts between requirements — which fits?” If clear from context, proceed with the matching interpretation.
Depth Scaling
Default: 2x. Parse depth from $ARGUMENTS if specified (e.g., “/requirements 4x [input]”).
| Depth | Min Requirements Found | Min Categories | Min Stakeholders | Min Conflict Checks |
|---|---|---|---|---|
| 1x | 15 | 4 | 3 | 2 |
| 2x | 30 | 6 | 5 | 4 |
| 4x | 50 | 8 | 7 | 6 |
| 8x | 80 | 10 | 10 | 8 |
| 16x | 120 | 12 | 15 | 12 |
The Process
Step 1: Identify the System Boundary
Before listing requirements, define what’s IN and OUT:
SYSTEM: [name]
PURPOSE: [one sentence]
IN SCOPE:
- [what this system does]
- [what this system manages]
OUT OF SCOPE:
- [what this system does NOT do]
- [adjacent systems]
BOUNDARY INTERFACES:
- [what goes IN to the system]
- [what comes OUT of the system]
- [what systems it connects to]Step 2: Stakeholder Analysis
Who has requirements for this system?
STAKEHOLDERS:
| # | Stakeholder | Relationship | Key Concern | Priority |
|---|-------------|-------------|-------------|----------|
| 1 | [who] | [how they interact] | [what they care about most] | HIGH/MED/LOW |
| 2 | [who] | [how they interact] | [what they care about most] | HIGH/MED/LOW |
...
HIDDEN STAKEHOLDERS (often missed):
- Future users (not current users)
- Maintainers (not just builders)
- Adjacent system owners
- Regulators/compliance
- Adversaries/attackers
- The system itself (self-management)Step 3: Requirement Categories
Systematically generate requirements across ALL categories:
3A: Functional Requirements (What it DOES)
FUNCTIONAL REQUIREMENTS:
For each stakeholder, for each interaction:
| ID | Stakeholder | Action | Input | Output | Priority | Notes |
|----|-------------|--------|-------|--------|----------|-------|
| F1 | [who] | [verb] | [what goes in] | [what comes out] | MUST/SHOULD/COULD | [notes] |
...3B: Non-Functional Requirements (How WELL it does it)
| Category | Requirement | Measurable Target | Priority |
|---|---|---|---|
| Performance | Response time | [specific metric] | |
| Performance | Throughput | [specific metric] | |
| Scalability | Growth handling | [specific metric] | |
| Reliability | Uptime | [specific metric] | |
| Reliability | Error handling | [specific behavior] | |
| Security | Authentication | [specific method] | |
| Security | Data protection | [specific standard] | |
| Usability | Learnability | [specific metric] | |
| Usability | Accessibility | [specific standard] | |
| Maintainability | Extensibility | [specific measure] | |
| Maintainability | Debuggability | [specific measure] | |
| Compatibility | Integrations | [specific systems] | |
| Portability | Platforms | [specific targets] |
3C: Constraints (What it CANNOT do or MUST comply with)
| Type | Constraint | Reason | Negotiable? |
|---|---|---|---|
| Technical | [limitation] | [why] | YES/NO |
| Business | [limitation] | [why] | YES/NO |
| Regulatory | [limitation] | [why] | NO |
| Resource | [limitation] | [why] | YES/NO |
| Timeline | [limitation] | [why] | YES/NO |
3D: Assumptions (What MUST be true for requirements to hold)
| ID | Assumption | If Wrong | Risk Level |
|---|---|---|---|
| A1 | [what’s assumed] | [what breaks] | HIGH/MED/LOW |
| … |
3E: Anti-Requirements (What it explicitly should NOT do)
| ID | Anti-Requirement | Reason |
|---|---|---|
| X1 | [what it must NOT do] | [why this matters] |
| … |
Step 4: Hidden Requirements Discovery
Apply these prompts to surface requirements that stakeholders forgot to mention:
| Prompt | Requirement Found? |
|---|---|
| ”What happens when [input] is missing?" | |
| "What happens when [input] is malformed?" | |
| "What happens at 10x current scale?" | |
| "What happens when [dependency] is down?" | |
| "What happens when a user does something unexpected?" | |
| "What does the FIRST interaction look like?" | |
| "What does the LAST interaction look like?" | |
| "What does day 2 look like vs day 1?" | |
| "What does the error state look like?" | |
| "What does the empty state look like?" | |
| "Who’s the WORST user for this system?" | |
| "What’s the most embarrassing failure?" | |
| "What would a competitor do better?" | |
| "What would you hate about using this?" | |
| "What would make you stop using this?” |
Step 5: Conflict Detection
Check all requirement pairs for conflicts:
CONFLICTS FOUND:
| Req A | Req B | Conflict Type | Resolution |
|-------|-------|---------------|------------|
| [R1] | [R2] | [contradiction / tension / resource competition] | [how to resolve] |
...
CONFLICT TYPES:
- Contradiction: A and B cannot both be true
- Tension: A and B pull in opposite directions
- Resource competition: A and B compete for same resource
- Priority conflict: Stakeholder X wants A, Stakeholder Y wants BStep 6: Prioritization (MoSCoW)
MUST HAVE (system doesn't work without these):
- [R1]: [reason it's must-have]
...
SHOULD HAVE (important but not blocking):
- [R5]: [reason]
...
COULD HAVE (nice to have):
- [R8]: [reason]
...
WON'T HAVE (explicitly excluded from this version):
- [R10]: [reason for deferral]
...Step 7: Specification Quality Check
For each MUST-HAVE requirement, verify:
| Quality | Test | Pass? |
|---|---|---|
| Specific | Could two people interpret this differently? | |
| Measurable | Can you verify this is met? | |
| Achievable | Is this technically possible? | |
| Relevant | Does this serve a stakeholder need? | |
| Testable | Can you write a test for this? | |
| Independent | Does this stand on its own? | |
| Traceable | Can you trace this to a stakeholder need? |
Output Format
## REQUIREMENTS SPECIFICATION: [System Name]
### System Boundary
[In scope / out of scope / interfaces]
### Stakeholders
[Table of stakeholders with priorities]
### Functional Requirements
[Numbered list with MoSCoW priority]
### Non-Functional Requirements
[Table with measurable targets]
### Constraints
[Table with negotiability]
### Assumptions
[Table with risk levels]
### Anti-Requirements
[What the system must NOT do]
### Hidden Requirements Discovered
[From Step 4 prompts]
### Conflicts & Resolutions
[Table of conflicts with resolutions]
### Priority Summary
MUST: [N] | SHOULD: [N] | COULD: [N] | WON'T: [N]
### Open Questions
[Requirements that need stakeholder input to resolve]Quality Checklist
Before completing:
- System boundary defined
- All stakeholder types considered (including hidden)
- All requirement categories covered (functional, non-functional, constraints, assumptions, anti-requirements)
- Hidden requirements prompts applied
- Conflicts identified and resolution proposed
- MoSCoW prioritization applied
- MUST-HAVE requirements pass quality check
- Open questions listed
Next Steps
After requirements:
- Use
/deto identify dependencies between requirements - Use
/toto sequence implementation - Use
/dcpto create decision procedure for requirement conflicts - Use
/flato anticipate implementation failures