This is an overview of the Quint 2 software qualities. It can be extended with the implications for a specific project

Availability of instructions for the user on how to interact with the software

The ability of software to withstand (and recover) from component, or environmental, failure.

Determines the ease of which the systems functions can be understood, relates to user mental models in Human Computer Interaction methods.

Amount of time the product is available to the user at the time it is needed.

This subcharacteristic concerns frequency of failure of the software.

Ease of verifying correctness of data processing on required points.

Characterizes response times for a given thru put, i.e. transaction rate.

A given software component or system does not typically function in isolation. This subcharacteristic concerns the ability of a software component to interact with other components or systems.

Characterizes the amount of effort to change a system.

Characterizes the sensitivity to change of a given system that is the negative impact that may be caused by system changes.

Ability to bring back a failed system to full operation, including data and network connections.

Characterizes the effort needed to verify (test) a system change.

Characterizes the plug and play aspect of software components, that is how easy is it to exchange a given software component within a specified environment.

User-friendliness in sytem usage

Where appropriate certain industry (or government) laws and guidelines need to be complied with, i.e. SOX. This subcharacteristic addresses the compliant capability of software.

Learning effort for different users, i.e. novice, expert, casual etc.

Ability of the software to be easily operated by a given user in a given environment.

Effort needed to reestablish the essential functionality after a breakdown.

Characterizes the effort required to install the software.

Characterizes resources used, i.e. memory, cpu, disk and network usage.

The ability to identify and fix a fault within a software component is what the maintainability characteristic addresses. In other software quality models this characteristic is referenced as supportability. Maintainability is impacted by code readability or complexity as well as modularization. Anything that helps with identifying the cause of a fault and then fixing the fault is the concern of maintainability. Also the ability to verify (or test) a system, i.e. testability, is one of the subcharacteristics of maintainability.

Clarity of the software product’s status (progression bars, etc.).

Effort needed to (re)establish the software’s running status.

Characterizes the ability to identify the root cause of a failure within the software.

This characteristic refers to how well the software can adopt to changes in its environment or with its requirements. The subcharacteristics of this characteristic include adaptability. Object oriented design and implementation practices can contribute to the extent to which this characteristic is present in a given system.

This refers to the correctness of the functions, an ATM may provide a cash dispensing function but is the amount correct?

This characteristic is concerned with the system resources used when providing the required functionality. The amount of disk space, memory, network etc. provides a good indication of this characteristic. As with a number of these characteristics, there are overlaps. For example the usability of a system is influenced by the system's Performance, in that if a system takes 3 hours to respond the system would not be easy to use although the essential issue is a performance or efficiency characteristic.

Once a software system is functioning, as specified, and delivered the reliability characteristic defines the capability of the system to maintain its service provision under defined conditions for defined periods of time. One aspect of this characteristic is fault tolerance that is the ability of a system to withstand component failure. For example if the network goes down for 20 seconds then comes back the system should be able to recover and continue functioning.

Satisfaction of latent user desires and preferences, through services, behavior and presentation beyond actual demands.

Clarity of making the user aware of the functions the software can perform.

Usability only exists with regard to functionality and refers to the ease of use for a given function. For example a function of an ATM machine is to dispense cash as requested. Placing common amounts on the screen for selection, i.e. $20.00, $40.00, $100.00 etc, does not impact the function of the ATM but addresses the Usability of the function. The ability to learn how to use a system (learnability) is also a major subcharacteristic of usability.

Characterizes the ability of the system to change to new specifications or operating environments.

This subcharacteristic relates to unauthorized access to the software functions.

Similar to compliance for functionality, but this characteristic relates to portability. One example would be Open SQL conformance which relates to portability of database used.

This is the essential Functionality characteristic and refers to the appropriateness (to specification) of the functions of the software.

Existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.

Potential for complete or partial reuse in another software product.