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

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

好处？他们选择本产品的可能性有多大？ 3. 产品应当遵循的标准或规范 提示：阐述本产品应当遵循什么标准、规范或业务规则（Business Rules），违反标准、规范或业务规则的产品通常不太可能被接受。 4. 产品范围 提示：阐述本产品“适用的领域”和“不适用的领域”，本产品“应当包含的内容”和“不包含的内容”。说清楚产品范围的好处是：（1）有助于判断什么是需求，什么不是需求；（2）可以将开发精力集中在产品范围之内，少干吃力不讨好的事情；（3）有助于控制需求的变更。 5. 产品中的角色 提示：阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。 角色名称 6. 产品的功能性需求 6.0 需求分类 功能类别 Feature A 功能名称、标识符 Function A.1 … Function B.1 … Function C.1 … 描述 职责描述 Feature B Feature C 6.m Feature M 6.m.n Function M.N 名称、标识符 优先级 功能描述 输入、输出 操作序列等 其它说明 7. 产品的非功能性需求 需求类别 用户界面需求 软硬件需求 质量需求 需求名称、标识符 描述

Page 25 of 34

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

8. 其它需求 附录A：需求建模 附录B：需求评审报告摘要 附录C：需求承诺 表4-6 《软件需求规格说明书》的文档模板

4.9 需求确认

4.9.1 规程

需求确认是指开发方和客户方共同对需求文档如《用户需求说明书》和《产品需求

规格说明书》进行评审，双方对需求达成共识后作出承诺。《用户需求说明书》和《产品需求规格说明书》可以分开也可以放在一起进行需求确认，视项目的具体情况而定。

需求确认包含两个重要工作：“需求评审”和“需求承诺”，一般规程如表4-7所示。

目的 角色与职责 开发方和客户对需求文档进行评审，并作书面承诺。 开发方和客户共同组织人员对需求文档进行评审。双方负责人对需求文档作书面承诺，使之具有商业合同效果。 启动准则 输入 主要步骤 需求文档如《用户需求说明书》和《产品需求规格说明书》已经完成。 需求文档如《用户需求说明书》和《产品需求规格说明书》 第一步：非正式需求评审 第二步：正式需求评审 第三步：获取需求承诺 输出 结束准则 度量 《需求评审报告》和书面的需求承诺 需求文档通过了正式评审，并且获得开发方和客户的书面承诺。 项目经理统计工作量和上述文档的规模。 表4-7 需求确认的规程

4.9.2 需求评审

对工作成果的技术评审有两类方式，一类是正式技术评审，另一类是非正式技术评

审。对于任何重要的工作成果，都应该至少执行一次正式技术评审，建议在正式技术评审之前进行若干次非正式技术评审。

需求评审的规程与其它重要工作成果（如系统设计文档、源代码）的评审规程非常相似，主要区别在于评审人员的组成不同。前者由开发方和客户方的代表共同组成，而后者通常来源于开发方内部。

需求评审究竟评审什么？要细到什么程度？

Page 26 of 34

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

严格地讲，应当检查需求文档中的每一个需求，每一行文字，每一张图表。评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完备性、可实现性、可验证性。

需求评审面临的困难及对策如下：

审时，大家都比较认真，越到后头越马虎。当需求文档很长时，几乎没人能够坚持到最后。会议主持人事先要强调需求评审的重要性：认真评审一小时可能会避免将来数十天的“返工”，让大家足够重视。主持人还要设法避免大家在昏昏沉沉中评审。如果评审时间比较长，建议每隔两小时休息一次，大家活动一会儿，让脑袋清醒清醒。

? 需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间

开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。我的经验是：需求文档从0.1版本发展到0.9版本期间不必进行需求评审，从0.91版本至0.99版本可能要进行多次的“非正式技术评审”，在1.0版本进行一次“正式技术评审”。 ? 开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大

家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。对于自主研发的产品，由于需求评审人员大部分是开发人员，大家会不知不觉地谈论软件“如何做”。由于需求是否“可实现、可验证”本来就属于需求评审的范畴，所以强制大家“只谈做什么，不谈怎么做”几乎是不可能的。我的建议是：在需求评审时允许开发人员谈如何做，但适可而止，尤其不要谈实现的细节，只要让大家确信可以实现就行。

? 开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞

成要好。然而当争议变为争吵时就坏事了，这事在我的开发小组里也发生过几次：不仅小伙子们怒气冲冲，连文雅的小姐也会气鼓鼓的。我们意识到争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。于是大家约定：（1）不论理由如何充分，谁都不准拍桌子、大吼大叫；（2）当大家对某个问题长时间不能达成共识时，主持人必须终止无限期的争议，由主持人决定下一步怎么办。

? 人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者

轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。有一次需求评审会议，我们开发小组就某个问题无法达成共识，结果分成了“两派”。我们建议两派的“头头”晚上睡觉时互换角色思考问题。第二天，令我们大吃一惊的是，这两个人竟然笑容可掬，都说对方的好，几乎相互倒戈。于是我们不再争议，很快就取得了折衷。

需求评审报告的模板见表4-8。

? 需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评

Page 27 of 34

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

需求评审报告 1. 基本信息 待评审的成果 技术评审方式 评审时间 评审地点 评审人员名字 名称，标识符，版本，作者，时间 正式技术评审 / 非正式技术评审 工作单位 职务职称 2. 问题记录及处理意见 问题记录 Problem A Problem B Problem C 3. 评审结论 评审结论 [ ] 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。 [√] 工作成果基本合格，需要作少量的修改，之后通过审核即可。 [ ] 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。 负责人 签字 处理意见 表4-8 需求评审报告的模板

4.9.3 需求承诺

需求承诺是指开发方和客户方的责任人对通过了正式技术评审的需求文档作出承需求承诺的“八股文”如下：

本需求文档建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该需求文档开展。如果需求发生变化，我们将按照“变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。

甲方签字 乙方签字

不少人会草率地对待需求承诺：不就是在一张纸的最后一行文字下面签字吗，反正已经评审过了，我就签吧。但他将来变更需求时可能会表示不瞒：“不错，我是签字了，但是我并没有阅读文档。是你们要我在文档上签字的，我是相信你们才这么做的。”

为了避免发生此类纠纷，人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么。

诺，该承诺具有商业合同的效果。

Page 28 of 34