知识卡片
质量需求可测
内容
非功能性需求只有可测试，才足以指导架构。比如“系统要快”不能产生设计约束，“预订确认不超过10秒、支持5000并发用户”才会影响部署、缓存、事务和容量方案。发散：质量属性要写成可被验证的承诺，否则它只是愿望。
参考来源
- 位置：《架构实战:软件架构设计的过程》第7章《定义需求》7.6节“步骤：细化非功能性需求场景”（源文件：_chapter-text/ch07.txt）
- 结论依据：原文以YourTour系统的预定确认响应时间和并发用户数为例，说明非功能性需求必须细化为可测量的场景才能指导架构，并引用Gilb的话强调质量属性必须可测量，直接支持“质量需求可测”。
- 原始内容：预定旅游线路用例声明了以下特殊需求：从提交预定到用户得到预定确认的响应时间小于10 s……环境。有5000个用户同时登录系统……质量属性总是能够做到可测量。这常常看起来很难，但总有方法做到这一点。（Gilb 1998）