Concerns, qualities and non-functional requirements

This page is published under the terms of the licence summarized in the footnote.



Architects sometimes struggle to find advice on architecting.

But there is no shortage of advice out there on stakeholder management and requirements capture.

You can find plenty of terms, lots of guidance, and some confusion.


The ISO 42010 standard lists examples of what it calls concerns.

TOGAF lists examples of what it calls qualities.

Many examples (e.g. performance, reliability and security) are listed in other sources under the heading of requirement types.

And in “Design Patterns” (Gamma et al.), some of the examples are called forces.


This paper (being written Feb 2014) is an attempt to relate these ideas, with some caveats.

It is as much an attempt to clarify for my own sake as to help anybody else.

If you have any comment make, you can email here.



Concerns. 1

On types and instances. 3

On generalisation and composition hierarchies. 4

ISO 42010 equates “concerns” with all kinds of subject matter 4

TOGAF equates “concerns” with qualities. 5

From requirement types to requirement instances. 5

Requirement types. 6



The ISO 42010 standard says: concern <system> interest in a system relevant to one or more of its stakeholders.

A concern can be small or large, general or specific, anything or everything.


Here are some statements made by stakeholders in your meetings with them.

·        Our concern is to halve the order to delivery time. Stakeholders: Mary, Joan.

·        Our concern is throughput. Stakeholders: Mary. Software development manager.

·        Our concern is next financial year budget deltas. Stakeholder: Joe. CFO. COO.

·        Our concern is prevention of unauthorised access. Stakeholders: Joe, Mary.

·        Our concern is the disability access law. Stakeholders: Company lawyer. Software development manager.


Are these all “concerns” as the standard means it?

The table below separates the statements above into more abstract areas of interest and more specific needs, goals or requirements (some perhaps related to risks).


Subject matter

Need, goal or requirement

Order to delivery time

Halve the order to delivery time.

Unauthorised access

Prevention of unauthorised access.


Throughput = 100 tps

Next Financial Year budget deltas

Each division has enough money

The disability access law

Compliance to the disability access law


Having drawn this distinction, note that stakeholders may feel their needs of a system are their interests in it.

And the standard does not explicitly distinguish abstract and specific interests, or broad and narrow interests, or types and instances of need.


First, the standard’s definition of “concern” appears to cover interests in everything from strategic influences to measurable goals.

The definition (“an interest in a system” or “any topic of interest pertaining to the system”) is very broad.

It is so broad, that nothing pertinent to a system - mentioned by a stakeholder - could be excluded from fitting the definition.


Second, "This International Standard does not prescribe: the granularity of concerns... or how concerns relate to ... stakeholder needs, system goals."

It explains no difference or relationship between concern (on the one hand) and need, goal or requirement (on the other).

“These issues are subjects for specific architecture frameworks, architecting methods or other practices.”


Third, the standard lists goals, risks and qualities as both concern examples and concern manifestations.


Para. 3.7 The standard says a concern pertains to any influence on a system:

·         Business, Developmental, Operational, Organizational, Regulatory influences.

·         Political, Economic, Social, Technological, Legal, and Ecological (PESTLE) influences

The standard lists these as influences rather than concerns.

Yet if an influence (e.g. a disability access law) is a topic of interest pertaining to the system, then surely, by definition, it is a concern?


Para. 4.2.3 The standard lists more than 30 examples of concerns which I have grouped for convenience under seven headings below.

·         Aims and directives: business goals, business strategies, system purposes

·         Planning concerns: cost, affordability, schedule, complexity, feasibility and known limitations

·         Need types: functionality, performance, reliability, security, privacy, data accessibility and disposability, compliance to regulation, customer experience, usage, qualities, quality of service

·         Needs relating to change: agility, evolvability, maintainability, modifiability and flexibility.

·         Design features: system features, system properties, structure, behaviour, modularity, inter-process communication, subsystem integration, concurrency, deadlock.

·         Other: openness, autonomy, state change, assurance, control, resource utilization, information assurance, software properties, distribution transparencies.


Para.5.3 The standard requires that following particular concerns shall be considered in an architecture description (AD):

·         purposes of the system, suitability of the architecture for achieving the system’s purposes,

·         evolvability and maintainability of the system

·         feasibility of constructing and deploying the system, potential risks and impacts of the system to its stakeholders.


Para 4.2.3 The standard says a concern could be manifested as:

·         Stakeholder needs, goals, requirements; risks, assumptions, issues and dependencies (RAID).

·         Architecture decisions, design constraints, expectations, quality attributes and responsibilities.


Why do goals, risks and qualities appear as both examples and manifestation of concerns?

Presumably, because a “concern manifestation” provides evidence of a stakeholder’s general interest in the subject matter.

In other words, particular goals, risks and qualities provide evidence of interests in the topics or subjects of goals, risks and qualities.

I believe the standard’s authors mean to say that a concern is simply a subject matter; it has no force, target or measure attached to it.


Note that the listed concern examples include what are commonly enumerated as requirement types (performance, reliability and security etc.).

And the standard places architecting in the context of a project with specified requirement instances.

