Software engineering values are what every software engineer must learn to produce high-quality software.
A requirements specification must completely define the tasks that are to be performed by the program or system, as well as any constraints that are placed on its development or use.

Requirements are of several kinds:

Software is important to many people, who play a variety of roles with regard to the software.
Primary stakeholders have direct contact with the production of software and/or its use:

The purchaser pays for the software and determines its overall objectives.

If the software is developed under contract then the requirements specification for the software is negotiated between the purchaser and the developers.

The primary values of the purchaser are concerned with correctness, reliability, system data, delivery, and cost.

Software is correct if it meets its requirements specifications.

Determination of correctness requires assessment of functional requirements.

Correct software, of course, is more highly valued.

Reliability as a value acknowledges that products can fail to meet their specifications.

The value placed on reliability is an adaptation of correctness to the real world through quantification:

Failures can result from flaws in the requirements, design, or code.

Large programs or systems of programs often have the responsibility of maintaining a permanent body of data.

Such data may be subject to constraints:

Then the software must ensure that it does not violate these constraints.

The purchaser of software almost always prefers to have it earlier rather than later, and preferably by a given date and not "R.S.N.": The value of timely delivery explains why defective software is sometimes successful: Finally, the purchaser will want to pay the smallest price that will obtain the desired functionality and quality.
Users, who may not be purchasers, interact with the software.

For users, software values will center around correctness, robustness, and ease of use or usability.

Related to these general user values are more specific principles of user interface design, which are not discussed here.

Users are also concerned with correctness.

If the software behaves incorrectly it will probably add significantly to the time that it takes to accomplish a task, or make the task impossible.

Incorrect software may lead to user frustration and decrease the chance of user acceptance.

Robustness is the ability of software to handle exceptional conditions.

Robustness is especially important for programs that interact with human users, since humans make mistakes. For example: Programs that crash or attempt to do something meaningless in exceptional conditions are brittle and can contribute to user frustration.

Usability is a familiar concept, but it is not simple.

The usability of software depends on the nature of the operations it offers, the ease of performing user tasks, the ease of learning the operations, user documentation, and system response time.

Usability is most difficult to analyze for programs that are designed to aid the user in performing a complex variety of tasks, such as word processors or spreadsheet programs.

Here the software designer has a spectrum of possible choices: The first choice is preferable provided that it is easy to specify the operations.
The ease of specifying an operation often depends largely on the ease and naturalness of specifying parameters of operations. For example,
Even when it is easy to specify the parameters of operations, providing one operation for each kind of task may result in software that is difficult to use because it provides an excessively large number of different operations:
Software's ease of use can be seen to be a composite of two values: Often, one of these values is achieved at the expense of the other: The best solution often lies somewhere between these extremes.
Regardless of what set of operations a piece of software affords, ease of learning also depends on two aspects of its documentation: User documentation is not to be confused with program documentation, discussed later.
Response time is the elapsed time between the initiation of an operation and its completion.

System managers oversee the operation of computer systems on which software must run.

System managers are responsible for installing new software and making sure that the system provides the resources that the software requires.

These responsibilities determine their values.
Ease of installation as a value depends on the type of software:
A program uses various resources that are available from the system:

A system manager prefers to see resource usage minimized in order to avoid higher costs for faster processors or additional disk space or memory.

Minimizing resource usage may also indirectly benefit the user since response time usually suffers when system resources are pushed to their limits.

Software developers face a difficult task in the production of quality software.

Programs need to be broken down into components, each specialized to deal with a limited aspect of the overall functionality of the program.

A software component is any piece of software that has a clear role, can be isolated, and therefore replaced. Examples:

Like a person in a complex organization, each component will do some of the work, but it will call upon other components if the need for their specialized ability arises.

The values that software developers place on components depends on the roles the developers play with regard to software components.

Many people are involved in the design and programming of a complex program and most will deal with only a few components.

The people involved in such a project thus play two roles, often simultaneously:

As users, software developers will evaluate other components in terms of the user values described previously.

As producers they will impose their own values — values that set software engineering apart from other disciplines:

Many important software components have the responsibility of maintaining a body of data and providing methods for accessing the data.

Maintaining data involves several values: Issues of data consistency and modifiability define the value of data integrity, a crucial value in the design of database management software, operating systems, data structures, and many other types of components.

Data integrity can be more easily achieved if data and the operations that can be used on it are kept together, so that changes to the data are localized.

Good programming languages provide encapsulation mechanisms that enforce this:

The special importance that maintenance has for software has already been described (see Software Maintenance at left).

The importance of maintenance has led to values and value concepts that refine the notion of ease of maintenance:

The software that is available today could not be produced at a reasonable cost if each program were constructed from scratch.

Therefore, software's ease of reuse is an important value.

Software developers employ reuse in two ways: Reusable software can come in two forms: Ease of use is desirable for all components, but it is much more important and more difficult for components that are intended for use in a variety of applications, such as frameworks.

A software component has cohesion (or is cohesive) if it "hangs together" as a single unit; that is, its interface defines a single abstraction.

A cohesive software component is more likely to be reusable than a non-cohesive one: Cohesive components are easier for developers to understand, so they aid in the management of complexity, which requires having components that perform complex operations, yet are easy to grasp.

One of the most important features of a high-quality software development process is a strategy for verification.

Verification refers to any activity whose purpose is ensuring system correctness.

Verification types include: Verification scopes include: Software verification is easier to accomplish when:

High quality components are not sufficient to guarantee quality of the complete program.

The components interact as a system and the structure of the interactions has a decisive influence on quality.

In order for values like ease of maintenance and verification to apply to complete programs, their components must be minimally coupled.

Two components are not coupled simply because they interact. They are coupled when: Designing components to interact without being coupled is a fundamental value of software engineering.

Certain components may have implementation dependence in order to serve an essential purpose.

For example, a function for adding entries to a table and a function for removing entries from a table must be dependent since they are working with the same implementation model.

On the other hand, clients of a table component should not need to be aware of the implementation.

Careful use of encapsulation can and should be used to keep the implementation dependence from arising between a table and its clients.
A strongly coupled group of components is more difficult to work with, because

Although these software developer values are of direct interest only to software producers, they have indirect, but significant, effects on other stakeholders.

If software developer values are upheld, other values are likely:
In addition, there are countless other people who are directly affected by software even though they may be unaware of its existence, e.g.:

These are "secondary" only in the sense that their roles are not directly involved with the production of software and its use.

The software values of these groups are difficult to generalize, but due to the software impact on their lives or property, they must be considered by the primary stakeholders.
Evaluation of software quality depends on aspects of the situation in which it is embedded.
Evaluation of software quality depends on the nature of the application and the roles of its components. For example:

Evaluation of quality also depends on the level of skill and sophistication of the user.

Three general classes of users:
Finally, evaluation of quality depends on the technological context. For example:

The values and value concepts presented here are only a first step towards learning to judge quality.

Although it is easy to grasp the values and value concepts in terms of their purpose and general nature, a good software engineer spends a lifetime learning to use them effectively to judge software quality.

Judgment is difficult, first, because the ability to understand a value concept does not automatically give you the ability to recognize when it is applicable.

One does not see where to apply value concepts until one has gotten into the habit of looking out for them. For example:

Judgment is also difficult because software quality is a network of values with complex relationships between them.

The values network is initially just a framework for your later understanding:

An example of the complex relationships among software values is tradeoffs, where values come in conflict with each other.

Every engineering endeavor involves value tradeoffs, and software engineering is no different. For example: