Non-Functional Requirementsfor the Solution Architect and Business Analyst

Last Modified: 2015-06-19

Author: Warren Weinmeyer

Document Version: 1.2

Table of Contents

1 Purpose of this Document...............................................................3

2 Introduction...................................................................................3

2.1 Basics of the SA/BA Relationship...................................................................3

2.2 Definition of Non-functional Requirements....................................................4

2.3 References.....................................................................................................5

3 A Taxonomy For Non-functional Requirements.................................6

3.1 High-Level NFR Classification.........................................................................6

3.2 Detail-Level NFR Classification.......................................................................7

4 Types of Stakeholders..................................................................13

5 The Non-Functional Requirements Framework...............................14

5.1 NFR Characteristic to Stakeholder Mapping.................................................14

5.2 Stakeholders to SA/BA Mapping...................................................................15

5.3 The Non-Functional Requirements RACI......................................................16

6 Suggested Improvements...............................................................................19

1 Purpose of this Document

This document leverages published best practices to define a framework of Non-functional Requirements (NFR) along with a methodology for assigning responsibilities for each NFR to either the BA or SA.

This guidance is especially useful for:1. Providing a reasonably rigorous classification, definition and master-list of the possible types of

non-functional requirements that might be considered for any solution (but refer to Suggested Improvements section at the end of this document).

2. Providing a best-practice based and reasonably object methodology for assigning role responsibilities when confusion or disputes arise between the SA and BA

2 Introduction

Architecture leading thought and best practices continue to evolve. Consequently, many organizations experience some degree of uncertainty regarding the practical matter of what exactly the role of an Architect should be and this uncertainty can be reflected as ambiguity in the organization’s governance model and role definitions.

Business Analysis leading thought also continues to evolve, but more slowly because the discipline has more maturity and history than Architecture.

It is important to note that the evolution of thought leadership within individual disciplines, like Architecture and Business Analysis (but also disciplines like Project Management, Business Architecture, Security, etc.), largely occurs within the bubble of that discipline and commonly results in overlaps in the “jurisdiction” claimed by other disciplines. This leaves the responsibility for ensuring harmonious role mandates to each individual organization to work out (though complex efforts to rationalize these roles, such as Skills Framework for the Information Age, do exist).

At the project level, the Solution Architect (SA) role is a relative newcomer to the core project delivery team compared to the Business Analyst (BA) role and BAs in many companies are accustomed to taking responsibility for tasks and deliverables that are better assigned to a Solution Architect (SA). When there is overall uncertainty about what an Architect does, there is fertile ground for inter-personal conflict.

2.1 Basics of the SA/BA Relationship

In a well-functioning project, the BA and SA have a close working relationship – in fact, it should be characterized more as a symbiotic partnership. With roles so intertwined, it is common for people to

either not understand the difference between a BA and SA, and/or to not see a need for having two different roles. However, there are differences in both skills and perspective between the two roles that justify this separation.

Often, the relationship between BA and SA is summarized as the BA is responsible for the requirements and the SA for the solution. However, Requirements and Solution Attributes are simply two faces of the same coin, and the reality is that both BAs and SAs are involved and concerned with both Requirements and Solution Attributes, but the types of requirements and attributes they are primarily concerned with can have different focus, as is their relative competency to be “Responsible” for specifying them. It does, however, make sense to maintain the BA as “Accountable” for Requirements overall and the SA to be “Accountable” for Solution Specification overall.

As an industry norm, BAs have a greater understanding of the Business as well as current best practices in business analysis and SAs have a greater understanding of technology as well as current best practices in architecture (security, strategic alignment, design patterns, technology trends, etc.).

The BA complements their strong understanding of the Business with a good functional understanding of technology, and the BA is often described as translating between Business and IT. The SA complements their strong understanding of technology with a good functional understanding of the Business, and the Architect is often described as integrating the Business and IT.

The BA has accountability to the Project Stakeholders for a solution that meets Stakeholder requirements, and their signature deliverable is the Detailed Requirements document. The SA is accountable for a fit-for-purpose solution for the project in the context of the needs of the larger enterprise, and their signature deliverable is the Solution Architecture Description.

