# arc42 Constraints

**In short:** Chapter 2 of arc42 lists every requirement that limits how architects may design and build a system. It shows where the team is free to choose and where it must comply.

## Explanation

A constraint is any requirement that limits the freedom of architects in their design and implementation decisions. Chapter 2 of arc42 (see *arc42 Architecture Documentation Template*) collects them in one place.

The reason is simple. Architects should know exactly where they are free to decide and where they must stick to a given limit.

**Handling constraints.** A team must always deal with a constraint. Some constraints can be negotiated, though. Writing down the background of each one helps readers see which limits are firm and which might move.

**Typical groups.** If the list grows long, you can split it into three groups:

- **Technical constraints.** Limits on the technology to use. The biking2 example requires a Java 8 and Spring Boot showcase. It also requires that the application compiles on Mac OS X, Linux and Windows.
- **Organizational and political constraints.** These include standard processes, budget, time and required information flows. The biking2 example requires that source and documentation be published as open source under the Apache 2 License.
- **Conventions.** Rules such as programming style and naming conventions.

**Typical format.** A simple table works well: one column names the constraint, and another explains it and gives its background.

**Constraints and other chapters.** The related article *Architectural Constraint* covers how constraints differ from requirements. Decisions the team makes itself belong in the chapter on *arc42 Architecture Decisions*. The approach built within the limits belongs in *Solution Strategy*.

## Example

A team builds a small web shop. Its constraints table might read:

| Constraint | Background |
|---|---|
| Must compile on Linux, Windows and macOS | Developers work on all three systems. |
| Source code published as open source | The company wants outside contributors. |
| Variable names follow the company naming rules | Teams share code across projects. |

A reader sees at once which choices are already made for the team. Everything not listed is open for design decisions.



## Checks

- The document lists constraints in one place, with an explanation or background for each.
- Constraints are grouped into technical, organizational/political and conventions where the list is long.
- Organizational constraints such as budget, time or processes are recorded.
- Conventions such as programming style and naming rules are recorded.
- Each constraint shows whether it may be negotiated.

## Related

- [Architectural Constraint](https://arc.fuet.ch/concepts/forces-decisions/requirements-versus-constraints.md)
- [arc42 Architecture Documentation Template](https://arc.fuet.ch/concepts/documentation/arc42-documentation-template.md)
- [Solution Strategy](https://arc.fuet.ch/concepts/documentation/arc42-solution-strategy.md)
- [arc42 Architecture Decisions](https://arc.fuet.ch/concepts/documentation/arc42-architecture-decisions.md)
- [arc42 Introduction and Goals](https://arc.fuet.ch/concepts/documentation/arc42-introduction-and-goals.md)
- [Operational Constraint](https://arc.fuet.ch/concepts/quality-attributes/operational-constraint.md)

## Sources

- [2 - Constraints | arc42 Documentation](https://docs.arc42.org/section-2/) — docs.arc42.org, accessed 2026-11-09
- [Question C-2-2: What types of constraints exist? | arc42 FAQ](https://faq.arc42.org/questions/C-2-2/) — faq.arc42.org, accessed 2026-11-09
- [Architecture Constraints · arc42 Examples](https://examples.arc42.org/systems/biking/02-architecture-constraints/) — examples.arc42.org, accessed 2026-11-09