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" |