View Source

Non-Functional Requirements

NFR-001: Performance Targets

Priority: HIGH
Owner: Technical Architect

Performance Metrics

Metric	Target	Measurement	Test Scenario
Monthly throughput	10M invoices	Application Insights	Production monitoring
100K batch processing	< 2 hours	Timestamp diff	Load test TC-200
API response (p50)	< 200ms	Application Insights	Load test TC-201
API response (p95)	< 500ms	Application Insights	Load test TC-202
API response (p99)	< 1000ms	Application Insights	Load test TC-203
PDF generation (p95)	< 5 seconds/invoice	Custom metric	Render test TC-204
Handlebars render (p95)	< 2 seconds/invoice	Custom metric	Render test TC-205
Queue processing lag	< 5 minutes	Queue depth / throughput	Queue monitoring
Database query (p95)	< 100ms	PostgreSQL slow query log	Query analysis
ParserService (10K batch)	< 2 minutes	Parse duration	Parser test TC-206

Load Testing Scenarios

Scenario 1: Steady State (Normal Month)

Duration: 24 hours
Load: 333K invoices evenly distributed
Concurrent batches: 5-10
Expected: All targets met, no errors

Scenario 2: Peak Load (Heating Season)

Duration: 8 hours
Load: 314K invoices (first week concentration)
Concurrent batches: 20+
Expected: 2-hour SLA met, >99% success

Scenario 3: Spike Test

Duration: 30 minutes
Load: 10 batches (50K invoices) uploaded simultaneously
Expected: Auto-scales, processes without degradation

Acceptance Criteria

#	Criterion	Validation	Target
1	100K batch completion	End-to-end test	≤ 2 hours
2	API latency under load	1000 RPS test	p95 ≤ 500ms
3	10M monthly capacity	Production monitoring	≥ 10M in peak month
4	50-org performance	50 concurrent uploads	All SLAs met
5	Worker auto-scaling	Monitor queue during peaks	Lag ≤ 5 min
6	PDF generation performance	1000 PDFs	p95 ≤ 5 seconds

NFR-002: Scalability & Auto-Scaling

Priority: HIGH
Owner: Technical Architect

Scaling Configuration

Component	Min	Max	Trigger	Threshold	Scale Up	Scale Down
CoreApiService	5	20	CPU OR Request Rate	70% OR 1000 RPS	2 min	10 min
ParserService	2	10	Queue Length	>0	1 min	5 min
DocumentGenerator	2	100	Queue Length	>32	1 min	5 min
EmailService	5	50	Queue Length	>50	1 min	5 min
PostalService	1	3	Scheduled	12:00, 20:00 CET	N/A	After completion

Peak Load Capacity

Normal Load (non-heating, mid-month):

333K invoices/day average
5-10 concurrent batches
Worker instances: 10-20 total

Peak Load (heating season, first/last week):

2.2M invoices/week
314K invoices/day
20+ concurrent batches
Worker instances: 80-100 total

Pre-Warming Strategy (Heating Season)

Monthly Schedule:
- Day 1-7: Pre-warm to 50 instances at 00:00
- Day 8-23: Scale based on queue (2-20 instances)
- Day 24-31: Pre-warm to 50 instances at 00:00

Heating Season (Oct-Mar): Double levels
- Day 1-7: Pre-warm to 80 instances
- Day 24-31: Pre-warm to 80 instances

NFR-003: Availability & Reliability

Priority: HIGH
Owner: Technical Architect

Availability Targets

Metric	Target	Allowed Downtime	Measurement
System Uptime	99.9%	43 min/month	Azure Monitor
Batch Success Rate	>99.5%	50 failures per 10K	Processing logs
Delivery Success Rate	>98%	200 failures per 10K	Delivery tracking
API Availability	99.9%	43 min/month	Health checks
MTTR	<30 minutes	N/A	Incident timestamps
MTBF	>720 hours	N/A	Incident tracking

Multi-Region Deployment

Primary Region: West Europe (Sweden, Denmark)
Secondary Region: North Europe (Norway, Finland)

Traffic Routing:

Azure Traffic Manager (Performance routing)
Health check: /health every 30 seconds
Auto-failover: 3 consecutive failures
Failover time: <2 minutes

NFR-004: Security Requirements

Priority: CRITICAL
Owner: Technical Architect

Authentication & Authorization

OAuth 2.0:

Grant Type: Client Credentials
Token Provider: Microsoft Entra ID
Token Lifetime: 1 hour
Algorithm: RS256

Roles:

Super Admin (global)
Organization Admin (single org)
Template Admin (single org)
Batch Operator (single org)
Read-Only User (single org)
API Client (single org)

Encryption

In Transit:

TLS 1.3 minimum
HSTS enabled

At Rest:

Blob Storage: AES-256
PostgreSQL: AES-256
Backups: AES-256

NFR-005: Data Retention

Priority: HIGH
Owner: Legal/Compliance

Data Type	Retention	Storage Tier Transitions
Invoices (PDF/HTML/JSON)	7 years	Day 0-365: Hot Day 366-2555: Cool Day 2556+: Archive
Batch Source (XML)	90 days	Day 0-30: Hot Day 31-90: Cool Day 91+: Delete
Audit Logs	7 years	Year 0-1: PostgreSQL Year 1-7: Blob (compressed)
Application Logs	90 days	Application Insights

Approval Section

Stakeholder Sign-Off

Stakeholder Role	Name	Signature	Date	Status
Product Owner				☐ PENDING
Technical Architect				☐ PENDING

Approval Criteria

All CRITICAL requirements reviewed and accepted
All HIGH requirements reviewed and accepted
All dependencies identified and acknowledged
All risks reviewed with mitigation strategies
All acceptance criteria defined and measurable
Budget and timeline implications understood
Resource allocation confirmed
Compliance requirements validated (GDPR, Bokföringslagen)

Change Control

Any changes to approved CRITICAL or HIGH priority requirements must follow the change control process:

Document proposed change in Jira (tag with egflow version)
Impact assessment (scope, timeline, cost)
Re-approval by Product Owner and Technical Architect
Update this document with version increment
Communicate changes to development team
Update affected Jira issues with new fixVersion

Version History

Version	Date	Author	Changes	Release Target
1.0	2025-11-20	Product Owner	Initial draft	egflow-1.0.0
1.1	2025-11-21	Product Owner	Added FR-003 details, updated acceptance criteria	egflow-1.0.0
1.2	2025-11-27	Product Owner	Updated versioning strategy to match Gasell model	egflow-1.0.0 "Corny Flamingo"