Skip to content
Software Architecture Guide

System Idea and Vision Elements

Explanation

Section titled “Explanation”

A system exists to improve how a business activity is supported. The requirements overview in arc42 (see arc42 Introduction and Goals) records those requirements and the driving forces that architects and the team must consider.

The vision statement. A vision board is one way to write the vision down. Its vision statement is a short summary of the idea. It covers the intention and the motivation behind it. See Vision Statement.

Elements around the statement. The vision board adds four more elements: target group, needs, product and value. The target group is the market or segment you want to address. Value links to the business goals and to the business case. The business case explains why investing in the product is worthwhile.

Stakeholders. arc42 asks for an explicit stakeholder overview. It is a table of roles, names and expectations. See Stakeholder.

Requirements built on the vision. The vision board should come before user stories. Stories need knowledge of the users and their reasons, and the board supplies both. The team then uses the board to create the initial backlog. See User Story.

Context. The business context lists all communication partners of the system. All stakeholders should be able to understand it. Domain and technical interfaces are among the most critical aspects. If needed, the business context (domain-specific inputs and outputs) is kept apart from the technical context. See Business and Technical Context.

Together, the vision, stakeholders, requirements and context describe one system from different sides.

Example

Section titled “Example”

A team plans a booking tool for small clinics. The vision statement says the tool should make appointment handling less work for front-desk staff. The target group is small clinics. The need is fewer missed appointments. The value is lower staff cost for the clinic. The team then writes user stories for front-desk staff. It also lists the communication partners, such as patients and a calendar service, in the business context.

Trade-offs

Section titled “Trade-offs”

Writing the vision first gives stories a clear purpose, because stories need knowledge of users and their reasons. The cost is extra upfront effort before any backlog exists. Keeping business and technical context apart helps all stakeholders read the business view. It does mean maintaining two views.

Elements of a vision and how they build on each other.

Diagram source 
flowchart LR
  V[Vision statement] --> T[Target group and needs]
  T --> P[Product and value]
  P --> B[Business goals]
  V --> S[User stories]
  V --> C[Context view]
  S --> C

Checks

Section titled “Checks”
  • The documentation has a stakeholder table with roles, names and expectations.
  • The business context lists all communication partners and is understandable by all stakeholders.
  • The vision statement summarizes the intention and motivation of the idea.
  • Value in the vision is linked to business goals and the business case.
Section titled “Related”

Sources

Section titled “Sources”