第八章软件需求实现

《第八章软件需求实现》由会员分享，可在线阅读，更多相关《第八章软件需求实现（38页珍藏版）》请在金锄头文库上搜索。

1、第八章第八章 软件需求实现软件需求实现周立新周立新 博士博士北京大学软件与微电子学院北京大学软件与微电子学院课程提纲课程提纲1.软件需求基本理论和概念2.软件需求工程过程3.软件需求获取4.软件需求分析5.软件需求规格说明6.软件需求验证7.软件需求管理8.软件需求实现9.软件需求工程新进展10.软件需求开发与需求管理工具内容提要需求与其他项目过程的需求与其他项目过程的联系联系过程改进原则及周期过程改进原则及周期需求相关的风险控制需求相关的风险控制特殊软件项目特殊软件项目(如维护、如维护、外包等外包等)的需求实践等的需求实践等 8.1 需求与其他需求与其他项目过程的联系项目过程的联系需求是每个

2、软件项目成功需求是每个软件项目成功的核心所在，它支持其他的核心所在，它支持其他技术活动和管理活动。技术活动和管理活动。对需求开发方法和需求管对需求开发方法和需求管理方法的变更会对项目的理方法的变更会对项目的其他过程产生影响，反之其他过程产生影响，反之亦然。亦然。右图演示了需求和其他过右图演示了需求和其他过程之间的某些连接，下面程之间的某些连接，下面简要介绍一下这些过程之简要介绍一下这些过程之间的接口间的接口。8.1.1 从需求到项目规划从需求到项目规划由于需求定义了项目的预期成果，所以项目规划、项由于需求定义了项目的预期成果，所以项目规划、项目预算和项目的进度安排都必须以软件需求为基础。目预算

3、和项目的进度安排都必须以软件需求为基础。最重要的项目成果是交付满足业务目标的系统，而不最重要的项目成果是交付满足业务目标的系统，而不一定是根据最初的项目规划实现所有初始需求的系统。一定是根据最初的项目规划实现所有初始需求的系统。需求和规划只代表团队最初的评估，项目成果就是根需求和规划只代表团队最初的评估，项目成果就是根据这一评估来完成的。据这一评估来完成的。下表说明对需求工作的投资可以加速项目的开发。下表说明对需求工作的投资可以加速项目的开发。需求阶段投入的工作量需求阶段投入的工作量 需求阶段投入的时间需求阶段投入的时间 开发较快的项目开发较快的项目 14%14% 17%17% 开发较慢的项目

4、开发较慢的项目 7%7% 9%9% 需求和预估需求和预估根据文本需求、图形分析模型、原型或用户界面根据文本需求、图形分析模型、原型或用户界面设计来预估产品的大小。设计来预估产品的大小。虽然对于软件的规模没有完善的度量标准，但下虽然对于软件的规模没有完善的度量标准，但下面是一些常用的度量标准：面是一些常用的度量标准：可单独测试需求的数量可单独测试需求的数量(Wilson 1995)。功能点和特性点的多少功能点和特性点的多少(Jones 1996b)，或者将数据、，或者将数据、功能和控制三者整合在一起的三维功能点的数量功能和控制三者整合在一起的三维功能点的数量(Whitmire 1995)。图形用

5、户界面图形用户界面(GUI)元素的数量、类型和复杂度。元素的数量、类型和复杂度。用于实现特定需求所需的源代码行数。用于实现特定需求所需的源代码行数。对象类的数量或者其他面向对象系统的衡量标准对象类的数量或者其他面向对象系统的衡量标准(Whitmire 1997)。需求和进度安排需求和进度安排主要的规划失误包括主要的规划失误包括: 忽略了公共忽略了公共(用用)的的项目任务，低估了所需的工作量和时间，项目任务，低估了所需的工作量和时间，没有考虑项目风险，没有考虑返工所需的没有考虑项目风险，没有考虑返工所需的时间，以及对自己的盲目乐观等。时间，以及对自己的盲目乐观等。有效的项目规划需要以下元素：有效

