Requirements Gathering

Reasoning Schema

Before elicitation: feature being defined, user inputs available, context from project, known constraints.

After elicitation: all four archetypes consulted, requirements structured, assumptions explicit, validation criteria defined.

Invariant Principles

1. Four Perspectives Are Mandatory: Every requirement set must address Queen, Emperor, Hermit, and Priestess.
2. Ambiguity Is Debt: Vague requirements become bugs. Demand specificity.
3. Explicit Over Implicit: Unstated assumptions are hidden requirements. Surface them.
4. User Value Anchors Everything: Features without clear user value are scope creep.
5. Constraints Shape Solutions: Understanding limits early prevents wasted design.

Inputs / Outputs

The Four Perspectives

Queen: User Needs

Who are the users? What problem is solved? What does success look like? User stories: "As a [type], I want [capability] so that [benefit]"

Emperor: Constraints

Technical constraints (stack, platform). Resource constraints (time, team). Integration requirements. Performance targets (latency, throughput).

Hermit: Security Surface

What sensitive data? Auth required? Attack vectors? Compliance requirements? What if compromised?

Priestess: Scope Boundaries

What's IN scope? What's OUT of scope (with reasons)? Edge cases to handle vs defer? What assumptions are we making?

Fractal exploration (optional): When perspectives produce contradictory requirements, invoke fractal-thinking with intensity pulse and seed: "How can [requirement A] and [constraint B] be reconciled?". Use the synthesis to present Pareto-optimal requirement resolution options.

Elicitation Process

1. Initial Extraction: Parse description for explicit requirements, implicit requirements, constraints, unknowns
2. Perspective Analysis: Apply each lens, generate questions, answer from context, flag UNKNOWN
3. Gap Identification: Questions without answers, assumptions without validation, conflicts
4. User Clarification: Present questions (one at a time) or document gaps as UNKNOWN for roundtable
5. Document Generation: Generate requirements with all four perspectives

Requirements Document Structure

# Requirements: [Feature Name]

## Overview
[2-3 sentence summary]

## User Needs (Queen)
- Primary users, problem statement, user stories, success criteria

## Constraints (Emperor)
- Technical, resource, integration, performance

## Security Surface (Hermit)
- Data classification, auth, threat model, compliance

## Scope Boundaries (Priestess)
- In scope, out of scope (with reasons), edge cases, assumptions

## Functional Requirements
| ID | Requirement | Priority | Source |

## Open Questions
- [ ] [Question] (Blocker: yes/no)

Example

Queen (User Needs):

• Users want single sign-on with existing Google/GitHub accounts
• Success: Login < 5 clicks, no separate password

Emperor (Constraints):

• Must use existing FastAPI backend
• Timeline: 1 sprint
• Must support mobile and web

Hermit (Security):

• Handles: email, profile (PII)
• Auth: OAuth 2.0 with PKCE
• Threats: Token theft → short expiry + refresh rotation

Priestess (Scope):

• IN: Google, GitHub OAuth
• OUT: Apple Sign-in (future), password fallback (intentional)
• Assumption: Users have Google/GitHub accounts

Quality Gates

Self-Check

• All four perspectives addressed
• Requirements specific and measurable
• Scope boundaries explicit (in AND out)
• Security surface documented
• Open questions marked blocking or non-blocking
• Roundtable feedback addressed (if any)

If ANY unchecked: revise before returning.

<FINAL_EMPHASIS> Requirements are the foundation. Queen ensures we build what users need. Emperor ensures we build within constraints. Hermit ensures we build securely. Priestess ensures we build the right scope. All four perspectives, every time. </FINAL_EMPHASIS>