绗?绔?闇�姹傚紑鍙戜笌闇�姹傜�＄�?- 鐧惧害鏂囧簱

第4章 需求开发与需求管理

性。例如阿富汗人民心目中的“小康”对美国人们而言简直不如乞丐的生活水平。

为了使需求无二义性，人们在写《产品需求规格说明书》时措词应当准确，切勿模棱两可。

4.7.4 一致

“一致”（Consistent）是指《产品需求规格说明书》中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。

地球上有个超级大国的“导弹发展计划”是这样写的：我们要研制世界上最先进的导弹，我们想打哪里就打哪里，任何防御系统都对它无可奈何。这段“需求”很清楚，无二义性，总统和国会看了都很高兴，于是批准了改计划，拨了很多经费。

同时这个国家的“导弹防御系统发展计划”是这样写的：我们要研制世界上最先进的导弹防御系统，使得任何导弹来袭都落得?肉包子打狗，有去无回?的下场。这段“需求”很清楚，无二义性，总统和国会看了都很高兴，批准了改计划，又拨了很多经费。

据说后来恐怖分子们利用了这两个计划之间的矛盾，用这种导弹打这种防御系统，给这个国家造成了很多麻烦。

4.7.5 必要

《产品需求规格说明书》中的各项需求对用户而言应当都是必要的。我们可以把“必要”比喻为“雪中送炭”。“必要”往前一步，要么是“画蛇添足”要么是“锦上添花”。

据说基于Windows系统的汽车控制软件有这么一项功能，当汽车发生碰撞时该软件会弹出一个对话框：您需要使用安全气囊吗？按OK键表示需要，按Cancel键表示不需要。

“画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。

“锦上添花”是好事，可能会让用户获得比期望更多的喜悦，但是眼前用户不会为此多付钱。开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在《产品需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。

4.7.6 完备

“完备”（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求。不完备的《产品需求规格说明书》将导致产生功能不完整的软件，用户在使用该软件时可能无法完成预期的任务。

人们往往倾向于关注系统的特色功能，而忽视了其它一些不起眼的但却是必需的功能。例如，在大城市的繁华街区往往找不到公共厕所，急得行人看到肯德基、麦当劳就

Page 21 of 34

第4章 需求开发与需求管理

往里闯。消费是人们的需求，但上厕所也是人们的需求。如果忽略了后者，高尚的社区迟早会被弄得臭气熏天。

4.7.7 可实现

《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的（Attainable）。“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。

营销人员和用户谈生意时，为了能拿到“单子”，他们往往对用户提出的需求“来者不拒”。吹牛皮虽然不犯法，但是《产品需求规格说明书》可是白纸黑字啊。经过双方确认的《产品需求规格说明书》相当于商业合同，如果开发方不能够实现《产品需求规格说明书》中的内容，那就是违约，可能会被罚款的。

对于合同项目，如果开发方不能确信某些需求是否可实现，则应事先与用户协商，达成一致的处理意见，避免将来发生商业纠纷。

4.7.8 可验证

《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。

例如，摩天大楼的一项需求是“抗十二级台风”，这个需求看起来堂而皇之，但是如何验证呢？当摩天大楼完工后验收时，用户又不是巫师，他怎能造个十二级台风来试验？如果双方都认可“采用计算机模拟十二级台风”等效于实际测试，那么这项需求就是“可验证”的。

4.7.9 确定优先级

为什么要确定需求的“优先级”？

理论上讲，软件的所有需求都应当被实现。但是在现实之中，项目存在“进度、费用、人力资源”等限制。在项目刚开始的时候，开发方和客户比较乐观，什么都要做，可是做着做着，人们常常会面临“进度延误、费用超支、人员不足”等问题，这时就乱套了。

久病成医那，人们想出了“取舍”办法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。

需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。

Page 22 of 34

第4章 需求开发与需求管理

4.7.10 阐述“做什么”而不是“怎么做”

《产品需求规格说明书》的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情。

