需求活动指南-范文1

　 XXX 有限公司

　需求活动指南

　文档修订记录 版本编号 *变化 状态 简要说明 日期 变更人 批准日期 批准人 V1.0 A

　 *变化状态：A——增加，M——修改，D——删除

　 目 录 1 1

　前言 ......................................................................................................................................................... 1

　1.1

　目的 ................................................................................................................................................. 1

　1.2

　适用范围 ......................................................................................................................................... 1

　1.3

　读者对象 ......................................................................................................................................... 1

　2 2

　需求活动的重要性 性 .................................................................................................................................. 2

　2.1

　需求是项目能否成功的根本原因 ................................................................................................. 2

　2.2

　了解客户/ 用户 ................................................................................................................................ 2

　2.3

　需求活动中的主要问题与对策 ..................................................................................................... 3

　2.3.1

　产品与集成项目是否都需要需求开发与管理活动

　............................................................. 3

　2.3.2

　知识与技能问题

　..................................................................................................................... 3

　2.3.3

　态度问题

　................................................................................................................................. 3

　2.3.4

　合作关系

　................................................................................................................................. 3

　2.3.5

　用户说不清楚需求

　................................................................................................................. 4

　2.3.6

　双方误解需求

　......................................................................................................................... 4

　2.3.7

　开发人员写不好需求文档

　..................................................................................................... 4

　2.3.8

　用户经常变更需求

　................................................................................................................. 4

　3 3

　需求开发 ................................................................................................................................................. 6

　3.1

　需求调查 ......................................................................................................................................... 6

　3.1.1

　调查准备

　................................................................................................................................. 6

　3.1.2

　调查活动实施

　......................................................................................................................... 6

　3.1.3

　调查记录与输出

　...................................................................................... 错误 ! 未定义书签。

　3.2

　需求分析 ......................................................................................................................................... 6

　3.2.1

　问答法

　..................................................................................................................................... 6

　3.2.2

　建模法

　..................................................................................................................................... 7

　3.3

　需求定义 ......................................................................................................................................... 7

　3.3.1

　正确性 (Accuracy) ................................................................................................................... 7

　3.3.2

　完备 (Complete) ....................................................................................................................... 8

　3.3.3

　一致性 (Consistent) ................................................................................................................. 8

　3.3.4

　无歧义性 (Unambiguous) ........................................................................................................ 8

　3.3.5

　可验证 (Verifiable) ................................................................................................................... 8

　3.3.6

　可修改性 (Adaptable) .............................................................................................................. 8

　3.3.7

　必要性 (Necessary) .................................................................................................................. 8

　3.3.8

　可跟踪性

　................................................................................................................................. 9

　3.3.9

　可实现 (Attainable) .................................................................................................................. 9

　3.3.10

　可理解性

　................................................................................................................................. 9

　3.3.11

　确定优先级别

　......................................................................................................................... 9

　3.3.12

　注意事项

　............................................................................................................................... 10

　3.4

　需求确认 ....................................................................................................................................... 10

　3.4.1

　需求评审

　............................................................................................................................... 10

　3.4.2

　需求承诺

　............................................................................................................................... 10

　 4 4

　需求管理活动......................................................................................................................................... 11

　4.1

　需求跟踪活动 ................................................................................................................................ 11

　4.2

　需求变更活动 ................................................................................................................................ 11

　4.2.1

　需求变更的来源

　.................................................................................................................... 11

　4.3

　需求变更控制 ............................................................................................................................... 12

　4.4

　需求状态跟踪活动 ....................................................................................................................... 12

　5 5

　附录 ....................................................................................................................................................... 12

　5.1

　引用文档/ 参考资料 ...................................................................................................................... 12

　5.2

　术语表 ........................................................................................................................................... 12

　1 1 前言 1.1 目的 定义和描述需求活动的过程指南，指导需求开发、需求管理活动的实施。

　本文档可以作为《需求管理过程》的扩展和补充内容。

　1.2 适用范围 本文档对需求指南活动的描述适用于各种领域、各种类型的开发和测试模式的需求管理的相关活动； 本文档的适用范围为组织中的各项目。

　错误! ! 未找到引用源。

　1.3 读者对象 本文档的对象适用于开发和测试过程中的相关人员，特别是需求开发与需求管理人员；包括有关部门总监、项目经理、需求分析人员、系统分析人员、SQA 人员等相关人员。

　2 2 需求活动的重要性

