量化需求

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

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

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

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