Skip to main content

​
Overview

The requirements command generates comprehensive business and technical requirements documentation that drives vendor RFPs, architecture reviews, and project delivery. It creates structured requirements across five categories: Business (BR), Functional (FR), Non-Functional (NFR), Integration (INT), and Data (DR).

​
Command Syntax

arckit requirements <project-id-or-name>
Example: 
arckit requirements "payment gateway modernization"
arckit requirements 001
arckit requirements authentication-module

​
Requirement Types

​
Business Requirements (BR-xxx)

Business objectives, ROI expectations, timeline constraints, and stakeholder needs. Example: BR-001: Reduce infrastructure costs by 40% within Year 1

​
Functional Requirements (FR-xxx)

User personas, user stories, features, capabilities, and workflows. Example: FR-005: Support passwordless authentication via biometric or passkey

​
Non-Functional Requirements (NFR-xxx)

Performance, security, scalability, reliability, and compliance constraints. Categories:
  • Performance (NFR-P-xxx): Response time, throughput, concurrent users
  • Security (NFR-SEC-xxx): Authentication, authorization, encryption
  • Scalability (NFR-S-xxx): Growth projections, load handling
  • Availability (NFR-A-xxx): Uptime SLA, MTBF, MTTR
  • Compliance (NFR-C-xxx): GDPR, PCI-DSS, HIPAA, FCA regulations
Example: NFR-P-001: API response time < 2 seconds at 95th percentile under 10,000 concurrent users

​
Integration Requirements (INT-xxx)

Upstream/downstream systems, APIs, protocols, data exchange formats, authentication methods. Example: INT-003: Integrate with Salesforce CRM via REST API for customer data sync (hourly batch)

​
Data Requirements (DR-xxx)

Data models, schemas, retention policies, privacy classifications, migration needs. Example: DR-002: Store customer transaction history for 7 years (PCI-DSS compliance)

​
Prerequisites

​
Mandatory

  • Stakeholder Analysis (STKE): Required to trace requirements back to stakeholder goals and priorities
    • Command: arckit stakeholders <project>
    • The tool will warn if missing and prompt you to run it first
  • Architecture Principles (PRIN): Aligns NFRs with technology standards and constraints
  • Risk Register (RISK): Identifies risk-driven requirements and mitigations
  • Business Case (SOBC): Ensures BR alignment with benefits and ROI targets

​
Workflow

​
1. Run Prerequisites

arckit stakeholders "payment gateway modernization"

​
2. Generate Requirements

arckit requirements "payment gateway modernization"

​
3. Review Output

The command creates:
  • File: projects/001-payment-gateway-modernization/ARC-001-REQ-v1.0.md
  • Summary: Shows requirement counts by type, conflicts identified, compliance frameworks, gaps

​
4. Next Steps (Handoffs)

After generating requirements, proceed with:

Data Model

Create ERD and entity catalog from DR-xxx requirements

Research

Research technology options to fulfill FR/NFR requirements

Risk Register

Create risk register from requirements analysis

DPIA

Assess data protection impact if PII identified

​
Features

​
Stakeholder Traceability

Every requirement traces back to stakeholder goals: Example:
“BR-001 addresses CFO’s goal G-1: Reduce infrastructure costs 40% by end of Year 1” “NFR-P-001 supports Operations Director’s outcome O-3: Maintain 99.95% uptime”

​
Conflict Resolution

Identifies and resolves competing stakeholder drivers: Common 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
Resolution Strategies:
  • Prioritize: Choose one over the other based on stakeholder power
  • Compromise: Find middle ground (e.g., MFA for admins, passwordless for users)
  • Phase: Satisfy both at different times (MVP speed, Phase 2 quality)
  • Innovate: Creative solution satisfying both (automated testing for speed AND quality)

​
Compliance Requirements

Automatically flags sector-specific compliance:
  • PCI-DSS: Payment card data handling
  • GDPR/DPA 2018: Personal data processing (UK)
  • HIPAA: Healthcare data (US)
  • FCA Regulations: Financial services (UK)
  • Government Security Classifications: OFFICIAL, SECRET (UK public sector)

​
Acceptance Criteria

Every requirement includes testable acceptance criteria: Example: 
**FR-012: User Login**
- **Requirement:** Users must authenticate via email/password or SSO
- **Acceptance Criteria:**
  - Email/password login completes in < 3 seconds
  - SSO redirect completes in < 5 seconds
  - Failed login shows error message within 1 second
  - Account locks after 5 failed attempts