　2.1 需求是项目能否成功的根本原因 项目开发的目标是：

　在预算内按时开发出符合客户真正需要的高质量的软件系统。简单的讲，成功的软件项目就是指那些可以达成这个目标的项目。调查显示（ESPITI 1995），与项目管理、软件测试、文档管理、编码等问题比较起来，需求规格说明与管理客户需求两个问题被 3800 位被调查从业人员列为产业中最重要的问题。数据表明：

　? 需求缺陷可能是最常见的缺陷； ? 需求缺陷可能是修改花费最昂贵的错误（可能消耗整个项目的 25%～40%）；参见下图：

　由此可以直观的体会到，需求的开发与管理活动是决定项目是否成功的根本因素。

　2.2 了解客户/ 用户 客户（customer）泛指与开发组织签订开发合同的组织或人；可以是代理商（往往代表许多最终用户）、组织的信息管理部门，也可以指本组织内的系统工程组、营业人员等。用户（user）是对使用（操作）系统的人一种泛称，可细分为最终用户（the end user）和间接用户（或称为关系人）。

　掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。如果软件是面向企业用户的，那么客户与最终用户通常不是同一个人；例如日文印刷社排版系统的客户可以看成是印刷社的系统工程部，而最终用户则是印刷社的制作部门。

　软件开发方与客户打交道的主要目的是：一是获取需求，二是签合同。客户所说的需求一般比较宏观，更详细的需求应该从最终用户那里获取。

　如果项目规模比较大，那么开发方与最终用户的来往就比较多。如从最终用户那里获取详细的需求，请最终用户试验软件，对最终用户进行培训等等。

　阶 段 需求时间 设计 编码 单元测试 验收测试 维护 在生命周期不同阶段修复缺陷的相对成本统计（Davis 1993）

　0.1 ～0.2 0.5 1 2 5 20

　2.3 需求活动中的主要问题与对策 2.3.1 产品与集成项目是否都需要需求开发与管理活动 由于合同项目的客户是已知的，需求开发和需求管理的各项活动可以有的放矢地开展。但是对于自主研发的产品而言，在产品没有卖出之前，并不存在真正的用户。由于用户是未知的，究竟该向谁调查需求？由谁来确认需求？其实，虽然待开发的产品尚未有真正的用户，但必定有潜在的目标用户。开发人员可以向潜在的用户们调查需求，请他们来确认需求。如果因条件限制，无法直接与潜在的用户沟通，可以通过角色扮演等方法，详见 3.1.2 节； 2.3.2 知识与技能问题 由于专业和职业的原因，多数软件开发人员不擅长与用户交流。有些人技术很出色，但与用户在一起时有劲使不出；所以公司不能期望他们能够无师自通地把需求开发工作做好，最好最快的解决办法是培训。作为项目的领导，既然要把那么重要的工作（需求开发）交给开发人员去做，就要舍得花钱对开发人员进行需求开发培训，帮助他们把需求开发工作做好。

　即使需求分析人员对需求调查、需求分析、需求定义已经有了丰富的经验，但他们的知识仍然可能不够用。应用领域的知识是无边无际、不断更新的，任何人都不可能是“万事通”。当需求分析人员缺乏应用领域知识时，首先要有勇气做事，否则连实践的机会都没有；其次应当赶紧补习应用领域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发组最好请既懂软件又懂应用领域知识的行家来帮忙。

　如果需求分析人员完全不了解应用领域，而用户几乎是个计算机盲，并且双方都不愿意主动了解对方领域的事情，这种状况下的需求开发很难成功。

　2.3.3 态度问题 相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。这是普遍现象，并不是开发人员懒惰所造成的，而是不正确的观念误导了他们：需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或经常变更需求，这类问题是用户产生的，应当由他们自己负责。

　用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。

　其实需求分析人员的工作就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。

　2.3.4 合作关系 如果需求分析人员不具备较强的交流、沟通能力，无法与用户建立良好的合作关系，那么即使他们有过硬的专业知识与行业背景，在需求开发过程中也会很疲惫。

　倘若用户不能很好地配合需求分析人员，那并不表示他有问题。因为用户有自己的想法：

　? 我回答了你们的问题，讲了该讲的。

　? 我们付钱给你们，难道还要我伺候你们不成？ ? 我还要干自己的事情，别再打扰我。

　? 你们自己想办法把活干好吧…… 对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你搞需求开发。