6、的项目规划需要以下元素：根据对需求的清楚理解来估计产品规模的大小。根据对需求的清楚理解来估计产品规模的大小。根据历史记录了解到的开发团队的工作效率。根据历史记录了解到的开发团队的工作效率。一张任务列表，以便完全地实现和验证每一特一张任务列表，以便完全地实现和验证每一特性或用例。性或用例。相当稳定的需求。相当稳定的需求。有效的预测和规划过程。有效的预测和规划过程。经验，这有助于项目经理对不可触及的因素和经验，这有助于项目经理对不可触及的因素和每一个项目所特有的因素加以调整。每一个项目所特有的因素加以调整。注意：不要迫于压力而许下自己明知道不可能做到的诺言，这是避免最后两败俱伤的秘诀。 8.1.2

7、 从需求到设计和编码从需求到设计和编码需求和设计之间存在差别需求和设计之间存在差别, 要防止规格说要防止规格说明造成实现上的倾向性，除非是有迫不得明造成实现上的倾向性，除非是有迫不得已的原因要有意地对设计加以约束。已的原因要有意地对设计加以约束。需求规格说明几乎总是包括某些设计信息，需求规格说明几乎总是包括某些设计信息，让设计人员或开发人员参与需求审查，这让设计人员或开发人员参与需求审查，这样可以确保需求为后续的设计打下坚实的样可以确保需求为后续的设计打下坚实的基础。基础。产品的需求、质量属性和用户特点可以决产品的需求、质量属性和用户特点可以决定产品体系结构。定产品体系结构。从需求到设计和编码

8、从需求到设计和编码对于同时包括软件组件和硬件组件的系统，对于同时包括软件组件和硬件组件的系统，以及只包括软件的复杂系统，体系结构就显以及只包括软件的复杂系统，体系结构就显得尤其关键。得尤其关键。将系统功能分配给子系统或组件必须采用自将系统功能分配给子系统或组件必须采用自顶向下的方法顶向下的方法(Hooks和和Farry 2001)。在开始实现产品之前，虽然不需要为整个产在开始实现产品之前，虽然不需要为整个产品开发完整的、详细的设计，但是，应该先品开发完整的、详细的设计，但是，应该先对每一个组件进行设计，然后再对其进行编对每一个组件进行设计，然后再对其进行编码。码。从需求到设计和编码从需求到设计

9、和编码下面的动作可以使所有的项目类型都从中受益：下面的动作可以使所有的项目类型都从中受益：为子系统和组件开发一个坚固的体系结构，这一体系结构在为子系统和组件开发一个坚固的体系结构，这一体系结构在产品改进的过程中可以保持不变。产品改进的过程中可以保持不变。确定需要构建的主要对象类或功能模块，定义它们的接口、确定需要构建的主要对象类或功能模块，定义它们的接口、职责以及与其他单元的协作。职责以及与其他单元的协作。对并行处理系统，要理解计划的执行线程或对并发进程的功对并行处理系统，要理解计划的执行线程或对并发进程的功能分配。能分配。根据强内聚、低耦合和信息隐藏等这些良好的设计原则，定根据强内聚、低耦合

10、和信息隐藏等这些良好的设计原则，定义每个代码单元的预期功能义每个代码单元的预期功能(McConnell 1993)。确保设计满足所有的功能性需求，但不要包括不必要的功能。确保设计满足所有的功能性需求，但不要包括不必要的功能。确保设计能适应可能出现的异常条件。确保设计能适应可能出现的异常条件。确保设计能达到所陈述的性能、健壮性、可靠性和其他一些确保设计能达到所陈述的性能、健壮性、可靠性和其他一些质量属性的目标。质量属性的目标。 8.1.3 从需求到测试从需求到测试测试和需求工程是一种互相促进的关系。测试和需求工程是一种互相促进的关系。需求是系统测试的基础，对产品的测试应该根据需求文档需求是系统测

11、试的基础，对产品的测试应该根据需求文档中所记录的产品的预期行为来进行，而不应该根据设计或中所记录的产品的预期行为来进行，而不应该根据设计或编码来测试。编码来测试。项目测试人员应该确定他们如何验证每一条需求，下面列项目测试人员应该确定他们如何验证每一条需求，下面列出了一些可能的方法：出了一些可能的方法：测试测试(执行软件以便发现缺陷执行软件以便发现缺陷)。审查审查(检查代码，以便确保代码满足了需求检查代码，以便确保代码满足了需求)。演示演示(显示产品的运作与所期望的相符显示产品的运作与所期望的相符)。分析分析(推导在某些情况下系统应该如何运作推导在某些情况下系统应该如何运作)。基于规格说明的测试

