Requirements Analyst

Expert guidance for gathering, analyzing, and documenting software requirements to ensure successful project outcomes.

When to Use This Skill

Starting a new project or feature
Gathering requirements from stakeholders
Writing user stories and acceptance criteria
Creating feature specification documents
Breaking down epics into smaller tasks
Defining MVP scope and feature prioritization
Clarifying ambiguous requirements

Requirements Gathering Process

1. Stakeholder Identification

Before gathering requirements, identify all stakeholders:

Primary users: Who will use the software daily?
Secondary users: Who will use it occasionally?
Administrators: Who will manage/configure the system?
Business owners: Who is funding/sponsoring the project?
Technical team: Who will build and maintain it?

2. Discovery Questions

Ask these questions to uncover requirements:

Problem Space

What problem are we solving?
Who experiences this problem?
How are users currently solving this problem?
What is the cost of not solving this problem?

Solution Space

What does success look like?
What are the must-have features vs nice-to-have?
What are the constraints (budget, timeline, technology)?
Are there existing systems we need to integrate with?

User Context

What devices/platforms will users access this from?
What is their technical proficiency level?
What accessibility requirements exist?
What are peak usage times/patterns?

User Story Format

Use this template for writing user stories:

As a [type of user],
I want [goal/desire],
So that [benefit/value].

User Story Examples

Good Example:

As a registered customer,
I want to save items to a wishlist,
So that I can easily find and purchase them later.

Poor Example:

As a user,
I want a wishlist feature,
So that I can use it.

User Story Checklist (INVEST)

Independent: Can be developed separately from other stories
Negotiable: Details can be discussed and refined
Valuable: Delivers value to the user or business
Estimable: Team can estimate the effort required
Small: Can be completed within one sprint
Testable: Clear criteria to verify completion

Acceptance Criteria

Write acceptance criteria using Given-When-Then format:

Given [precondition/context],
When [action/trigger],
Then [expected outcome].

Acceptance Criteria Example

For the wishlist user story:

Given I am logged in as a registered customer,
When I click "Add to Wishlist" on a product page,
Then the product is added to my wishlist,
And I see a confirmation message,
And the wishlist count increases by 1.

Given I have items in my wishlist,
When I view my wishlist page,
Then I see all saved items with their current prices,
And I can remove items or add them to cart.

Given I am not logged in,
When I click "Add to Wishlist",
Then I am prompted to log in or create an account.

Feature Specification Template

Use this template for detailed feature specs:

# Feature: [Feature Name]

## Overview
Brief description of the feature and its purpose.

## User Stories
- Story 1
- Story 2

## Functional Requirements
### FR-001: [Requirement Title]
Description of what the system must do.

### FR-002: [Requirement Title]
Description of what the system must do.

## Non-Functional Requirements
### Performance
- Response time expectations
- Concurrent user load

### Security
- Authentication requirements
- Data protection needs

### Accessibility
- WCAG compliance level
- Specific accessibility features

## User Interface
Mockup references or UI descriptions.

## Data Requirements
- Data to be collected
- Storage requirements
- Data retention policies

## Integration Points
External systems or APIs involved.

## Out of Scope
Explicitly list what is NOT included.

## Dependencies
Other features or systems this depends on.

## Open Questions
Unresolved items requiring clarification.

Epic Breakdown Strategy

When breaking down large features (epics) into smaller stories:

1. Workflow Steps

Break by steps in the user workflow:

Epic: "User Registration"
- Story: Email/password registration
- Story: Social login (Google)
- Story: Email verification
- Story: Profile completion

2. CRUD Operations

Break by data operations:

Epic: "Product Management"
- Story: Create new product
- Story: View product list
- Story: Edit product details
- Story: Delete product

3. User Roles

Break by different user types:

Epic: "Dashboard"
- Story: Admin dashboard
- Story: Manager dashboard
- Story: User dashboard

4. Business Rules

Break by variations in business logic:

Epic: "Checkout"
- Story: Standard checkout
- Story: Guest checkout
- Story: Subscription checkout

Prioritization Framework (MoSCoW)

Categorize requirements by priority:

Priority	Description	Guideline
Must Have	Critical for launch, non-negotiable	~60% of effort
Should Have	Important but not critical	~20% of effort
Could Have	Nice to have, can be deferred	~20% of effort
Won't Have	Out of scope for this release	Document for future

Requirements Documentation Tips

Be Specific: Avoid vague terms like "fast," "user-friendly," "intuitive"
Be Measurable: Include specific numbers where possible
Avoid Implementation Details: Focus on WHAT, not HOW
Include Rationale: Explain WHY each requirement exists
Version Control: Track changes to requirements over time
Traceability: Link requirements to tests and implementations

Common Pitfalls to Avoid

❌ Assuming you understand the user's needs without validation
❌ Mixing requirements with solutions
❌ Writing stories too large to estimate or deliver
❌ Missing edge cases and error scenarios
❌ Not involving technical team in refinement
❌ Incomplete acceptance criteria
❌ Scope creep without re-prioritization

Output Artifacts

When this skill is activated, I can help create:

User Story Document: Collection of well-formed user stories
Feature Specification: Detailed spec using the template above
Requirements Matrix: Traceability between requirements, stories, and tests
MVP Definition: Prioritized list of features for initial release
Questions List: Clarifying questions for stakeholders

requirements-analyst