　开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。推荐一种方法：开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确

　定合作关系。“好话”和“丑话”都说在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。

　表 4-1 列举了用户在需求工程中的“权利与义务”，项目组可以根据实际情况适当地修改。

　用户的权利 1. 有权要求开发方派遣资质合格的需求分析人员和相关人员。

　2. 有权要求开发方采用用户熟悉的语言来描述需求，即开发方必须提供用户看得懂的需求文档。

　3. 有权审查需求文档，并对有争议的需求作出决策。如果认为需求文档不能准确地反映用户真实的意愿，可以拒绝在需求文档上签字。

　4. 如果用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可信的评估，以便用户决定是否变更需求。

　用户的义务 1. 以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人员提供工作和生活上的便利。

　2. 乐意接受需求分析人员的采访，在不泄漏机密的前提下，尽可能地回答需求分析人员的问题。

　3. 在不泄漏机密的前提下，尽可能地向需求分析人员提供与需求相关的材料。

　4. 与需求分析人员共同评审需求文档，确保需求文档准确地反映用户真实的意愿。

　5. 不轻易变更需求。如果需要变更需求的话，按照“需求变更控制规程”执行，而非强迫开发方接受。

　2.3.5 用户说不清楚需求 用户说不清楚需求是普遍现象，这是让开发人员头痛的大问题。

　有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。开发人员可能觉得奇怪：用户自己都不知道要什么，为什么还要我们开发软件？这种现象有些时候是正常的，例如开发方的营销人员水平比较高，他能够在用户不清楚自己要什么的情况下引导用户“消费”。有些用户虽然心里明白想要什么，但却说不清楚需求；或者用户的描述开发人员无法理解。

　需求分析人员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。无论是什么原因导致用户说不清楚需求，需求分析人员必须设法搞清楚用户真正的需求，这是需求分析人员的职责，也是职业的挑战。

　2.3.6 双方误解需求 人们在交流的时候，经常会发生“问非所求，答非所问”的事情。有时用户会把开发人员的建议或答复给想歪了，反之亦然。

　同时用户表达的需求，不同的开发人员可能有不同的理解。如果需求分析人员误解了需求，那会导致后续的不少开发人员将错就错、白干活。

　不论是复杂的项目还是简单的项目，需求分析人员和用户都有可能误解需求；所以需求验证工作必不可少。

　2.3.7 开发人员写不好需求文档 开发人员写不好需求文档的主要原因如下：

　? 需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。

　? 开发人员写作能力比较差，虽然在调查过程中已经获得了不少需求信息，却写不出好的需求文档来。软件开发人员的写作能力可能远不及其开发能力。提高开发人员写作能力的根本办法就是让他们多练习写文档，熟能生巧。另外，公司应当提供合适的文档模板以及比较好的示例文档，尽可能地降低写作难度。

　2.3.8 用户经常变更需求 需求变更通常会对项目的进度、人力资源、经费产生很大的影响，这是开发商非常畏惧的问题。

　如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的，双方应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的错误。相关活动的描述详见 4.2 节。

　3 3 需求开发

　3.1 需求调查 活动包括调查准备、搜集客户需求资料、对客户的需求/需要文件化、整理客户的实际需求/需要；评审客户需求/要求。

　3.1.1 调查准备 首先应确定产品的用户群或产品的服务对象；并对需求分析人员进行业务技能培训、对用户代表进行需求阶段相关知识的培训。

　3.1.2 调查 活动实施 需求调查工作围绕三项展开：调查什么？通过什么方式去调查？“何人”在“何时”调查？ ? 需求分析人员应当起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。问题表可以有多份，随着调查的深入，问题表将不断地被细化。根据经验，用户通常没有耐心回答复杂的“论述题”，所以问题表应当以“选择题”和“是非题”为主。制定问题表最简便的方法就是从《用户需求说明书》的模板中提取需求问题。

　? 需求分析人员应当确定需求调查的方式，例如：

　? 与用户交谈，向用户提问题； ? 参观用户的工作流程，观察用户的操作；

　? 向用户群体发调查问卷； ? 与同行、专家交谈，听取他们的意见；

　? 分析已经存在的同类软件产品，提取需求；

　? 从行业标准、规则中提取需求； ? 从 Internet 上搜查相关资料； ? 需求分析人员与被调查者建立联系，确定调查的时间、地点、人员等，撰写需求调查计划。要特别留意的是不要漏掉典型的用户。