12、可以运用若干测试设计策略：动作驱基于规格说明的测试可以运用若干测试设计策略：动作驱动、数据驱动动、数据驱动(包括边界值分析和等价类划分包括边界值分析和等价类划分)、逻辑驱动、逻辑驱动、事件驱动和状态驱动事件驱动和状态驱动(Poston 1996)。 8.1.4 从需求到成功从需求到成功使项目更成功的一种方法是，列出与特定的代码版本相对使项目更成功的一种方法是，列出与特定的代码版本相对应的所有需求。应的所有需求。项目的质量保证项目的质量保证(quality assurance，QA)小组通过对照小组通过对照相应的需求来执行测试，从而对每一个版本进行评估。这相应的需求来执行测试，从而对每一个版本进

13、行评估。这个项目的成功，在很大程度上得益于根据需求文档来决定个项目的成功，在很大程度上得益于根据需求文档来决定何时发布产品。何时发布产品。软件开发项目最终的可交付工件应该是一个满足客户需要软件开发项目最终的可交付工件应该是一个满足客户需要和期望的软件系统。和期望的软件系统。需求是从业务需要通向用户满意之路中必不可少的一步。需求是从业务需要通向用户满意之路中必不可少的一步。如果不以高质量的需求作为项目规划、软件设计和系统测如果不以高质量的需求作为项目规划、软件设计和系统测试的基础，那么在试图发布优秀产品的过程中将浪费大量试的基础，那么在试图发布优秀产品的过程中将浪费大量的工作。的工作。精确的规格

14、说明与可将产品失败的风险降至可接受程度的精确的规格说明与可将产品失败的风险降至可接受程度的编码之间做出明智的选择。编码之间做出明智的选择。 8.2.1 软件过程改进的基本原则软件过程改进的基本原则应该牢记下面应该牢记下面4条软件过程改进的原则条软件过程改进的原则(Wiegers 1996a)：1.过程改进应该是不断演化的、连续的、周期性的过程改进应该是不断演化的、连续的、周期性的 不要期望一次就能改进全部过程，要知道在第不要期望一次就能改进全部过程，要知道在第1次尝试变更时，可能无法解次尝试变更时，可能无法解决所有问题。决所有问题。2.只有人们和组织具有变更的动机时才可能实施变更只有人们和组织

15、具有变更的动机时才可能实施变更下面列出了一些典型的问题，也许能为需求过程的变更提供驱动力：下面列出了一些典型的问题，也许能为需求过程的变更提供驱动力：项目超出了最后期限，原因是需求比预期的扩展了很多，也复杂了很多。项目超出了最后期限，原因是需求比预期的扩展了很多，也复杂了很多。开发人员频繁加班，原因是直到开发后期才发现了引起误解的需求和表达不明确的需开发人员频繁加班，原因是直到开发后期才发现了引起误解的需求和表达不明确的需求。求。系统测试工作前功尽弃，原因是测试人员并没有弄清楚产品应该做什么。系统测试工作前功尽弃，原因是测试人员并没有弄清楚产品应该做什么。虽然正确的功能都实现了，但是用户不满意

16、，这是由于性能不好、易使用性差或存在虽然正确的功能都实现了，但是用户不满意，这是由于性能不好、易使用性差或存在其他质量缺陷。其他质量缺陷。维护费用很高，因为客户的对产品的许多增强要求没有在需求获取阶段确定下来。维护费用很高，因为客户的对产品的许多增强要求没有在需求获取阶段确定下来。开发组织名誉受损，因为客户不接受交付的软件。开发组织名誉受损，因为客户不接受交付的软件。3.过程变更要有的放矢过程变更要有的放矢在开始运用更好的过程之前，一定要明确变更的目标是什么在开始运用更好的过程之前，一定要明确变更的目标是什么(Potter and Sakry 2002)。4.将改进活动视作小型项目将改进活动视

17、作小型项目项目的总体计划应该包括过程改进的资源和任务。与所有项目一样，改进项目项目的总体计划应该包括过程改进的资源和任务。与所有项目一样，改进项目也要执行计划、跟踪、测量和报告，只是规模相应地缩小了。也要执行计划、跟踪、测量和报告，只是规模相应地缩小了。 8.2.2 过程改进周期过程改进周期右图是一个有效右图是一个有效的过程改进周期。的过程改进周期。这一方法反映了这一方法反映了您在执行下一个您在执行下一个任务之前先清楚任务之前先清楚自己所处位置的自己所处位置的重要性；反映了重要性；反映了绘制过程路线图绘制过程路线图的必要性，以及的必要性，以及以往的经验在持以往的经验在持续的过程改进中续的过程改

