Ask any group of stakeholders which qualities matter and every one of them matters. That answer is useless, because the attributes genuinely fight each other. Keeping a second copy of the data in another building buys availability and costs latency and money. Answering from a cache buys speed and costs freshness. Splitting the system into independently deployable parts buys the ability to change one thing safely and costs you a network hop in every path that used to be a function call. A design cannot maximise all of them, so somebody ranks them, and if you do not do it deliberately the ranking still happens, made accidentally by whoever writes the first component. The usable form is a tree: take each attribute, list the scenarios that express it, and mark each scenario twice, once for how much the business cares and once for how hard you think it will be. The scenarios that are high on both are the ones your architecture actually has to be built around, and there are usually only a handful. Stakeholders rank far more honestly against concrete scenarios than against words like reliability. After this Concept you can turn a set of scenarios into a ranked short list, and name the two or three that your design must be organised around.
Video tutorial: Evaluating Software Architecture Tradeoffs and Risks Using ATAM