- **Priority:** MUST
- **Rationale:** Security policy requires account lockout; user research shows 3s tolerance

​
Document Structure

The generated document follows this structure: 
# Requirements Document

## Document Control
- Document ID: ARC-001-REQ-v1.0
- Version: 1.0
- Status: DRAFT
- Owner: [Name] ([Role])

## Revision History
| Version | Date | Author | Changes |

## Executive Summary
- Total Requirements: 47
- Conflicts Identified: 3 (resolved)
- Compliance: GDPR, PCI-DSS

## Business Requirements (BR-xxx)
[Business objectives, ROI, timeline]

## Functional Requirements (FR-xxx)
[User stories, features, workflows]

## Non-Functional Requirements (NFR-xxx)
[Performance, security, scalability]

## Integration Requirements (INT-xxx)
[APIs, systems, data exchange]

## Data Requirements (DR-xxx)
[Data models, retention, privacy]

## Requirement Conflicts & Resolutions
[Detailed conflict analysis and decisions]

## Requirements Traceability Matrix
[Requirement ID → Stakeholder Goal mapping]

## Acceptance Criteria
[Testable criteria per requirement]

​
Real-World Example

Project: Payment Gateway Modernization (Project 001)Total Requirements: 47
  • Business Requirements (BR-xxx): 8
  • Functional Requirements (FR-xxx): 15
  • Non-Functional Requirements (NFR-xxx): 12
    • Performance (NFR-P-xxx): 3
    • Security (NFR-SEC-xxx): 5
    • Availability (NFR-A-xxx): 2
    • Compliance (NFR-C-xxx): 2
  • Data Requirements (DR-xxx): 8
  • Integration Requirements (INT-xxx): 4
Compliance Requirements:
  • PCI-DSS Level 1 (payment card data)
  • GDPR/DPA 2018 (customer PII)
  • FCA regulations (financial services, UK)
Key Conflicts Resolved:
  • CFO vs CTO: Cost reduction (cloud migration) vs Security (on-premise preference)
    • Resolution: Hybrid approach - PCI data on-premise, non-sensitive workloads cloud
    • Decision Authority: CEO (stakeholder analysis RACI matrix)
Next Steps:
  • Run /arckit data-model 001 to create ERD from DR-xxx requirements
  • Run /arckit research payment-processors for vendor analysis
### FR-003: Multi-Currency Payment Processing

**Requirement:** The system shall process payments in GBP, EUR, USD with real-time FX conversion.

**Acceptance Criteria:**
- Support Visa, Mastercard, Amex card networks
- FX rates updated every 15 minutes from ECB API
- Transaction authorization completes in < 2 seconds
- 3D Secure 2.0 for SCA compliance (PSD2)
- Tokenize card data (no plaintext storage)

**Priority:** MUST

**Rationale:**
- Traces to BR-002: Expand to EU market (CFO goal G-2)
- PCI-DSS requirement for tokenization
- PSD2 Strong Customer Authentication (SCA) mandate

**Source Stakeholder:** CFO (Business Expansion), CTO (Security)

​
Tips & Best Practices

Be Specific and MeasurableAvoid vague terms like “fast” or “secure”. Use quantified targets:
  • ❌ “The system should be fast”
  • ✅ “API response time < 2 seconds at 95th percentile under 10,000 concurrent users”
Document the WHY, Not Just the WHATEvery requirement should include rationale tracing back to business goals or compliance mandates. This helps stakeholders understand trade-offs and prevents scope creep.
Versioning and UpdatesThe command auto-detects existing requirements documents:
  • v1.0 → v1.1: Scope unchanged (refreshed content, corrections)
  • v1.0 → v2.0: Scope materially changed (new requirement categories, significant additions)

​
Quality Checks

Before generating the document, ArcKit validates:

​
Common Use Cases

​
Vendor RFPs

Requirements drive vendor evaluation criteria and SOW specifications.

​
Architecture Reviews

NFRs guide technology selection and design decisions.

​
Testing & QA

Acceptance criteria become test cases and acceptance tests.

​
Compliance Audits

Compliance requirements provide evidence for GDPR, PCI-DSS, HIPAA audits.

Stakeholders

Prerequisite: Run before requirements to identify goals

Data Model

Next step: Create ERD from DR-xxx requirements

DPIA

Next step: Assess data protection impact

Research

Next step: Research technology options

Risk Register

Next step: Create risk register from requirements

Traceability

Downstream: Map requirements to design/code

​
Additional Resources

Build docs developers (and LLMs) love

Get started for freeTalk to us