18、进中的重要性。的重要性。 8.2.2.1 评估当前用的方法评估当前用的方法所有改进活动的第所有改进活动的第1步都是评估组织当前所使用的步都是评估组织当前所使用的方法，找出这些方法的优点和缺陷。方法，找出这些方法的优点和缺陷。设计结构化问卷表是一种更系统的方法，它能够设计结构化问卷表是一种更系统的方法，它能够以较低的费用对当前过程进行评估。与团队成员以较低的费用对当前过程进行评估。与团队成员进行面谈和讨论，可以更准确更全面地了解当前进行面谈和讨论，可以更准确更全面地了解当前的过程。的过程。 8.2.2.2 规划改进活动规划改进活动战略性计划描述了组织的总体软件过程改进，战战略性计划描述了组织的总

19、体软件过程改进，战术性的活动计划则描述需要改进的专门领域。术性的活动计划则描述需要改进的专门领域。需求管理改进计划，它包括下面这些活动条目：需求管理改进计划，它包括下面这些活动条目：1.起草一个需求变更控制过程草案。起草一个需求变更控制过程草案。2.评审并修订变更控制过程。评审并修订变更控制过程。3.在项目在项目A中试验变更控制过程。中试验变更控制过程。4.根据试验的反馈信息，修订变更控制过程。根据试验的反馈信息，修订变更控制过程。5.评估问题跟踪工具，并从中选择一种工具来支持变评估问题跟踪工具，并从中选择一种工具来支持变更控制过程。更控制过程。6.购买并定制问题跟踪工具以支持变更控制过程。购

20、买并定制问题跟踪工具以支持变更控制过程。7.在组织中使用新的变更控制过程和工具。在组织中使用新的变更控制过程和工具。8.2.2.3 建立、实验并实现新过程建立、实验并实现新过程实现活动计划意味着开发一些过程，并相信这些实现活动计划意味着开发一些过程，并相信这些过程比当前的工作方式会带来更好的结果，但不过程比当前的工作方式会带来更好的结果，但不要期望新的过程第要期望新的过程第1次试用就很完美。次试用就很完美。请牢记下面这些关于指导过程实验的建议：请牢记下面这些关于指导过程实验的建议：选择实验参与者，他们将尝试新方法并提供有用的反选择实验参与者，他们将尝试新方法并提供有用的反馈信息。馈信息。使改进

21、过程的结果容易解释。使改进过程的结果容易解释。确定需要了解实验情况和实验原因的有关涉众。确定需要了解实验情况和实验原因的有关涉众。考虑在不同的项目中实验新过程的不同部分，这样可考虑在不同的项目中实验新过程的不同部分，这样可以使更多的人尝试新方法，因此提高了了解程度，增以使更多的人尝试新方法，因此提高了了解程度，增加了反馈信息，更易于大家接受。加了反馈信息，更易于大家接受。询问实验参与者。询问实验参与者。 8.2.2.4 评估结果评估结果过程改进周期的最后一步是评估完成的活动和取过程改进周期的最后一步是评估完成的活动和取得的成果，这种评估有助于团队在未来的改进活得的成果，这种评估有助于团队在未来

22、的改进活动中做得更好。动中做得更好。评估内容包括判断实验进行得是否顺利，在解决评估内容包括判断实验进行得是否顺利，在解决新过程的不确定性方面是否有效，下一次指导过新过程的不确定性方面是否有效，下一次指导过程实验时是否需要做些变更。程实验时是否需要做些变更。同时还要考虑新过程的总体执行情况是否顺利，同时还要考虑新过程的总体执行情况是否顺利，包括新过程或模板的可用性是否有效地传达给了包括新过程或模板的可用性是否有效地传达给了每一个人，参与者是否理解并成功地应用了新过每一个人，参与者是否理解并成功地应用了新过程，下次工作中是否需要有所变更等。程，下次工作中是否需要有所变更等。其中关键的一步是，评估新