　另外，如果有些事情现场就能分析清楚，那么不要拖延到以后做。在调查需求的同时应当进行必要的需求分析，建议采用“问答分析法”，尽可能确定每个需求的基本要素，如“是什么”、“为什么”等。

　3.2 需求分析 对客户需求进行详细分析，解决有关客户需求/要求中存在的问题。对于不一致的问题要进行讨论达成一定的共识，确定客户需求/要求和将处理客户需求的软件项目之间建立对客户需求的共同理解。

　由项目经理等组织分析讨论有关项目的具体客户需求、SOW。

　需求分析的方法有很多种，主要有问答（比较适合于需求调查阶段）和建模（比较适合于需求定义阶段）方法：

　3.2.1 问答法 每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。

　其它常见的问题有：

　? 需求存在二义性吗？

　? 需求文档的上下文有矛盾吗？ ? 需求完备吗？ ? 需求是必要的吗？ ? 需求可实现吗？ ? 需求可验证吗？ ? 需求的优先级确定了吗？ 3.2.2 建模法 在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。

　1) 结构化分析法

　文献[Pressmen99, p206-p214]对结构化分析方法作了高度概括，参见下图：

　? “数据字典”是中心，它包含了软件中所有数据对象的描述。

　? “实体－关系图”是用图形符号来标识数据对象以及它们之间的关系。

　? “数据流图”指明了数据在系统中移动时如何被变换。

　? “状态－变迁图”表示了系统存在的各种状态以及它们之间的变迁方式。

　2) 面向对象分析法（ OOAD ）

　UML（统一建模语言）吸取了各种 OOAD 方法的精髓，对于 OOAD 中的语义、图形表示法和使用规则作了完整而详细的定义；成为 OOAD 建模语言的国际标准。UML 的建模能力超过了以往任何一种 OOAD 方法，当然其复杂性也随之膨胀。

　真正使 UML 流行的是 Rational 公司基于 UML 的建模工具 Rose。Rose 易学易用，它能交互式地构建类图、用例图、构件图、部署图、状态图、活动图、顺序图、协作图等等。

　3.3 需求定义 经过调查与分析，确定下来的需求必须以文档方式表达，定义分配给软件的需求的文档就是《需求规格说明书》；《需求规格说明书》的表达形式根据产品/项目的实际情况不同，通常是指由《需求列表》、《需求规格说明书》、需求式样文档、辅助性质的系统测试用例（关键用例）等共同组成的一组说明性文档。具体可以参见软件需求规格说明模板。

　《需求规格说明书》必须具有：正确性、完备性、一致性、无歧义性、可验证性、可修改性、必要性、可跟踪性、可实现性、可理解性、有优先级别的。

　3.3.1 正确性(Accuracy) 是指《需求规格说明书》应当正确地反映用户的真实意图，即当且仅当每个需求项都代表了要构造系统所要完成的事物；“正确”是《需求规格说明书》最重要的属性。比较困难是开发者和用户自己都不确定用户究竟“想要什么”和“不要什么”；为确保需求是正确的，开发方和用户必须对《需求规格说明书》进行验证；验证的基础在于需求项是否对目标达成有贡献。

　数据字典 实体－关系图 数据流图 状态－变迁图

　3.3.2 完备(Complete) 是指《需求规格说明书》中没有遗漏一些必要的需求，即 当且仅当该文档描述了用户关心的所有有意义的需求，包括功能、性能、设计约束、属性或外部接口有关的需求 （IEEE 830-1993, 4.3.3, 1994）。不完备的《需求规格说明书》将导致产生功能不完整的软件，用户在使用该软件时可能无法完成预期的任务。

　1) 非功能性需求的完备性

　建议创建一个遵循前面提供的适用性、可靠性、性能和可支持性指南的一个简单的检查列表，其覆盖了在寻找设计约束是会问到的所有问题；并且关于非功能需求描述的数字化也是非常重要的。

　2) 功能性需求的完备性

　请应用领域的专家参与到功能性评审是非常有效的保证功能性需求的方法；开发人员同时也应该注意那些用户固有的或他们认为显而易见的需求。

　3) 通过原型开发保证完备性

　用例描述、需求评审以及采用迭代方法为系统建立原型是有效的保证，越接近真正的使用，用户对开发组提供的产品就越有经验，开发组也可以及时发现需求定义中的问题。特别需要重视的是，边缘条件、异常处理等问题。

