requirements-definition

name	Requirements Definition
description	This skill should be used when the user asks to "define requirements", "create specification", "clarify requirements", "write requirements document", or mentions requirement analysis. Provides comprehensive requirements definition methodology.
version	0.1.0

Provide structured methodology for requirements definition, ensuring comprehensive specification before implementation. Directory structure analysis Symbol analysis via Serena Keyword search Symbol search via Serena Dependency mapping via Serena Specific content details Latest API documentation and best practices Sequential investigation process for gathering requirements context Directory structure analysis using Glob Symbol analysis using get_symbols_overview Keyword search using Grep or find_symbol Dependency mapping using find_referencing_symbols Specific content details using Read Latest API documentation using Context7 Score each question by these criteria (1-5 each) to prioritize requirement clarification How much does the answer affect design direction? How difficult to change after implementation? Cannot be determined through code investigation alone? How much does it affect implementation effort? Present high-score questions first. Do not proceed without clear answers to critical questions (score >= 15) Question: "Should we use TypeScript's strict mode?" - Design Branching: 5 (affects all type decisions) - Irreversibility: 4 (hard to change later) - Investigation Impossibility: 3 (requires policy decision) - Effort Impact: 4 (affects development effort) Total: 16 (critical - must answer before proceeding) Categories of questions that arise during requirements definition Confirming existing behavior or constraints Choosing between valid alternatives Technical or business limitations Boundaries of implementation Order and importance of features - Spec Confirmation: "Does the API return null or empty array for no results?" - Design Choice: "Should we use REST or GraphQL?" - Constraint: "Must support IE11 browsers?" - Scope: "Should admin features be included in v1?" - Priority: "Which feature should be implemented first?" Format functional requirements with clear identifiers and acceptance criteria FR-001: User Authentication Priority: mandatory - Users must be able to log in with email and password - Session must expire after 24 hours of inactivity - Failed login attempts must be rate-limited (max 5 per hour) Specify measurable non-functional requirements across key dimensions Performance: - API response time < 200ms for 95th percentile - Support 1000 concurrent users

Security:

• All data encrypted at rest using AES-256
• JWT tokens for authentication

Maintainability:

• Test coverage >= 80%
• Documentation for all public APIs

Document design policies, patterns, and key decisions with rationale Design Decision: Use React Query for data fetching Rationale: - Built-in caching reduces API calls - Automatic background refetching - TypeScript support - Widely adopted in existing codebase

Impact Scope:

• All components making API calls
• Testing utilities need to mock React Query

Quantitative measures of requirement quality Feasibility (0-100): Technical achievability given constraints - 90-100: Straightforward with existing tools - 70-89: Requires some research or new libraries - 50-69: Significant technical challenges - Below 50: May need architecture changes

Objectivity (0-100): Evidence-based vs. assumption-based

• 90-100: All requirements verified through investigation
• 70-89: Most requirements verified, some assumptions documented
• 50-69: Mix of verification and assumptions
• Below 50: Mostly assumptions, needs more investigation

- One-sentence request description - Background and context - Expected outcomes

- Existing system description - Technology stack - Relevant patterns and conventions Format: FR-XXX (FR-001, FR-002, ...) - Priority: mandatory or optional - Clear acceptance criteria - Performance: response time, throughput - Security: authentication, authorization, data protection - Maintainability: code quality, documentation - Design policies and patterns - Impact scope analysis - Key design decisions with rationale - Feasibility (0-100): Technical achievability - Objectivity (0-100): Evidence-based specification - Technical constraints: platform, language, framework - Operational constraints: deployment, maintenance - Unit test coverage expectations - Integration test scenarios - Acceptance criteria verification - Dependency graph: task dependencies and execution order - Phased tasks: files to modify/create, overview of changes, dependencies - Execute handoff: key decisions, reference implementations, constraints Never proceed without clear answers to critical questions (score >= 15) All requirements must be verifiable and measurable Distinguish mandatory from optional requirements Present high-score questions first in requirement discussions Document assumptions explicitly when requirements are unclear Include rationale for key design decisions Map requirements to test scenarios

<best_practices> Always investigate current state before defining requirements using Serena's symbol-level operations Score questions using the 4-criteria scoring system and prioritize high-score questions (>= 15) Clearly distinguish mandatory from optional requirements with explicit rationale Document all assumptions when requirements are unclear or incomplete Map each requirement to specific test scenarios for verification Include rationale for key design decisions in technical specifications Use Context7 to verify latest library documentation and best practices Create dependency graphs showing task execution order </best_practices>

<anti_patterns> Requirements that are unclear or unmeasurable Write specific, testable requirements with clear acceptance criteria Specifying implementation details instead of requirements Describe what needs to be achieved, not how to implement it Writing requirements without investigating existing code Always investigate current state before defining requirements Not identifying technical or operational constraints Explicitly document all constraints that affect implementation Treating all requirements as equally important Clearly mark requirements as mandatory or optional with rationale </anti_patterns>