This document provides a framework for classifying and assigning responsibilities for non-functional requirements (NFRs) between a solution architect (SA) and business analyst (BA). It defines NFRs and outlines a taxonomy with high-level categories and more detailed sub-categories. The framework includes mapping NFR characteristics to stakeholders, mapping stakeholders to the SA and BA roles, and a responsibility assignment matrix (RACI) for NFRs. The goal is to provide guidance for distinguishing SA and BA responsibilities when addressing NFRs during a project.

1. Non-Functional Requirements
for the Solution Architect and Business Analyst
Last Modified: 2015-11-20
Author: Warren Weinmeyer
Document Version: 1.3

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
...............................................................................................................14
5.2 Stakeholders to SA/BA Mapping.............................................................15
5.3 The Non-Functional Requirements RACI..................................................16
6 Suggested Improvements .....................................................................19

3. 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 objective 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

4. 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

5. 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

6. 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 the 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 Qualities
Characteristic Description
Functional Suitability
The 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
Compatibility
The 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
Usability
The 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
Reliability
The degree to which a product performs specified functions under specified conditions for a
specified period of time
Security
The 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
Maintainability
The degree of effectiveness and efficiency with which a product or system can be modified by
the intended maintainers
Portability
The 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 Qualities
Characteristic 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

7. Satisfaction
The 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 Qualities
Characteristic Description
Service Cost
The financial burden undertaken by the enterprise to implement, support, and retire the
product or system
Vendor Risk Mitigation
The 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 Mitigation
The 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 Characteristic
Sub-
Characteristic
Description Notes or Example Metric
Intrinsic
Functional
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

8. 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 Maturity
The 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
intended despite the presence of
hardware or software faults
Redundancy; replication;
diversity; graceful degradation;
Availability is the probability-
based numerical rating of fault
tolerance
Recoverability The degree to which, in the event of Recovery Time Objective

9. an interruption or a failure, a product
or system can recover the data
directly affected and re-establish the
desired state of the system
(RTO); Recovery Point
Objective (RPO); Mean time
to repair (MTTR); mean time
to recover (data); backup
frequency (snapshots; hot;
scheduled; mirroring); disaster
recovery
Availability
The 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
Accountability
The 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
Authenticity
The 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 Mean Failure Analysis Time

10. 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
(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
Manageability
The 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
Supportability
The 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
Conformance
The degree to which the product can
conform to new or changing
regulations
Internationalization
The ability to change the system to
deal with additional international
conventions
Support for multiple such as
languages, number formats,
currencies, etc.
Usage Effectiveness Effectiveness
The accuracy and completeness with
which users achieve specified goals
Error Frequency = #errors
made / #Tasks

11. Efficiency Efficiency
The 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
Comfort
The 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
components of the product
HW/SW costs; licensing costs;
deployment costs (i.e.
additional infrastructure);
vendor consultant costs;
Training costs
Operational Cost
The 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 Cost The cost of removing the product Disposition costs; data

12. from the environment migration costs
Vendor Risk
Mitigation
Market Share
R+D Budget
Years in Market
Client List
Profitability
Industry
Reputation
Escrow
Agreements
Product Risk
Mitigation
Licensing Model
Years in Market
Product Maturity
User Community
Reference Clients
Development &
Release Discipline

13. 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.

14. 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 sub-characteristics
(non-functional requirements), 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 Characteristic
Concern of/Relevant to
Primary
Users
Indirect
Users
Support IT Potential
Users
Intrinsic
Functional
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
✔

15. 5.2 Stakeholders to SA/BA Mapping
Based on the roles and competencies described above in the Basics of the SA/BA Relationship section,
we can propose a mapping between the above-identified ISO stakeholder types (plus the additional one
we added) and who is best positioned to be aware of and account for their needs.
Type of
Stakeholder
ISO/IEC Stakeholder Description
Primary Champion
BA Architect
Primary people who directly use the product/solution ✔
Indirect
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
✔
Potential
People and systems outside the identified Primary and Indirect
stakeholders that could realize business benefit by leveraging the
solution.
✔
When deciding who (BA or SA) should typically be responsible for any specific non-functional
requirement, a reasonably objective approach would be to identify the type of stakeholder who is most
vested in (or affected by) that NFR and assign responsibility for specifying that NFR based on that table
above.

16. 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 Characteristic
Sub-
Characteristic
Main
Stakeholder
BA Architect
A R C I A R C I
Intrinsic
Functional
Suitability
Functional
Appropriateness
Primary ✔
Functional
Completeness
Primary ✔
Functional
Correctness
Primary ✔
Functional
Targeting
Primary ✔
Performance
Efficiency
Time Behaviour Primary ✔
Resource
Utilization
IT ✔
Capacity Support ✔
Compatibility
Co-existence IT ✔
Interoperability IT ✔
Usability
Obvious
Applicability
Primary ✔
Intuitiveness Primary ✔
Learnability Primary ✔
Aesthetics Primary ✔
Accessibility Primary ✔
User Error
Protection
Primary ✔
Reliability
Maturity Support ✔
Fault Tolerance Support ✔
Recoverability Support ✔
Availability Support ✔
Robustness Support ✔
Security
Confidentiality IT ✔
Integrity IT ✔
Non-repudiation Primary ✔
Accountability Primary ✔

17. Authenticity IT ✔
Maintainability
Scalability Support ✔
Modularity Support ✔
Analyzability Support ✔
Modifiability Support ✔
Testability Support ✔
Manageability Support ✔
Reusability Support ✔
Supportability Support ✔
Portability
Adaptability IT ✔
Installability IT ✔
Replaceability IT ✔
Conformance IT ✔
Internationalization Primary ✔
Usage
Effectiveness
Effectiveness Primary ✔
Efficiency
Efficiency Primary ✔
Satisfaction
Usefulness Primary ✔
Trust Primary ✔
Comfort Primary ✔
Freedom from
Risk
Economic Risk
Mitigation
Primary ✔
Health and Safety
Risk Mitigation
Primary ✔
Environmental
Harm Risk
Mitigation
Primary ✔
Context
Coverage
Context
Completeness
Primary ✔
Flexibility IT ✔
Service
Experience
Service
Availability
Primary ✔
Support
Availability
Support ✔
Service Delivery
Costs
Primary ✔
External
Service Cost
Acquisition Cost ✔
Operational Cost IT ✔
Retirement Cost IT ✔
Vendor Risk
Mitigation
Market Share ✔
R+D Budget IT ✔

18. Years in Market IT ✔
Training and
Support
Primary ✔
Client List Primary ✔
Profitability Primary ✔
Industry
Reputation
IT ✔
Escrow
Agreements
IT ✔
Product Risk
Mitigation
Licensing Model Primary ✔
Product Maturity Support ✔
User Community Primary ✔
Reference Clients Primary ✔
Development &
Release Discipline
Support ✔

19. 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