Definition of Software Quality

Understanding quality in software

Software quality can feel abstract in a planning meeting, yet it becomes concrete when customers struggle, release schedules slip, or maintenance costs climb. For leaders, getting specific about what quality means for your organization is the first step to getting predictable outcomes. A vague definition leads to scattered priorities, mismatched metrics, and rework that shows up as budget overrun or customer churn.

“In the context of software engineering, software quality measures how well the software is designed (quality of design), and how well the software conforms to that design (quality of conformance). It is often described as the ‘fitness for purpose’ of a piece of software.”

In engineering circles, quality is often described as fitness for purpose, the degree to which a product achieves its intended outcomes. That purpose is viewed through different lenses. Developers care about architecture and maintainability. Test leaders look for coverage of requirements, usability, performance, and security. End users experience whether the product is easy and reliable in their context. Executives look for market fit, compliance, and return on investment. A shared, contextual definition aligns these perspectives and gives teams a north star for decisions.

ISO 25010, the current reference model

Quality models emerged to help bridge the gap between what people expect and what software actually delivers. Early frameworks like McCall’s and Boehm’s organized attributes such as correctness, reliability, and maintainability so teams could talk about quality in a structured way. These models paved the path to today’s international standards, which most organizations now rely on to define and evaluate software quality in a consistent, comparable way.

ISO/IEC 25010 is the prevailing international standard for software product quality. It presents two complementary views. The product quality model covers characteristics such as functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability. The quality in use model focuses on the outcomes people experience in the real world, including effectiveness, efficiency, satisfaction, freedom from risk, and context coverage. Together they help leaders set requirements, choose metrics, and evaluate trade-offs with a common language.

This matters because quality decisions are trade-offs. An onboarding flow can be more secure with additional verification, yet that may increase friction for legitimate users. A build can be shipped faster by relaxing certain performance targets, yet customer retention may suffer. ISO 25010 provides a catalog of attributes that helps organizations decide deliberately which qualities are essential for their market and product, and which can be improved over time.

With those attributes defined, the next decision is how they influence business outcomes in day-to-day use.

Why non-functional requirements drive business outcomes

Functional requirements describe what the software does. Non-functional requirements describe how it behaves while doing it. Customers will rarely praise correct results if the experience is slow, confusing, or unreliable. Performance, usability, and reliability are not just technical ideals, they are business levers that influence conversion, retention, and support costs.

Consider web responsiveness. Google’s Core Web Vitals program centers on user-centric field metrics. In March 2024, Google formally replaced First Input Delay with Interaction to Next Paint, a responsiveness measure that captures the latency of real user interactions. This shift reflects how perceived responsiveness affects satisfaction and task completion, which are core to quality in use.

Performance also connects directly to revenue. Multiple industry analyses have shown a relationship between slow load times and abandonment on mobile. While percentages vary by study and segment, the direction is consistent, faster experiences tend to reduce bounce and improve conversion. When leaders weigh scope and timeline decisions, this link between non-functional quality and business KPIs should be explicit.

Security and privacy belong in the same conversation. The GDPR established data protection by design and by default as a legal requirement, placing responsibility on controllers to implement technical and organizational measures that enforce purpose limitation and data minimization. That is more than compliance language, it is a quality bar for systems that handle personal data in real contexts of use.

To make these qualities concrete for your team, the next section walks through each characteristic with a practical example.

Non-functional characteristics in practice

If you are familiar with ISO’s prior model of non-functional requirements, you will notice recent updates added sub-characteristics such as risk identification and user engagement, and introduced new organizing ideas such as interaction capability. Non-functional requirements must first be specified in clear, testable terms. Only then can they be satisfied in design and verified in validation. In many organizations, achieving non-functional targets is harder than meeting functional ones because the targets are cross-cutting and context dependent. The printer example below makes the difference concrete.

Functional Suitability

Completeness, correctness, and appropriateness. Does the print function help the user complete their task and objective, for example printing to a chosen device or to PDF without workarounds?

Performance Efficiency

Time behavior and resource use. Does the print function respond within a predefined number of seconds, and when does the first page begin printing under expected load?

Compatibility

Coexistence and interoperability. Can users print across networks and operating systems, and can one user print immediately after another who used a different platform or driver?

Interaction Capability

Learnability and user error protection. Can a user figure out how to print without help, and when an error occurs, is the message understandable and the recovery path clear?

Reliability

Fault tolerance and recoverability. If the printer is unplugged mid-job, is the user notified, are pages preserved, and can the print be resumed without starting over?

Security

Confidentiality, integrity, non-repudiation, authenticity, and accountability. Are credentials enforced for sensitive reports, is there a record of who printed what, and are outputs protected from unauthorized access?

Maintainability

Modularity, reusability, testability, and modifiability. Can test criteria be specified for printing, can the code be adapted for new output modes without risky rewrites?

Flexibility

Adaptability and installability. Can the software automatically detect a new printer or updated driver, and can advanced users access shortcuts without compromising clarity for others?

Safety

Prevention of harm to users, systems, and data. Does the software warn when the target printer is offline, or when page size and content are incompatible to avoid wasted paper or misleading output?

These characteristics do not live in isolation; they move through a lifecycle from process to product to real-world use.

