| < Day Day Up > |
|
The ability of a system (or system component) to continue normal operation despite the presence of hardware or software faults.
The extent to which the benefits of a new or enhanced system will exceed the total costs and also satisfy the business requirements.
A formal study to determine the feasibility of a proposed system (new or enhanced) in order to make a recommendation to proceed or to propose alternative solutions.
Testing that is performed at the user site.
An operational system installed at the user site.
The systems development work pattern defined by life cycle phases described in SEP documentation (Chapter 10).
The relative usefulness of a functional requirement as it satisfies a business need.
The approved documentation that describes the functional characteristics of the system, subsystem, or component. See baseline.
An audit to ensure that the functional requirements have been met by the delivered configuration item. See audit.
A requirement that specifies a function (activity or behavior, based on a business requirement) that the system (or system component) must be capable of performing.
A formal document of the business (functional) requirements of a system; the baseline for system validation.
Testing that ignores the internal mechanism of a system (or system component) and focuses solely on the outputs generated in response to selected inputs and execution conditions. Same as black-box testing.
| < Day Day Up > |
|