Often, the deviation between the requirements of the greater enterprise and the Project Stakeholders revolves around the compatibility of the solution to the current technology and information landscape, the future strategic roadmap, and leveraging the solution functionality by other business functions/units in the enterprise. These types of concerns tend to be reflected in the non-functional, rather than the functional, characteristics of the solution, so this is often the area where SAs and BAs can have conflict.

2.2 Definition of Non-functional Requirements

Non-functional requirements define the overall qualities or attributes of the resulting system and place restrictions on the product being developed, the development process, and specify external constraints that the product must meet.

Wikipedia defines non-functional requirements as follows:

In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions. The

plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture.

Broadly, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Functional requirements are usually in the form of "system shall do…", while non-functional requirements are "system shall be… ".

Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are "constraints", "quality attributes", "quality goals", "quality of service requirements" and "non-behavioral requirements". Informally these are sometimes called the "ilities", from attributes like stability and portability. Qualities (i.e., non-functional requirements) can be divided into two main categories:1. Execution qualities, such as security and usability, which are observable at run time.2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are

embodied in the static structure of the software system.

(For example:)

A system may be required to present the user with a display of the number of records in a database. This is a functional requirement. How up-to-date this number needs to be is a non-functional requirement. If the number needs to be updated in real time, the system architects must ensure that the system is capable of updating the displayed record count within an acceptably short interval of the number of records changing.

Other sources offer very similar definitions for Non-Functional Requirements

2.3 References

The following sources are referenced in this document: Non-Functional Requirements, FURP, RAS, ISO 9126, Wikipedia Representing and Using Non-Functional Requirements: A Process-Oriented Approach, John

Mylopoulos, Lawrence Chung, Brian Nixon, Dept of Computer Science, University of Toronto Defining Non-Functional Requirements, Ruth Malan and Dana Bredemey, Bredemeyer

Consulting A Framework for the Measure of Software Quality, Joseph P. Cavano, James A. McCall, Rome Air

Development Center Organizational Requirements Engineering, Prof. Dr. Armin B. Cremers, Sascha Alda, B-IT ISO/IEC 9126 In Practice: What Do We Need to Know?, P. Botella, X. Burgués, J.P. Carvallo, X.

Franch, G. Grau, J. Marco, C. Quer, Barcelona Tech ISO/IEC 25010 International Standard – Final Draft, ISO/IEC Discover Non-Functional Requirements, http://www.semanticarchitecture.net

3 A Taxonomy For Non-functional Requirements

In order to attack the problem of attaching RACI to non-functional requirements, it is necessary to establish a foundational list of these requirements. The following sections are largely guided by ISO/IEC Standards 9126 and 25010/SQuaRE, to which we add in some minor supplementation from similar quality frameworks like FURPS and RADC to create a robust list of attributes that can be applied to any software/hardware solution (but refer to Suggested Improvements section at the end of this document). The Requirements for any particular solution are directly derivable from this list by selecting which attributes are relevant and specifying the quality metric that must be achieved in order to meet the stakeholder needs.

3.1 High-Level NFR Classification

ISO/IEC suggests solution attributes can be divided into 3 main categories, called “Qualities”; these Qualities serve as a top-level breakdown of non-functional requirements:

Intrinsic Qualities: characteristics of the product/solution itself Usage Qualities: characteristics related to outcomes of user interaction with the

product/solution External Qualities: market-related characteristics associated with the product/solution

Within these 3 top-level categories, we can define sub-categories called "Characteristics" that describe fairly high-level qualities of the product/solution:

Intrinsic QualitiesCharacteristic Description

Functional SuitabilityThe degree to which a product functions that meets stated and implied needs when used under specified conditions

Performance Efficiency The performance relative to the amount of resources used under stated conditions

CompatibilityThe degree to which a product can exchange information with other products, and/or perform its required functions, while sharing the same hardware or software environment

UsabilityThe degree to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use

ReliabilityThe degree to which a product performs specified functions under specified conditions for a specified period of time

SecurityThe degree to which a product protects information and data so that persons or other products have the degree of data access appropriate to their types and levels of authorization

MaintainabilityThe degree of effectiveness and efficiency with which a product or system can be modified by the intended maintainers

