Skip to content
Software Architecture Guide

Stakeholder Questions Addressed in Views

Explanation

Section titled “Explanation”

A single large model of a system serves individual stakeholders poorly. Each person struggles to find the part that interests them. Separate views solve this problem. Together, the views describe the whole system.

A viewpoint is a set of conventions for building one type of view. It also states whose concerns it reflects. So each concern maps to a viewpoint, and each view serves a defined audience. The article “Stakeholder Concern” covers concerns in more detail.

This gives a practical method. List the questions your stakeholders keep asking. Then pick the view that answers each one. Skip views that nobody asks about.

Some examples of how questions map to views:

  • “Who and what does the system talk to?” The Context viewpoint answers this. It shows how the system relates to its environment, meaning external systems and users.
  • “What are the main parts, and how are they split up?” The arc42 building block view answers this. It shows the static decomposition. Architects can discuss it with stakeholders at an abstract level, without exposing implementation details.
  • “Which quality goals matter most?” arc42 quality goals are the ones of highest importance to the major stakeholders. They shape fundamental architectural decisions, so the documentation should make them easy to find.

The first step is to know your stakeholders. arc42 asks architects to identify all of them, including people who need the documentation to do their work. Without that list, you cannot know which questions to answer.

Example

Section titled “Example”

A team builds an order-handling system. The project sponsor asks which quality goals matter most. A partner company asks which systems exchange data with it. A new developer asks how the system is split into parts.

The team does not write one giant document. It writes a short quality goals list for the sponsor. It draws a context view for the partner. It draws a building block view for the developer. Each reader finds an answer to their own question.

Trade-offs

Section titled “Trade-offs”

Separate views serve each audience better, but they create more documents to keep consistent. Choosing views by questions also depends on knowing your stakeholders. If you miss a stakeholder, you miss their questions, and no view will answer them.

Stakeholder questions point to the views that answer them

Diagram source 
flowchart LR
  S[Stakeholder] --> Q[Recurring question]
  Q --> C[Concern]
  C --> VP[Viewpoint]
  VP --> V[View]
  V --> S

Checks

Section titled “Checks”
  • The documentation lists its stakeholders, including those who need it for their work.
  • Each view or viewpoint states which stakeholders’ concerns it serves.
  • Questions about external systems and users are answered in a context view.
  • The most important quality goals are stated and tied to the major stakeholders.
  • The building block view explains the static decomposition without implementation detail.
Section titled “Related”

Sources

Section titled “Sources”