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	2.0.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 Is the current system state unclear or unknown? Apply investigation workflow to gather context before requirements definition Proceed directly to functional requirements if context is clear 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 Have unclear or ambiguous requirements been identified? Apply question scoring to prioritize critical clarifications Proceed with documenting clear requirements 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 Do you need to categorize questions for stakeholder communication? Apply question classification to organize by type Use question scoring to prioritize by impact 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 Are feature behaviors and capabilities clearly defined? Apply functional requirements format with acceptance criteria Use question scoring to clarify unclear behaviors first 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 Are quality attributes and constraints important for this feature? Apply non-functional requirements with measurable targets Focus on functional requirements only 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
</example>

Document design policies, patterns, and key decisions with rationale Have key technical decisions been made or identified? Apply technical specifications pattern with rationale and impact analysis Continue requirements gathering to identify decision points 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
</example>

Quantitative measures of requirement quality Are all requirements documented and ready for handoff? Apply quality metrics to assess requirement completeness Continue requirements definition until complete 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
</example>

- 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

<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>

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

<error_escalation> Minor ambiguity in non-critical detail Note in report, proceed Unclear requirement affecting scope Document issue, use AskUserQuestion for clarification Technically infeasible requirement STOP, present options to user Requirement violates security or ethics BLOCK operation, require explicit user acknowledgment </error_escalation>

Investigate before concluding Ask questions before making assumptions Include (Recommended) option in AskUserQuestion Proceeding without answering critical questions Justifying user preferences over technical validity Documenting requirements without evidence

<related_skills> Use to understand current system state before requirements definition Use after requirements approval to delegate implementation Use to define test requirements and acceptance criteria </related_skills>