Functional Requirements Command¶

The /functional-requirements command generates comprehensive Functional Requirements Documents (FRDs) with story point estimates and Teamwork-ready CSV backlogs.

Overview¶

Command: /functional-requirements

Purpose: Transform project ideas into detailed, actionable FRDs that serve both as client-facing documentation and developer-ready specifications.

Outputs: - Functional Requirements Document (Markdown) - Teamwork CSV Backlog (CSV)

Usage¶

Basic Usage¶

/functional-requirements

Claude will start an interactive discovery process, asking questions about: - Business objectives and success metrics - Target users and their needs - Technical constraints and architecture - Team composition and timeline - Feature priorities and scope

With Inline Context¶

/functional-requirements

I'm building a healthcare website for a hospital system.

**Platform**: Drupal CMS 2.0+, Drupal Core 11.3+
**Architecture**: Recipe-based with Saplings collection
**Features**: Provider directory, services, locations, events, news, alerts, departments, internal resources
**Team**: 3 developers, ~28 points/sprint
**Timeline**: Launch at DrupalCon Chicago (February 2026)
**Compliance**: WCAG 2.2 Level AA, HIPAA-aware (no PHI storage)

The command will acknowledge provided information and only ask about missing details.

Discovery Process¶

The command guides you through project discovery with questions about:

1. Business Objectives¶

• What problems does this project solve?
• What are the key success metrics?
• What business value will it deliver?
• What is the target launch date?

2. Target Users¶

• Who are the primary users?
• What are their goals and pain points?
• What user roles are needed?
• What are their technical capabilities?

3. Technical Requirements¶

• What platform/framework? (Drupal, WordPress, Laravel, etc.)
• What specific versions?
• What architecture patterns? (recipe-based, microservices, monolithic)
• What existing systems need integration?
• What third-party services are required?

4. Compliance & Standards¶

• What accessibility standards? (WCAG 2.1 AA, WCAG 2.2 AA)
• What regulatory requirements? (HIPAA, GDPR, etc.)
• What security standards?
• What performance requirements?

5. Team & Timeline¶

• How many developers?
• What is the estimated sprint velocity?
• Full-time or part-time resources?
• Any timeline constraints?
• Budget considerations?

6. Scope & Priorities¶

• What features are must-have?
• What features are should-have?
• What features are nice-to-have?
• What's in MVP vs future phases?

Generated FRD Structure¶

The command generates a comprehensive FRD with these sections:

Executive Summary¶

• Project vision and objectives
• High-level scope and deliverables
• Expected business value
• Target launch date/milestone

Technical Requirements¶

• Platform & Architecture overview with specific versions
• Technology stack with justifications
• Architecture patterns (e.g., recipe-based, microservices)
• Module/package dependencies
• Third-party integrations and APIs
• Performance requirements and SLAs
• Security requirements and data protection
• Development environment setup

Functional Requirements¶

• Numbered requirements (FR-001, FR-002, etc.)
• User stories with acceptance criteria
• Feature specifications with priority levels
• User roles and permissions matrix
• Business logic and workflow descriptions
• For recipe-based projects: Recipe structure and dependencies

User Interface Requirements¶

• Key user flows and wireframes descriptions
• Responsive design requirements
• Accessibility standards (WCAG compliance level)
• Branding and design system considerations
• Theme/styling approach

Data Requirements¶

• Data models and entity relationships
• Data validation rules
• Storage and backup requirements
• Data migration needs (if applicable)
• Demo/sample data requirements

Non-Functional Requirements¶

• Performance benchmarks (Lighthouse, Core Web Vitals)
• Scalability considerations
• Browser/device compatibility
• Availability and uptime requirements
• SEO requirements

Implementation Plan¶

• Phased delivery approach with milestones
• Epic and story breakdown structure
• Dependencies and critical path
• Risk assessment matrix
• Team velocity assumptions
• Total story points by phase

Testing Requirements¶

• Test scenarios and acceptance criteria
• Performance testing benchmarks
• Accessibility testing requirements
• Security testing requirements
• Cross-browser/device testing
• UAT process and timeline

Risk Assessment¶

• Technical risks (integrations, dependencies, performance)
• Project risks (resources, timeline, scope)
• Mitigation strategies
• Likelihood and impact assessment

Success Criteria¶

• Functional Success: Features implemented, acceptance criteria met
• Technical Success: Performance, accessibility, security benchmarks met
• Business Success: Timeline, budget, stakeholder satisfaction

Appendices¶

• Dependency diagrams
• Field storage matrices (for recipe-based projects)
• View lists
• Glossaries

Story Point Estimation¶

The command uses Fibonacci sequence estimation:

Velocity Calculation¶

The FRD includes sprint velocity calculation:

(Team size × Hours per sprint × Productive %) / Hours per point

Example: - 3 developers - 80 hours per sprint (2 weeks) - 70% productive time - 6 hours per story point on average

Calculation: 3 × 80 × 0.70 / 6 = 28 points per sprint

CSV Backlog Export¶

The command generates a Teamwork-ready CSV with:

CSV Columns¶

