System Quality Attributes

System quality attributes (SQAs) — also called non-functional requirements (NFRs) or cross-cutting concerns — describe how well a system performs, as distinct from what it does (its functional requirements). A system can be functionally complete and still fail its users if it's slow, insecure, unmaintainable, or unreliable.

Complementary framings of the same idea

• System Quality Attributes (SQAs) — the broad umbrella term used here.
• Cross-Functional Constraints (CFCs) — requirements that cut across every feature rather than belonging to one (e.g. "every API response under 200ms").
• Non-Functional Requirements (NFRs) — the classic requirements- engineering term, contrasted with functional requirements.
• Cross-Cutting Concerns (CCCs) — the software-architecture framing, emphasizing that these concerns touch many modules rather than living in one.

A representative sample of attributes

Over 100 named attributes exist; a working set worth knowing by name and being able to define precisely (each is a real, distinct concept, not a synonym for "good quality" generically):

• Reliability, Availability, Durability, Fault-tolerance, Resiliency, Recoverability — different angles on "keeps working, or comes back quickly, when something goes wrong."
• Scalability (horizontal and vertical), Efficiency, Elasticity (not listed by name but related to Adaptivity/Autonomicity) — handling more load without a proportional cost increase.
• Security-adjacent: Auditability, Integrity, Accountability, Encryptability — different facets of "can be trusted and verified."
• Maintainability, Modifiability, Extensibility, Modularity, Refactorability — how cheaply the system can be changed later.
• Observability, Monitorability, Debugability, Traceability, Inspectability — how well you can tell what the system is actually doing.
• Usability, Learnability, Accessibility, Discoverability — how well real users (including users of assistive technology) can actually use it.
• Testability, Reproducibility, Determinability — how reliably you can verify the system behaves as intended.
• Portability, Interoperability, Compatibility, Configurability — how well it works across different environments and with other systems.

Choosing which of 100+ attributes actually matters for a given system is itself the design decision — not every attribute is relevant to every system, and treating them all as equally important produces an unfocused, unactionable requirements list.

Planning and tracking tools that use SQAs

• Key Performance Indicator (KPI) — see Key Performance Indicators for turning a chosen quality attribute into a tracked, targeted metric.
• Quality Assessment Report (QAR) — a structured report against chosen attributes at a point in time.
• System Quality Attributes Maturity Model (SQAMM) — applying Maturity Models's level-based structure specifically to quality-attribute capability.
• SQALE (Software Quality Assessment based on Lifecycle Expectations) — a model for quantifying technical debt against quality expectations.
• Chaos Engineering — deliberately injecting failure to empirically test Reliability/Resiliency/Fault-tolerance claims rather than assuming them from design alone.

How to use this in practice

1. From the full list, pick the handful of attributes that are actually decision-relevant for this specific system (a payments system prioritizes Integrity and Auditability differently than an internal admin tool does).
2. State each chosen attribute as a specific, checkable requirement, not just the attribute's name — "the system should be scalable" isn't actionable; "the system handles 10x current peak load with no architecture change" is.
3. Track the chosen attributes as real KPIs/QARs over time, not just at initial design — quality attributes degrade under sustained feature pressure if nothing is actively measuring them.

Common pitfalls

• Treating "non-functional" as "optional" or "later" — quality attributes are requirements, not nice-to-haves; deferring them indefinitely usually means retrofitting them expensively after the system already exists.
• Naming an attribute without defining it precisely for this system — "reliable" means something different for a life-safety system than for an internal reporting dashboard; the specific, checkable target is what makes the attribute actionable.
• Trying to maximize every attribute at once — many quality attributes trade off against each other (e.g. Security vs. Usability, Flexibility vs. Simplicity); an explicit prioritization is needed, not an attempt to be best-in-class on all 100+.
• Measuring an attribute once at launch and never again — attributes like Maintainability and Observability erode gradually under ordinary feature work unless something actively tracks and defends them.

Learn more

• joelparkerhenderson/system-quality-attributes — the source for this skill, with 100+ attributes each explained individually.
• Key Performance Indicators for turning a chosen attribute into a tracked metric.
• Maturity Models for assessing quality-attribute capability over levels.