requirements-documentlisted

## What this skill does Generates a Business Requirements Document (BRD) or Functional Requirements Specification (FRS) skeleton populated from the user's input. It structures requirements with unique IDs, priority, source, and acceptance notes — making them traceable and reviewable. ## When to use it - User asks to "write a requirements document", "produce a BRD", or "create a functional spec". - A project needs formal requirements sign-off before design or build begins. - Requirements must be traceable to use cases, test cases, or regulatory obligations. - User wants to consolidate user stories, use cases, and constraints into a single document. ## Key concepts ### BRD vs. FRS | | BRD — Business Requirements Document | FRS — Functional Requirements Specification | | --- | --- | --- | | **Audience** | Business stakeholders, project sponsors | Solution architects, developers, testers | | **Focus** | What the business needs and why | What the system must do | | **Language** | Business language | Technical/functional language | | **Produced by** | Business analyst | Functional/technical analyst | | **Input to** | FRS, project charter | Design specs, test plans | This skill produces **both in a single document** unless the user specifies one type only. ### Requirement types | Type | Description | Prefix | | --- | --- | --- | | Business requirement | High-level business need or goal | BR- | | Functional requirement | Specific system behaviour | FR- | | Non-functional req