A diagram of boxes and arrows cannot be right or wrong on its own, because it makes no claim. It becomes checkable the moment you push a written scenario through it. Take one quality attribute scenario, the kind with a stimulus, an environment and a measured response, and trace it across the drawing step by step. A request arrives here, it crosses this boundary, this component reads that store, this hop has a timeout, the answer returns. At each step ask two questions: what is the response the design produces, and where is the number coming from. Then repeat with the scenario for the next attribute, and with the failure scenarios, where the stimulus is a machine dying or a dependency answering slowly rather than a user clicking. Two things fall out. The first is a set of sensitivity points, the places where one component or one setting decides the outcome for the whole scenario. The second is a set of trade-off points, the places where the design already does well on one attribute at the cost of another. A walkthrough is cheap, needs no code, and finds the design flaws that a review of the drawing alone will not. You can now take a design drawing and a list of scenarios and produce, for each scenario, the response the design gives and the step that determines it.
Video tutorial: Evaluating Software Architecture Tradeoffs and Risks Using ATAM