Non-Functional Requirements

In 2017, Equifax disclosed a breach affecting 147 million people—nearly half the US population. The root cause? An unpatched Apache Struts vulnerability that had been public for two months. The breach cost Equifax over $700 million in settlements, created years of remediation work, and irrevocably damaged trust.

Security breaches rarely originate from sophisticated nation-state attacks. They come from overlooked patches, misconfigured cloud buckets, weak passwords, inadequate access controls, and a thousand small failures that seemed unimportant until they weren't.

Security requirements define the protective measures your system must implement. Unlike other non-functional requirements where trade-offs are routine, security failures are often binary: the wall holds or it doesn't. Getting security requirements right isn't about optimization—it's about survival.

Security requirements are grounded in fundamental security properties. Understanding these foundations enables precise requirement specification.

The CIA Triad:

The classic security model defines three core properties:

Confidentiality: Information is accessible only to authorized parties. Prevents unauthorized disclosure. Violated when data is exposed to wrong parties.

Integrity: Information is accurate, complete, and unaltered by unauthorized parties. Violated when data is modified, corrupted, or fabricated.

Availability: Information and systems are accessible when needed by authorized parties. (This overlaps with availability requirements but has a security dimension: preventing denial-of-service.)

Defense in Depth:

No single security control is sufficient. Security requirements should specify multiple layers:

┌─────────────────────────────────────────────────────────────────┐
│                     Security Layers                             │
├─────────────────────────────────────────────────────────────────┤
│  Perimeter      │ Firewalls, WAF, DDoS protection              │
├─────────────────────────────────────────────────────────────────┤
│  Network        │ VPC, network segmentation, private subnets   │
├─────────────────────────────────────────────────────────────────┤
│  Transport      │ TLS/mTLS, certificate management              │
├─────────────────────────────────────────────────────────────────┤
│  Application    │ Authentication, authorization, input validation│
├─────────────────────────────────────────────────────────────────┤
│  Data           │ Encryption at rest, field-level encryption   │
├─────────────────────────────────────────────────────────────────┤
│  Operational    │ Logging, monitoring, incident response        │
└─────────────────────────────────────────────────────────────────┘

Each layer provides protection even if another layer fails. Requirements should address each layer.

Authentication verifies that users and systems are who they claim to be. Strong authentication requirements are the first line of defense.

Authentication Factors:

Multi-Factor Authentication (MFA):

MFA combines two or more factors. Requirements should specify when MFA is required:

Federated Identity and SSO:

For systems that integrate with external identity providers:

Federated Authentication Requirements:

1. Enterprise SSO
   - Protocol: SAML 2.0 or OpenID Connect
   - Providers: Okta, Azure AD, Google Workspace
   - Just-in-time provisioning: Create accounts on first SSO login
   - Attribute mapping: Map IdP groups to internal roles

2. Social Login
   - Supported: Google, Apple, Microsoft
   - Not supported: Facebook (data practices), Twitter (API stability)
   - Scope: Request minimum necessary (email, profile)
   - Fallback: Email/password for users without social accounts

3. API Authentication
   - OAuth 2.0 with PKCE for user-delegated access
   - API keys for server-to-server long-lived access
   - JWT bearer tokens for short-lived access
   - Token introspection: Validate tokens with issuer

Authorization determines what authenticated users can do. The principle of least privilege—granting minimum necessary access—underpins all authorization requirements.

Authorization Models:

Authorization Requirements Specification:

Authorization Requirements:

1. Access Control Model
   - Primary model: RBAC with ABAC extensions
   - Roles defined: Admin, Manager, Member, Viewer, API
   - Attributes for context: IP range, time of day, risk score
   - Relationship-based: Resource ownership, team membership

2. Role Definitions

   Admin:
   - All CRUD operations on all resources
   - User management (except cannot modify own permissions)
   - System configuration
   - Audit log access
   Require: MFA, approval workflow for creation

   Manager:
   - CRUD on resources within their department
   - Read access to cross-department resources
   - Approve member-level requests
   Require: MFA for write operations

   Member:
   - CRUD on self-owned resources
   - Read access to shared resources
   - Cannot modify other users

   Viewer:
   - Read-only access to specified resources
   - No export capability (data loss prevention)

3. Permission Granularity
   - Actions: Create, Read, Update, Delete, Export, Share, Admin
   - Resources: Users, Documents, Projects, Teams, Settings
   - Scopes: Global, Organization, Team, Self-owned

4. Least Privilege Enforcement
   - Default: No access (explicit grant required)
   - Access review: Quarterly review of all elevated permissions
   - Temporary elevation: Time-boxed access with automatic revocation
   - Separation of duties: Critical operations require 2-person approval

Data protection requirements specify how sensitive data is secured throughout its lifecycle—in transit, at rest, and in use.