project - “endeavour with defined start and finish criteria undertaken to create a product or service in accordance with specified resources and requirements” [ISO/IEC 12207, ISO/IEC 15288].

On types and instances

Types are abstractions from, and descriptions of, instances.

There is much potential for type-instance ambiguity in natural language.

If you hear about a list of system requirements, you may wonder:

Is it a list of requirement types, general concerns, kinds of need, that are applicable to many systems, many transactions?

·        Throughput

o   Throughput definition: A concern about transaction volume, measured as volume over time.

o   Throughput measure: Transactions per second.

·        Response time

o   Etc,


Or is it a list requirement instances, specific interests, particular needs, for one system?

·        Requirement id: 9998

o   Transaction: Price enquiry

o   Throughput measure: 10,000 transactions per second.

·        Requirement id: 9999

o   Transaction: Price change

o   Throughput measure: 1,000 transactions per second.


Notice the attribute type of the requirement type is instantiated with an attribute value in each requirement instance.

On generalisation and composition hierarchies

The BCS reference model uses the term "aim hierarchy" in relation to goals, objectives and requirements.


It says goal, objective and requirement are three subtypes of “aim” with common properties such as priority and deadline.

The definitions form a two-level type (aka class) hierarchy.


It says for one system, there can be many instances of goals, objectives and requirements, which may be arranged in a hierarchical structure.

From the top-down, goals are decomposed into objectives. From the bottom-up, requirements are traced to objectives.

This makes for a multi-level composition or delegation hierarchy of aim instances. (Cf. delegation in a “balanced score card” system).


The term "aim hierarchy" might be read as referring to the two-level class hierarchy.

But it was in fact written with reference to multi-level composition or delegation hierarchy of aim instances.

Both meanings are possible, and valid in their different ways.


Note that in TOGAF and other sources, SMART means specific, measurable, actionable, realistic and time-bound.

In the BCS aim hierarchy, goals, objectives and requirements are aim instances that can or should have SMART values.

ISO 42010 equates “concern” with a subject matter of interest

The term "concern" implies a worry or motivation to see one or other outcome wrt a topic.

However, the ISO standard appears to say that it is only a topic or subject matter of interest, nothing more.

It does not imply any direction for activity wrt that topic.


Concern: an interest in a system relevant to one or more of its stakeholders.

In the standard, a concern is simply an area of interest, a subject matter, with no force, target or measure attached to it.

Subject matters of interest can include requirements, all standards, a particular standard, architecture, modularity.


The standard’s concern examples do include what are commonly enumerated as requirement types (performance, reliability and security etc.)

I believe this means that its concerns include areas and types of requirement (e.g. throughout) rather than any measurable instance (e.g. 100 tps).

TOGAF tends to equate “concern” with a quality or requirement type

TOGAF has a somewhat different take on concerns.

TOGAF uses the term “concern” in a sense that is closer to stakeholder needs, which must be addressed.

“Concerns” are the key interests that are crucially important to the stakeholders in the system, and determine the acceptability of the system.”


Accordingly, TOGAF lists concerns that correspond to required qualities to be optimised (aka non-functional requirement types).

"The notion of “forces” [as in Design Patterns. Gamma et al.] equates in many ways to the “qualities” that architects seek to optimize, and the concerns they seek to address, in designing architectures.

For example: security, robustness, reliability, fault-tolerance, manageability, efficiency, performance. etc."

From requirement types to requirement instances

The standard says: “Concerns arise throughout the life cycle from system needs and requirements…”

TOGAF directs the reverse: "Identify stakeholders and their concerns/objectives, and define key business requirements to be addressed."


TOGAF says: “Concerns are the root of the process of decomposition into requirements.

Implication: the requirement types above (performance, reliability and security etc.) can appear as concerns in a stakeholder communications plan or architecture viewpoint library.


TOGAF says: “Concerns are represented in the architecture by these requirements.”

Meaning, in response to concerns, requirement instances will be recorded in a requirements repository or catalogue.


TOGAF says: “Requirements should be SMART (e.g. specific metrics).”

Where a requirement type (say throughput) has an attribute type for measurement (transactions per second), a requirement instance should have a value for that attribute type (say, 100).


Suppose your principal stakeholder tells you every day of the week that his main concern is that the target system:

·        Mon: does not fall over when we have high business volumes.

·        Tues: can process the throughput of transactions predicted by the COO.

·        Wed: can process the COO’s predicted maximum throughput of 100 tps.

·        Thurs: can process the predicted throughput of transactions.


These are all expressions of an interest, be it in the topic of throughput in general, or in the topic of the COO’s specifically measurable target.

The more specific and measurable the interest, the more actionable it is, the more likely it will be called a “requirement” rather than a concern.

Requirement types

The rest of this paper focuses on requirement types of the kind listed under the heading of “qualities” in TOGAF.

It does not include all of the BCS reference model entries.

It does not include Avancier’s advice on measuring requirements; it only compares and contrasts lists of requirement types in the public domain.


The table below maps the requirement types in British Computer Society (BCS) standard reference model for enterprise and solution architecture to two other sources.

