aiup/aiup-core
AI Unified Process - stack-agnostic core methodology (requirements, entity model, use cases)
93
95%
Does it follow best practices?
Impact
93%
1.43xAverage score across 10 eval scenarios
Passed
No known issues
SKILL.mdskills/requirements/
- name:
- requirements
- description:
- Gathers, organizes, and documents software requirements into structured catalogs with functional requirements (user stories), non-functional requirements (measurable quality attributes), and constraints. Use when the user asks to "write requirements", "create a PRD", "gather requirements", "document feature specs", "write user stories", "define NFRs", "list constraints", or mentions requirements catalog, requirements analysis, product requirements document, or feature specification.
Requirements
Instructions
Create or update the requirements catalog at docs/requirements.md based on docs/vision.md.
The document contains functional requirements, non-functional requirements, and constraints organized as Markdown
tables.
DO NOT
- Mix requirement types in a single table
- Skip the user story format for functional requirements
- Use duplicate IDs across requirement types
- Leave the Status column empty
Requirement Types
Functional Requirements (FR)
Define what the system should do. Always use the user story format:
Format: As a [role], I want [goal] so that [benefit].
| ID | Title | User Story | Priority | Status |
|---|---|---|---|---|
| FR-001 | Create Task | As a project manager, I want to create tasks so that I can track work items. | High | Open |
| FR-002 | Assign Task | As a project manager, I want to assign tasks to team members so that work is distributed. | High | Open |
| FR-003 | Filter Tasks | As a team member, I want to filter tasks by status so that I can focus on relevant items. | Medium | Open |
Non-Functional Requirements (NFR)
Define quality attributes. Must be measurable.
| ID | Title | Requirement | Category | Priority | Status |
|---|---|---|---|---|---|
| NFR-001 | Response Time | All page loads must complete within 2 seconds. | Performance | High | Open |
| NFR-002 | Availability | System must maintain 99.9% uptime during business hours. | Availability | High | Open |
| NFR-003 | Concurrent Users | System must support 100 concurrent users without degradation. | Scalability | Medium | Open |
| NFR-004 | Data Encryption | All data in transit must use TLS 1.3 encryption. | Security | High | Open |
Constraints (C)
Define limitations and boundaries imposed on the solution.
| ID | Title | Constraint | Category | Priority | Status |
|---|---|---|---|---|---|
| C-001 | Runtime Platform | Backend must run on Java 21 LTS. | Technical | High | Open |
| C-002 | Database Platform | System must use PostgreSQL 16. | Technical | High | Open |
| C-003 | Browser Support | UI must support Chrome, Firefox, and Safari (latest 2 versions). | Technical | High | Open |
| C-004 | Budget Limit | Total development cost must not exceed $50,000. | Business | High | Open |
| C-005 | Deadline | System must be production-ready by Q2 2025. | Schedule | High | Open |
Reference
See references/REFERENCE.md for ID prefixes, priority levels, status values, NFR categories, and constraint categories.
Requirement Quality Checks
Every requirement must pass these checks before finalizing:
| Check | Rule | Bad Example | Good Example |
|---|---|---|---|
| Measurable | NFRs must have a number or threshold | "System should be fast" | "Pages load within 2 seconds" |
| Singular | One requirement per row | "System must log in and export data" | Split into FR-001 and FR-002 |
| Unambiguous | No subjective terms | "User-friendly interface" | "WCAG 2.1 AA compliant" |
| Testable | Can write a pass/fail test | "System is reliable" | "99.9% uptime over 30 days" |
| Unique IDs | No duplicate IDs across all tables | Two FR-001 entries | Each ID used exactly once |
Error Recovery
- Incomplete source document: List what is missing (roles, NFR categories, constraints) and ask the user to clarify before proceeding
- Ambiguous requirement from user: Rewrite it as a measurable requirement and ask the user to confirm the threshold
- Conflicting requirements: Flag the conflict explicitly (e.g., "FR-003 requires real-time sync but C-002 limits to batch processing") and ask the user to resolve
- Missing stakeholder roles: Default to generic roles (User, Admin, System) and note them for user review
Format survives error recovery. Ambiguity, conflict, and provisional status never justify abandoning the user-story form. Every FR row — even one you are flagging as conflicting or unconfirmed — must still read "As a [role], I want [goal] so that [benefit]." Record the issue in a note or in the Status column (e.g.,
Conflict,Needs review); never by dropping the requirement to a flat statement like "Support real-time sync."
Workflow
- Read the vision document or project brief
- Use TodoWrite to create tasks for each requirement type
- Write the document header
- For functional requirements:
- Identify user roles
- Define user stories with clear goals and benefits
- Assign priorities based on business value
- For non-functional requirements:
- Define measurable quality attributes
- Categorize by NFR type
- Ensure requirements are testable
- For constraints:
- Document technical and business limitations
- Categorize by constraint type
- Validate: run every requirement against the quality checks table above
- No duplicate IDs across all tables
- All Status columns filled
- Hard gate: every FR User Story matches "As a [role], I want [goal] so that [benefit]" — scan each row; any row missing "As a", "I want", or "so that" is rejected and rewritten before finalizing, no exceptions
- All NFRs contain a measurable threshold
- Mark todos complete