Arckit Requirements

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

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

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.

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

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

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

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

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

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