NFR and Capacity Analysis
Translate business expectations into precise, measurable non-functional requirements and SLO definitions that constrain and guide architecture decisions.
Overview
NFRs are the quality attributes a system must have in addition to its functional behaviour. Vague NFRs ("must be fast", "must be secure") are useless. This skill produces specific, measurable NFRs and derives the capacity model that the architecture must support.
NFR Categories and Metrics
Performance
- Response time: p50, p95, p99 latency targets per endpoint type
- Throughput: requests per second at peak load
- Processing time: for batch or async operations
Availability and Reliability
- Uptime SLO: expressed as % per month (99.9% = 43.8min downtime/month)
- RTO (Recovery Time Objective): max time to restore service after failure
- RPO (Recovery Point Objective): max data loss acceptable
- MTBF (Mean Time Between Failures): for hardware/infrastructure
Scalability
- Concurrent users: expected and peak concurrent sessions
- Data volume: current volume and growth rate (1yr, 3yr projection)
- Request rate: sustained and burst peak (e.g., "10x normal during Black Friday")
- Geographic distribution: single region or multi-region
Security
- Authentication strength: MFA required? Which protocols?
- Data classification: PII, financial, health, public
- Encryption requirements: in transit (TLS 1.3), at rest (AES-256)
- Compliance requirements: GDPR, SOC 2, ISO 27001, PCI-DSS, HIPAA
Maintainability
- Deployment frequency target: multiple/day, daily, weekly
- Change failure rate target: < X% of deployments cause incidents
- Mean time to recovery: < X hours for P1 incidents
- Code coverage floor: minimum test coverage %
NFR Documentation Format
## Non-Functional Requirements
### Performance
| Metric | Current | Target | Rationale |
|---|---|---|---|
| API p95 latency | N/A | < 200ms | UX research shows 200ms feels instant |
| Throughput | N/A | 1,000 rps peak | Based on 50,000 DAU × 20 actions/day |
### Availability
| Metric | Target | Downtime Budget/Month |
|---|---|---|
| Uptime SLO | 99.9% | 43.8 minutes |
| RTO | 1 hour | — |
| RPO | 15 minutes | — |
### Scalability
| Dimension | Current | 1 Year | 3 Year |
|---|---|---|---|
| Registered users | 0 | 100,000 | 1,000,000 |
| Concurrent sessions | 0 | 5,000 peak | 50,000 peak |
| Data volume | 0 | 500GB | 5TB |
Capacity Model
Derive infrastructure sizing from NFRs:
- Start from peak concurrent users and request rate
- Model request distribution across endpoints (80/20: 80% reads, 20% writes typical)
- Estimate CPU and memory per request based on complexity
- Add redundancy multiplier (N+1 for active-passive, N+2 for active-active)
- Add headroom buffer (30% minimum for burst)
- Size database IOPS from write rate and read cache hit ratio
Produce a capacity table:
| Component |
Baseline |
Peak Load |
Redundancy |
Recommended Size |
| API servers |
[size] |
[size] |
N+1 |
[recommendation] |
| Database |
[size] |
[size] |
Primary + Replica |
[recommendation] |
Additional Resources
references/slo-sli-reference.md — SLO/SLI definitions and examples by system typereferences/capacity-planning-models.md — Capacity calculation worksheets
1---2name: nfr-and-capacity-analysis3description: This skill should be used when the user asks to "define NFRs", "set performance targets", "define SLAs and SLOs", "analyse capacity requirements", "specify scalability targets", "define reliability requirements", or needs to translate business expectations into measurable non-functional requirements.4---56# NFR and Capacity Analysis78Translate business expectations into precise, measurable non-functional requirements and SLO definitions that constrain and guide architecture decisions.910## Overview1112NFRs are the quality attributes a system must have in addition to its functional behaviour. Vague NFRs ("must be fast", "must be secure") are useless. This skill produces specific, measurable NFRs and derives the capacity model that the architecture must support.1314## NFR Categories and Metrics1516### Performance17- **Response time**: p50, p95, p99 latency targets per endpoint type18- **Throughput**: requests per second at peak load19- **Processing time**: for batch or async operations2021### Availability and Reliability22- **Uptime SLO**: expressed as % per month (99.9% = 43.8min downtime/month)23- **RTO** (Recovery Time Objective): max time to restore service after failure24- **RPO** (Recovery Point Objective): max data loss acceptable25- **MTBF** (Mean Time Between Failures): for hardware/infrastructure2627### Scalability28- **Concurrent users**: expected and peak concurrent sessions29- **Data volume**: current volume and growth rate (1yr, 3yr projection)30- **Request rate**: sustained and burst peak (e.g., "10x normal during Black Friday")31- **Geographic distribution**: single region or multi-region3233### Security34- **Authentication strength**: MFA required? Which protocols?35- **Data classification**: PII, financial, health, public36- **Encryption requirements**: in transit (TLS 1.3), at rest (AES-256)37- **Compliance requirements**: GDPR, SOC 2, ISO 27001, PCI-DSS, HIPAA3839### Maintainability40- **Deployment frequency target**: multiple/day, daily, weekly41- **Change failure rate target**: < X% of deployments cause incidents42- **Mean time to recovery**: < X hours for P1 incidents43- **Code coverage floor**: minimum test coverage %4445## NFR Documentation Format4647```markdown48## Non-Functional Requirements4950### Performance51| Metric | Current | Target | Rationale |52|---|---|---|---|53| API p95 latency | N/A | < 200ms | UX research shows 200ms feels instant |54| Throughput | N/A | 1,000 rps peak | Based on 50,000 DAU × 20 actions/day |5556### Availability57| Metric | Target | Downtime Budget/Month |58|---|---|---|59| Uptime SLO | 99.9% | 43.8 minutes |60| RTO | 1 hour | — |61| RPO | 15 minutes | — |6263### Scalability64| Dimension | Current | 1 Year | 3 Year |65|---|---|---|---|66| Registered users | 0 | 100,000 | 1,000,000 |67| Concurrent sessions | 0 | 5,000 peak | 50,000 peak |68| Data volume | 0 | 500GB | 5TB |69```7071## Capacity Model7273Derive infrastructure sizing from NFRs:74751. Start from peak concurrent users and request rate762. Model request distribution across endpoints (80/20: 80% reads, 20% writes typical)773. Estimate CPU and memory per request based on complexity784. Add redundancy multiplier (N+1 for active-passive, N+2 for active-active)795. Add headroom buffer (30% minimum for burst)806. Size database IOPS from write rate and read cache hit ratio8182Produce a capacity table:8384| Component | Baseline | Peak Load | Redundancy | Recommended Size |85|---|---|---|---|---|86| API servers | [size] | [size] | N+1 | [recommendation] |87| Database | [size] | [size] | Primary + Replica | [recommendation] |8889## Additional Resources9091- **`references/slo-sli-reference.md`** — SLO/SLI definitions and examples by system type92- **`references/capacity-planning-models.md`** — Capacity calculation worksheets
VAMFI