agentsclimarketplace

Requirements elicitation

Skill bg-szy/TOP-SKILLS/skills/marketplace/requirements-elicitation

全球最大的 Claude Code 技能聚合库 · 收录 3900+ 来自 12+ 来源的技能，提供在线搜索与趋势分析看板 / The world's largest Claude Code skill aggregation hub — 3900+ skills from 12+ sources with online search and trend dashboard

Install
npx -y skills add bg-szy/TOP-SKILLS --skill requirements-elicitation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Requirements gathering and elicitation techniques for business analysis. Use when conducting stakeholder interviews, gathering functional/non-functional requirements, or identifying gaps in requirements.

SKILL.md

4.7 KB, as published. Nobody here has run it

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

  1. Document As-Is State: Current capabilities
  2. Define To-Be State: Desired capabilities
  3. Identify Gaps: Missing capabilities
  4. Prioritize Gaps: By business value
  5. 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

  1. End Users: Direct system users
  2. Business Owners: Decision makers
  3. Technical Team: Developers, architects
  4. Operations: Support, maintenance
  5. 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.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.