需求规格说明书里，功能需求往往写得详细，非功能需求却常被几个词打发：“高扩展性、高弹性、高可用、易维护”。写的人Copy，看的人略过。可到了开发阶段，架构师却可能被这些词坑得苦不堪言。
定性之败：架构师的愤怒
一位架构师指着需求文档里的“高扩展性、高弹性”，愤怒地问需求人员：“你告诉我系统还要往哪儿扩、往哪儿弹！”原来他在这两个词上吃过亏。看到“高扩展性”，他实现了流程可配置、数据库字段可扩展、界面可配置。结果呢？流程、数据、界面的变化都不多，反而是业务规则大量变化，而这块他没做可配置。最后被“高扩展性”搞得筋疲力尽。
问题出在哪？光写“高扩展性”是不够的。应该说明未来的“变化”是什么：业务流程变化？法规变化？业务模式变化？只有说清楚变化场景，架构师才知道往哪儿扩、往哪儿弹。比如，如果业务规则经常变，那就该把规则引擎作为扩展点，而不是界面配置。
定量之伤：为量化而量化
另一份需求文档里写着：“平均无故障时间2756小时，平均用户学习时间1.25小时。”作者被问及这些指标怎么来的，悄悄说：“我们是CMMI 4级，你懂的……”CMMI 4级是量化管理级，为了给评估师看，硬编了数字。这样的量化，毫无意义。
量化难，难在需求阶段缺乏历史数据。没有历史数据，量化就是拍脑袋。比如“平均无故障时间2756小时”，依据是什么？如果以前系统平均故障间隔是2000小时，目标提升到2756小时，那还合理。如果凭空写，架构师只能苦笑。
破解之道：场景化描述
非功能需求不能只写定性词，也不能为量化而量化。正确方法是场景化。
比如“高扩展性”，可以写成：“系统需支持业务规则的频繁变更。预计每季度新增或修改约20条规则，变更后无需修改代码，通过配置即可生效。”这样架构师就知道要做规则引擎。
再比如“易用性”，不要写“界面友好”，而是写：“新用户首次使用，应在5分钟内完成核心操作，无需培训。用户群体为40岁以上非技术人员，界面需大字体、步骤提示。”这样交互设计师就有方向。
性能需求也一样。不要写“响应快”，而是写：“在1000用户并发下，查询操作响应时间不超过2秒。峰值出现在每月1日上午9点，并发用户约1500。”如果历史数据显示过去峰值是1200，那1500就是合理目标。
量化需要历史数据
有效量化前提是积累历史数据。如果组织有历史项目数据，可以基于基线设定目标。比如过去系统平均故障间隔2000小时，新系统目标提升20%，即2400小时。如果没有历史数据，可以先写场景和约束，等系统上线后收集数据，再逐步量化。不要为了评估而编数字。
总结
非功能需求描述，定性空洞无效，定量虚假有害。破解之道是场景化：说清楚谁用、什么场景、什么变化、什么约束。量化要基于历史数据，没有数据就先描述场景。这样架构师才知道往哪儿努力，系统才能真正满足需要。
最后，四句诗总结：
定性空谈害死人，定量无据亦失真。
场景描述明方向，历史数据定乾坤。
参考书目：有效需求分析 ，作者： 徐锋，出版社： 电子工业出版社