23、实现的过程是否带来其中关键的一步是，评估新实现的过程是否带来了期望的结果。了期望的结果。 8.3.1 软件风险管理基本原理软件风险管理基本原理除了与项目范围和需求有关的风险外，项目还面临着除了与项目范围和需求有关的风险外，项目还面临着许多其他风险。许多其他风险。对外部实体的依赖就是一种常见的风险来源。对外部实体的依赖就是一种常见的风险来源。项目管理一直面临各种风险的挑战：评估不准确、管项目管理一直面临各种风险的挑战：评估不准确、管理人员拒绝开发人员的准确评估、对项目状态不了解理人员拒绝开发人员的准确评估、对项目状态不了解以及进行了人员调整等原因所引起的风险。以及进行了人员调整等原因所引起的风险

24、。技术风险威胁着高度复杂或很前沿的开发项目。技术风险威胁着高度复杂或很前沿的开发项目。知识的缺乏是风险的另一种来源，另外还有参与者对知识的缺乏是风险的另一种来源，另外还有参与者对所用的技术或项目应用领域经验不足。经常变更的或所用的技术或项目应用领域经验不足。经常变更的或强制执行的一些政府规定可能会使最好的项目规划彻强制执行的一些政府规定可能会使最好的项目规划彻底作废。底作废。 8.3.1.1 风险管理的要素风险管理的要素风险管理风险管理(risk management)就是使用某些工具和步骤把项目风险限就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。制在一个可接受的范围内。风险管理提

25、供了一种标准的方法，可以指出风险因素并将其编写成文风险管理提供了一种标准的方法，可以指出风险因素并将其编写成文档，评估这些风险的潜在威胁，并提出减少这些风险因素的战略档，评估这些风险的潜在威胁，并提出减少这些风险因素的战略(Williams，Walker和和Dorofee 1997)。风险管理包括下图所示的这些活动。风险管理包括下图所示的这些活动。风险评估风险评估(risk assessment)是一个对项目进行检查以确定潜在风险是一个对项目进行检查以确定潜在风险领域的过程。领域的过程。风险避免风险避免(risk avoidance)是处理风险的一种方法，也就是尽量不要是处理风险的一种方法，也

26、就是尽量不要做冒险的事做冒险的事。 8.3.1.2 编写项目风险文档编写项目风险文档只是认识到项目所面只是认识到项目所面临的风险是远远不够临的风险是远远不够的，我们还必须以某的，我们还必须以某种方式对风险进行管种方式对风险进行管理，以便在整个项目理，以便在整个项目开发过程中可以将风开发过程中可以将风险问题和状态传达给险问题和状态传达给项目的涉众。项目的涉众。右图展示了一个模板，右图展示了一个模板，用于对单个风险编写用于对单个风险编写文档。文档。 8.3.1.3 制定风险管理计划制定风险管理计划对于小型项目，可以把控制风险的计对于小型项目，可以把控制风险的计划包括在软件项目管理计划内。划包括在软

27、件项目管理计划内。但对一个大型项目，则应该编写一个但对一个大型项目，则应该编写一个单独的风险管理计划，详细说明打算单独的风险管理计划，详细说明打算采用哪些方法来识别、评估、编档和采用哪些方法来识别、评估、编档和跟踪风险。这一计划还应该包括风险跟踪风险。这一计划还应该包括风险管理活动的角色和职责。管理活动的角色和职责。风险管理计划模板可以从风险管理计划模板可以从http:/ 注意：不要想当然地以为，在识别出了风险并采取了降低风险的相应活动之后，风险就会处于您的控制之下。接下来还要实行风险管理活动。 8.3.2 与需求相关的风险与需求相关的风险下面介绍的这些风险因素，是按照需求下面介绍的这些风险因

28、素，是按照需求工程的分支过程组织的，即需求获取、工程的分支过程组织的，即需求获取、需求分析、编写需求规格说明、需求确需求分析、编写需求规格说明、需求确认和需求管理过程。认和需求管理过程。推荐的方法可以减小风险发生的可能性推荐的方法可以减小风险发生的可能性或风险发生后给项目造成的影响。或风险发生后给项目造成的影响。 8.3.2.1 需求获取需求获取产品前景和项目范围产品前景和项目范围应该在项目早期，编写一份包括业务需求在内的前景和范围文档，并将应该在项目早期，编写一份包括业务需求在内的前景和范围文档，并将它作为添加新需求和修改现有需求的指导。它作为添加新需求和修改现有需求的指导。需求开发所需的时

