Skip to main content

Functional vs Quality Requirements: The ATAM Mindset

What This Concept Is​

Every system has two kinds of requirements:

  • Functional requirements describe what the system does. "A customer can place an order." "A teller can reverse a transaction in the same business day."
  • Quality requirements (also called non-functional requirements, NFRs, or architectural characteristics) describe how well the system must do it. "The order API responds in under 300 ms at the 95th percentile during a flash sale." "Transaction reversals are durable across a single-datacenter failure."

The Architecture Tradeoff Analysis Method (ATAM) is the discipline of making qualities measurable and deliberate rather than adjectives on a slide. In ATAM terms, a quality is only usable if it has:

  • a stimulus (what happens)
  • an environment (under what conditions)
  • a response (what the system does)
  • a response measure (how we know we succeeded)

"Fast" is not a requirement. "95% of order-submission requests complete in under 300 ms during normal hours" is.

Why It Matters Here​

Functional requirements are the easier half of system building. Most teams can ship them, at least once. Quality requirements are where systems fail, because:

  • stakeholders state them as adjectives ("scalable," "secure," "modern")
  • engineers translate those adjectives into whatever they happen to know
  • nobody notices the mismatch until production

The ATAM mindset forces the conversation into measurable shape before architectural decisions are made. The scenario format is the smallest unit that cannot be faked.

Concrete Example​

A payments platform handles bank-teller transactions. Here are three stakeholder statements and their ATAM rewrites.

Before (adjective form): "Transaction processing should be fast."

After (scenario form):

  • Stimulus: a teller submits a transaction through the branch client.
  • Environment: normal business hours, standard backend load.
  • Response: the transaction is accepted or declined.
  • Response measure: 99% of submissions receive a response within 800 ms; 99.9% within 2 s.

Before: "The system should be available."

After:

  • Stimulus: a single region's primary database becomes unreachable.
  • Environment: during a banking day, read and write load present.
  • Response: the ledger service fails over to a replica within defined RPO/RTO and resumes operation.
  • Response measure: read-only operation in under 30 s; full read-write in under 5 min; RPO ≤ 60 s of lost writes.

Before: "We need good security for regulatory compliance."

After:

  • Stimulus: a user (teller or support engineer) attempts to view the full account number of a customer.
  • Environment: any environment including dev, staging, and production.
  • Response: the access is denied unless the user has the pii:read role granted in the last 24 hours.
  • Response measure: 100% of denials logged; 0 full account numbers in any log file; monthly audit produces zero findings.

Each "before" could be interpreted six different ways. Each "after" tells an engineer what to build and a reviewer how to check it.

Common Confusion / Misconception​

"Non-functional means less important." Non-functional usually determines whether the functional ever ships successfully. The name is unfortunate; prefer "quality" or "characteristic."

"We'll add the NFRs later." Qualities tend to be expensive to retrofit. Adding strong consistency to a system that shipped on eventual consistency is a rewrite.

"ATAM is a heavyweight methodology." The full ATAM workshop is heavy. The mindset - writing qualities as scenarios with measures - is lightweight enough for a single meeting. This module uses the mindset, not the full method.

"Scenarios should list every edge case." A good scenario captures the most informative case, not an exhaustive list. One scenario per quality is often enough at the architecture level.

How To Use It​

Any time a stakeholder gives you an adjective about the system, demand a scenario. The questions are always the same:

  1. What triggers this? (stimulus)
  2. Under what conditions? (environment)
  3. What does the system do? (response)
  4. How do we know we succeeded? (measurable response)

If the stakeholder cannot answer, the quality is not ready to be designed against. That is valuable information on its own - you now know the decision is premature.

Check Yourself​

  1. Rewrite "the streaming service should be reliable" as an ATAM scenario for a video-start API.
  2. What is the difference between a response ("the system logs the access") and a response measure ("100% of accesses logged, observable within 60 s")?
  3. Why does demanding a measurable scenario sometimes reveal that the "requirement" was a solution in disguise?

Mini Drill or Application​

Find a real requirements document or ticket at your work (or use one from a prior project). Pick 5 adjective-form quality statements and rewrite each as a scenario. For each, ask:

  • could a test or monitor detect the response?
  • could two engineers disagree about whether the system met it?

If the answer to the first is "no" or the second is "yes," the scenario is not finished.

Read This Only If Stuck​