Cost is usually treated as an afterthought, a bill that arrives once the design is finished. It behaves exactly like the other quality attributes, and it should be written down the same way: a quantity, a target value, and the condition under which it holds. Monthly running cost at the stated peak load, or cost per thousand completed orders, is a requirement in the same sense that a response-time target is. Stating it early changes designs, because almost every tactic that buys availability, latency or throughput buys it by spending money: a second copy of a machine, a cache, a queue with its own capacity, a standby that serves nothing. If cost has no target, those purchases look free during design and appear as a surprise in operation, at which point the cheapest thing to cut is usually the redundancy that was protecting the availability target. Cost also has an unusual property among attributes: it is the one every stakeholder already understands, so expressing a trade in money is often the only way a technical argument reaches a decision. After this Concept you can write a cost requirement with a unit and a condition, and explain which of your other targets a cost ceiling is quietly bounding.
This concept describes a three-force tradeoff model for software architecture decisions, in which every design choice is pulled between performance (low latency, high throughput), cost (budget constr…