量化需求

作者：基思·布雷思韦特（KeithBraithwaite）

“速度快”不能算作需求，“响应灵敏”和“可扩展”也不能算需求，因为我们无法客观的判断是否满足了这样的条件。但是这些又确实是用户想要的。架构师的工作在很大程度上是平衡这些需求之间的不可避免的冲突和矛盾，同时又使系统尽可能的满足他们。如果缺乏客观的规律，架构师就只能任凭挑剔的用户和偏执的程序员摆布（“还不够快，我拒绝接受”和“还不够快，我不能发布”是他们的口头禅）。

在记录需求的过程中，经常会出现模糊的描述，比如“灵活”、“可维护性”等，实践证明，所有这些需求都可以量化，并设定相应的检测标准（甚至连“易于使用”这样的需求都可以量化，只是要费些工夫）。没有量化的需求会导致用户验收系统时缺乏依据，架构师不知所措，开发工作失去正确的指导。

我们可以通过一些简单的问题来量化需求，例如：数量有多少？在什么阶段？有多频繁？不能超过多长时间？增加还是减少？占多大比例？如果得不到答案，需求就不明确。这些答案应该包括在系统的业务策划方案里，否则还得费不少脑筋。如果架构师无法从业务部门那里得到这些数字，应该先反思原因，然后再想办法。下次再有人对系统提出“可伸缩（scalable）”的要求，一定要问清楚新用户从何而来，为什么数量会增加，以及何时增加，会增加多少。拒绝“很多”，“马上”这类模棱两可的答案。

对那些无法明确量化的指标也必须给出一个描述范围，比如：上限、下限等。没有范围，就没办法理解具体的需求。随着架构的发展，这些指标范围会用来检查系统是否（仍然）符合要求，久而久之，性能指标的变化会反馈出有价值的信息。不过，要找出这些指标范围，并根据它们来检验系统，是件既费时又花钱的事。如果客户不关心系统的性能表现（既没有需求文档，也没有口头要求），也不愿意为性能测试买单，那么性能对他们来说可能不重要，这时你可以从容地将精力放到其