Context: Component
Goals: When a failed component is recovered, the recovered component must be functionally identical to the failed component, the recovery process must be systematic, must occur with minimal or no user detectable outage, and must not require scheduled system outages.
Rationale: If the availability of the system is sufficiently critical, the recovery of failed hardware or software components must be a predictable, systematic process, must require a minimum of work effort; and must not affect the functionality, availability or performance of the system.
Requirement: The recovery of a failed component shall not cause user detectable loss of business functionality for more than Metric. The recovery of the failed component shall require no more than Metric elapsed time.
Metric:
Level A:
A1. During recovery, the user detectable loss of business functionality will be no more than 60 seconds.
A2. During component recovery, business functionality will be available to the user without re-authentication or loss of context.
A3. During component recovery, the system will continue to meet all Non-Functional Requirements other than Resiliency Requirements
Level B:
B1. During recovery, the user detectable loss of business functionality will be no more than four business hours.
Level C:
C1. The component shall be recoverable within one business day
C2. During recovery, no data modifications will be lost.
Level D:
D1. After component recovery, the system will meet all pre-failure functional and non-functional requirements.
Scale: Loss of functionality: Duration, elapsed time. Component Recovery: duration elapsed time.
Stakeholders: System Managers, Operations
Implications: If this requirement is not met, the organization will incur decreased flexibility for hosting and system management, inability to maintain system during normal work hours, and increased frequency and duration of maintenance outages.
Applicability: See Enterprise Requirements Framework
Tags: Hardware, Software, Recoverability
Status: Approved, Requirement
Author: <Author>
Revision: <Revision >
Note:
Incorporates traditional concepts of Configuration Management and Maintainability. Assures that components can be brought on line without maintenance windows.
While the resiliency NFR’s cover the behavior of systems when components fail, the recoverability NFR’s assure that the design of systems includes the ability to restore the system to its original, pre-failure state in a predictable manner.
To assure component recoverability, the designer needs to assure that the configuration of all system components is known, and that a means exists to create new components that are identical to existing components.
For more information, see NFR Summary