PortabilityThe degree of effectiveness and efficiency with which a system, product or component can be transferred from one hardware, software or other operational or usage environment to another

Usage QualitiesCharacteristic Description

Effectiveness The accuracy and completeness with which users achieve specified goals

Efficiency The resources expended in relation to the accuracy and completeness with which users

achieve goals

SatisfactionThe degree to which user needs are satisfied when a product or system is used in a specified context of use

Freedom from Risk (Safety)

The degree to which a product or system mitigates the potential risk to economic status, human life, health, or the environment

Context Coverage (Usability Scope)

The degree to which a product or system can be used with effectiveness, efficiency, freedom from risk and satisfaction in both specified contexts of use and in contexts beyond those initially explicitly identified

External QualitiesCharacteristic Description

Service CostThe financial burden undertaken by the enterprise to implement, support, and retire the product or system

Vendor Risk MitigationThe degree to which support, cost and longevity risks the Vendor can demonstrate there are minimal risks associated with selecting a product from them

Product Risk MitigationThe degree to which functionality, cost and longevity risks associated with investing in the product can be mitigated

3.2 Detail-Level NFR Classification

The Characteristics listed above are still at too high a level to be translatable into clear requirements; we can elaborate on each Characteristic with Sub-Characteristics (largely drawn from ISO/IEC 25010, with a few renamed for better clarity), as follows:

Quality CharacteristicSub-

CharacteristicDescription Notes or Example Metric

IntrinsicFunctional Suitability

Functional Appropriateness

The degree to which the functions facilitate the accomplishment of specified tasks and objectives

Does not expose the user to unnecessary steps, functions, or information

Functional Completeness

The degree to which the set of functions covers all the specified tasks and user objectives

The % of desired functionality present in the product

Functional Correctness

The degree to which a product provides the correct results with the needed degree of precision

The ratio of incorrect to total of processed transactions; integrity of information processed

Functional Targeting

The degree to which a product supports required functionality without introducing ancillary, unwanted functionality

The ratio of the % of desired functionality present in the product to the total functions offered by the product

Performance Efficiency

Time Behavior The degree to which the response and processing times and throughput rates of a product meet requirements

Throughput; response time; application load time; screen open/refresh time; calculation time; import/export time; report/query time

Resource Utilization

The degree to which the amounts and types of resources used by a product meet requirements

Bandwidth, cpu utilization, memory utilization, storage

Capacity The degree to which the maximum limits of a product or system parameter meet requirements

Refers to initial planned capacity, not scalability to future levels; transactions per

unit time; maximum database/file size; maximum number of users/connections

Compatibility Co-existence

The degree to which a product can perform its required functions efficiently while sharing a common environment and resources with other products, without detrimental impact on any other product

Alignment to technical standards; Product certification; awareness of resource contention (avoids direct hardware access)

Interoperability

The degree to which two or more systems, products or components can exchange information and use the information that has been exchanged

Alignment to communication, integration, and information standards

Usability

Obvious Applicability

(ISO: Appropriateness Recognizability)

The degree to which users can recognize whether a product or system is appropriate for their needs, without having to operate the system first

From initial impressions, demos, tutorials, docs, etc.

Intuitiveness

(ISO: Operability)

The degree to which a product or system has attributes that make it easy to operate and control

The degree to which the product can be used without specific training

Learnability

The degree to which a product or system can be used by specified users to achieve specified goals of learning to use the product or system with effectiveness, efficiency, freedom from risk and satisfaction in a specified context of use

The time to learn to use the solution at a practical working level to get routine tasks done.

Aesthetics

(ISO: User Interface Aesthetics)

The degree to which a user interface enables pleasing and satisfying interaction for the user

Subjective user surveys with standardized ratings

Accessibility

The degree to which a product or system can be used by people with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use

Most typically: limited visual acuity, colour-blindness

User Error Protection

The degree to which a system protects users against making errors

Rules-based validation, input completeness rules, sanity checks, referential integrity, confirmation on CRUD operations

Reliability MaturityThe degree to which a system meets needs for reliability under normal operation

