a desired result, more detailed than a goal.
Note that a high-level goal is achieved if its
associated more detailed objectives are achieved.
Note that objectives should be attainable, cohesive,
measurable, and realistic.
describing a characteristic or behavior that is visible
to its stakeholder.
For example information hiding makes software less
observable, and therefore less testable because the tester
needs to be able to observe the actual characteristic or
behavior in order to compare it with the expected
characteristic or behavior.
a standard process for creating a project-specific
delivery process. The components of the OPF are process
components (endeavors, stages, producers, work units, work
products, and languages) and associated usage
guidelines.
(1) a user-oriented
quality
requirement specifying the proportion of the time that an
application or component shall function (i.e., be available
for performing work).
(2) a quantitative quality factor measuring the
proportion of the time that an application or component
actually functions.
Note that operational availability is typically:
Defined in terms of the minimum average percent of time
that an application must operate without scheduled or
unscheduled downtime.
Specified as either a number of nines (e.g., 3 nines =
99.9% and 5 nines = 99.999%) or continuous availability
(i.e., absolutely no downtime is allowed).
the activity consisting of the cohesive collection of all
tasks that are primarily performed to keep an application
operating after it has been deployed for use by the user
organizations.
the source (e.g., the requirements, design, or an
authoritative domain expert) of testing information that
specifies the expected (i.e., correct) behavior of an
executable work product.
the management work product consisting of a diagram that
documents the composition of the either the development
organization or the project team in terms of its component
teams and the aggregation relationships between them.
