# Step 5: Collect constraints and forces

## What you get from this step

You get two lists. The first lists the constraints: requirements that limit how you may design and build the system. The second lists the forces: pressures that pull a design decision in different directions.

The constraint list goes into chapter 2 of arc42 (see [arc42 Constraints](https://arc.fuet.ch/concepts/documentation/arc42-constraints.md)). It shows where the team is free to choose and where it must comply. The force list helps you later, when you weigh options and write down decisions.

The two lists work differently. You must deal with a constraint, although some can be negotiated. You weigh a force against other forces. [Architectural Force](https://arc.fuet.ch/concepts/forces-decisions/architectural-forces.md) explains the difference.

## What you need first

- A rough idea of what the system must do and for whom.
- The main stakeholders and the quality goals they care about most. A stakeholder is a person or group with an interest in the system. See [Stakeholder Concern](https://arc.fuet.ch/concepts/forces-decisions/stakeholder-concern.md) and [Concern](https://arc.fuet.ch/concepts/forces-decisions/concern.md).
- Access to the people who set rules for your project: management, the organization's technology owners, and legal or security contacts.

## If something is missing

- **You do not know the quality goals.** Ask the most important stakeholders first. Without their goals you cannot tell which pressures matter. See [Requirements and Means Influence Architecture](https://arc.fuet.ch/concepts/fundamentals/requirements-and-means-influence-architecture.md).
- **You cannot tell whether something is a constraint or a force.** Ask who wants it and why. If nobody can say, write it down as "unclear" and find out.
- **You do not know whether a constraint is fixed.** Mark it "to be clarified" and name the person who can answer. Do not guess.
- **The list is incomplete.** That is normal at the start. Constraints limit your freedom, and early choices may prove wrong, so you will revisit the list. See [Architecture Challenges at Project Start](https://arc.fuet.ch/concepts/forces-decisions/architecture-challenges-at-project-start.md).
- **You find a technical limit or a goal conflict while working.** Record it and pass it back to the requirements. See [Twin Peaks Model](https://arc.fuet.ch/concepts/forces-decisions/twin-peaks-model.md).

## How to do it

1. **Learn the difference.** A constraint must be handled, and some constraints can be negotiated. A force is weighed against other forces. Typical forces are deadlines, cost, skills and change. See [Architectural Force](https://arc.fuet.ch/concepts/forces-decisions/architectural-forces.md).
2. **Collect all constraints in one place.** One list lets architects see where they are free and where they must comply. See [Architectural Constraint](https://arc.fuet.ch/concepts/forces-decisions/requirements-versus-constraints.md) and [arc42 Constraints](https://arc.fuet.ch/concepts/documentation/arc42-constraints.md).
3. **Look beyond your own system.** Organization-wide rules, such as mandated technologies, also count as constraints. Check the organization's standards. A catalogue of approved technologies tells you which ones are standard, need approval or are not permitted. See [Relationship between Enterprise Architecture and Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/relationship-between-enterprise-architecture-and-application-architecture.md) and [IT Component Catalogue](https://arc.fuet.ch/concepts/enterprise-architecture/it-component-catalogue.md).
4. **Check hosting and regulation.** Technical constraints and rules on regulation or data location belong on the list. See [Technology Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/technology-architecture.md).
5. **Group a long list.** Use three groups: technical, organizational/political, and conventions. Organizational constraints include budget, time and processes. Conventions include programming style and naming rules. See [arc42 Constraints](https://arc.fuet.ch/concepts/documentation/arc42-constraints.md).
6. **Describe each constraint.** For each one, write down:
   - who wants it and why,
   - what it costs you, such as extra effort,
   - whether it is fixed or negotiable.

   See [Architectural Constraint](https://arc.fuet.ch/concepts/forces-decisions/requirements-versus-constraints.md) and [Software Architecture in Its Context](https://arc.fuet.ch/concepts/fundamentals/software-architecture-in-its-context.md).
7. **Mark which constraints come from the wider organization.** Separate them from constraints that come only from your system. See [Software Architecture in Its Context](https://arc.fuet.ch/concepts/fundamentals/software-architecture-in-its-context.md).
8. **List the forces.** Name the pressures that pull in different directions. Write each as a pair of competing concerns, such as time to market versus maintainability. See [Concern](https://arc.fuet.ch/concepts/forces-decisions/concern.md).
9. **State where you are free and where you are bound.** Read both lists together and write one or two sentences about it. See [Architectural Force](https://arc.fuet.ch/concepts/forces-decisions/architectural-forces.md).
10. **Keep the lists current.** Revisit them when the context changes.

## Example: ClinicBook

ClinicBook is an online appointment booking system for 40 small medical practices. Patients book, move and cancel appointments on the web and in a mobile app. Practice staff manage calendars. The system sends reminders by SMS and e-mail.

The team collects these constraints. The entries are fictional.

| Constraint | Group | Who wants it, and why | Consequence | Fixed or negotiable |
|---|---|---|---|---|
| Work with the practices' existing practice-management software from several vendors | Technical | The practices. They run their daily work on that software. | Several integrations to build and test | Fixed. The practices keep their software. |
| Protect health data | Technical | Patients, practices and the law. Health data is sensitive. | Extra effort for security, and checks on where data is hosted | Fixed |
| Launch on the agreed date | Organizational | The project sponsor | Less room to add features or integrations | To be clarified. Ask the sponsor whether the date can move. |
| Team of a few developers | Organizational | Budget set by the sponsor | Limits how much the team can build and run | Negotiable only through budget |
| Agreed code style and naming rules | Conventions | The team, for readability | Small effort to set up and check | Negotiable inside the team |

Hosting stays on the list as an open question. The team asks the privacy contact for concrete rules on where health data may be stored. See [Technology Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/technology-architecture.md).

Next, the team lists the forces:

- **Privacy and security versus quick booking.** Stronger checks protect data but may slow patients down.
- **Availability during morning peaks versus a small team.** Extra redundancy keeps booking working when parts fail. It also adds cost and complexity that a small team must carry. See [Architectural Decisions for Availability](https://arc.fuet.ch/concepts/forces-decisions/architectural-decisions-for-availability.md).
- **Integration with legacy systems versus the launch date.** Every new vendor adds work, and the date does not move.
- **Many integrations versus a small team.** The team must choose where to spend limited effort.

Finally, the team writes a short summary. The integration needs, the data protection rules and the launch date bind the design. The team is free in how it builds the web app, the mobile app and the reminder service. The launch date goes back to the sponsor as an open question.

## Done when

- All constraints sit in one list, grouped as technical, organizational/political and conventions. See [arc42 Constraints](https://arc.fuet.ch/concepts/documentation/arc42-constraints.md).
- Each constraint shows who wants it, why, what it costs and whether it is fixed or negotiable. See [Architectural Constraint](https://arc.fuet.ch/concepts/forces-decisions/requirements-versus-constraints.md).
- Organization-wide constraints are marked apart from system-specific ones. See [Relationship between Enterprise Architecture and Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/relationship-between-enterprise-architecture-and-application-architecture.md).
- Hosting and regulatory limits appear as concrete entries, or as named open questions. See [Technology Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/technology-architecture.md).
- The forces are listed as competing concerns and kept apart from the constraints. See [Architectural Force](https://arc.fuet.ch/concepts/forces-decisions/architectural-forces.md).
- A short statement says where the team is free and where it is bound. See [Software Architecture in Its Context](https://arc.fuet.ch/concepts/fundamentals/software-architecture-in-its-context.md).

## Learn more

- [arc42 Constraints](https://arc.fuet.ch/concepts/documentation/arc42-constraints.md)
- [Architectural Constraint](https://arc.fuet.ch/concepts/forces-decisions/requirements-versus-constraints.md)
- [Architectural Force](https://arc.fuet.ch/concepts/forces-decisions/architectural-forces.md)
- [Concern](https://arc.fuet.ch/concepts/forces-decisions/concern.md)
- [Stakeholder Concern](https://arc.fuet.ch/concepts/forces-decisions/stakeholder-concern.md)
- [Requirements and Means Influence Architecture](https://arc.fuet.ch/concepts/fundamentals/requirements-and-means-influence-architecture.md)
- [Software Architecture in Its Context](https://arc.fuet.ch/concepts/fundamentals/software-architecture-in-its-context.md)
- [Architecture Challenges at Project Start](https://arc.fuet.ch/concepts/forces-decisions/architecture-challenges-at-project-start.md)
- [Relationship between Enterprise Architecture and Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/relationship-between-enterprise-architecture-and-application-architecture.md)
- [IT Component Catalogue](https://arc.fuet.ch/concepts/enterprise-architecture/it-component-catalogue.md)
- [Technology Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/technology-architecture.md)
- [Twin Peaks Model](https://arc.fuet.ch/concepts/forces-decisions/twin-peaks-model.md)
- [Architectural Decisions for Availability](https://arc.fuet.ch/concepts/forces-decisions/architectural-decisions-for-availability.md)