　3.3.3 一致性(Consistent) 是指《需求规格说明书》中各个需求项之间不会发生矛盾，即 当且仅当需求定义中没有单个需求项的子集与另一个子集冲突 （IEEE 830-1993, 4.3.4.1, 1994）。矛盾常常潜伏在需求文档的上下文中。

　例如：HR 系统需求的一部分可能要求“35 岁以上的员工每年有 15 个工作日的带薪年休假”，而另外的章节可能要求“所有入司 10 年以上的员工每年有 10 个工作日的带薪年休假”，那么同时满足这两个条件的员工该如何确定休假期限？ 3.3.4 无歧义性(Unambiguous) 是指每个需求项有唯一的含义，即 当且仅当需求只有一种解释 （IEEE 830-1993, 4.3.2, 1994）。如果需求存在二义性，将会导致人们误解需求而开发出偏离需求的产品。

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

　3.3.5 可验证(Verifiable) 《需求规格说明书》中的各项需求对 用户方而言应当都是可验证的，即 当且仅当所包含的各个需求组件是可验证的（断定一条需求是可验证当且仅当存在一个有限的、合理的过程，人或设备怾用它来确定所开发的软件系统真正满足该需求）

　（IEEE 830-1993, 4.3.6, 1994）。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。

　3.3.6 可修改性(Adaptable) 当且仅当需求规格说明的结构和风格是：可以对其中每个需求项的很容易地、完整地、一致地进行变更；同时保持已存在的需求规格定义的结构和风格 （IEEE 830-1993, 4.3.7, 1994）。这要求需求说明中具有最小的冗余并且以恰当的目录、索引以及交叉引用的能力很好地组织；并且应根据项目的规模和复杂性进行权衡。

　3.3.7 必要性(Necessary) 《需求规格说明书》中的各项需求对用户而言应当都是必要的。

　“必要”往前一步，要么是“画蛇添足”要么是“锦上添花”。

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

　求规格说明书中“画蛇添足”的那些需求。

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

　如果左边的圆代表用户需求的全域，右边的圆代表需求；则正确的需求是两个圆重叠的区域，即区域 B；必要性就是保证 C 区域保持最小的冗余；完备性就是尽量减少因失误带来的区域 A 内容的增加。

　3.3.8 可跟踪性 指 当且仅当需求的各个需求模块的来历是清晰的，并且存在一种机制使得在未来的开发工作中引用该需求项是可行 （IEEE 830-1993, 4.3.8, 1994）。在实践中，这通常意味着需求必须以唯一的编号或标记被标识。

　需求变更的可能性，导致了可跟踪性的重要。当需要增加或删除需求项的特征时，需要回溯到用户处重新协商有关预算或进度时，这种能力将是非常必要的。

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

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

　3.3.10 可理解性 如果用户和开发人员都能完全理解单个需求项和需求整体的全部功能，那么《需求规格说明书》就是可理解的。当系统分析人员细化需求定义，即产生详细需求时，各种描述讲更加详细和明确，更多的开始采用技术性词汇；因此文档做成人员必须理解所有读者的专业词汇、术语和文化。另外用户是否能从整体上理解系统的行为也非常重要，通常可以利用用例来描述运行环境辅助理解。

　3.3.11 确定优先级别 理论上讲，软件的所有需求都应当被实现。但是在现实之中，项目存在“进度、费用、人力资源”等限制。优先级就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。

　开发人员、客户以及其他风险承担人应该根据对客户的重要性以及稳定性 （IEEE 830-1993, 4.3.8, 1994）给每个需求项分级。

　用户需求

　 A

　 B

　C

　 陈述的需求

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

　目前的开发组中，开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾；所以他们在调查、分析、定义需求时，自然会想到“怎么做”，这并没有什么过错。如果在调查、定义需求时想好了“怎么做”，当然应该写下来；关键是不要将“怎么做”写到需求规格说明里面，而是记录在其它文档里（如概要设计文档）。

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

　需求确认包含两个重要工作：“需求评审”和“需求承诺”。

　3.4.1 需 需 求评审 1) 概述

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

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

　2)

　 注意事项

　? 避免需求评审的“虎头蛇尾”；应该严格的检查需求规格说明文档中的每个需求项，每行文字和每张图表，因为认真评审一个小时可能会避免未来数十天的“开发”或“返工”；因此评审前应提前要求参与评审人员熟悉需求规格说明文档，并按照确认单进行初步确认，然后带着问题参与评审过程。

