A developer-tools team writes "the workspace must be fast and reliable" into a design document. What is wrong with that, and what should it say instead?

What is wrong

Neither word is testable, so neither word constrains anything. Two engineers can build very different systems, both honestly believing they satisfied it. A quality attribute that cannot fail a test cannot influence a design.

The shape that works

A quality attribute scenario has six parts: source, stimulus, environment, artefact, response, response measure. Written out for an API collaboration tool:

When a user opens a workspace containing 5,000 saved requests (stimulus) under normal weekday load (environment), the collection tree renders its first level within 300ms and becomes interactive within 800ms at p95 (response measure), on a mid-range laptop over a 50ms-RTT connection.

That sentence does work. It tells you the tree cannot be fetched as one document, that the first level must be independently retrievable, and that a 5,000-item workspace is the design point rather than the 20-item one everybody tests with.

The second scenario the first one hides

Reliability for a tool of this shape is rarely about uptime. It is about sync: two devices, one of them offline for twenty minutes, editing the same collection. The scenario is "after reconnection, no user edit is lost and the conflict is presented rather than silently resolved" — and that is a completely different architectural problem from the render-latency one.

Writing them separately is the point. "Fast and reliable" collapses two unrelated design problems into one adjective and delivers neither.