Concerns, qualities and non-functional requirements

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

Abstract

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.

Contents

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

Concerns

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	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	TOGAF’s definitions (note some duplication therein)
Performance: a compound of Response time and Throughput	Performance	Performance	Ability of a component to perform its tasks in an appropriate time
	Efficiency	Response time	Response times that the service provider must meet for particular operations.
	Utilization, Throughput, Bandwidth Requirements	Throughput	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.
		Capacity	Contracted capacity of the service provider to meet requests
		Throughput period	Time period needed to deliver throughput capacity [see response time]
Availability: a compound of Reliability and Recoverability		Availability	Degree to which something is available for use.
		Service times	Hours during which the service must be available.
	Reliability, Fault-tolerance	Reliability	Resistance to failure
	Robustness	Recoverability	Ability to restore a system to a working state after an interruption
Integrity	Completeness, Correctness	Quality of information	Contracted requirements on accuracy and completeness of information
		Integrity	Ability of a system to ensure that data has not been corrupted
Security	Security	Security	Ability of a system to prevent unauthorized access to functions and data.
		Privacy	Protection of data from unauthorized access.
		Credibility	Ability of a system to ensure that the service request originates from an authorized source.
Scalability	Scalability (Incremental Growth On-demand)	Scalability	Ability of the service to grow or shrink its performance or capacity appropriately to the demands of the environment in which it operates.
		Growth	Expected future growth rate of service request.
		Growth period	Time period needed to reach the expected growth rate.
Serviceability	Manageability	Serviceability	Ability to identify problems and take corrective action, such as to repair or upgrade a component in a running system. [see manageability]
		Manageability	Ability to gather information about the state of something and control it.
Usability	Ease-of-use	Localization	Ability of a service to support localized variants for different consumer groups.
		Internationalization	Ability of a service to support international variations in business logic and data or character set.
Maintainability	Evolvability, Maintainability	n/a
Portability	Portability, Openness	Portability	Of data, people, applications, and components.
Interoperability	Composability (Plug-and-play), Re-usability	Interoperability	Ability of the service to interoperate with different technical environments, inside and outside of the organization.
Extensibility	Extensibility	Extensibility	Ability to accept new functionality.
n/a	n/a	Locatability	Ability of a system to be found when needed.
n/a	Space, Modularity, Independence, Ease-of-construction,	n/a
n/a	n/a	Contract control requirements	Level of governance and enforcement applied to the contractual parameters for overall service.
n/a	n/a	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
Accessibility	Requirement Type	Compliance with Disability law and W3C test cases
Availability	Requirement Type	Up time, with exceptions
Capacity, current and forecast	Requirement Type	Throughput as transaction volume over time
Certification	Requirement Type	Certified or not
Compliance	Requirement Type	Compliance or not
Disaster recovery	Requirement Type	RTO + RPO
Effectiveness	Requirement Type	Performance in relation to effort
Efficiency	Requirement Type	Resource consumption for given load
Emotional factors	Requirement Type	Like fun or absorbing
Escrow	Requirement Type	Successful invocation of Escrow arrangement
Exploitability	Requirement Type	Not sure what Wikipedia means
Extensibility	Requirement Type	Adding features, and carry-forward of customizations at next upgrade
Interoperability	Requirement Type	Notoriously vague: open standards? Canonical data model
Legal and licensing	Requirement Type	Number of fine, imprisonment and patent-infringements
Maintainability	Requirement Type	A notoriously difficult requirement to measure
Modifiability	Requirement Type	A notoriously difficult requirement to measure
Operability	Requirement Type	Does this mean Supportability?
Performance	Requirement Type	Response time
Platform compatibility	Requirement Type	Notoriously vague. Open standards?
Portability	Requirement Type	Notoriously vague. Open standards?
Price	Requirement Type	Surely this means cost?
Privacy	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
Reliability	Requirement Type	MTBF - mean time between failure
Reporting	Requirement Type	functional I/O testing
Resilience	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
Security	Requirement Type	PEN test results
Supportability	Requirement Type	See Failure Management and Fault Tolerance
Testability	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.
Backup	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
Robustness	System Feature?	To meet Supportability & Business Continuity requirements
Software, tools, standards etc. Compatibility	System Feature?	To meet other requirements
Deployment	Z	Not sure what Wikipedia means
Documentation	Z	Not sure what Wikipedia means
Environmental protection	Z	Not sure what Wikipedia means
Stability	Z	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: http://avancier.co.uk” 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 http://creativecommons.org