29、间需求开发所需的时间 将每个项目中需求开发所耗费的实际工作量记录下来，这样就可以判断将每个项目中需求开发所耗费的实际工作量记录下来，这样就可以判断出需求开发是否充分，并可以改进未来项目的工作计划。出需求开发是否充分，并可以改进未来项目的工作计划。需求规格说明的完整性和正确性需求规格说明的完整性和正确性为了确保需求是客户真正需要的，应该以用户任务为中心，应用用例技为了确保需求是客户真正需要的，应该以用户任务为中心，应用用例技术来获取需求。术来获取需求。创新产品的需求创新产品的需求对某类产品中的第对某类产品中的第1个产品，不太容易把握市场对产品的反映。个产品，不太容易把握市场对产品的反映。定义非功

30、能需求定义非功能需求由于我们一般都会强调产品的功能，所以很容易忽略产品的非由于我们一般都会强调产品的功能，所以很容易忽略产品的非功能性需求。功能性需求。 8.3.2.1 需求获取客户对产品需求意见一致客户对产品需求意见一致确定那些主要的客户，并采用产品代言人的方法，保确定那些主要的客户，并采用产品代言人的方法，保证有足够的客户代表的积极参与。证有足够的客户代表的积极参与。未加说明的需求未加说明的需求 客户经常会有一些隐含的期望要求，但并未以文档的客户经常会有一些隐含的期望要求，但并未以文档的方式说明出来。尽量识别客户可能做出的任何假设。方式说明出来。尽量识别客户可能做出的任何假设。把已有的产品

31、作为需求基线来源把已有的产品作为需求基线来源将通过逆向工程发现的需求编写成文档，让客户评审将通过逆向工程发现的需求编写成文档，让客户评审这些需求，以确保其正确性和相关性。这些需求，以确保其正确性和相关性。根据需要提出解决方案根据需要提出解决方案 分析人员必须提炼出隐藏在客户提出的解决方案背后分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图。的真正意图。 8.3.2.2 需求分析需求分析设定需求优先级设定需求优先级要确保对每一个功能需求、特性或用例都设定要确保对每一个功能需求、特性或用例都设定了优先级，并安排在一个特定的系统版本或迭了优先级，并安排在一个特定的系统版本或迭代中实现它们。代

32、中实现它们。技术上难以实现的特性技术上难以实现的特性 采用项目状态跟踪来监控落后于实现计划的需采用项目状态跟踪来监控落后于实现计划的需求，并尽早采取纠正措施。求，并尽早采取纠正措施。不熟悉的技术、方法、语言、工具或硬件不熟悉的技术、方法、语言、工具或硬件 留出足够的时间用于从错误中学习经验、实验留出足够的时间用于从错误中学习经验、实验及制作原型。及制作原型。 8.3.2.3 编写需求规格说明编写需求规格说明需求理解需求理解 开发人员和客户对需求的不同理解会导致彼此间的期开发人员和客户对需求的不同理解会导致彼此间的期望差距，并最终导致交付的产品无法满足客户的需要。望差距，并最终导致交付的产品无法

33、满足客户的需要。尽管问题待确定但迫于时间压力而继续向前尽管问题待确定但迫于时间压力而继续向前在软件需求规格说明中，将需要进一步研究的地方标在软件需求规格说明中，将需要进一步研究的地方标上上TBD(to be determined，待确定，待确定)，不失为一个好，不失为一个好主意。主意。具有二义性的术语具有二义性的术语 对于不同的读者可能会有不同解释的业务术语或技术对于不同的读者可能会有不同解释的业务术语或技术术语，应该创建一个术语表对这些术语进行定义。术语，应该创建一个术语表对这些术语进行定义。需求中包括了设计需求中包括了设计 软件需求规格说明中所包含的设计对开发人员做出有软件需求规格说明中所

34、包含的设计对开发人员做出有效选择造成了不必要的限制，会妨碍他们发挥创造性效选择造成了不必要的限制，会妨碍他们发挥创造性设计出最佳方案。设计出最佳方案。 8.3.2.4 需求确认需求确认未经确认的需求未经确认的需求软件需求规格说明会令人望而生畏，软件需求规格说明会令人望而生畏，在开发过程早期编写测试用例的想法在开发过程早期编写测试用例的想法就是基于这一点。就是基于这一点。审查熟练程度审查熟练程度 要对参与需求文档审查的所有团队成要对参与需求文档审查的所有团队成员进行培训，请组织内部有经验的审员进行培训，请组织内部有经验的审查人员或外界的咨询顾问来评述早先查人员或外界的咨询顾问来评述早先的审查。的