Data Classification:

Before specifying protection requirements, classify data by sensitivity:

Privacy Requirements (GDPR/CCPA):

Privacy Requirements:

1. Data Subject Rights
   - Right to access: Export user's data within 30 days of request
   - Right to rectification: Allow users to correct their data
   - Right to erasure: Delete user data within 30 days of request
   - Right to portability: Provide data in machine-readable format
   - Right to object: Allow opt-out of processing for marketing

2. Consent Management
   - Consent records: Track what user consented to and when
   - Consent withdrawal: Process withdrawal within 24 hours
   - Granular consent: Separate consent for different purposes
   - No dark patterns: Consent must be freely given, not coerced

3. Privacy by Design
   - Default to privacy: Most restrictive settings by default
   - Data mapping: Maintain inventory of where personal data exists
   - Impact assessments: DPIA for new features processing PII

Network security requirements define how the system is protected at the network layer, controlling traffic flow and preventing unauthorized access.

Network Security Architecture:

Network Security Requirements Specification:

Network Security Requirements:

1. Network Architecture
   - VPC design: Public, private, and isolated subnets
   - Internet exposure: Only load balancers in public subnets
   - Database access: Private subnet only, no public IP
   - NAT gateway: Outbound internet for private resources

2. Traffic Control
   - Default inbound: Deny all
   - Allowed inbound: HTTPS (443), explicit service ports
   - SSH/RDP: Disabled for public access; use bastion or SSM
   - Inter-service: Explicit security group rules per service pair

3. DDoS Protection
   - L3/L4 protection: Automatic via AWS Shield Standard
   - L7 protection: WAF with rate limiting (1000 req/s per IP)
   - Alert threshold: Alert if traffic exceeds 10x normal baseline
   - Mitigation: Automatic for known patterns, on-call for novel attacks

4. Web Application Firewall Rules
   - OWASP Core Rule Set: Enabled (SQL injection, XSS, etc.)
   - Rate limiting: 100 requests/second per IP to any single endpoint
   - Geographic blocking: Block high-risk countries if not serving them
   - Bot protection: Block known bad bots, challenge suspicious UA

5. API Security
   - Rate limiting: Per-key limits, burst handling
   - Request validation: Schema validation at gateway
   - Response filtering: Strip internal headers, hide server info
   - Payload limits: Maximum 10 MB request body

Security doesn't end at prevention. Detection and response capabilities are equally critical. Requirements must specify what is logged, how it's monitored, and how incidents are handled.

Security Logging Requirements:

Security requirements often originate from regulatory and compliance frameworks. Understanding applicable regulations is essential for complete requirement specification.

Common Compliance Frameworks:

Compliance Requirements Specification:

Compliance Requirements:

1. Applicable Frameworks
   - PCI DSS: System processes payment card data
   - GDPR: System stores EU customer data
   - SOC 2 Type II: Required by enterprise customers

2. PCI DSS Requirements
   - Scope: Payment processing and stored card data
   - Network segmentation: Card data environment (CDE) isolated
   - Encryption: TLS 1.2+ for transit, AES-256 for storage
   - Access: MFA for CDE access, quarterly access reviews
   - Logging: 1 year retention, daily log review
   - Vulnerability scanning: Quarterly ASV scans
   - Penetration testing: Annual, after significant changes

3. GDPR Requirements
   - Lawful basis: Document legal basis for each processing activity
   - Consent: Affirmative consent for marketing, granular options
   - Data subject rights: Implement access, portability, erasure
   - Cross-border: Standard contractual clauses for non-EU transfers
   - DPIA: Conduct for new features involving personal data
   - DPO: Appointed, contact details published
   - Breach notification: Process to notify within 72 hours

4. SOC 2 Requirements
   - Security: Access controls, encryption, monitoring
   - Availability: Uptime SLAs, disaster recovery, incident response
   - Audit evidence: All controls documented, evidence collected
   - Third-party auditor: Annual Type II audit

5. Certification Timeline
   - SOC 2 Type I: Complete by [date]
   - SOC 2 Type II: Complete by [date + 6 months]
   - PCI DSS: Compliance by [date]
   - Annual recertification: Ongoing

We have covered the complete framework for security requirements. Let's consolidate the essential takeaways:

Module Complete:

With security requirements, we have completed the comprehensive exploration of non-functional requirements. You now have frameworks for specifying:

• Scalability: How the system handles growth
• Availability: How reliably the system operates
• Latency: How quickly the system responds
• Consistency: How accurate the system's data is
• Security: How protected the system is

These five dimensions form the foundation upon which all architectural decisions rest. A system designed without clear non-functional requirements is a system designed for failure—not because it doesn't work, but because it can't verify that it works the way it needs to.