国内的很多软件公司里，开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。所以他们在调查、分析、定义需求时，自然会想到“怎么做”，这并没有什么过错。如果在调查、定义需求时想好了“怎么做”，当然应该写下来，否则岂不浪费！关键是不要将“怎么做”写到需求规格说明书里面，记录在其它文档里就行了。

4.8 如何定义产品需求

4.8.1 规程

产品需求定义的一般规程如表4-5所示。

目的 角色与职责 启动准则 输入 主要步骤 定义准确无误的产品需求，产生《产品需求规格说明书》。 需求分析员定义产品需求。客户与最终用户确认产品需求。 《用户需求说明书》已经撰写完成。 《用户需求说明书》 第一步：细化并分析用户需求 第二步：撰写产品需求规格说明书 第三步：需求确认 输出 结束准则 《产品需求规格说明书》 《产品需求规格说明书》已经撰写完成。开发方和客户方已经对产品需求进行了确认（包括需求评审和承诺）。 度量 需求分析员统计工作量和上述文档的规模，汇报给项目经理。 表4-2 需求调查的规程

定义产品需求的主要步骤如下： ? 第一步：细化并分析用户需求

需求分析员首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模

分析，以帮助软件开发人员更好地理解需求。例如采用Rational 的Rose工具进行需求的建模分析，建模分析产生的文档可以作为《产品需求规格说明书》的附件。补充说明：建模分析的技术难度比较高，需求分析员应当根据自身水平进行取舍。 ? 第二步：撰写产品需求规格说明书

需求分析员按照指定的文档模板撰写《产品需求规格说明书》。如果待开发的产品分

Page 23 of 34

第4章 需求开发与需求管理

为软件和硬件两部分的话，则应当分别撰写《软件需求规格说明书》和《硬件需求规格说明书》。

? 第三步：进行需求确认

项目经理邀请同行专家和用户（包括客户和最终用户）一起评审《产品需求规格说明书》，尽最大努力使《产品需求规格说明书》能够正确无误地反映用户的真实意愿。 需求评审之后，开发方和客户方的责任人对《产品需求规格说明书》作书面承诺。

4.8.2 软件需求规格说明书的模板

软件需求规格说明书应当按照指定的文档模板来写，这样做至少有以下好处： （1）文档模板已经规定了书写格式，降低了写作难度，开发人员可以把精力集中在文档的内容上。

（2）按照文档模板写出来的《软件需求规格说明书》比较规范，容易被用户和开发人员接受。

好的文档模板有如下特性：

（1）贴切于该项目。关于软件需求规格说明书的文档模板非常多，目前国际上没有（也不可能有）统一的标准。不要以为文档模板“大而全”就越好，小规模的民用项目套用美国军方“大而全”的文档模板显然是不合适的。所以开发人员应当根据项目的特征，定制最贴切于该项目的文档模板。

（2）结构清晰。那怕是天下最无能的领导，都知道在作报告时要先从宏观上讲一、二、三、四、五，再从细节上讲A、B、C、D、E。如果文档模板的结构很清晰，那么作者和读者都会比较轻松，有时候人们光看标题就能了解文档的大致内容。

（3）要点完备。人们在写软件需求规格说明书时，经常会遗忘掉一些重要的内容。例如人们通常着重于写功能性需求，却忘了或者压根就没有想到还要写非功能性需求。要点完备的文档模板有助于人们写出完备的软件需求规格说明书。

表4-6是本书作者制定的《软件需求规格说明书》的文档模板，供读者参考。

软件需求规格说明书 0. 文档介绍 0.1文档目的 0.2文档范围 0.3读者对象 0.4参考文档 0.5术语与缩写解释 1. 产品介绍 提示：（1）说明产品是什么，什么用途。（2）介绍产品的开发背景。 2. 产品面向的用户群体 提示：（1）描述本产品面向的用户（客户、最终用户）的特征，（2）说明本产品将给他们带来什么

Page 24 of 34