Requirements Interview

A structured framework for transforming vague requests into actionable specifications.

Interview Framework

Phase 1: Context Understanding

Start with open questions to understand the big picture:

code

1. Goal: "What problem are you trying to solve?"
2. Users: "Who will use this feature?"
3. Success: "How will you know this is successful?"
4. Motivation: "Why is this needed now?"

Phase 2: Functional Requirements

Use trade-off questions (not open-ended):

Bad Question:

"What features do you want?"

Good Question:

"For user authentication, would you prefer:

•Social login (faster to implement, depends on third parties)

•Custom auth (more control, longer to build)

•Both (most flexibility, highest complexity)"

Question Templates

Technology Decisions

code

For [feature], would you prefer:
A) [Option A] - [Pros] but [Cons]
B) [Option B] - [Pros] but [Cons]
C) Let me recommend based on your constraints

Scope Boundaries

code

Should [feature] include:
- [Sub-feature 1]: Yes / No / Later
- [Sub-feature 2]: Yes / No / Later
- [Sub-feature 3]: Yes / No / Later

Priority

code

Rank these by importance (1-5):
- [ ] Feature A
- [ ] Feature B
- [ ] Feature C

Phase 3: Non-Functional Requirements

Gather constraints with specific options:

Performance

code

What response time is acceptable?
- Real-time (<100ms)
- Interactive (<500ms)
- Background (<2s)
- Async (minutes-hours)

Scale

code

How many concurrent users do you expect?
- Team (10-50)
- Departmental (50-500)
- Organization (500-5000)
- Public (5000+)

Availability

code

What uptime is required?
- Best effort (95%)
- Business hours (99%)
- Always available (99.9%)
- Critical (99.99%)

Security

code

What data sensitivity level?
- Public (no restrictions)
- Internal (employees only)
- Confidential (need-to-know)
- Restricted (regulated data)

Phase 4: Edge Cases

Ask about boundaries:

code

What should happen when:
- User has no internet connection?
- Data is invalid or malformed?
- User doesn't have permission?
- System is under heavy load?
- User cancels mid-operation?
- Concurrent edits occur?

Phase 5: Existing Constraints

Identify limitations:

code

Are there any constraints we need to work within?
- Existing systems to integrate with?
- Technology restrictions?
- Budget or time limits?
- Compliance requirements (GDPR, HIPAA, SOC2)?
- Team skill constraints?

Interview Checklist

Before concluding, verify:

• User personas identified
• Primary use cases documented
• Success metrics defined
• Functional requirements listed
• Non-functional requirements specified
• Edge cases considered
• Constraints documented
• Out-of-scope items clarified
• Dependencies identified

Output Format

After interview, produce this summary:

markdown

# Requirements Summary: [Feature Name]

## Context
- **Problem**: [What problem this solves]
- **Users**: [Target users]
- **Success Metric**: [How success is measured]

## Functional Requirements
| ID | Requirement | Priority |
|----|-------------|----------|
| FR-001 | User can... | P0 |
| FR-002 | System should... | P1 |

## Non-Functional Requirements
| Category | Requirement |
|----------|-------------|
| Performance | [Target] |
| Security | [Requirements] |
| Scalability | [Expectations] |

## Constraints
- [Constraint 1]
- [Constraint 2]

## Out of Scope
- [Item 1]
- [Item 2]

## Open Questions
- [Any remaining ambiguities]

## Next Steps
1. Review and approve requirements
2. Create detailed specification
3. Begin implementation planning

Tips for Effective Interviews

•Listen First: Let the user explain before asking specific questions
•Summarize Often: "So what I'm hearing is..." to confirm understanding
•Avoid Jargon: Use plain language unless user is technical
•Document Everything: Even "obvious" requirements
•Ask "Why": Understand motivation, not just requests
•Offer Trade-offs: Present options with pros/cons
•Be Patient: Good requirements take time

Common Pitfalls to Avoid

Pitfall	Why It's Bad	Instead
Leading questions	Biases answers	Ask neutrally
Yes/No only	Misses nuance	Ask for context
Assuming expertise	Confuses users	Define terms
Skipping NFRs	Incomplete spec	Always ask
Rushing	Misses details	Take time

Rules (L1 - Hard)

Critical for requirements accuracy. Violations lead to incorrect implementations.

•ALWAYS use AskUserQuestion tool when gathering requirements (prevents assumptions)
•NEVER assume requirements that weren't stated (assumptions cause rework)
•NEVER skip non-functional requirements (incomplete spec)
•ALWAYS get explicit scope confirmation before proceeding
•NEVER proceed with open questions (ambiguity causes wrong decisions)
•MUST invoke AskUserQuestion for each interview phase (Context, Functional, Non-Functional, Edge Cases, Constraints)

Defaults (L2 - Soft)

Important for quality. Override with reasoning when appropriate.

•Document trade-offs discussed during the interview
•Summarize understanding back to user before concluding
•Use structured question templates (can adapt for context)
•Produce requirements summary in the specified format

Guidelines (L3)

Recommendations for better interviews.

•Consider asking "why" to understand motivation, not just requests
•Prefer trade-off questions over open-ended ones
•Consider documenting even "obvious" requirements
•Use plain language unless user is technical