Pro Requirements Workspace

A structured skill for gathering, organizing, and managing software requirements. Pro Requirements Workspace guides you through stakeholder interviews, user story creation, acceptance criteria definition, and requirements traceability — producing documentation that development teams can immediately act on.

When to Use This Skill

Choose Pro Requirements Workspace when:

• Starting a new project and need to capture stakeholder needs systematically
• Translating business objectives into technical requirements with acceptance criteria
• Building a requirements traceability matrix linking features to business goals
• Preparing specifications for handoff between product and engineering teams

Consider alternatives when:

• You need project management tracking (use a dedicated PM tool)
• Requirements are already well-defined and you need implementation planning (use a planning skill)
• You're working on bug fixes rather than feature development

Quick Start

Copy
claude "Gather requirements for a user authentication system with SSO support"

Copy
# Requirements Document: User Authentication System

## Stakeholders
| Role | Name | Concerns |
|------|------|----------|
| Product Owner | — | Time to market, user adoption |
| Security Lead | — | Compliance, vulnerability surface |
| Engineering | — | Implementation complexity, maintenance |

## Functional Requirements

### FR-001: Email/Password Authentication
**Priority:** P0 (Must Have)
**User Story:** As a user, I want to sign up with email and password so I can access the platform.
**Acceptance Criteria:**
- [ ] Password minimum 12 characters with complexity rules
- [ ] Email verification required before first login
- [ ] Rate limiting on failed attempts (5 per 15 minutes)
- [ ] Password reset flow via email token (expires in 1 hour)

### FR-002: SSO Integration
**Priority:** P0 (Must Have)
**User Story:** As an enterprise user, I want to log in with my company SSO so I don't need separate credentials.
**Acceptance Criteria:**
- [ ] Support SAML 2.0 and OIDC protocols
- [ ] Auto-provision user accounts on first SSO login
- [ ] Map SSO groups to application roles

Core Concepts

Requirements Hierarchy

Level	Purpose	Example
Business Requirement	Why the project exists	"Reduce customer onboarding time by 50%"
User Requirement	What users need to do	"User can complete signup in under 2 minutes"
Functional Requirement	How the system behaves	"System validates email format on input"
Non-Functional Requirement	Quality attributes	"Page load time under 200ms at P95"

MoSCoW Prioritization

Copy
## Priority Matrix

### Must Have (P0)
- Core authentication flow
- Data encryption at rest and in transit
- Audit logging for compliance

### Should Have (P1)
- Social login providers (Google, GitHub)
- Remember me functionality
- Session management dashboard

### Could Have (P2)
- Biometric authentication
- Login analytics dashboard

### Won't Have (This Release)
- Hardware key support (deferred to v2)

Traceability Matrix

Copy
| Req ID | Business Goal | Feature | Test Case | Status |
|--------|--------------|---------|-----------|--------|
| FR-001 | Secure access | Email auth | TC-001..TC-008 | Draft |
| FR-002 | Enterprise sales | SSO | TC-009..TC-015 | Draft |
| NFR-001 | Performance SLA | Load time | TC-016..TC-018 | Draft |

Configuration

Parameter	Description	Default
prioritization_method	MoSCoW, RICE, or Kano	MoSCoW
template_format	Output format for requirements docs	markdown
include_acceptance_criteria	Auto-generate acceptance criteria	true
traceability	Generate traceability matrix	true
stakeholder_analysis	Include RACI chart	false

Best Practices

1. Start with business goals, not features. Every functional requirement should trace back to a measurable business objective — if it doesn't serve a goal, question whether it belongs in scope.

2. Write acceptance criteria as testable statements. Use "Given/When/Then" or checkbox format so QA can verify requirements without ambiguity. Vague criteria like "system should be fast" are not requirements.

3. Version your requirements document. Requirements evolve — maintain a changelog with dates and rationale for changes so the team understands why scope shifted.

4. Separate functional from non-functional requirements. Performance targets, security constraints, and accessibility standards deserve their own section — they cut across all features and are easy to overlook when buried in user stories.

5. Involve stakeholders early and often. Requirements written in isolation miss edge cases. Schedule review sessions after drafting each major section, not just at the end.

Common Issues

Requirements are too vague to implement. Replace subjective language with measurable criteria. Instead of "the system should handle high traffic," specify "the system must support 10,000 concurrent users with P99 latency under 500ms." Every requirement should answer: what, for whom, and how you'll verify it.

Scope creep during development. Freeze requirements after stakeholder sign-off and use a formal change request process. Track each change with business justification, impact assessment, and updated timeline. A simple "CR-001" numbering system with approval workflows prevents undocumented scope additions.

Missing non-functional requirements. Create a checklist covering performance, security, accessibility, scalability, reliability, and compliance before marking requirements as complete. Non-functional requirements are the ones that cause the most expensive rework when discovered late.