aiskillstore Requirements Elicitation Skill
Overview
This skill provides structured techniques for gathering, analyzing, and documenting software requirements from stakeholders and existing systems.
Elicitation Techniques
1. Structured Interviews
Use predefined question sets organized by category:
- Start with open-ended questions to understand context
- Follow with specific questions to gather details
- End with validation questions to confirm understanding
2. Adaptive Questioning
Dynamically adjust questions based on:
- Previous answers provided
- Domain context discovered
- Gaps identified in requirements
- Stakeholder role and expertise level
3. Document Analysis
Extract requirements from existing:
- Business process documents
- User manuals
- Training materials
- Support tickets and feedback
4. Observation
Understand requirements by observing:
- Current system usage
- User workflows
- Pain points and workarounds
Requirement Categories
Functional Requirements (FR)
What the system must DO:
- Features and capabilities
- Business rules and logic
- Data processing requirements
- User interactions
Non-Functional Requirements (NFR)
How the system must BEHAVE:
FURPS+ Model
- Functionality: Security, compliance
- Usability: Accessibility, learnability
- Reliability: Availability, fault tolerance
- Performance: Response time, throughput
- Supportability: Maintainability, testability
- +Constraints: Design, implementation, interface
Constraints
Limitations on the solution:
- Budget constraints
- Timeline constraints
- Technology constraints
- Regulatory constraints
- Resource constraints
Assumptions
Conditions assumed to be true:
- User capabilities
- Infrastructure availability
- Third-party dependencies
- Business conditions
Prioritization Methods
MoSCoW Method
- Must Have: Critical for success, non-negotiable
- Should Have: Important but not critical
- Could Have: Nice to have, low impact if absent
- Won't Have: Out of scope for current release
Value vs Effort Matrix
High Value + Low Effort = Do First (Quick Wins)
High Value + High Effort = Do Second (Major Projects)
Low Value + Low Effort = Do Later (Fill-ins)
Low Value + High Effort = Don't Do (Time Wasters)
Gap Analysis Process
- Document As-Is State: Current capabilities
- Define To-Be State: Desired capabilities
- Identify Gaps: Missing capabilities
- Prioritize Gaps: By business value
- Create Requirements: To close gaps
Validation Techniques
Requirement Quality Checks
Each requirement should be:
- Complete: All necessary information included
- Consistent: No conflicts with other requirements
- Unambiguous: Single clear interpretation
- Verifiable: Can be tested/measured
- Traceable: Linked to business objective
SMART Criteria
- Specific: Clear and precise
- Measurable: Quantifiable success criteria
- Achievable: Technically feasible
- Relevant: Aligned with business goals
- Time-bound: Has timeline context
INVEST Criteria (for User Stories)
- Independent: Can be developed separately
- Negotiable: Open to discussion
- Valuable: Delivers user/business value
- Estimable: Can be sized
- Small: Fits in a sprint
- Testable: Has clear acceptance criteria
Stakeholder Analysis
Stakeholder Categories
- End Users: Direct system users
- Business Owners: Decision makers
- Technical Team: Developers, architects
- Operations: Support, maintenance
- External: Regulators, partners, customers
Stakeholder Mapping
For each stakeholder identify:
- Role and responsibilities
- Interest level (High/Medium/Low)
- Influence level (High/Medium/Low)
- Key concerns and priorities
- Communication preferences
Output Artifacts
Requirements List
| ID | Category | Description | Priority | Status |
|----|----------|-------------|----------|--------|
| FR-001 | Functional | User can login with email | Must | Confirmed |
| NFR-001 | Performance | Page load < 3 seconds | Should | Pending |
User Story Format
As a [role]
I want [capability]
So that [business value]
Acceptance Criteria:
- Given [context]
- When [action]
- Then [outcome]
Requirement Traceability
Business Objective -> Requirement -> User Story -> Test Case
See question-templates.md for structured interview questions.