　? 需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易；但是需要更注意需求项之间的一致性。

　? 在需求评审时主要解决的问题是应该作什么？当然讨论其实现性时也允许开发人员谈如何做，但不要谈实现的细节，只要让大家确信可以实现就行。

　? 评审的对象只是需求，不是真理；所以评审过程中的意见分歧是非常正常的，“换位思考”是解决分歧的有效手段，更容易达到双赢的结果。一旦对某个问题长时间无法达成共识，评审主持人必须终止无限期的争议，并改而讨论确定解决该问题的任务分配；相关内容必须记录在评审报告中。

　3.4.2 需求承诺 与客户一起评审《需求规格说明书》（如有确实的用户代表需包含用户代表在内），项目组和用户代表必须对需求达成一致，并取得用户代表的认可和批准。如果用户代表同意《需求规格说明书》，需要签字认可。

　承诺应包括如下内容：

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

　 4 4 需求管理活动 4.1 需求跟踪活动 参见《需求管理过程》第 3.2 节的相关内容。

　4.2 需求变更活动 4.2.1 需求变更的来源 1) 变更原因分析 对大多数项目而言，需求发生若干次变更似乎是不可避免的。需求发生变更的起因主要有：

　? 随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。例如：

　? 变更发生在用户需求规格说明书或机能式样书中，由于操作性的关系，GUI 方面的设计需要在后期被作为需求的形式固定下来； ? 变更发生在设计中，例如对于需求的某种修改和限定，使得系统可以更容易做成； ? 变更发生在编码中，例如在实际实现中才发现的某些限制等。

　? 市场或业务发生了变化，原先的需求定义内容可能跟不上当前的市场或业务需要，因此要变更需求。

　2) 变更影响分析 提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发组而言，变更需求的影响在于：

　? 使得变更前的开发工作和成果失效； ? 使变更需求项相关的开发活动返工； ? 要调整资源、重新分配任务、修改前期工作成果等，开发组要为此付出较重的代价。

　3) 降低变更风险 ? 在需求开发活动中与客户/用户充分沟通；

　? 向用户介绍开发流程，明确稳定的需求对开发过程的重要意义，参见下表：

　项目开发工作

　项目开发组织

　客户/ / 用户

　需求是产品后续开发工作的基础； 需求是产品维护工作的参考； 对用户的承诺； 关系到项目开发工作的投入、交付期限和产品质量 关系到能否按期获取所需产品； 需求文档 作为合同的附件，关系到双方的利益； 是产品验收的依据； ? 由于需求定义不确切、频繁变更会给开发过程带来冲击；而且需求变更越晚提出，对开发过程与成本的压力越大； ? 需求变更会影响到项目进度与质量，所以变更应该慎重。

　? 吸收用户参与需求开发，交流采用文档方式； ? 项目开发合同、需求评审报告中明确开发中对需求变更的应对条款，并经双方批准； ? 对于项目自身具有需求不确定的特点，建议采用快速原型模型和螺旋模型等适合的生命周期模型； ? 项目策划活动中，根据需求变更的风险，提高开发计划的可调节性； ? 严格实施需求变更控制。

　4.3 需求变更控制 1)

　需求变更控制的动机是：

　? 如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。

　? 如果需求变更带来的坏处大于好处，那么拒绝变更。

　2)

　由于需求文档是重要的配置项，需求的变更应当遵循配置管理中的变更控制规程。

　4.4 需求状态跟踪活动 参见《需求管理过程》第 3.4 节的相关内容。

　5 5 附录

　5.1 引用文档/ 参考资料 ? 引用文档 ? 《需求管理方针》

　 ? 《需求管理过程》

　 ? 参考资料：

　? Paulk, Mark C., et al. Capability Maturity Model for Software, Version 1.1 CMU/SEI-93-TR-24 ? Paulk, Mark C., et al. Key Practices of the Capability Maturity Model,Version 1.1, CMU/SEI-93-TR-25 ? 《基于软件能力成熟度模型的软件过程改进》，郑人杰等编著，清华大学出版社，2003 年3 月 ? Dean Leffingwell and Don Widrig: Managing Software Requirements:A Unified Approach 5.2 术语表 ? SOW：

　Statement Of Works， 工作内容陈述 其它参见《需求管理过程》相关

相关热词搜索：需求 指南 活动