• Tasklist: Phase grouping (e.g., "Phase 1: Setup")
• Task: Task name with hierarchy and story points
• Description: Complete ticket template with user story
• Assign to: Email (initially blank)
• Start date: Date (initially blank)
• Due date: Date (initially blank)
• Priority: high/medium/low
• Estimated time: Hours (initially blank)
• Tags: SP-X (story points), Phase-X (phase)
• Status: Active for all new tasks

Task Hierarchy¶

[EPIC] Feature Name [21 points]
- [STORY] Sub-feature [8 points]
-- [TASK] Specific work [3 points]
-- [TASK] More work [2 points]
- [STORY] Another sub-feature [5 points]
-- [TASK] Implementation [3 points]

Ticket Description Template¶

Each task includes a complete description:

## Description
> As a [user type], I need to [action] so that [benefit].

## Working With this Epic
[Integration branch workflow]

## Acceptance Criteria
* Specific testable criteria

## Assumptions
* Known constraints or issues

## Steps to Validate
1. Explicit validation steps

## Affected URL
[link_to_test_site]

## Designs
- Desktop
- Mobile

## Helpful Resources
[Links and references]

## Technical Details
[Implementation specifics]

## Deployment Notes
[Post-launch requirements]

Recipe-Based Project Support¶

For Drupal recipes and similar architectures, the command provides special handling:

Recipe Structure Guidelines¶

• Recipes must be self-contained with ALL related config entities
• Include: content types, fields, taxonomies, views, pathauto, metatag, image styles
• Do NOT include simple config (core.extension.yml, system.site.yml)
• Use flat naming: [project]_[feature] (e.g., saplings_person)
• Master recipe installs all dependencies and demo content

Shared Field Storage Documentation¶

The FRD includes: - Which recipes create shared field storage - Map of field reuse across content types - Installation order based on dependencies - Dependency diagram in appendix

Example:

## FR-001: saplings_person Recipe [MUST HAVE]

**Creates Shared Fields:**
- field_phone (used by: Person, Location, Department)
- field_services (used by: Person, Location, Department, News)
- field_department (used by: Person, Service, Event, Internal Resource)

**Installation:** Must be installed before recipes that use these shared fields.

Recipe Dependencies¶

FRD includes: - Base platform recipes (e.g., Drupal CMS recipes) - Reusable recipe collection (e.g., Saplings recipes) - Master site template recipe - Theme separation (theme is NOT a recipe)

Examples¶

Example 1: Drupal Healthcare Site¶

Input:

/functional-requirements

Healthcare site for hospital system.
Platform: Drupal CMS 2.0+
Features: Provider directory, services, locations, events, news
Architecture: Recipe-based with Saplings
Team: 3 devs, 28 points/sprint
Launch: DrupalCon Chicago 2026

Output: - 68-page FRD with 8 functional requirements (one per recipe) - 8 implementation phases totaling 720 story points - Recipe dependency diagram - Shared field storage matrix - CSV with 31 epics across 8 phases

Example 2: WordPress Portfolio Site¶

Input:

/functional-requirements

WordPress portfolio site for design agency.
Features: Portfolio gallery, case studies, blog, contact
Team: 2 devs, 15 points/sprint
Timeline: 3 months
Design: Figma designs provided

Output: - FRD with WordPress-specific technical requirements - Custom post types and taxonomies - Block patterns and page templates - Performance requirements (Core Web Vitals) - 5 implementation phases - CSV with phased backlog

Tips & Best Practices¶

Provide Context Upfront¶

Give as much detail as possible in your initial request: - Platform and versions - Feature list - Team composition - Timeline - Architecture preferences

This reduces back-and-forth questions.

Reference Existing Documentation¶

/functional-requirements

Please review:
- README.md for project overview
- docs/architecture.md for technical stack
- docs/content-model.md for data structures

Then generate FRD incorporating these details.

Request Specific Focus¶

/functional-requirements

Focus on recipe-based architecture. Include:
- Detailed shared field storage documentation
- Recipe dependency diagram with installation order
- Demo content integration patterns

Iterative Refinement¶

After generating the initial FRD: 1. Review for accuracy and completeness 2. Ask for specific section updates 3. Request additional detail where needed 4. Refine story point estimates based on team feedback

Output File Locations¶

By default, files are saved to:

• FRD: docs/functional-requirements.md or docs/frd-[project-name].md
• CSV: [project-name]-backlog-teamwork.csv

You can specify custom locations:

/functional-requirements

Save FRD to requirements/project-spec.md
Save CSV to planning/teamwork-import.csv

Next Steps After Generation¶

1. Review FRD with stakeholders and team
2. Refine estimates based on team velocity history
3. Import CSV to Teamwork or other project management tool
4. Break down large epics (21+ points) into smaller stories
5. Begin sprint planning using phase-based organization

Related Documentation¶

• Quick Start Guide - Step-by-step tutorial
• Recipe Projects - Drupal recipe patterns
• Story Point Estimation - Detailed estimation guide
• Teamwork Import - CSV import instructions

Getting Help¶

• Documentation: https://kanopi.github.io/cms-planner/
• GitHub Issues: https://github.com/kanopi/cms-planner/issues
• Email: code@kanopi.com