arckit-requirements
$
npx mdskill add tractorjuice/arc-kit/arckit-requirementsGenerate vendor-ready requirements from project context and policies.
- Transforms project inputs into structured business and technical specifications.
- Scans project directories, external docs, and global policies for context.
- Creates new project artifacts when no matching project exists.
- Outputs comprehensive requirements documents for RFP and review use.
SKILL.md
.github/skills/arckit-requirementsView on GitHub ↗
---
name: arckit-requirements
description: "Create comprehensive business and technical requirements"
---
You are helping an enterprise architect define comprehensive requirements for a project that will be used for vendor RFPs and architecture reviews.
## User Input
```text
$ARGUMENTS
```
## Instructions
> **Note**: Before generating, scan `projects/` for existing project directories. For each project, list all `ARC-*.md` artifacts, check `external/` for reference documents, and check `000-global/` for cross-project policies. If no external docs exist but they would improve output, ask the user.
1. **Identify the target project**:
- Use the **ArcKit Project Context** (above) to find the project matching the user's input (by name or number)
- If no match, create a new project:
1. Use Glob to list `projects/*/` directories and find the highest `NNN-*` number (or start at `001` if none exist)
2. Calculate the next number (zero-padded to 3 digits, e.g., `002`)
3. Slugify the project name (lowercase, replace non-alphanumeric with hyphens, trim)
4. Use the Write tool to create `projects/{NNN}-{slug}/README.md` with the project name, ID, and date — the Write tool will create all parent directories automatically
5. Also create `projects/{NNN}-{slug}/external/README.md` with a note to place external reference documents here
6. Set `PROJECT_ID` = the 3-digit number, `PROJECT_PATH` = the new directory path
2. **Read existing artifacts** from the project context:
**MANDATORY** (warn if missing):
- **STKE** (Stakeholder Analysis) — Extract: goals, priorities, drivers, conflict analysis, RACI matrix
- If missing: warn user to run `$arckit-stakeholders` first
**RECOMMENDED** (read if available, note if missing):
- **PRIN** (Architecture Principles, in 000-global) — Extract: technology standards, constraints, compliance requirements for NFR alignment
- If missing: suggest running `$arckit-principles` first
- **RISK** (Risk Register) — Extract: risk-driven requirements, mitigations that need NFRs
- **SOBC** (Business Case) — Extract: benefits, cost constraints, ROI targets for BR alignment
**OPTIONAL** (read if available, skip silently):
- **PLAN** (Project Plan) — Extract: timeline constraints, phasing for requirement prioritization
3. **Read external documents and policies**:
- Read any **external documents** listed in the project context (`external/` files) — extract requirements, constraints, scope definitions, acceptance criteria, legacy system interfaces
- Read any **global policies** listed in the project context (`000-global/policies/`) — extract mandatory compliance requirements, technology constraints, security standards
- Read any **enterprise standards** in `projects/000-global/external/` — extract cross-project requirements patterns
- If no external docs exist but they would significantly improve requirements, ask: "Do you have any RFP/ITT documents, legacy system specifications, or user research reports? I can read PDFs and Word docs directly. Place them in `projects/{project-dir}/external/` and re-run, or skip."
- **Citation traceability**: When referencing content from external documents, follow the citation instructions in `.arckit/references/citation-instructions.md`. Place inline citation markers (e.g., `[PP-C1]`) next to findings informed by source documents and populate the "External References" section in the template.
4. **Read the template** (with user override support):
- **First**, check if `.arckit/templates/requirements-template.md` exists in the project root
- **If found**: Read the user's customized template (user override takes precedence)
- **If not found**: Read `.arckit/templates/requirements-template.md` (default)
- **Update Template Version**: Replace the version in the template metadata line with `{ARCKIT_VERSION}` from the session context
> **Tip**: Users can customize templates with `$arckit-customize requirements`
5. **Generate comprehensive requirements** based on user input:
**Business Requirements (BR-xxx)**:
- Business objectives and success criteria
- ROI and cost savings expectations
- Timeline and milestones
- Stakeholder needs
**Functional Requirements (FR-xxx)**:
- User personas and their needs
- User stories and use cases
- Features and capabilities
- User workflows
**Non-Functional Requirements (NFR-xxx)**:
- Performance (response time, throughput, concurrent users)
- Security (authentication, authorisation, encryption, compliance)
- Scalability (growth projections, load handling)
- Reliability (uptime SLA, MTBF, MTTR)
- Compliance (regulations, standards, certifications)
**Integration Requirements (INT-xxx)**:
- Upstream/downstream systems
- APIs and protocols
- Data exchange formats
- Authentication methods
**Data Requirements (DR-xxx)**:
- Data models and schemas
- Data retention and archival
- Data privacy and classification
- Migration requirements
6. **Ensure traceability**: Each requirement MUST have:
- Unique ID (BR-001, FR-001, NFR-P-001, etc.)
- Clear requirement statement
- Acceptance criteria (testable)
- Priority (MUST/SHOULD/MAY)
- Rationale
7. **Align with stakeholder goals and architecture principles**:
- If stakeholder analysis exists, trace requirements back to stakeholder goals:
- Example: "BR-001 addresses CFO's goal G-1: Reduce infrastructure costs 40% by end of Year 1"
- Example: "NFR-P-001 supports Operations Director's outcome O-3: Maintain 99.95% uptime"
- Reference relevant principles from `projects/000-global/ARC-000-PRIN-*.md`:
- Example: "NFR-S-001 aligns with Security by Design principle (SEC-001)"
- Ensure high-priority stakeholder drivers get MUST requirements
- Document which stakeholder benefits from each requirement
8. **Identify and resolve conflicting requirements**:
- Review stakeholder analysis `conflict analysis` section for known competing drivers
- Identify requirement conflicts that arise from stakeholder conflicts:
- **Speed vs Quality**: CFO wants fast delivery vs Operations wants thorough testing
- **Cost vs Features**: Finance wants minimal spend vs Product wants rich features
- **Security vs Usability**: Security wants MFA vs Users want seamless experience
- **Flexibility vs Standardization**: Business wants customization vs IT wants standards
- For each conflict, document:
- **Conflicting Requirements**: Which requirements are incompatible (e.g., FR-001 vs NFR-P-002)
- **Stakeholders Involved**: Who wants what (e.g., CFO wants X, CTO wants Y)
- **Trade-off Analysis**: What is gained and lost with each option
- **Resolution Strategy**: How will this be resolved:
- **Prioritize**: Choose one over the other based on stakeholder power/importance
- **Compromise**: Find middle ground (e.g., MFA for admin, passwordless for regular users)
- **Phase**: Satisfy both but at different times (e.g., MVP focused on speed, Phase 2 adds quality)
- **Innovate**: Find creative solution that satisfies both (e.g., automated testing for speed AND quality)
- **Decision Authority**: Reference stakeholder analysis RACI matrix for who decides
- **Document Resolution**: Create explicit "Requirement Conflicts & Resolutions" section showing:
- What was chosen and why
- What was deferred or rejected
- Which stakeholder "won" and which "lost"
- How losing stakeholder will be managed (communication, future consideration)
- **Transparency**: Be explicit about trade-offs - don't hide conflicts or pretend both can be satisfied
9. **Write the output**:
Before writing the file, read `.arckit/references/quality-checklist.md` and verify all **Common Checks** plus the **REQ** per-type checks pass. Fix any failures before proceeding.
- **CRITICAL - Token Efficiency**: Use the **Write tool** to create `projects/{project-dir}/ARC-{PROJECT_ID}-REQ-v${VERSION}.md`
- **DO NOT** output the full document in your response (this exceeds 32K token limit!)
- Use the exact template structure
- Include all sections even if some are TBD
- MUST include "Requirement Conflicts & Resolutions" section if any conflicts exist
**CRITICAL - Auto-Populate Document Control Fields**:
Before completing the document, populate ALL document control fields in the header:
### Step 0: Detect Version
Before generating the document ID, check if a previous version exists:
1. Look for existing `ARC-{PROJECT_ID}-REQ-v*.md` files in the project directory
2. **If no existing file**: Use VERSION="1.0"
3. **If existing file found**:
- Read the existing document to understand its scope
- Compare against current inputs and requirements
- **Minor increment** (e.g., 1.0 → 1.1): Scope unchanged — refreshed content, updated details, corrections
- **Major increment** (e.g., 1.0 → 2.0): Scope materially changed — new requirement categories, removed categories, significant new requirements added
4. Use the determined version for document ID, filename, Document Control, and Revision History
5. For v1.1+/v2.0+: Add a Revision History entry
### Step 1: Construct Document ID
- **Document ID**: `ARC-{PROJECT_ID}-REQ-v{VERSION}` (e.g., `ARC-001-REQ-v1.0`)
### Step 2: Populate Required Fields
**Auto-populated fields** (populate these automatically):
- `[PROJECT_ID]` → Extract from project path (e.g., "001" from "projects/001-project-name")
- `[VERSION]` → Determined version from Step 0
- `[DATE]` / `[YYYY-MM-DD]` → Current date in YYYY-MM-DD format
- `[DOCUMENT_TYPE_NAME]` → "Business and Technical Requirements"
- `ARC-[PROJECT_ID]-REQ-v[VERSION]` → Construct using format from Step 1
- `[COMMAND]` → "arckit.requirements"
**User-provided fields** (extract from project metadata or user input):
- `[PROJECT_NAME]` → Full project name from project metadata or user input
- `[OWNER_NAME_AND_ROLE]` → Document owner (prompt user if not in metadata)
- `[CLASSIFICATION]` → Default to "OFFICIAL" for UK Gov, "PUBLIC" otherwise (or prompt user)
**Calculated fields**:
- `[YYYY-MM-DD]` for Review Date → Current date + 30 days (requirements, research, risks)
- `[YYYY-MM-DD]` for Review Date → Phase gate dates (Alpha/Beta/Live for compliance docs)
**Pending fields** (leave as [PENDING] until manually updated):
- `[REVIEWER_NAME]` → [PENDING]
- `[APPROVER_NAME]` → [PENDING]
- `[DISTRIBUTION_LIST]` → Default to "Project Team, Architecture Team" or [PENDING]
### Step 3: Populate Revision History
```markdown
| 1.0 | {DATE} | ArcKit AI | Initial creation from `$arckit-requirements` command | [PENDING] | [PENDING] |
```
### Step 4: Populate Generation Metadata Footer
The footer should be populated with:
```markdown
**Generated by**: ArcKit `$arckit-requirements` command
**Generated on**: {DATE} {TIME} GMT
**ArcKit Version**: {ARCKIT_VERSION}
**Project**: {PROJECT_NAME} (Project {PROJECT_ID})
**AI Model**: [Use actual model name, e.g., "claude-sonnet-4-5-20250929"]
**Generation Context**: [Brief note about source documents used]
```
### Example Fully Populated Document Control Section
```markdown
## Document Control
| Field | Value |
|-------|-------|
| **Document ID** | ARC-001-REQ-v1.0 |
| **Document Type** | {Document purpose} |
| **Project** | Windows 10 to Windows 11 Migration (Project 001) |
| **Classification** | OFFICIAL-SENSITIVE |
| **Status** | DRAFT |
| **Version** | 1.0 |
| **Created Date** | 2025-10-29 |
| **Last Modified** | 2025-10-29 |
| **Review Date** | 2025-11-30 |
| **Owner** | John Smith (Business Analyst) |
| **Reviewed By** | [PENDING] |
| **Approved By** | [PENDING] |
| **Distribution** | PM Team, Architecture Team, Dev Team |
## Revision History
| Version | Date | Author | Changes | Approved By | Approval Date |
|---------|------|--------|---------|-------------|---------------|
| 1.0 | 2025-10-29 | ArcKit AI | Initial creation from `$arckit-requirements` command | [PENDING] | [PENDING] |
```
10. **Show summary only** (NOT the full document):
After writing the file with Write tool, show ONLY this summary:
```markdown
## Requirements Complete ✅
**Project**: [Project Name]
**File Created**: `projects/[PROJECT]/ARC-{PROJECT_ID}-REQ-v1.0.md`
### Requirements Summary
**Total Requirements**: [Number]
- Business Requirements (BR-xxx): [Number]
- Functional Requirements (FR-xxx): [Number]
- Non-Functional Requirements (NFR-xxx): [Number]
- Performance (NFR-P-xxx): [Number]
- Security (NFR-SEC-xxx): [Number]
- Scalability (NFR-S-xxx): [Number]
- Availability (NFR-A-xxx): [Number]
- Compliance (NFR-C-xxx): [Number]
- Data Requirements (DR-xxx): [Number]
- Integration Requirements (INT-xxx): [Number]
**Requirement Conflicts**: [Number] conflicts identified and resolved
- [Brief summary of key conflicts and resolutions]
- [Which stakeholders won/lost in conflicts]
**Compliance Requirements**:
- [List key compliance frameworks: PCI-DSS, GDPR, HIPAA, etc.]
**Key Gaps/TBDs**:
- [List any major gaps that need follow-up]
### What's in the Document
- Business Requirements with measurable success criteria
- Functional Requirements organized by user journey
- Non-Functional Requirements with specific targets
- Data Requirements with GDPR considerations
- Integration Requirements with third-party systems
- Acceptance Criteria for each requirement
- Requirements Traceability Matrix
- Requirement Conflicts & Resolutions
### Next Steps
- Review `ARC-{PROJECT_ID}-REQ-v1.0.md` for full details
- [If DR-xxx exist]: Run `$arckit-data-model` to create comprehensive data model
- [If no DR-xxx]: Run `$arckit-research` to research technology options
```
## Example Usage
User: `$arckit-requirements Create requirements for a payment gateway modernization project`
You should:
- Check for architecture principles
- Create project "payment-gateway-modernization" (gets number 001)
- Generate comprehensive requirements:
- Business: Cost savings, improved conversion, reduced downtime
- Functional: Payment processing, refunds, fraud detection, reporting
- NFR: PCI-DSS compliance, 99.99% uptime, <2s response time, encryption
- Integration: CRM, accounting system, fraud service
- Data: Transaction records, PII handling, 7-year retention
- Write to `projects/001-payment-gateway-modernization/ARC-001-REQ-v1.0.md`
- Confirm completion with summary
## Important Notes
- Requirements drive everything: SOW, vendor evaluation, design reviews, testing
- Be specific and measurable (avoid "fast", use "< 2 seconds")
- Include WHY (rationale) not just WHAT
- Make acceptance criteria testable
- Flag compliance requirements clearly (PCI-DSS, HIPAA, SOX, GDPR, etc.)
- **Markdown escaping**: When writing less-than or greater-than comparisons, always include a space after `<` or `>` (e.g., `< 3 seconds`, `> 99.9% uptime`) to prevent markdown renderers from interpreting them as HTML tags or emoji
## Suggested Next Steps
After completing this command, consider running:
- `$arckit-data-model` -- Create data model from data requirements *(when DR-xxx data requirements were generated)*
- `$arckit-research` -- Research technology options
- `$arckit-risk` -- Create risk register from requirements
- `$arckit-dpia` -- Assess data protection impact
More from tractorjuice/arc-kit
- architecture-workflowThis skill should be used when the user asks how to start an architecture project, which ArcKit commands to run and in what order, what workflow to follow, getting started, new project setup, guide me through, or what comes next.
- arckit-adrDocument architectural decisions with options analysis and traceability
- arckit-ai-playbookAssess UK Government AI Playbook compliance for responsible AI deployment
- arckit-analyzePerform comprehensive governance quality analysis across architecture artifacts (requirements, principles, designs, assessments)
- arckit-at-bvergg[COMMUNITY] Generate Austrian public procurement documentation aligned with Bundesvergabegesetz 2018 — Oberschwellen/Unterschwellen determination, ANKÖ publication, BVergGVS secondary rules, and BVwG review pathway
- arckit-at-dsgvo[COMMUNITY] Assess Austrian DSG / DSGVO obligations — Datenschutzbehörde patterns, §§12–13 DSG special provisions, image processing (§12 DSG), and Austrian enforcement practice
- arckit-at-nisg[COMMUNITY] Assess Austrian NISG obligations (BGBl. I Nr. 94/2025) — AT transposition of NIS2, BKA (GovCERT) / BMI (SPOC) reporting, KSÖ coordination, and Austrian sectoral rules for Essential/Important entities
- arckit-atrsGenerate Algorithmic Transparency Recording Standard (ATRS) record for AI/algorithmic tools
- arckit-aws-researchResearch AWS services and architecture patterns using AWS Knowledge MCP for authoritative guidance
- arckit-azure-researchResearch Azure services and architecture patterns using Microsoft Learn MCP for authoritative guidance