These are properties of engineering systems.<\/p>\n\n\n\n
In software engineering, following are most used \u201c-ilities\u201d.<\/p>\n\n\n\n
1. Usability<\/p>\n\n\n\n
Software usability can be described as how effectively end users can use, learn, or control the system. Some questions to ask yourself to determine usability might be:<\/p>\n\n\n\n
Is there a UI metaphor that I am using to help users adapt? (for example, the \u2018desktop\u2019 is a metaphor)
\nAre the most common operations streamlined to be performed quickly?
\nCan new users quickly adapt to the software without help? (is it intuitive?)
\nDo validation and error messages make sense?
\n2. Maintainability ( or Flexibility \/ Testibility)<\/p>\n\n\n\n
The definition of maintainability [for me] implies how brittle the code is to change. As a result, I tie the terms flexibility and testability into the overall maintainability of a project.<\/p>\n\n\n\n
Does the entire team understand the code base or does knowledge islands exist?
\nIs the code throughly regression tested?
\nCan modifications to the project be done in a timely manner?<\/p>\n\n\n\n
3. Scalability<\/p>\n\n\n\n
Scalability is the ability for your program to gracefully meet the demand of stress caused by increased usage. In short, ensuring your program doesn\u2019t slow or bust when pounded by more users than you originally anticipated.<\/p>\n\n\n\n
What is your current peak load that you can handle?
\nHow many database records can create until critical operations slow down?
\nIs the primary scaling strategy to \u201cscale up\u201d or to \u201cscale out\u201d \u2014 that is, to upgrade the nodes in a fixed topology, or to add nodes?<\/p>\n\n\n\n
4. Availability (or Reliability)<\/p>\n\n\n\n
How long the system is up and running and the Mean Time Between Failure (MTBF) is known as the availability of a program.<\/p>\n\n\n\n
How long does the system need to run without failure?
\nWhat is the acceptable length of time for the system to be down?
\nCan down times be scheduled?<\/p>\n\n\n\n
5. Extensibility<\/p>\n\n\n\n
Are there points in the system where changes can be made with (or without) program changes?<\/p>\n\n\n\n
Can the database schema flex to accommodate change?
\nDoes the system allow Inversion of Control (IoC)?
\nCan end users extend the system (scripts, user defined fields, etc)?
\nCan 3rd party developers leverage your system?<\/p>\n\n\n\n
6. Security<\/p>\n\n\n\n
I shouldn\u2019t need to go into this one but to be thorough I like this definition of security: the measure of system\u2019s ability to resist unauthorized attempts at usage or behavior modification, while still providing service to legitimate users.<\/p>\n\n\n\n
Does the system need user or role based security?
\nDoes code access security need to occur?
\nWhat operations need to be secured?
\nHow will users be administered?<\/p>\n\n\n\n
7. Portability<\/p>\n\n\n\n
Portability is the ability for your application to run on numerous platforms. This is can include actual application hosting, viewing, or data portability.<\/p>\n\n\n\n
Can the data be migrated to other systems?
\nFor web applications, which browsers does your web app support?
\nWhich operating systems does your program run on?
\nObviously, this is not an exhaustive list. There are many many more (Backwards compatibility, Interoperability, and Reusability to name a few)<\/p>\n\n\n\n
The following summary covers 17 software quality attributes through the lens of Enterprise Architecture and solution design. Definitions are aligned primarily with\u00a0ISO\/IEC 25010:2023<\/strong>, which defines a product quality model composed of main characteristics \u2014 including Functional Suitability, Performance Efficiency, Compatibility, Usability, Reliability, Security, Maintainability, and Portability \u2014 each decomposed into sub-characteristics. Where an attribute is not an explicit ISO\/IEC 25010 characteristic, it is described using accepted EA terminology, and its relationship to the standard is noted.<\/p>\n\n\n\n Definition:<\/strong>\u00a0The composite measure of a software system’s fitness for purpose across all functional and non-functional dimensions. In systems and software engineering, quality attributes are realized non-functional requirements used to evaluate the performance of a system, sometimes referred to as “architecture characteristics” or “-ilities”. Software architects are responsible for matching these attributes with business and user requirements.<\/p>\n\n\n\n Example:<\/strong> An enterprise CRM platform that consistently meets acceptance criteria across reliability, usability, security, and performance is judged high-quality because it satisfies stakeholder expectations holistically.<\/p>\n\n\n\n Definition:<\/strong>\u00a0The degree to which a system, product, or component performs specified functions under specified conditions for a specified period of time. ISO\/IEC 25010 decomposes Reliability into sub-characteristics including\u00a0Availability<\/strong>,\u00a0Fault Tolerance<\/strong>, and\u00a0Recoverability<\/strong>. In reliability engineering, it is formally defined as the probability that a product, system, or service will perform its intended function adequately for a specified period of time.<\/p>\n\n\n\n Example:<\/strong> A cloud-based payroll service engineered for fault tolerance and recoverability delivers consistent uptime, ensuring payroll runs on schedule despite individual component failures.<\/p>\n\n\n\n Definition:<\/strong>\u00a0The degree to which a system operates without causing unacceptable risk of harm. A widely referenced formal definition is “freedom from unacceptable risk” (ISO\/IEC 2014). In safety-critical systems, the acronym\u00a0RAMS<\/strong>\u00a0(Reliability, Availability, Maintainability, and Safety) is frequently used to address these concerns together. Safety is also closely related to\u00a0Dependability<\/strong>, which is an aggregate of availability, reliability, safety, integrity, and maintainability.<\/p>\n\n\n\n Example:<\/strong> An industrial IoT control system with built-in fail-safes that automatically shut down equipment when sensors report dangerous operating conditions prevents physical harm to operators.<\/p>\n\n\n\n EA tradeoff note:<\/strong> Increasing safety mechanisms (redundant checks, fail-safes) typically adds latency and development cost, creating tension with performance efficiency and time-to-market.<\/p>\n\n\n\n Definition:<\/strong>\u00a0The ability of a system to respond to potential internal or external changes affecting its value delivery, in a timely and cost-effective manner. Uncertainty is a key element: flexibility becomes valuable precisely because uncertainty creates both risks and opportunities.<\/p>\n\n\n\n Example:<\/strong> A configurable enterprise order-management platform that allows business analysts to adjust pricing rules and promotion logic without code changes responds swiftly to shifting market strategies.<\/p>\n\n\n\n Definition:<\/strong> The degree to which a system functions correctly and maintains stability under stress, invalid inputs, or abnormal conditions \u2014 degrading gracefully rather than failing catastrophically. A useful distinction: robust systems are designed to resist change and maintain stability through strength<\/strong>, whereas resilient systems focus on recovery after disruption.<\/p>\n\n\n\n Example:<\/strong> A banking API that continues processing valid transactions when it receives malformed requests \u2014 logging errors without crashing \u2014 demonstrates robust boundary handling.<\/p>\n\n\n\n Contrast with Resilience:<\/strong> Robustness prevents degradation under adverse conditions; resilience restores service after degradation has occurred.<\/p>\n\n\n\n Definition:<\/strong>\u00a0In database systems, durability is the ACID property that guarantees that the effects of committed transactions will survive permanently, even in cases of failures, including incidents and catastrophic events. More broadly in EA practice, durability refers to a system’s ability to remain operational and preserve data integrity over prolonged use without degradation.\u00a0<\/p>\n\n\n\n Example:<\/strong>\u00a0A flight-booking system where, once a seat is successfully reserved, the booking persists even if the system crashes immediately afterward \u2014 this illustrates durable transaction handling. Mechanisms include write-ahead logging (WAL) to non-volatile storage and replication strategies that provide logical stable memory.<\/p>\n\n\n\n Definition:<\/strong>\u00a0The property of a system to handle a growing amount of work, which for software systems may be achieved by adding resources to the system. Scalability can be measured across multiple dimensions, including\u00a0Administrative<\/strong>\u00a0(more organizations\/users),\u00a0Functional<\/strong>\u00a0(adding features without disruption),\u00a0Geographic<\/strong>\u00a0(expansion to larger regions),\u00a0Load<\/strong>\u00a0(heavier\/lighter traffic), and\u00a0Generation<\/strong>(adopting new component generations).<\/p>\n\n\n\n Two primary scaling strategies exist:<\/p>\n\n\n\n Example:<\/strong> A web application that seamlessly scales from hundreds to hundreds of thousands of concurrent users by dynamically adding cloud instances illustrates horizontal scalability.<\/p>\n\n\n\n EA tradeoff note:<\/strong>\u00a0Horizontal scaling avoids single-node limits but introduces distributed-systems complexity (synchronization, latency, data consistency). As a guiding principle, “a system is scalable in the range where marginal cost of additional workload is nearly constant”.<\/p>\n\n\n\n Definition:<\/strong>\u00a0Within ISO\/IEC 25010, Adaptability is a sub-characteristic of\u00a0Portability<\/strong>, describing the ability of software to be transferred and function effectively in different environments. An important nuance from software engineering:\u00a0adaptability<\/em>\u00a0refers to users substantially customising the system through tailoring activities, while\u00a0adaptivity<\/em>\u00a0refers to a system that adapts automatically to changing conditions.\u00a0<\/p>\n\n\n\n Example:<\/strong> A containerized microservice deployable across AWS, Azure, or on-premises Kubernetes clusters with minimal configuration changes \u2014 fitting diverse IT environments without rearchitecting.<\/p>\n\n\n\n Definition:<\/strong>\u00a0The ability of a system’s architecture to accommodate new features or capabilities through planned extension points (plug-ins, modules, APIs), with minimal change to existing components. In the systems-quality taxonomy, extensibility is one of seven attributes constituting\u00a0Agility<\/strong>\u00a0alongside debuggability, portability, scalability, securability, testability, and understandability.<\/p>\n\n\n\n Example:<\/strong> A corporate analytics platform that supports adding new data connectors via a plug-in framework, enriching its data-source ecosystem without altering core processing logic.<\/p>\n\n\n\n Definition:<\/strong>\u00a0The degree to which a software product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction. ISO\/IEC 25010 decomposes Usability into sub-characteristics:\u00a0Appropriateness Recognizability<\/strong>,\u00a0Learnability<\/strong>,\u00a0Operability<\/strong>,\u00a0User Error Protection<\/strong>,\u00a0User Interface Aesthetics<\/strong>, and\u00a0Accessibility<\/strong>.<\/p>\n\n\n\n Example:<\/strong> An internal employee self-service portal with clear navigation and contextual help that new hires can use without formal training \u2014 reducing support tickets and improving task-completion speed.<\/p>\n\n\n\n Definition:<\/strong>\u00a0A measure of how well internal states of a system can be inferred from knowledge of its external outputs. The concept originated in control theory (introduced by Rudolf E. K\u00e1lm\u00e1n for linear dynamic systems) and has been adopted in modern cloud-native and DevOps practice through the “three pillars” of logs, metrics, and distributed traces.<\/p>\n\n\n\n Example:<\/strong> A microservices platform instrumented with structured logging, distributed tracing, and real-time dashboards \u2014 enabling SRE teams to diagnose latency spikes or error cascades within minutes rather than hours.<\/p>\n\n\n\n EA tradeoff note:<\/strong> Comprehensive observability instrumentation increases telemetry data volume and storage costs; architects must balance depth of insight against operational overhead.<\/p>\n\n\n\n Definition:<\/strong>\u00a0The ability of a system to work seamlessly with other systems or components, exchanging data and services via agreed interfaces, formats, or protocols. ISO\/IEC 25010 places Interoperability alongside\u00a0Coexistence<\/strong>\u00a0as sub-characteristics of\u00a0Compatibility<\/strong>\u00a0\u2014 the ability to operate with other products or systems without negative impact.<\/p>\n\n\n\n Example:<\/strong> An enterprise data warehouse that integrates with ERP, CRM, and supply-chain systems via standardized APIs and open data formats, enabling frictionless data exchange across the organization’s software ecosystem.<\/p>\n\n\n\n Definition:<\/strong> The degree to which a software system can be maintained and evolved over the long term with acceptable cost, effort, and resource consumption \u2014 encompassing both technical sustainability<\/strong> (low technical debt, clean architecture) and environmental sustainability<\/strong> (energy-efficient computation, minimal resource waste). Academic research frames sustainability as a distinct property of software quality, addressing the environmental dimension of software performance.<\/p>\n\n\n\n Example:<\/strong> A corporate application built with clean-code practices, modular design, and energy-efficient deployment patterns that remains economical to operate, update, and extend on evolving infrastructure over a multi-year lifecycle.<\/p>\n\n\n\n Definition:<\/strong>\u00a0The ease with which a software product can be modified to correct defects, improve performance, or adapt to a changed environment. ISO\/IEC 25010 decomposes Maintainability into\u00a0Modularity<\/strong>,\u00a0Reusability<\/strong>,\u00a0Analyzability<\/strong>,\u00a0Modifiability<\/strong>, and\u00a0Testability<\/strong>. High maintainability is especially critical for long-term enterprise systems and DevOps success.<\/p>\n\n\n\n Example:<\/strong> A well-documented enterprise billing system with clear separation of concerns, where developers can implement regulatory changes or fix defects rapidly without triggering unintended side effects in adjacent modules.<\/p>\n\n\n\n Definition:<\/strong>\u00a0The degree to which test criteria can be established for a system and tests performed to determine whether those criteria have been met. As a sub-characteristic of Maintainability in ISO\/IEC 25010, testability directly enables confidence in releases and supports continuous delivery pipelines.\u00a0<\/p>\n\n\n\n Example:<\/strong> A service-oriented application designed with dependency injection and clearly separated logic layers that enables fully automated unit and integration test suites \u2014 QA teams can verify each release with high confidence and minimal manual effort.<\/p>\n\n\n\n Definition:<\/strong>\u00a0The degree to which a system is composed of discrete, well-encapsulated components with defined interfaces, so that a change to one component has minimal impact on others. ISO\/IEC 25010 lists Modularity as the first sub-characteristic of\u00a0Maintainability<\/strong>.<\/p>\n\n\n\n Example:<\/strong> An ERP system composed of independent, bounded modules (HR, Finance, Inventory) with clearly defined integration APIs \u2014 allowing a team to update the Inventory module without affecting HR or Finance.<\/p>\n\n\n\n Definition:<\/strong>\u00a0The capacity of a system to withstand disruption and\u00a0recover quickly<\/strong>, ensuring continuity of critical service. The key distinction from robustness: “Software is resilient if it can go back to normal after a disruption,” whereas robustness describes the ability to withstand high load before going down. Resilience is closely related to the ISO\/IEC 25010 Reliability sub-characteristics of Fault Tolerance and Recoverability.\u00a0<\/p>\n\n\n\n Example:<\/strong> A distributed e-commerce platform that automatically reroutes traffic to backup availability zones and preserves critical checkout operations even when a primary data center goes offline \u2014 restoring full service within seconds.<\/p>\n\n\n\n Architectural note:<\/strong> These attributes are interdependent and often involve tradeoffs. For example, maximizing safety may reduce performance efficiency; achieving high scalability may complicate maintainability; and deep observability increases operational costs. In TOGAF-based EA practice, architects should map these quality attributes to business requirements<\/strong> and negotiate acceptable tradeoff positions with stakeholders, recognizing that synchronous communication between architectural components entangles them and forces shared architectural characteristics. [en.wikipedia.org]<\/a><\/p>\n
\n\n\n\nQuality (Overarching Concept)<\/em><\/h3>\n\n\n\n
\n\n\n\nReliability (ISO\/IEC 25010 \u2014 Main Characteristic)<\/em><\/h3>\n\n\n\n
\n\n\n\nSafety (Recognized in RAMS; ISO\/IEC 25010:2023 evolution)<\/em><\/h3>\n\n\n\n
\n\n\n\nFlexibility (Not an explicit ISO\/IEC 25010 characteristic)<\/em><\/h3>\n\n\n\n
\n\n\n\nRobustness (Not an explicit ISO\/IEC 25010 characteristic)<\/em><\/h3>\n\n\n\n
\n\n\n\nDurability (Not a standalone ISO\/IEC 25010 characteristic; core ACID property)<\/em><\/h3>\n\n\n\n
\n\n\n\nScalability (Not an explicit ISO\/IEC 25010 characteristic)<\/em><\/h3>\n\n\n\n
\n
\n\n\n\nAdaptability (ISO\/IEC 25010 \u2014 Sub-characteristic under Portability)<\/em><\/h3>\n\n\n\n
\n\n\n\nExtensibility (Not an explicit ISO\/IEC 25010 characteristic; related to Agility)<\/em><\/h3>\n\n\n\n
\n\n\n\nUsability (ISO\/IEC 25010 \u2014 Main Characteristic)<\/em><\/h3>\n\n\n\n
\n\n\n\nObservability (Not an explicit ISO\/IEC 25010 characteristic; operational practice)<\/em><\/h3>\n\n\n\n
\n\n\n\nInteroperability (ISO\/IEC 25010 \u2014 Sub-characteristic under Compatibility)<\/em><\/h3>\n\n\n\n
\n\n\n\nSustainability (Not an explicit ISO\/IEC 25010 characteristic; emerging EA concern)<\/em><\/h3>\n\n\n\n
\n\n\n\nMaintainability (ISO\/IEC 25010 \u2014 Main Characteristic)<\/em><\/h3>\n\n\n\n
\n\n\n\nTestability (ISO\/IEC 25010 \u2014 Sub-characteristic under Maintainability)<\/em><\/h3>\n\n\n\n
\n\n\n\nModularity (ISO\/IEC 25010 \u2014 Sub-characteristic under Maintainability)<\/em><\/h3>\n\n\n\n
\n\n\n\nResilience (Not an explicit ISO\/IEC 25010 characteristic; related to Reliability)<\/em><\/h3>\n\n\n\n
\n\n\n\nQuick-Reference: ISO\/IEC 25010 Alignment Map<\/h3>\n\n\n\n
Attribute<\/th> ISO\/IEC 25010:2023 Status<\/th><\/tr><\/thead> Reliability<\/strong><\/td> Main characteristic (Availability, Fault Tolerance, Recoverability)<\/td><\/tr> Usability<\/strong><\/td> Main characteristic (Learnability, Operability, Accessibility, \u2026)<\/td><\/tr> Maintainability<\/strong><\/td> Main characteristic (Modularity, Reusability, Analyzability, Modifiability, Testability)<\/td><\/tr> Interoperability<\/strong><\/td> Sub-characteristic of Compatibility<\/td><\/tr> Adaptability<\/strong><\/td> Sub-characteristic of Portability<\/td><\/tr> Testability<\/strong><\/td> Sub-characteristic of Maintainability<\/td><\/tr> Modularity<\/strong><\/td> Sub-characteristic of Maintainability<\/td><\/tr> Safety<\/strong><\/td> Addressed via RAMS practice; related to Dependability aggregate<\/td><\/tr> Scalability<\/strong><\/td> addressed as architectural concern<\/td><\/tr> Flexibility<\/strong><\/td> addressed as architectural concern<\/td><\/tr> Robustness<\/strong><\/td> related to Fault Tolerance under Reliability<\/td><\/tr> Durability<\/strong><\/td> core ACID property for data systems<\/td><\/tr> Extensibility<\/strong><\/td> part of Agility aggregate\u00a0<\/td><\/tr> Observability<\/strong><\/td> This is one of the key qualities of a software systems or Systems engineering <\/td><\/tr> Sustainability<\/strong><\/td> Measure of usage of power and where the power is drawn<\/td><\/tr> Resilience<\/strong><\/td> Works with Recoverability and Fault Tolerance<\/td><\/tr> <\/td> <\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n