Skip to content
Software Architecture Guide

Stakeholder Concern

Explanation

Section titled “Explanation”

A concern is an interest that a stakeholder has in a system. arc42 uses ISO 42010 terminology here and gives examples: performance, security, and maintainability.

A stakeholder is a person, team, or organization with an interest in the realization of the system. Stakeholder types include acquirers, who oversee procurement, and developers, who build and deploy the system from specifications. See the article Stakeholder for more.

Each stakeholder group has its own requirements, interests, and needs. The system must meet them. So different groups bring different concerns.

How concerns connect to other things

  • Concerns and views relate n:m (many-to-many). One view can address several concerns, held by several stakeholders. One concern can also appear in several views.
  • A viewpoint defines which stakeholders’ concerns it reflects. In ISO 42010, a viewpoint is a specification for building a single view. It names the stakeholders, the concerns, and the modeling techniques. In this way, concerns frame viewpoints. See Architecture Viewpoint and Architecture View.
  • Stakeholders’ quality goals influence fundamental architectural decisions. arc42 recommends a table with roles, names, and what each stakeholder expects from the architecture and its documentation.
  • Business objectives are often more global and higher-level than detailed system requirements. They are an input from which concerns can be drawn.

Why it matters for documentation

An architecture description is complete only if it addresses stakeholder concerns explicitly. A concern that nobody wrote down cannot be shown as addressed.

Example

Section titled “Example”

A town builds an online permit system. The acquirer, who oversees procurement, cares about what the system will cost to buy. The developers care about building it from clear specifications. Both concerns go into a stakeholder table with each role and its expectations. One view, such as a diagram of the main parts of the system, may address both concerns. The architecture description then shows explicitly how each concern is addressed.

Trade-offs

Section titled “Trade-offs”

Every stakeholder group brings its own needs, and one view can serve several concerns at once. That makes it hard to cover them all in a single view. Making every concern explicit makes the description more complete, but it also means more concerns to track and show as addressed.

Stakeholders hold concerns. Viewpoints are framed by concerns, and views address them.

Diagram source 
flowchart LR
  S[Stakeholders] -->|hold| C[Concerns]
  C -->|frame| P[Viewpoints]
  P -->|used to build| V[Views]
  V -->|show how architecture addresses| C

Checks

Section titled “Checks”
  • Stakeholders and their expectations are recorded, for example in a table with roles and expectations.
  • Each stakeholder concern is explicitly addressed in the architecture description.
  • Each viewpoint names the stakeholders and concerns it reflects.
  • Each view states which concerns it addresses.
Section titled “Related”

Sources

Section titled “Sources”