Requirements Elicitation

Purpose

Systematically extract, clarify, and document requirements from stakeholders, project briefs, and domain analysis to establish a complete understanding of what the system must do.

When to Use

• Project initiation
• New feature requests
• Stakeholder interviews
• Analyzing competitor products
• Domain exploration

Prerequisites

• Access to stakeholders or project brief
• Understanding of project domain
• Elicitation techniques knowledge

Process

Step 1: Gather Initial Input

Collect from available sources:
- Project brief/description
- Stakeholder requests
- Existing documentation
- Competitor analysis
- Domain research

Step 2: Apply Elicitation Techniques

Techniques to use:
1. Questioning: Who, What, When, Where, Why, How
2. Scenarios: Walk through user journeys
3. Personas: Define user types and goals
4. Constraints: Identify limitations
5. Edge cases: What if X happens?

Step 3: Generate Clarifying Questions

For each vague or incomplete requirement:
- What is the expected behavior?
- Who is the primary user?
- What triggers this action?
- What is the success criteria?
- What happens in error cases?
- Are there constraints (time, data, access)?

Step 4: Document Raw Requirements

For each requirement capture:
- Source (who requested)
- Description (what is needed)
- Rationale (why it's needed)
- Priority indication
- Related requirements
- Open questions

Step 5: Validate Understanding

Confirm requirements by:
- Restating in different words
- Providing examples
- Identifying edge cases
- Checking against constraints
- Getting stakeholder confirmation

Inputs

Input	Type	Required	Description
project_brief	String	Yes	Initial project description
stakeholder_input	String	Optional	Direct stakeholder requests
domain_context	String	Optional	Industry/domain information

Outputs

Output	Type	Description
raw_requirements.md	Markdown	Unstructured requirements
clarifying_questions.md	Markdown	Questions needing answers
personas.md	Markdown	User personas identified
domain_glossary.md	Markdown	Domain terms defined

StudyAbroad-Specific Considerations

• User types: Prospective student, Current student, Advisor, Admin
• Journey stages: Discovery, Application, Preparation, Abroad, Return
• External integrations: Universities, visa services, housing
• Compliance: GDPR for EU students, FERPA for academic records
• Peak usage: Application deadlines, enrollment periods

Integration Points

• Orchestrator: Receives project brief
• Spec Kit: /speckit.specify command integration
• BMAD Analyst: Elicitation patterns
• Ralph Wiggum: /ralph-loop for iterative elicitation until requirements complete

Examples

Project Brief: "Build a study abroad application platform"

Elicitation Questions Generated:

Users:
- Q1: Who are the primary users? (Students, advisors, admins?)
- Q2: What student types? (Undergrad, grad, exchange?)
- Q3: Do advisors manage multiple students?

Features:
- Q4: What does "application" include? (Forms, documents, payments?)
- Q5: Is there a matching/recommendation system?
- Q6: How do students discover programs?

Integrations:
- Q7: Which university databases to integrate?
- Q8: Is visa status tracking needed?
- Q9: Housing search integration needed?

Constraints:
- Q10: What regions/countries supported?
- Q11: Mobile app or web only?
- Q12: Offline functionality needed?

Compliance:
- Q13: GDPR compliance required?
- Q14: Document retention policies?
- Q15: Data residency requirements?

Validation

• All ambiguous terms clarified
• No TBD items in final requirements
• Stakeholder sign-off on understanding
• Domain terms defined in glossary
• User personas documented