35、审查。 8.3.2.5 需求管理需求管理变更需求变更需求 将前景和范围文档作为批准需求变更的参照，可以减将前景和范围文档作为批准需求变更的参照，可以减少范围蔓延。少范围蔓延。需求变更过程需求变更过程 与需求变更的处理方式相关的风险包括，缺少已定义与需求变更的处理方式相关的风险包括，缺少已定义的变更过程，采用无效的变更机制，以及不遵循制定的变更过程，采用无效的变更机制，以及不遵循制定的过程来做出变更。的过程来做出变更。未实现的需求未实现的需求需求跟踪矩阵有助于在设计、构造或测试期间避免遗需求跟踪矩阵有助于在设计、构造或测试期间避免遗漏任何需求。漏任何需求。扩大项目范围扩大项目范围 如果最初的需求

36、定义不够好，那么进一步定义需求就如果最初的需求定义不够好，那么进一步定义需求就会扩大项目的范围。会扩大项目的范围。 8.3.3 风险管理是我们的好帮手风险管理是我们的好帮手周期性地进行风险跟踪可以使项目经理周期性地进行风险跟踪可以使项目经理了解风险对项目的威胁，没有得到有效了解风险对项目的威胁，没有得到有效控制的风险应该上报高层管理人员，他控制的风险应该上报高层管理人员，他们可能开始采取一些纠正措施，也可能们可能开始采取一些纠正措施，也可能不管风险，依旧按照原来的业务决策思不管风险，依旧按照原来的业务决策思路进行。路进行。即使不能控制项目可能遇到的所有风险，即使不能控制项目可能遇到的所有风险，

37、风险管理也能帮助我们看清形势，做出风险管理也能帮助我们看清形势，做出合理的决策。合理的决策。318.4 特殊软件项目的需求实践特殊软件项目的需求实践一般所讲述的需求开发，是针对一个新软件一般所讲述的需求开发，是针对一个新软件或系统开发项目的情况，这种项目有时也称或系统开发项目的情况，这种项目有时也称为零起点项目为零起点项目(green-field project)。大多数组织的主要精力集中于维护现存的遗大多数组织的主要精力集中于维护现存的遗留系统，或者为已有的商业产品构建新的版留系统，或者为已有的商业产品构建新的版本；其他组织也很少是从零开始构建一个新本；其他组织也很少是从零开始构建一个新系统

38、，而是对商用现货系统，而是对商用现货(off-the-shelf，COTS)产品进行集成、定制和扩充，以满足产品进行集成、定制和扩充，以满足自己的需要。自己的需要。 8.4.1 维护项目的需求维护项目的需求维护是指对当前运行的项目进行修改，维护是指对当前运行的项目进行修改，有时也称为继续工程有时也称为继续工程(continuing engineering)或后续开发或后续开发(ongoing development)。程序维护的任务主要是纠正缺陷、为程序维护的任务主要是纠正缺陷、为现有系统添加新功能或新报表，以及现有系统添加新功能或新报表，以及对功能进行修改以便遵循修订后的业对功能进行修改以便

39、遵循修订后的业务规则。务规则。 8.4.1.1 开始捕获信息开始捕获信息缺少精确的需求文档，那么维护人员就必须进行逆向工缺少精确的需求文档，那么维护人员就必须进行逆向工程，通过代码来理解系统，我将此看作是软件考古学程，通过代码来理解系统，我将此看作是软件考古学(software archaeology)。为了能够从逆向工程中获得最大的收益，考古探险队应为了能够从逆向工程中获得最大的收益，考古探险队应该将通过需求和设计描述表中所了解到的信息记录下来，该将通过需求和设计描述表中所了解到的信息记录下来，然后将有关当前系统某些部分的精确信息积累起来。然后将有关当前系统某些部分的精确信息积累起来。 构建

40、一个包含当前系统部分的需求表示可达到以下构建一个包含当前系统部分的需求表示可达到以下3个有个有用的目标：用的目标：消除知识鸿沟，使将来的维护人员能更好地理解所做的变更。消除知识鸿沟，使将来的维护人员能更好地理解所做的变更。收集当前系统的一些信息收集当前系统的一些信息当前系统在以前缺乏良好的书面文当前系统在以前缺乏良好的书面文档。当项目团队日后再完成其他的维护任务时，可以对这些零星档。当项目团队日后再完成其他的维护任务时，可以对这些零星分散的知识表示加以扩充，进而逐步完善系统文档。记录这些新分散的知识表示加以扩充，进而逐步完善系统文档。记录这些新发现的知识所需要增加的费用，比起以后必须重新发现这

