> The goal of a design document is to convince the reader the design is optimal given the situation.
This is a nitpick, but I don't think the goal of a design is to be optimal so much as sufficient.
Software systems design, like any design, is about coping with constraints and tradeoffs. The design doc should clearly lay out these out and present an approach that meets the requirements and constraints with acceptable tradeoffs. Where multiple reasonable alternatives exist, they should be make explicit along with a justification for why one option was chosen over the others.
Will it be perfect? Probably not, unless it is an easy problem or you over-designed. And even if it's a good design, it can hit unforeseen issues during implementation. The goal of design is not to eliminate all possibility of such issues but to mitigate risks and communicate to the stakeholders what we're building and why we're building it that way.
Isn’t “making acceptable tradeoffs” (optimization) while “meeting requirements & constraints” (under constraints) simply optimization under constraints? I fail to see how this is about sufficient _but not optimal_ solutions.
The dictionary defintion of optimal is just 'best'; the connotation that 'optimal' means not perfect, but satisfying multiple constraint, is engineering jargon. In fact, with 'optimal', people will often mean 'Pareto optimal' (a design where there is no change that would improve the solution on all dimensions/constraints).
Pareto optimality also implies that multiple designs may exist in a 'draw', where design 1 is better on dimension A, but worse on dimension B, and design 2 flips those. These designs are on a pareto front. Making the trade-offs explicit helps readers of the design document who come along later to choose a different trade-off when it later turns out that the relative importance of the dimensions involved changed.
I generally read "optimal" to mean "optimal according to some objective function". In the case of a technical design, the objective is not something you can readily formalize, because there are so many considerations.
For example, suppose you are designing a network service to meet some use case. Yes, it needs to meet the use case, but there are other things you care about like simplicity of the code, latency, cost to operate the service, and others.
For any design you propose, there might exist an alternate design that is strictly better by some criteria-maybe it works exactly the same but has much better latency characteristics. If an oracle gave you this design, you might agree it was more optimal and choose to implement it, but I don't think it means you failed if you come up with a (sub-optimal) design that solves the problem within the constraint.
Compromise is the term synonymous with "making acceptable tradeoffs”, not optimisation.
"Optimal" in this context includes time, effort and cost. So the design isn't perfect irrespective of these things, but it is optimal in terms of balancing the effectiveness of the solution with the effort put in.
It's also not intended to be frozen in place and some allowance should be made for refinement with out scope breaking (fine but falls under change control) -- the level of detail here is important so known unknowns are surfaced not solved. High Level Designs and Low Level Designs are different documents for a reason allowing for a sufficient approach to be optimized during the transition.