10.3 Non-Functional Requirements & Quality Attributes

10.3 Non-Functional Requirements & Quality Attributes

[!NOTE] The Quality Dimension on the PMI-PBA Exam: While functional requirements describe what a software system does, Non-Functional Requirements (NFRs) dictate how well the solution performs in production. PMI-PBA examination questions regularly test the candidate's capability to detect subjective, unmeasurable NFR statements, convert them into quantifiable metrics, balance architectural trade-offs between conflicting quality attributes, and evaluate reliability metrics such as MTBF, MTTR, RPO, and RTO.

---

The Primacy of Quality Attributes: Why NFRs Determine Solution Viability

In requirements engineering, projects rarely fail solely because of missing functional capabilities. A banking platform can calculate interest with mathematical perfection, but if the login portal crashes under peak trading volume or takes 45 seconds to load an account page, customers will abandon the service and brand equity will evaporate.

Non-Functional Requirements (NFRs)—formally designated as Quality Attributes, System Qualities, or Quality of Service (QoS) Requirements—define the operational characteristics, performance thresholds, security boundaries, and environmental constraints within which functional capabilities must execute.

Under The PMI Guide to Business Analysis, quality attributes are not secondary afterthoughts to be addressed during deployment; they are primary architectural drivers that must be elicited, analyzed, and baselined concurrently with functional scope.

---

Taxonomy of Quality Attributes: The URPS+ Framework and ISO/IEC 25010

To ensure exhaustive elicitation of non-functional requirements, business analysts utilize standardized classification frameworks. The most prominent model referenced in PMI standards and modern software architecture is the URPS+ framework (originally developed by Robert Grady at Hewlett-Packard) and its international counterpart, ISO/IEC 25010:

+===================================================================================+
|                         THE URPS+ REQUIREMENTS FRAMEWORK                          |
+===================================================================================+
| U - USABILITY      : Human factors, cognitive ergonomics, learnability, WCAG      |
| R - RELIABILITY    : Availability, fault tolerance, MTBF, MTTR, disaster recovery |
| P - PERFORMANCE    : Latency percentiles, throughput (TPS), concurrency, bandwidth|
| S - SUPPORTABILITY : Maintainability, modularity, testability, extensibility      |
| + - THE EXTENSIONS : Security (CIA), Scalability (horizontal/vertical), Compliance|
+===================================================================================+

Detailed Breakdown of the URPS+ Dimensions

1. Usability (Ergonomics, Human Factors & Accessibility):

   • Learnability: How rapidly a novice user can achieve basic competency (e.g., "A newly onboarded loan intake clerk shall complete an application submission in under 10 minutes without instructor guidance after completing 1 hour of CBT training").
   • Task Completion Efficiency: Number of clicks, keystrokes, or seconds required to execute a common workflow.
   • Accessibility: Compliance with statutory civil rights and digital inclusion standards (such as WCAG 2.2 Level AA, ADA, Section 508), including screen reader compatibility, keyboard-only navigation, and high-contrast color palettes.

2. Reliability (Fault Tolerance, Availability & Durability):

   • Availability: Percentage of planned operational time the system is accessible to end users.
   • Mean Time Between Failures (MTBF): The predicted elapsed time between inherent operational failures during normal system operation.
   • Mean Time to Repair / Recover (MTTR): The average time required to troubleshoot, fix, and restore an operational system following an outage.
   • Data Durability & Integrity: Guaranteeing that stored transactions remain uncorrupted and mathematically consistent across distributed databases.

3. Performance (Latency, Throughput & Resource Utilization):

   • Response Time / Latency: The elapsed time from when a user submits an action until the system returns an observable result. Professional NFRs specify latency across statistical distributions (such as p50, p95, and p99 percentiles) rather than simple mathematical averages.
   • Throughput: Number of successful operations executed per unit of time (e.g., Transactions Per Second [TPS], queries per second, or records batch-processed per hour).
   • Concurrency: Number of simultaneous users or active sessions supported without degrading latency beyond agreed thresholds.