41、些知识发现的知识所需要增加的费用，比起以后必须重新发现这些知识所需要的费用更少。所需要的费用更少。提供一个指标，表明当前的系统测试集对系统功能的覆盖率。提供一个指标，表明当前的系统测试集对系统功能的覆盖率。 8.4.1.2 亲身实践一下新的需求技术亲身实践一下新的需求技术技能水平对项目的成功或失败有着至关重要的影响，技能水平对项目的成功或失败有着至关重要的影响，那么实践经验就可以减少在一个零起点项目中第一那么实践经验就可以减少在一个零起点项目中第一次应用用例的风险。次应用用例的风险。我们还可以在小规模项目维护中试试其他一些技术：我们还可以在小规模项目维护中试试其他一些技术：创建数据字典创建数据

42、字典绘制分析模型绘制分析模型指定质量属性和性能目标指定质量属性和性能目标构建用户界面和技术原型构建用户界面和技术原型审查需求规格说明审查需求规格说明根据需求编写测试用例根据需求编写测试用例制定客户验收标准制定客户验收标准 8.4.1.3 遵循跟踪链遵循跟踪链需求的跟踪数据有助于程序维护人员确定由于某一特定的需求的跟踪数据有助于程序维护人员确定由于某一特定的需求发生了变更。需求发生了变更。由于许多软件修改都会引发很大的连锁反应，所以我们必由于许多软件修改都会引发很大的连锁反应，所以我们必须确保每次需求变更都要正确地传给下游工作产品，审查须确保每次需求变更都要正确地传给下游工作产品，审查就是检查这

43、种一致性的一种好方法。就是检查这种一致性的一种好方法。4种来源的观点，也适用于维护工作：种来源的观点，也适用于维护工作：对需求进行修改或增强的作者。对需求进行修改或增强的作者。提出请求的客户或市场代表，他们能确保新的需求准确地描提出请求的客户或市场代表，他们能确保新的需求准确地描述所需要的变更。述所需要的变更。开发人员、测试人员或者其他必须以新的需求为基础来完成开发人员、测试人员或者其他必须以新的需求为基础来完成自己工作的人们。自己工作的人们。其工作产品可能受这种变更影响的人们。其工作产品可能受这种变更影响的人们。 8.4.2 外包项目的需求外包项目的需求将产品的开发承包给某个独立的公司，需要

44、准备高质量将产品的开发承包给某个独立的公司，需要准备高质量的需求文档，因为与工程团队的直接交互可能很少。的需求文档，因为与工程团队的直接交互可能很少。需方将向供方发送一份建议请求、一份需求规格说明和需方将向供方发送一份建议请求、一份需求规格说明和一些产品验收标准，而供方则要向需方返回完成的产品一些产品验收标准，而供方则要向需方返回完成的产品和支持文档，如下图所示。和支持文档，如下图所示。 8.4.2 外包项目的需求外包项目的需求对外包项目准备需求文档时，要牢记以对外包项目准备需求文档时，要牢记以下几点建议：下几点建议：提供细节。提供细节。避免二义性。避免二义性。 安排与承包方的接触点。安排与承

45、包方的接触点。定义双方都能接受的变更控制过程。定义双方都能接受的变更控制过程。为需求的多次迭代和评审预留时间。为需求的多次迭代和评审预留时间。制定验收标准制定验收标准。本章练习题1.请举例说明用自然语言描述用户需求和系统需求的问题2.需求工程包括哪些基本活动？每一项活动的主要任务是什么?3.在某些紧急情况下，软件可能在需求变更请求被批准之前就进行修改。请给出一个修改过程模型，确保需求文档和系统实现不会产生不一致。4.利益相关者是将来购买软件系统的人？5.在需求分析过程中，需求分析员从用户那里要解决的最重要的问题是明确软件做什么？6.在项目初始阶段，开发任务的目标是？理解基本问题or确定解决方案？7.目前存在很普遍的现象，即不同的客户提出的需求是相互矛盾的，但每个人都争辩自己是正确的？8.需求工程师的任务是将所有利益相关者的信息进行分类以便决策者选择一个相一致的需求集？