arc42: How Do You Document Constraints for Your Software Architecture in Chapter 2?

Not even love is without boundary conditions.

There are certainly some constraints for your software. Some constraints are more central to your software architecture than the name suggests. This is because constraints limit you in finding a solution.

Constraints are requirements for your software that take away your freedom.

This is not necessarily a bad thing.

Of course, it sometimes makes finding a solution quite taxing. But at the same time, these restrictions allow you to rule out alternatives. So, they show you the way and take the burden of decision away from you.

To know your true decision freedom, you should write down the constraints.

This is precisely what chapter 2 of the arc42 outline is for.

It gives you an overview of the limitations you have to deal with. This way you can negotiate, consider and track them. Because typically, constraints also change over the lifetime of your software.

How do you write them down?

• In a table (name, explanation).
• Give the constraint a name and explain it briefly (origin, purpose).
• If you have many constraints, it is a good idea to group them and split them into several tables. (Suggested candidates for groups in arc42 are technical constraints, organizational constraints, and conventions).
• Some constraints are company-wide or apply to a product category/industry. If there is documentation, refer to the considered version and name the most influential ones here.