4. Supportability (Maintainability, Testability & Extensibility):

   • Maintainability: Ease with which software components can be modified, patched, or refactored.
   • Testability: The degree to which software modules expose interfaces, logs, and mocks for automated testing suites.
   • Portability & Modularity: The ability of the software to run across diverse operating systems, browsers, and cloud container environments without code changes.

5. The "+" Extensions (Security, Scalability & Compliance):

   • Security: Confidentiality, Integrity, and Availability (The CIA Triad), role-based access control (RBAC), multi-factor authentication (MFA), vulnerability mitigation, and encryption protocols (AES-256 at rest, TLS 1.3 in transit).
   • Scalability: The capacity of the architecture to handle increased workloads by adding hardware resources horizontally (adding more compute nodes) or vertically (adding CPU/RAM to existing nodes).
   • Compliance & Statutory Governance: Adherence to legal, regulatory, and industrial mandates (e.g., GDPR, HIPAA, PCI-DSS, SOX, CCPA), including immutable audit trails and data retention rules.

---

The "Vague NFR Trap" and the Metric Quantification Formula

The most pervasive error in requirements analysis is authoring subjective, unquantifiable NFRs. When requirements contain ambiguous adjectives, testing teams cannot verify them, architects cannot design for them, and business stakeholders argue over interpretation.

+-----------------------------------------------------------------------------------+
|                         THE VAGUE NFR TRAP VS. QUANTIFIED NFR                     |
+-----------------------------------------------------------------------------------+
| VAGUE (UNTESTABLE) : "The new mortgage portal shall be fast and user-friendly."   |
|                                                                                   |
| QUANTIFIED         : "Under a peak workload of 1,200 concurrent user sessions,    |
| (TESTABLE)           95% of mortgage pre-approval quote requests (p95) shall      |
|                      render the complete decision results screen within           |
|                      1,800 milliseconds, as measured by synthetic APM monitoring."|
+-----------------------------------------------------------------------------------+

The Five-Element Metric Quantification Formula

To ensure an NFR is verifiable, the business analyst must apply the Five-Element Formula:

1. Target Quality Attribute: The exact parameter being constrained (e.g., API Latency, Database Uptime, Error Rate).
2. Measurement Unit: An objective, standard unit of measure (e.g., Milliseconds, Percentage, Transactions/Second, Decibels).
3. Operational Context / Workload Baseline: The real-world operating conditions under which the metric applies (e.g., "during peak end-of-month financial closing", "under 5,000 concurrent shopping carts").
4. Acceptable Threshold & Statistical Boundary: The quantitative target, preferably referencing percentiles or failure tolerances (e.g., "<= 800ms at p99", ">= 99.95% uptime").
5. Verification & Measurement Instrument: The tool, methodology, or audit process that proves compliance (e.g., "load testing via Apache JMeter", "automated third-party penetration testing audit").

---

Operationalizing Quality Attributes: SLAs, SLOs, and SLIs

In enterprise systems, non-functional requirements are operationalized and governed through the site reliability engineering (SRE) hierarchy of SLIs, SLOs, and SLAs:

+===================================================================================+
|                      THE SLI / SLO / SLA OPERATIONAL PYRAMID                      |
+===================================================================================+
| SERVICE LEVEL INDICATOR (SLI) : "What is the actual measured performance?"       |
| (e.g., The real-time latency of the checkout API measured at the load balancer)   |
|                                                                                   |
| SERVICE LEVEL OBJECTIVE (SLO) : "What is our internal engineering target?"       |
| (e.g., 99.5% of checkout requests shall resolve in < 500ms over a 30-day window)  |
|                                                                                   |
| SERVICE LEVEL AGREEMENT (SLA) : "What is our contractually binding guarantee?"    |
| (e.g., 99.0% of checkouts resolve in < 1,000ms, or client receives a 10% credit) |
+===================================================================================+

Error Budgets and Feature Velocity

