Skip to content

Twin Peaks Model

Requirements say what a system must do. Architecture describes how the system will be built. The Twin Peaks Model says these two should not run one after the other. Teams refine them in parallel, and each one influences the other.

Both start rough and general. Through repeated rounds, both become detailed. A team might sketch the main requirements, then sketch a first architecture. Next it returns to the requirements with new insight, then deepens the architecture again.

This interplay matters because architecture work can teach something about the requirements. While designing, the team can find technical limits. It can also find goals that conflict with each other. Those findings feed back into the requirements.

See Architecturally Significant Requirement for requirements that shape the architecture most.

A team sketches the requirements for an online ticket shop. Its first architecture draft shows that two goals pull against each other: instant order confirmation and a slow external check of every order. The team takes this back to the requirements and revises them. Then it refines the architecture again, with more detail on both sides.

The verified facts do not cover costs or downsides of this approach.

Requirements and architecture alternate, both gaining detail each round.

Diagram source
flowchart LR
R1[Rough requirements] --> A1[Rough architecture]
A1 --> R2[More detailed requirements]
R2 --> A2[More detailed architecture]
A2 -. limits and goal conflicts .-> R2
  • The document shows that requirements and architecture were refined together, in mutual interplay.
  • Requirements and architecture are described at a level of detail that grew through iteration, starting from a rough version.
  • Technical limits or goal conflicts found during architecture work are recorded as feedback to the requirements.