Decision Analysis and Resolution (process area)

Recorded information.
Recorded information can include technical data, computer software documents, financial information, management information, representation of facts, numbers, or datum of any nature that can be communicated, stored, and processed.

The disciplined processes and systems that plan for, acquire, and provide stewardship for business and technical data, consistent with data requirements, throughout the data lifecycle.

Number of defects per unit of product size.
An example is the number of problem reports per thousand lines of code.

A managed process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines; has a maintained process description; and contributes process related experiences to the organizational process assets. (See also “managed process.”)

A characterization of required functionality and quality attributes obtained through “chunking,” organizing, annotating, structuring, or formalizing the requirements (functional and non-functional) to facilitate further refinement and reasoning about the requirements as well as (possibly, initial) solution exploration, definition, and evaluation. (See also “architecture,” “functional architecture,” and “quality attribute.”)
As technical solution processes progress, this characterization can be further evolved into a description of the architecture versus simply helping scope and guide its development, depending on the engineering processes used; requirements specification and architectural languages used; and the tools and the environment used for product or service system development.

An item to be provided to an acquirer or other designated recipient as specified in an agreement. (See also “acquirer.”)
This item can be a document, hardware item, software item, service, or any type of work product.

The complete set of circumstances and conditions under which services are delivered in accordance with service agreements. (See also “service” and “service agreement.”)
The delivery environment encompasses everything that has or can have a significant effect on service delivery, including but not limited to service system operation, natural phenomena, and the behavior of all parties, whether or not they intend to have such an effect. For example, consider the effect of weather or traffic patterns on a transportation service. (See also “service system.”)
The delivery environment is uniquely distinguished from other environments (e.g., simulation environments, testing environments). The delivery environment is the one in which services are actually delivered and count as satisfying a service agreement.

Measure that is defined as a function of two or more values of base measures. (See also “base measure.”)

Requirements that are not explicitly stated in customer requirements but are inferred (1) from contextual requirements (e.g., applicable standards, laws, policies, common practices, management decisions) or (2) from requirements needed to specify a product or service component.
Derived requirements can also arise during analysis and design of components of the product or service. (See also “product requirements.”)

A formal, documented, comprehensive, and systematic examination of a design to determine if the design meets the applicable requirements, to identify problems, and to propose solutions.

To create a product or service system by deliberate effort.
In some contexts, development can include the maintenance of the developed product.

Department of Homeland Security

A collection of data, regardless of the medium on which it is recorded, that generally has permanence and can be read by humans or machines.
Documents include both paper and electronic documents.

Department of Defense