The quality lifecycle you actually manage

Quality is shaped across four layers. Process quality covers how work gets done, including planning, reviews, test strategy, environments, and release management. Internal properties are the architecture and code structure. External properties are behavior observed during system testing. Quality in use is what customers experience in real contexts.

Figure 1, Software quality lifecycle, describes two flows. Influence moves from left to right as process decisions shape internal properties, which shape external behavior, which shapes quality in use. Evidence moves from right to left as measures in the field inform external measures, then internal measures, then process changes. When checkout abandonment rises, start with quality-in-use indicators, examine external behavior for the affected flow, inspect internal hotspots that drive that behavior, then make the process adjustment that prevents recurrence.

Key characteristics of quality in use

Figure 2, Quality in use characteristics, defines five outcomes to monitor in the field. Effectiveness is task completion. Efficiency is the time and effort required. Satisfaction reflects comfort, trust, and perceived usefulness. Freedom from risk addresses economic, safety, and environmental harms. Context coverage confirms that intended devices, locations, and scenarios are supported.

These outcomes link back to the earlier characteristics. For example, clear interaction capability and reliability targets in design tend to show up later as faster task completion, fewer recoveries, and fewer complaints in production analytics.

Making measurement practical and goal-driven

Leaders often ask which metrics matter. The better question is which outcomes matter, then which questions you need to answer to manage those outcomes, and finally which metrics provide evidence. This is the logic behind the Goal-Question-Metric approach pioneered in software engineering. You define the goal in context, derive the questions that reveal progress or risk, then choose a small set of metrics that answer those questions. This prevents dashboards from drifting into vanity measures that do not inform decisions.

Two measurement families tend to be useful together.

First, product quality and quality-in-use measures, for example defect trends by severity, crash-free session rates, task success rates, and support ticket patterns. These reflect what customers experience. Second, delivery performance measures that predict the organization’s ability to respond to change. The DORA research program popularized four such indicators, deployment frequency, lead time for changes, change failure rate, and time to restore service. These are correlated with software delivery performance in broad industry studies and help leaders see whether they can deliver quality improvements without gridlock.

When code-level risks need to be surfaced early, consider structural quality standards that can be automated in pipelines. ISO 5055 defines measures for security, reliability, performance efficiency, and maintainability based on known weakness patterns so teams can identify structural issues before they become customer-visible incidents. It complements outcome metrics with evidence from the code itself.

Finally, do not ignore cost signals. The cost of quality framework from the American Society for Quality distinguishes prevention and appraisal costs from internal and external failure costs. Seeing these costs together helps justify investments that reduce downstream failures such as production defects, security incidents, and reputation damage.

Requirements quality, the upstream leverage point

Many leaders equate quality with conformance to requirements. The hard part is that requirements are often ambiguous when they are written, and they evolve when stakeholders see working software. That is why modern teams use collaborative practices to make requirements testable and observable, for example clear acceptance criteria, prototypes and usability validation for critical flows, and explicit non-functional targets tied to business outcomes. When the feature at risk is revenue-critical or safety-critical, include user acceptance testing in realistic contexts and environments. This step usually reveals gaps that systematic functional testing does not expose, especially for performance, accessibility, and cross-platform behavior.

As requirements mature, connect them to the quality attributes you have prioritized. A login feature may have functional acceptance criteria, yet the quality bar is fully expressed only when you add targets such as median and tail response time, failed login error clarity, session management rules, attack-surface constraints, and auditability. This is how a definition of quality becomes an implementable specification.

Standards, regulations, and external definitions of quality

In regulated settings, quality is partially defined outside your organization. ISO testing standards provide terminology and process guidance for building test strategies that stand up to scrutiny, for example ISO/IEC/IEEE 29119 describes concepts and documentation families across the testing lifecycle. This does not replace context and judgment, yet it helps align stakeholders and auditors on what good looks like.

Privacy regulation influences the definition in a similar way. Article 25 of the GDPR requires data protection by design and by default, including purpose limitation, data minimization, and access control. Product and QA leaders translate that obligation into testable requirements and “quality in use” risks, because a system that violates privacy expectations is, by definition, low quality for the people it affects.

Leadership questions that clarify the definition

When you need a crisp definition of quality that teams can execute, these prompts help.

Which quality attributes are essential for our market, and how will we know we achieved them in the field? How does the definition change by customer segment or platform, for example mobile, web, or partner API? Which measures give us early warning that quality is drifting? How do we balance delivery speed with change failure rate and recovery time? Where does compliance shape or constrain our definition? Which few structural code risks must be prevented at source?

Clear answers align investment, reduce noise, and make trade-offs visible before they become incidents.

Putting it together, a working definition you can manage

An effective definition of software quality has three parts. First, a concise statement of fitness for purpose in your context, for example safe, reliable fund transfers within defined time thresholds on supported devices and networks. Second, a prioritized subset of ISO 25010 attributes with explicit targets, for example performance targets for critical flows, security controls for sensitive data, and usability outcomes for core tasks. Third, a measurement plan that combines field evidence, delivery indicators, and structural checks, for example quality-in-use analytics, DORA metrics, and automated code quality gates. This turns an abstract concept into a management system leaders can steer.