Catalog
concept#Architecture#Software Engineering#Reliability#Security

Non-Functional Requirements

Non-functional requirements specify a system's quality attributes (e.g. performance, security, maintainability) and complement functional requirements. They guide architecture, operations, and testing decisions.

Non-functional requirements define a system's quality attributes such as performance, security, scalability, and maintainability.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Intermediate

Technical context

Monitoring and observability tools (e.g. Prometheus)CI/CD pipeline for automated performance validationIncident management and SLA reporting systems

Principles & goals

Formulate measurable criteria (e.g. metrics, thresholds).Prioritize by business impact and risk.Plan early validation via tests and monitoring.
Discovery
Enterprise, Domain, Team

Use cases & scenarios

Compromises

  • Over-engineering can lead to cost overruns.
  • Unclear or conflicting requirements create implementation risks.
  • Lack of measurability prevents verification and operational control.
  • Formulate requirements as S.M.A.R.T. metrics.
  • Early validation via automated tests and load testing.
  • Implement regular review and prioritization cycles.

I/O & resources

  • Stakeholder goals and business requirements
  • Measurable performance and security targets
  • Existing system architecture and monitoring data
  • Catalog of non-functional requirements with metrics
  • Prioritized quality attributes and acceptance criteria
  • Test and monitoring plan for validation

Description

Non-functional requirements define a system's quality attributes such as performance, security, scalability, and maintainability. They complement functional requirements and influence architecture, design, and organizational decisions. Formulating measurable criteria enables verification, testing, and clear alignment with stakeholder expectations. They are critical for contractual agreements and operational reliability.

✔

  • Improved predictability and verifiability of quality goals.
  • Clear foundation for architecture and operational decisions.
  • Reduced risk of wrong assumptions and rework.

✖

  • Not all quality attributes can be fully satisfied simultaneously.
  • Measurability may be limited in early phases.
  • Increased effort for specification and validation.

  • Median/P95 response time

    Measure response time under load to assess performance.

  • Availability (uptime %)

    Percentage of operational time within defined windows.

  • Mean Time To Recovery (MTTR)

    Average time to recover after an outage.

SLA for payment service availability

Definition of measurable availability targets (e.g. 99.95%) and recovery times.

Performance definition for API endpoints

Concrete latency and throughput targets per endpoint with test cases.

Security requirements for personal data

Encryption, access controls and audit logs to satisfy data protection requirements.

1

Identify stakeholders and elicit quality goals.

2

Define metrics and acceptance criteria for each attribute.

3

Integrate tests, monitoring, and responsibilities into the delivery process.

⚠️ Technical debt & bottlenecks

  • Lack of observability complicates later validation.
  • Tight coupling reduces ability to scale.
  • Insufficient test coverage for load and security cases.
Monolithic componentsLack of observabilityDatabase performance bottleneck
  • Specifying 'high security' without concrete measures.
  • Setting unrealistic performance goals without test basis.
  • Ignoring operational requirements during cloud migration.
  • Not identifying conflicts between quality goals early enough.
  • Defining metrics without measurement infrastructure.
  • Forcing excessive detail in early phases.
Architecture and quality-model knowledgeTest automation and performance testingSecurity and compliance understanding
Availability and recovery time objectivesScalability under loadSecurity and privacy requirements
  • • Budget and operational constraints
  • • Regulatory requirements (e.g. data protection)
  • • Existing legacy systems