# Twin Peaks Model

**In short:** The Twin Peaks Model treats requirements and architecture as two bodies of work that grow together. Both start rough and become detailed through repeated rounds, each informing the other.

## Explanation

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.

## Example

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.

## Trade-offs

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

Requirements and architecture alternate, both gaining detail each round.

```mermaid
flowchart LR
  R1[Rough requirements] --> A1[Rough architecture]
  A1 --> R2[More detailed requirements]
  R2 --> A2[More detailed architecture]
  A2 -. limits and goal conflicts .-> R2
```

## Checks

- 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.

## Related

- [Architecturally Significant Requirement](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-requirement.md)
- [Iterative and Incremental Development](https://arc.fuet.ch/concepts/fundamentals/iterative-and-incremental-development.md)
- [Architectural Force](https://arc.fuet.ch/concepts/forces-decisions/architectural-forces.md)
- [Iterative Domain Modeling](https://arc.fuet.ch/concepts/domain-driven-design/evolutionary-domain-modeling.md)
- [Solution as Moving Target](https://arc.fuet.ch/concepts/forces-decisions/solution-as-moving-target.md)

## Sources

- [What Is the Twin Peaks Model? | microTOOL](https://www.microtool.de/en/knowledge-base/what-is-the-twin-peaks-model/) — microtool.de, accessed 2026-11-09