Mean time between failures (MTBF); The degree of stable operations encountered after product updates and enhancements (ratio of #incidents for a period of time before a change to #incidents after the change); predictability (variation in performance KPIs under specified loads)

Fault Tolerance The degree to which a system, product or component operates as

Redundancy; replication; diversity; graceful

intended despite the presence of hardware or software faults

degradation; Availability is the probability-based numerical rating of fault tolerance

Recoverability

The degree to which, in the event of an interruption or a failure, a product or system can recover the data directly affected and re-establish the desired state of the system

Recovery Time Objective (RTO); Recovery Point Objective (RPO); Mean time to repair (MTTR); mean time to recover (data); backup frequency (snapshots; hot; scheduled; mirroring); disaster recovery

AvailabilityThe degree to which a system, product or component is operational and accessible when required for use

The ratio of time the product is operating fully in a period of time to the total period of time: the availability of a system for a period of time is the probability that the system is available for use at any random time in that period. Expressed as a Requirement in terms of minutes per month of downtime tolerated.

Robustness

The ability of a product to cope with errors during execution or the ability of an algorithm to continue to operate despite abnormalities in conditions, input, calculations, etc.

Malformed data; unknown message types; missing data; out-of-sequence messages; network latency; low bandwidth

Security Confidentiality

The degree to which a product or system ensures that data are accessible only to those authorized to have access

Strong passwords; password recycling policies ; multi-level access control; inactivity timeouts; includes protection of data outside the envelope of normal software interfaces, such as directly accessing serialized data or intercepting transmitted data; disposition rules

Integrity

The probability that errors or attacks will not lead to access or damage to the state of the system, including data, code, etc

Non-repudiation

The degree to which actions or events can be proven to have taken place, so that the events or actions cannot be repudiated later

AccountabilityThe degree to which the actions of an entity can be traced uniquely to the entity

Audit logs; transaction logs; user session logs; not modifiable by Administrator; retention rules

AuthenticityThe degree to which the identity of a subject or resource can be proved to be the one claimed

multi-factor authentication;

Maintainability Scalability

The degree to which the product can efficiently and effectively accommodate increases to its original Capacity

Horizontal, vertical scaling; module replication; built-in clustering; load balancing

Modularity

The degree to which a product is composed of discrete components such that a change to one component has minimal impact on other components

The ability of the solution to be delivered, deployed, maintained and administered in self-contained units

Analyzability

The degree of effectiveness and efficiency with which it is possible to assess the impact on a product or system of an intended change to one or more of its parts, or to diagnose a product for deficiencies or causes of failures, or to identify parts to be modified

Mean Failure Analysis Time (the mean time needed to analyze a failure and to discover the faults that arise from the failure); product can analyze its own faults and provide reports prior to a failure or other event; transaction logs; debug mode

Modifiability

The degree to which a product's functionality can be effectively and efficiently modified without introducing defects or degrading existing product quality

The average amount of effort needed to modify the product; the functionality that can be changed by configuration or other means other than coding

Testability

The degree of effectiveness and efficiency with which test criteria can be established for a product and tests can be performed to determine whether those criteria have been met

ManageabilityThe degree to which the product facilitates efficient and effective management of its operations

The ratio of effort put in controlling (administering, maintaining) the product to the total hours of operation of the product

Reusability

The degree to which product or product component can be used in more than one system, or in building other solutions

Ability to host other solutions (servers, network components, storage; databases; web servers and other application platforms); ability to participate in "mash-ups" or other plug-and-play ad hoc solutions

SupportabilityThe ease with which the product can be supported by support personnel

Match to available skill-sets; quality of support and administrative documentation; existence of additional structured training

Portability Adaptability

The degree to which a product or system can effectively and efficiently be adapted for different or evolving hardware, software or other operational or usage environments

Installability

The degree of effectiveness and efficiency with which a product or system can be successfully installed and/or uninstalled in a specified environment

Automated install script; registry-free install; automated default configurations

Replaceability

The degree to which a product can be replaced by another specified software product for the same purpose in the same environment

Loose coupling for integrations; abstracted interfaces

ConformanceThe degree to which the product can conform to new or changing regulations

InternationalizationThe ability to change the system to deal with additional international conventions

Support for multiple such as languages, number formats, currencies, etc.

Usage Effectiveness EffectivenessThe accuracy and completeness with which users achieve specified goals

Error Frequency = #errors made / #Tasks

Efficiency EfficiencyThe resources expended in relation to the accuracy and completeness with which users achieve goals

time to complete the task; the financial cost of usage

Satisfaction Usefulness

The degree to which a user is satisfied with their perceived achievement of pragmatic goals, including the results of use and the consequences of use

Trust

The degree to which a user or other stakeholder has confidence that a product or system will behave as intended

ComfortThe degree to which the user is satisfied with physical comfort

Ergonomic design of the solution

Freedom from Risk

Economic Risk Mitigation

The degree to which a product or system mitigates the potential risk to financial status, efficient operation, commercial property, reputation or other resources in the intended contexts of use

Health and Safety Risk Mitigation

The degree to which a product or system mitigates the potential risk to people in the intended contexts of use

Environmental Harm Risk Mitigation

The degree to which a product or system mitigates the potential risk to property or the environment in the intended contexts of use

Context Coverage

Context completeness

The degree to which a product or system can be used with effectiveness, efficiency, freedom from risk and satisfaction in all the specified contexts of use i.e. fit-for-purpose

eg. usable using a small screen, by a new user, even if off-line/disconnected

Flexibility

The degree to which a product or system can be used with effectiveness, efficiency, freedom from risk and satisfaction in contexts beyond those initially specified in the requirements

eg. Designed to be usable using a small screen, by a new user, even if off-line/disconnected – also works in low-bandwidth situations

Service Experience

Service Availability

The degree to which the solution is obligated to be available for use

Support Availability

The degree to which support for the solution is obligated to be available

Service Delivery Costs

The degree to which usage of the solution or support is borne explicitly by the user

External Service Cost Acquisition Cost The resource costs (non-staff) involved with acquiring and deploying all of the requisite

HW/SW costs; licensing costs; deployment costs (i.e. additional infrastructure);

components of the productvendor consultant costs; Training costs

Operational CostThe cost of maintaining on-going operations of the product

Vendor support costs; support desk costs; infrastructure operating costs; annual licensing costs; predicted costs (projected infrastructure growth, patches and version upgrades);

Retirement CostThe cost of removing the product from the environment

Disposition costs; data migration costs

Vendor Risk Mitigation

Market Share

R+D BudgetYears in Market Client ListProfitabilityIndustry ReputationEscrow Agreements

Product Risk Mitigation

Licensing Model

Years in MarketProduct MaturityUser CommunityReference ClientsDevelopment & Release Discipline

4 Types of Stakeholders

ISO/IEC has proposed that the Stakeholders of a delivered solution can be divided into the following groups:

Primary Users: People who directly use the solution Indirect Users: People and systems downstream from the solution that obtain outputs from it

(for example, through data integration or querying a database that the solution updates) Support: Maintenance, sustainment, support personnel and administrators of the product or

solution IT: IT Management and people involved in procurement, planning and QA activities

To this, we add an additional stakeholder type to address those who could make use of the solution but aren’t part of the current scope of Primary or Indirect users (for example, business units that could opt to use the solution instead of going out and creating another one, thus saving the company time and money).

Potential Users: People and systems outside the identified Primary and Indirect stakeholders that could realize business benefit by leveraging the solution.

5 The Non-Functional Requirements Framework

5.1 NFR Characteristic to Stakeholder Mapping

Though each of the 16 Characteristics are further broken down into more concrete qualities (Sub-Characteristics), it is a useful exercise to draw out a high-level mapping of these Characteristics to Stakeholders who are most likely to be directly and visibly impacted by them (i.e., more than Stakeholder types who do not have a check-mark), using the above definitions for type of Stakeholder:

Quality CharacteristicConcern of/Relevant to

Primary Users

Indirect Users

Support IT Potential Users

IntrinsicFunctional Suitability

✔ ✔ ✔

Performance Efficiency

✔ ✔ ✔

Compatibility ✔ ✔Usability ✔ ✔Reliability ✔ ✔ ✔Security ✔ ✔ ✔Maintainability ✔Portability ✔ ✔

Usage Effectiveness ✔ ✔Efficiency ✔ ✔Satisfaction ✔ ✔Freedom from Risk

✔ ✔

Context Coverage ✔ ✔ ✔External Service Cost ✔

Vendor Risk Mitigation

✔

Product Risk Mitigation

✔

5.2 Stakeholders to SA/BA Mapping

ISO/IEC has proposed that the affected NFR Stakeholders can be divided into the following groups: Primary Users: People who directly use the product/solution Indirect Users: People and systems downstream from the product that obtain outputs from it Support: Maintenance, sustainment, support personnel and administrators of the product or

solution IT: IT Management and people involved in procurement, planning and QA activities

To this, we add an additional stakeholder type to address those who could make use of the solution but isn’t part of the current scope of Primary or Indirect users (for example, by using the solution instead of going out and creating another one).

Beneficiary: People and systems outside the identified Primary and Indirect stakeholders that could realize business benefit by leveraging the solution.

Based on the roles and competencies described above in the Basics of the SA/BA Relationship section, we can propose a mapping between these ISO stakeholder types and who is best positioned to be aware of and account for their needs.

Type of Stakeholder

ISO/IEC Stakeholder DescriptionPrimary Champion

BA ArchitectPrimary people who directly use the product/solution ✔

Indirectpeople and systems downstream from the product that obtain outputs from it

✔

SupportMaintenance, sustainment, support personnel and administrators of the product or solution

✔

ITIT Management and people involved in procurement, planning and QA activities

✔

PotentialPeople and systems outside the identified Primary and Indirect stakeholders that could realize business benefit by leveraging the solution.

✔

5.3 The Non-Functional Requirements RACI

Using the above stakeholder-type assignments as an overall decision-making pattern, we can make reasonably objective assignments for the detailed list of NFRs. The following table presents the Non-functional Sub-Characteristics for the “Responsible” role of the RACI assignment (we have already positioned the BA to be overall “Accountable” for all Requirements, and we are not addressing “Consult” and “Inform” here):

Quality CharacteristicSub-

Characteristic

BA Architect

A R C I A R C I

IntrinsicFunctional Suitability

Functional Appropriateness

✔

Functional Completeness

✔

Functional Correctness

✔

Functional Targeting

✔

Performance Efficiency

Time Behaviour ✔Resource Utilization

✔

Capacity ✔Compatibility

Co-existence ✔Interoperability ✔

UsabilityObvious Applicability

✔

Intuitiveness ✔Learnability ✔Aesthetics ✔Accessibility ✔User Error Protection

✔

ReliabilityMaturity ✔Fault Tolerance ✔Recoverability ✔Availability ✔Robustness ✔

Security

Confidentiality ✔Integrity ✔

Non-repudiation ✔Accountability ✔Authenticity ✔

MaintainabilityScalability ✔Modularity ✔Analyzability ✔Modifiability ✔Testability ✔Manageability ✔Reusability ✔Supportability ✔

PortabilityAdaptability ✔Installability ✔Replaceability ✔Conformance ✔Internationalization ✔

UsageEffectiveness

Effectiveness ✔Efficiency

Efficiency ✔Satisfaction

Usefulness ✔Trust ✔Comfort ✔

Freedom from Risk

Economic Risk Mitigation

✔

Health and Safety Risk Mitigation

✔

Environmental Harm Risk Mitigation

✔

Context Coverage

Context Completeness

✔

Flexibility ✔Service Experience

Service Availability

✔

Support Availability

✔

Service Delivery Costs

✔

ExternalService Cost

Acquisition Cost ✔ Operational Cost ✔Retirement Cost ✔

Vendor Risk Mitigation

Market Share ✔R+D Budget ✔Years in Market ✔Training and Support

✔

Client List ✔Profitability ✔Industry Reputation

✔

Escrow Agreements

✔

Product Risk Mitigation

Licensing Model ✔Product Maturity ✔User Community ✔Reference Clients ✔Development & Release Discipline

✔

6 Suggested Improvements

As a future enhancement to this framework, it is recommended to address Data Quality in a more rigorous manner. The ISO 25010 Data Quality Model is summarized below as a suggest place to begin: Accuracy Completeness Consistency Credibility Currentness Accessibility Compliance Confidentiality Efficiency Precision Traceability Understandability Availability Portability Recoverability