The mathematical gap between the internal engineering target (SLO, e.g., 99.9%) and total perfection (100%) represents the Error Budget (0.1%).

• If system performance remains well within the error budget, the project team can release new features rapidly.
• If production incidents exhaust the error budget, feature releases are automatically frozen, and all engineering resources are redirected to non-functional refactoring, stability, and reliability hardening.

---

Reliability Engineering: Availability Math, MTBF, MTTR, RPO, and RTO

Reliability requirements must be specified with mathematical rigor. Two fundamental equations govern availability and disaster recovery:

The Availability Formula

System availability is mathematically defined as the ratio of uptime to total operating time, expressed as a function of Mean Time Between Failures (MTBF) and Mean Time to Repair (MTTR):

\text{Availability (A)} = \left( \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}} \right) \times 100\%$$$${}

Where:

• MTBF (Uptime) represents the operational reliability of the system components.
• MTTR (Downtime) represents the speed and efficiency of the incident response, failover automation, and recovery procedures.

The Exponential Cost of "The Nines"

On the PMI-PBA exam, candidates must recognize that increasing availability requirements triggers an exponential cost curve. Each additional "nine" of availability requires disproportionately complex, expensive architectural redundancies (such as multi-region active-active clustering, real-time cross-continent data replication, and automated hitless failover):

Disaster Recovery: RPO versus RTO

In business continuity planning, the business analyst collaborates with stakeholders to establish two critical recovery parameters:

+===================================================================================+
|                     DISASTER RECOVERY: RPO VERSUS RTO                             |
+===================================================================================+
|              PAST (Data)                    OUTAGE               FUTURE (Time)    |
| <─────────────────────────────────────────────┼─────────────────────────────────> |
|                  RPO                          │               RTO                 |
|       [Recovery Point Objective]              │    [Recovery Time Objective]      |
|       "How much data can we lose?"            │    "How long can we be down?"     |
| (e.g., Max 15 minutes of transactional data)  │ (e.g., Systems online within 2 hrs)|
+===================================================================================+

1. Recovery Point Objective (RPO):

   • Defines the maximum acceptable age of data that can be lost in the event of an unscheduled catastrophic disaster, measured backward in time from the moment of outage.
   • An RPO of 15 minutes mandates that automated database snapshots or transaction log replications occur at least every 15 minutes.
   • An RPO of 0 mandates continuous synchronous replication across geographically separated data centers.

2. Recovery Time Objective (RTO):

   • Defines the maximum acceptable duration of time that the business can tolerate a system being offline before operations are restored, measured forward in time from the outage.
   • An RTO of 4 hours means the technical team has exactly 4 hours to provision new infrastructure, restore database snapshots, reroute DNS traffic, and validate system integrity.

---

Navigating Quality Attribute Trade-Offs

A critical responsibility of the certified business analyst is exposing and resolving conflicting non-functional requirements. Software architecture is the science of trade-offs; optimizing for one quality attribute almost invariably compromises another:

+-----------------------------------------------------------------------------------+
|                         CLASSIC QUALITY ATTRIBUTE TRADE-OFFS                      |
+-----------------------------------------------------------------------------------+
| 1. Performance vs. Security      : Deep packet inspection, AES-256 encryption,    |
|                                    and MFA handshakes add compute latency.        |
|                                                                                   |
| 2. Availability vs. Cost         : Achieving 99.999% uptime multiplies cloud      |
|                                    infrastructure, bandwidth, and licensing costs.|
|                                                                                   |
| 3. Usability vs. Security        : Frictionless 1-click checkout conflicts with   |
|                                    mandated biometric multi-factor authentication.|
|                                                                                   |
| 4. Maintainability vs. Latency   : Highly decoupled microservices introduce       |
|                                    network serialization latency vs. monoliths.   |
+-----------------------------------------------------------------------------------+

When trade-offs emerge, the business analyst does not make arbitrary technical choices. Instead, the analyst articulates the business consequences, models the financial costs, and guides business leaders through structured trade-off analysis.

---

Non-Functional Requirements Metrics Specification Table