Day 24: Beyond Speed, Stability, and Security – Defining Quality Requirements with Six Elements

Why Vague Quality Goals Are Not Enough

Product managers demand a “fast” system, operations require it to be “stable,” and security teams insist on “patient data safety.” These statements are directionally correct but lack measurability, making them mere wishes for architects.

Without concrete numbers, architects cannot design, load‑test, or accept a system. For example, is “fast” 2 seconds or 20 seconds? Is “stable” a 30‑second recovery or half‑day? How should “secure” be verified?

From Vague to Verifiable Requirements

Vague: “The registration system must be fast.”

Verifiable: “During the 8 am weekday registration peak, 10 000 patients simultaneously request registration. The system must complete identity verification, decrement slot count, and return results, with 95 % of requests finishing within 2 seconds and an error rate below 0.1 %.”

This precise statement guides architecture, performance testing, and acceptance.

Quality‑Attribute Scenario Six Elements

Stimulus source → Stimulus → Environment → Artifact → Response → Response metric

Plain‑language translation:

Who → Does what → Under what conditions → Affects which part of the system → How the system reacts → What quantitative threshold defines success.

1. Stimulus Source

The person, system, device, or component that generates the stimulus. Examples: patients, attackers, administrators, payment platforms, database nodes.

2. Stimulus

The event or condition the system must handle. Examples: a patient submits a registration request, a database primary node fails, an attacker attempts illegal access, a product manager proposes a feature change, an external payment interface returns an error.

3. Environment

The runtime conditions when the stimulus occurs (not a physical location). Examples: normal operation, registration peak, system overload, partial node failure, degraded mode, maintenance window. “8 am weekday registration peak” is an environment.

4. Artifact

The part of the system impacted by the stimulus. Examples: registration service, patient‑record database, payment interface, notification service, UI, the entire internet‑hospital system. It is the affected subsystem, not a product output.

5. Response

The actions the system takes after the stimulus reaches the artifact. Examples: complete request and return result, detect and isolate fault, switch to standby node, reject unauthorized access, record audit log and alert, modify component and retest.

“Switch to standby node” is a response; “switch within 30 seconds” is the response metric.

6. Response Metric

Quantitative criteria that determine whether the response meets the requirement. Common metrics include response time, throughput, concurrency, error rate, recovery time, data loss, modification cost, and impact scope. Example metrics: 95 % of requests finish within 2 seconds, error rate < 0.1 %, recovery within 30 seconds, data loss ≤ 1 second, alert within 5 seconds, modification ≤ 5 person‑days, impact ≤ 3 modules.

Concrete Scenarios

Performance Scenario – Registration Peak

During the 8 am weekday registration peak, 10 000 patients simultaneously submit registration requests. The system must perform identity verification, decrement slot count, and return results. 95 % of requests must complete within 2 seconds, error rate < 0.1 %, and no over‑booking.

Stimulus source: 10 000 patients

Stimulus: simultaneous registration requests

Environment: 8 am weekday peak

Artifact: registration service

Response: verify identity, decrement slot, return result

Response metric: 95 % ≤ 2 s, error < 0.1 %

Availability Scenario – Database Failure

When the system is running normally and the primary database node fails, the registration data service must detect and isolate the fault, switch to a standby node, recover within 30 seconds, and lose no more than 1 second of data.

Stimulus source: primary database node

Stimulus: node failure

Environment: normal operation

Artifact: registration data service / database cluster

Response: detect, isolate, switch to standby

Response metric: recovery ≤ 30 s, data loss ≤ 1 s (RTO = 30 s, RPO = 1 s)

Security Scenario – Illegal Record Access

While the system is normally connected, an unauthorized attacker attempts to read patient records. The medical‑record service must reject the request, record an audit log, and raise an alert; all unauthorized requests must be denied and an alert generated within 5 seconds.

Stimulus source: attacker

Stimulus: illegal read attempt

Environment: normal networked operation

Artifact: medical‑record service

Response: reject, audit, alert

Response metric: 100 % denial, alert ≤ 5 s

Modifiability Scenario – Adding a Payment Channel

After the system enters a normal iteration phase, the product manager proposes integrating a new insurance payment channel. Maintenance staff should add a new payment adapter without changing core registration logic; the change must be completed within 5 person‑days, affect no more than 3 modules, and pass all existing tests.

Stimulus source: product manager

Stimulus: request to add insurance payment channel

Environment: normal iteration phase

Artifact: payment interface and module

Response: add adapter, test, deploy

Response metric: ≤ 5 person‑days, ≤ 3 modules impacted, all tests pass

Common Metrics for Quality Attributes

Performance : response time, throughput, concurrency, resource utilization

Availability : availability rate, fault detection time, recovery time, data loss

Security : block rate, detection time, alert time, audit completeness

Modifiability : modification time, person‑days, cost, number of impacted modules

Usability : task completion time, error count, learning time, success rate

Testability : fault localization time, test coverage, test execution time

Do not place architectural solutions (e.g., caching, master‑slave, encryption, adapters) into response metrics; metrics must answer “to what extent is the response acceptable.”

Use‑Case vs. Quality‑Attribute Scenario

Use‑case view focuses on “what the system does” (e.g., patient selects doctor, queries schedule, submits registration, completes payment).

Quality‑attribute scenario focuses on “how well the system does it” (e.g., 95 % of registration requests finish within 2 seconds during peak).

Both can be combined: first describe the use case, then specify the quality‑attribute scenario for performance, availability, etc.

How to Decompose a Question into Six Elements

Round 1 – Identify “who” (stimulus source) and “what happened” (stimulus).

Round 2 – Identify the operating condition (environment) and the impacted subsystem (artifact).

Round 3 – Separate the action (response) from the quantitative criteria (response metric).

Answer Template for Exam Questions

The scenario includes stimulus source, stimulus, environment, artifact, response, and response metric. In the environment , when the stimulus source applies the stimulus to the artifact , the system should response and achieve the response metric .

Eight Common Mistakes

Confusing stimulus source (who) with stimulus (what they did).

Treating environment as a physical location instead of a runtime condition.

Mistaking artifact for the system’s output product.

Mixing response (action) with response metric (degree).

Leaving quality goals unmeasured (e.g., “system must be fast”).

Using non‑quantitative metrics; prefer time, percentage, count, cost, impact.

Including architectural solutions (e.g., “use cache”) as metrics.

Listing six words without ensuring they describe a single real event.

Self‑Test Questions and Answers

Answers include the correct order of the six elements (stimulus source, stimulus, environment, artifact, response, response metric) and identification of each element in the given examples.

1. B – The formal order is stimulus source, stimulus, environment, artifact, response, response metric. 2. A – “Attacker” is the stimulus source; “attempt to read” is the stimulus. 3. C – It describes the runtime condition of the stimulus. 4. D – Registration service is the artifact (the part of the system affected). 5. C – “Detect and switch” is the response; “30 seconds” is the metric. 6. D – “95 % of requests in 2 seconds” is a response metric. 7. C – Provides environment, response goal, and verifiable quantitative indicators. 8. A – Modification time and impacted modules are metrics of modifiability.

Memorization Card

Quality‑Attribute Scenario: Stimulus source, Stimulus, Environment, Artifact, Response, Response metric. Mnemonic: “Who does what, under what conditions, affects where, system does how, to what degree it passes.”