CACrown ArchivesThe cinema collection
Menu
Research dossier · Science & Nature

Software quality

degree of suitability of software for the intended purpose, including functional quality and structural quality

Specimen drawers, botanical folios and brass scientific instruments under study light
Science and natureInterpretive dossier study · Crown Archives visual atlas
Record originEnglish Wikipedia
Text licenseCC BY-SA 4.0
Source revisionJul 21, 2026
Entity authorityQ1412670
Source-derived summary

In the context of software engineering, software quality refers to two related but distinct notions:

Software's functional quality reflects how well it complies with or conforms to a given design, based on functional requirements or specifications. That attribute can also be described as the fitness for the purpose of a piece of software or how it compares to competitors in the marketplace as a worthwhile product. It is the degree to which the correct software was produced.

Software structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability. It has a lot more to do with the degree to which the software works as needed.

Many aspects of structural quality can be evaluated only statically through the analysis of the software's inner structure, its source code (see Software metrics), at the unit level, and at the system level (sometimes referred to as end-to-end testing), which is in effect how its architecture adheres to sound principles of software architecture outlined in a paper on the topic by Object Management Group (OMG).

Some structural qualities, such as usability, can be assessed only dynamically (users or others acting on their behalf interact with the software or, at least, some prototype or partial implementation; even the interaction with a mock version made in cardboard represents a dynamic test because such version can be considered a prototype). Other aspects, such as reliability, might involve not only the software but also the underlying hardware, therefore, it can be assessed both statically and dynamically (stress test).

Using automated tests and fitness functions can help to maintain some of the quality related attributes.

Functional quality is typically assessed dynamically but it is also possible to use static tests (such as software reviews).

Editorial summary

This brief starts where responsible research should: with the source description of “Software quality” as degree of suitability of software for the intended purpose, including functional quality and structural quality. Everything that follows is an evidence route, not borrowed authority.

Editorial reviewA practical orientation to terminology and classification, particularly when read beside dated observations, specimens or technical literature. The current 296-word lead offers orientation but no explicit four-digit date, so chronology should not be assumed. The selected authority fields contribute no independent date. The account is most persuasive where Software, quality and degree can be independently traced.
Editorial analysis

Why this record matters

The subject matters to the science & nature register because the source frames it as degree of suitability of software for the intended purpose, including functional quality and structural quality. Its deeper value depends on whether names, dates, institutions and citations support that framing.

Evidence profile

Datasets, specimens, observations and peer-reviewed methods provide the appropriate test for the technical claims summarized here. The source revision retrieved here is dated Jul 21, 2026. The linked authority identifier is Q1412670. None of the 0 selected statements returned an explicit reference.

Critical limits

A general summary may omit uncertainty, sample limits or methodological disagreement that is explicit in the technical record. The source lead contains qualifying language; that uncertainty should survive quotation, summary and reuse. Authority statements aid reconciliation but still require their own references, qualifiers and ranks to be checked.

How to read it

Check terminology, classification and the date of the cited evidence. Scientific names and technical consensus can change while older records retain historical value.

Best used for
  • Current terminology
  • Classification context
  • Finding cited technical literature
Verify next

Primary datasets, specimen catalogues, standards bodies and the most recent peer-reviewed literature.

Three-step research path

  1. Establish the record: confirm the title “Software quality”, its source revision and the description used here.
  2. Expand the search: follow Software quality primary sources, Software quality archive and Software research across catalogues and specialist indexes.
  3. Test the account: compare the strongest cited source with the responsible institution’s current record and note any disagreement.

Questions for further research

  1. Which source most directly establishes the central claim about “Software quality”?
  2. Has classification or technical consensus changed since the cited source?
  3. Is the terminology current, historical or disputed?
Subject index

Search terms from this dossier

Source & attribution

This entry incorporates text from Software quality” on English Wikipedia. Contributors are listed in the page history. Text is available under the Creative Commons Attribution-ShareAlike 4.0 License. Selected authority identifiers and statements are retrieved from Wikidata under CC0; their references and qualifiers remain part of the verification path.