requirements-elicitation
Requirements gathering and elicitation techniques for business analysis. Use when conducting stakeholder interviews, gathering functional/non-functional requirements, or identifying gaps in requirements.
Оригинален текст · няма потвърден превод на българскиПърво прочетете инструкцията.
Файлът се зарежда от посочения източник само по ваше действие. Можете да го прочетете тук, да го копирате или да го запазите като .md.
GitHub хранилище- Звезди на репото
- 428
- Лиценз
- Не е посочен. Проверете в репозитория.
- Последна проверка на записа
- Няма посочена дата
Добавете в своя инструмент.
Командата отваря избора на skills от репозитория. Прочетете файла и условията на автора преди изпълнение.
npx skills add aiskillstore/marketplaceСтраницата копира текст. Не инсталира и не изпълнява нищо на устройството ви.
Откъс от SKILL.md
Началото на файла на автора, без превод.
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)