Note that although requirement measures are commonly applied to a whole component, each service (within an interface) may have its own measure.


BCS reference model

Forces in “Design Patterns”


TOGAF’s definitions (note some duplication therein)


a compound of

Response time and Throughput



Ability of a component to perform its tasks in an appropriate time


Response time

Response times that the service provider must meet for particular operations.



Bandwidth Requirements


Required throughput capacity.

Peak profile long term

Long-term profile of peak service traffic.

Peak profile short term

Short term profile of peak service traffic.


Contracted capacity of the service provider to meet requests

Throughput period

Time period needed to deliver throughput capacity [see response time]


a compound of

Reliability and Recoverability



Degree to which something is available for use.

Service times

Hours during which the service must be available.




Resistance to failure



Ability to restore a system to a working state after an interruption


Completeness, Correctness

Quality of information

Contracted requirements on accuracy and completeness of information


Ability of a system to ensure that data has not been corrupted





Ability of a system to prevent unauthorized access to functions and data.


Protection of data from unauthorized access.


Ability of a system to ensure that the service request originates from an authorized source.




Growth On-demand)


Ability of the service to grow or shrink its performance or capacity appropriately to the demands of the environment in which it operates.


Expected future growth rate of service request.

Growth period

Time period needed to reach the expected growth rate.




Ability to identify problems and take corrective action, such as to repair or upgrade a component in a running system. [see manageability]


Ability to gather information about the state of something and control it.




Ability of a service to support localized variants for different consumer groups.


Ability of a service to support international variations in business logic and data or  character set.


Evolvability, Maintainability




Portability, Openness


Of data, people, applications, and components.






Ability of the service to interoperate with different technical environments, inside and outside of the organization.




Ability to accept new functionality.




Ability of a system to be found when needed.


Space, Modularity,











Contract control


Level of governance and enforcement applied to the contractual parameters for overall service.



Result control

Measures in place to ensure that each service request meets contracted criteria.


Looking at Wikipedia's long list of Requirement types, one is a Planning Concern, there is some duplication of Requirement Types, and some might be called Design Features subordinate to Requirement Types


Wikipedia's list of Requirement Types

Concern subtype

Might be measured in any instance as

Dependency on other parties

Planning concern

A risk type rather than requirement type


Requirement Type

Compliance with Disability law and W3C test cases


Requirement Type

Up time, with exceptions

Capacity, current and forecast

Requirement Type

Throughput as transaction volume over time


Requirement Type

Certified or not


Requirement Type

Compliance or not

Disaster recovery

Requirement Type



Requirement Type

Performance in relation to effort


Requirement Type

Resource consumption for given load

Emotional factors

Requirement Type

Like fun or absorbing


Requirement Type

Successful invocation of Escrow arrangement


Requirement Type

Not sure what Wikipedia means


Requirement Type

Adding features, and carry-forward of customizations at next upgrade


Requirement Type

Notoriously vague: open standards? Canonical data model

Legal and licensing

Requirement Type

Number of fine, imprisonment and patent-infringements


Requirement Type

A notoriously difficult requirement to measure


Requirement Type

A notoriously difficult requirement to measure


Requirement Type

Does this mean Supportability?


Requirement Type

Response time

Platform compatibility

Requirement Type

Notoriously vague. Open standards?


Requirement Type

Notoriously vague. Open standards?


Requirement Type

Surely this means cost?


Requirement Type

PEN test results

Quality [QA sense]

Requirement Type

Faults discovered, faults delivered, fault removal efficacy

Recovery / recoverability

Requirement Type

MTTR - mean time to repair, or RTO + RPO


Requirement Type

MTBF - mean time between failure


Requirement Type

functional I/O testing


Requirement Type

duplicates others?

Response time

Requirement Type

Response time

Safety or Factor of safety

Requirement Type

Needs to be more specific

Scalability (horizontal, vertical)

Requirement Type

Ability to scale


Requirement Type

PEN test results


Requirement Type

See Failure Management and Fault Tolerance


Requirement Type

Test team can make test cases from specifications?

Usability by target user community

Requirement Type

PLUME characteristics. Judgment by nominated test team

Audit and control

Requirement Type.

Ability to inspect who did what and when.


System Feature?

To meet Business Continuity requirements

Configuration management

System Feature?

To meet Maintainability and Modifiability requirements

Failure management

System Feature?

To meet Supportability & Business Continuity requirements

Fault tolerance (System Monitoring, Measuring & Management)

System Feature?

To meet Supportability & Business Continuity requirements

Network topology

System Feature?

To meet other requirements?

Open source

System Feature?

To meet other requirements?

Resource constraints (processor speed, memory, disk space, network bandwidth, etc.)

System Feature?

To meet price/cost or other requirements


System Feature?

To meet Supportability & Business Continuity requirements

Software, tools, standards etc. Compatibility

System Feature?

To meet other requirements



Not sure what Wikipedia means



Not sure what Wikipedia means

Environmental protection


Not sure what Wikipedia means



Not sure what Wikipedia means



Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0                     27/05/2014 20:42

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see