软件需求工程--北京大学软件与微电子学院

《软件需求工程--北京大学软件与微电子学院》由会员分享，可在线阅读，更多相关《软件需求工程--北京大学软件与微电子学院（38页珍藏版）》请在装配图网上搜索。

1、第八章第八章 软件需求实现软件需求实现周立新周立新 博士博士北京大学软件与微电子学院北京大学软件与微电子学院课程提纲课程提纲1.1.软件需求根本理论和概念软件需求根本理论和概念 2.2.软件需求工程过程软件需求工程过程 3.3.软件需求获取软件需求获取 4.4.软件需求分析软件需求分析 5.5.软件需求规格说明软件需求规格说明 6.6.软件需求验证软件需求验证 7.7.软件需求管理软件需求管理 8.8.软件需求实现软件需求实现 9.9.软件需求工程新进展软件需求工程新进展 10.10.软件需求开发与需求管理工具软件需求开发与需求管理工具内容提要需求与其他工程过程的需求与其他工程过程的联系联系过

2、程改进原那么及周期过程改进原那么及周期需求相关的风险控制需求相关的风险控制特殊软件工程特殊软件工程(如维护、如维护、外包等外包等)的需求实践等的需求实践等 8.1 需求与其他需求与其他工程过程的联系工程过程的联系需求是每个软件工程成功需求是每个软件工程成功的核心所在，它支持其他的核心所在，它支持其他技术活动和管理活动。技术活动和管理活动。对需求开发方法和需求管对需求开发方法和需求管理方法的变更会对工程的理方法的变更会对工程的其他过程产生影响，反之其他过程产生影响，反之亦然。亦然。右图演示了需求和其他过右图演示了需求和其他过程之间的某些连接，下面程之间的某些连接，下面简要介绍一下这些过程之简要介

3、绍一下这些过程之间的接口。间的接口。8.1.1 从需求到工程规划从需求到工程规划由于需求定义了工程的预期成果，所以工程规划、工由于需求定义了工程的预期成果，所以工程规划、工程预算和工程的进度安排都必须以软件需求为根底。程预算和工程的进度安排都必须以软件需求为根底。最重要的工程成果是交付满足业务目标的系统，而不最重要的工程成果是交付满足业务目标的系统，而不一定是根据最初的工程规划实现所有初始需求的系统。一定是根据最初的工程规划实现所有初始需求的系统。需求和规划只代表团队最初的评估，工程成果就是根需求和规划只代表团队最初的评估，工程成果就是根据这一评估来完成的。据这一评估来完成的。下表说明对需求工

4、作的投资可以加速工程的开发。下表说明对需求工作的投资可以加速工程的开发。需求阶段投入的工作量需求阶段投入的工作量 需求阶段投入的时间需求阶段投入的时间 开发较快的项目开发较快的项目 14%14%17%17%开发较慢的项目开发较慢的项目 7%7%9%9%需求和预估需求和预估根据文本需求、图形分析模型、原型或用户界面根据文本需求、图形分析模型、原型或用户界面设计来预估产品的大小。设计来预估产品的大小。虽然对于软件的规模没有完善的度量标准，但下虽然对于软件的规模没有完善的度量标准，但下面是一些常用的度量标准：面是一些常用的度量标准：可单独测试需求的数量可单独测试需求的数量(Wilson 1995)。

5、功能点和特性点的多少功能点和特性点的多少(Jones 1996b)，或者将数据、，或者将数据、功能和控制三者整合在一起的三维功能点的数量功能和控制三者整合在一起的三维功能点的数量(Whitmire 1995)。图形用户界面图形用户界面(GUI)元素的数量、类型和复杂度。元素的数量、类型和复杂度。用于实现特定需求所需的源代码行数。用于实现特定需求所需的源代码行数。对象类的数量或者其他面向对象系统的衡量标准对象类的数量或者其他面向对象系统的衡量标准(Whitmire 1997)。需求和进度安排需求和进度安排主要的规划失误包括主要的规划失误包括:忽略了公共忽略了公共(用用)的的工程任务，低估了所需的

6、工作量和时间，工程任务，低估了所需的工作量和时间，没有考虑工程风险，没有考虑返工所需的没有考虑工程风险，没有考虑返工所需的时间，以及对自己的盲目乐观等。时间，以及对自己的盲目乐观等。有效的工程规划需要以下元素：有效的工程规划需要以下元素：根据对需求的清楚理解来估计产品规模的根据对需求的清楚理解来估计产品规模的大小。大小。根据历史记录了解到的开发团队的工作效根据历史记录了解到的开发团队的工作效率。率。一张任务列表，以便完全地实现和验证每一张任务列表，以便完全地实现和验证每一特性或用例。一特性或用例。相当稳定的需求。相当稳定的需求。有效的预测和规划过程。有效的预测和规划过程。经验，这有助于工程经理

7、对不可触及的因经验，这有助于工程经理对不可触及的因素和每一个工程所特有的因素加以调整。素和每一个工程所特有的因素加以调整。注意：不要迫于压力而许下自己明知道不可能做到的诺言，这是防止最后两败俱伤的秘诀。8.1.2 从需求到设计和编码从需求到设计和编码需求和设计之间存在差异需求和设计之间存在差异,要防止规格说要防止规格说明造成实现上的倾向性，除非是有迫不得明造成实现上的倾向性，除非是有迫不得已的原因要有意地对设计加以约束。已的原因要有意地对设计加以约束。需求规格说明几乎总是包括某些设计信息，需求规格说明几乎总是包括某些设计信息，让设计人员或开发人员参与需求审查，这让设计人员或开发人员参与需求审查

8、，这样可以确保需求为后续的设计打下坚实的样可以确保需求为后续的设计打下坚实的根底。根底。产品的需求、质量属性和用户特点可以决产品的需求、质量属性和用户特点可以决定产品体系结构。定产品体系结构。从需求到设计和编码从需求到设计和编码对于同时包括软件组件和硬件组件的系统，对于同时包括软件组件和硬件组件的系统，以及只包括软件的复杂系统，体系结构就显以及只包括软件的复杂系统，体系结构就显得尤其关键。得尤其关键。将系统功能分配给子系统或组件必须采用自将系统功能分配给子系统或组件必须采用自顶向下的方法顶向下的方法(Hooks和和Farry 2001)。在开始实现产品之前，虽然不需要为整个产在开始实现产品之前

9、，虽然不需要为整个产品开发完整的、详细的设计，但是，应该先品开发完整的、详细的设计，但是，应该先对每一个组件进行设计，然后再对其进行编对每一个组件进行设计，然后再对其进行编码。码。从需求到设计和编码从需求到设计和编码下面的动作可以使所有的工程类型都从中受益：下面的动作可以使所有的工程类型都从中受益：为子系统和组件开发一个巩固的体系结构，这一体系为子系统和组件开发一个巩固的体系结构，这一体系结构在产品改进的过程中可以保持不变。结构在产品改进的过程中可以保持不变。确定需要构建的主要对象类或功能模块，定义它们的确定需要构建的主要对象类或功能模块，定义它们的接口、职责以及与其他单元的协作。接口、职责以

10、及与其他单元的协作。对并行处理系统，要理解方案的执行线程或对并发进对并行处理系统，要理解方案的执行线程或对并发进程的功能分配。程的功能分配。根据强内聚、低耦合和信息隐藏等这些良好的设计原根据强内聚、低耦合和信息隐藏等这些良好的设计原那么，定义每个代码单元的预期功能那么，定义每个代码单元的预期功能(McConnell 1993)。确保设计满足所有的功能性需求，但不要包括不必要确保设计满足所有的功能性需求，但不要包括不必要的功能。的功能。确保设计能适应可能出现的异常条件。确保设计能适应可能出现的异常条件。确保设计能到达所陈述的性能、健壮性、可靠性和其确保设计能到达所陈述的性能、健壮性、可靠性和其他

11、一些质量属性的目标。他一些质量属性的目标。8.1.3 从需求到测试从需求到测试测试和需求工程是一种互相促进的关系。测试和需求工程是一种互相促进的关系。需求是系统测试的根底，对产品的测试应该根据需求文档需求是系统测试的根底，对产品的测试应该根据需求文档中所记录的产品的预期行为来进行，而不应该根据设计或中所记录的产品的预期行为来进行，而不应该根据设计或编码来测试。编码来测试。工程测试人员应该确定他们如何验证每一条需求，下面列工程测试人员应该确定他们如何验证每一条需求，下面列出了一些可能的方法：出了一些可能的方法：测试测试(执行软件以便发现缺陷执行软件以便发现缺陷)。审查审查(检查代码，以便确保代码

12、满足了需求检查代码，以便确保代码满足了需求)。演示演示(显示产品的运作与所期望的相符显示产品的运作与所期望的相符)。分析分析(推导在某些情况下系统应该如何运作推导在某些情况下系统应该如何运作)。基于规格说明的测试可以运用假设干测试设计策略：动作基于规格说明的测试可以运用假设干测试设计策略：动作驱动、数据驱动驱动、数据驱动(包括边界值分析和等价类划分包括边界值分析和等价类划分)、逻辑驱、逻辑驱动、事件驱动和状态驱动动、事件驱动和状态驱动(Poston 1996)。8.1.4 从需求到成功从需求到成功使工程更成功的一种方法是，列出与特定的代码版本相对使工程更成功的一种方法是，列出与特定的代码版本相

13、对应的所有需求。应的所有需求。工程的质量保证工程的质量保证(quality assurance，QA)小组通过对照小组通过对照相应的需求来执行测试，从而对每一个版本进行评估。这相应的需求来执行测试，从而对每一个版本进行评估。这个工程的成功，在很大程度上得益于根据需求文档来决定个工程的成功，在很大程度上得益于根据需求文档来决定何时发布产品。何时发布产品。软件开发工程最终的可交付工件应该是一个满足客户需要软件开发工程最终的可交付工件应该是一个满足客户需要和期望的软件系统。和期望的软件系统。需求是从业务需要通向用户满意之路中必不可少的一步。需求是从业务需要通向用户满意之路中必不可少的一步。如果不以高

14、质量的需求作为工程规划、软件设计和系统测如果不以高质量的需求作为工程规划、软件设计和系统测试的根底，那么在试图发布优秀产品的过程中将浪费大量试的根底，那么在试图发布优秀产品的过程中将浪费大量的工作。的工作。精确的规格说明与可将产品失败的风险降至可接受程度的精确的规格说明与可将产品失败的风险降至可接受程度的编码之间做出明智的选择。编码之间做出明智的选择。软件过程改进的根本原那么软件过程改进的根本原那么应该牢记下面应该牢记下面4条软件过程改进的原那么条软件过程改进的原那么(Wiegers 1996a)：1.过程改进应该是不断演化的、连续的、周期性的过程改进应该是不断演化的、连续的、周期性的 不要期

15、望一次就能改进全部过程，要知道在第不要期望一次就能改进全部过程，要知道在第1次尝试变更次尝试变更时，可能无法解决所有问题。时，可能无法解决所有问题。2.只有人们和组织具有变更的动机时才可能实施变更只有人们和组织具有变更的动机时才可能实施变更下面列出了一些典型的问题，也许能为需求过程的变更提下面列出了一些典型的问题，也许能为需求过程的变更提供驱动力：供驱动力：工程超出了最后期限，原因是需求比预期的扩展了很多，工程超出了最后期限，原因是需求比预期的扩展了很多，也复杂了很多。也复杂了很多。开发人员频繁加班，原因是直到开发后期才发现了引起误开发人员频繁加班，原因是直到开发后期才发现了引起误解的需求和表

16、达不明确的需求。解的需求和表达不明确的需求。系统测试工作前功尽弃，原因是测试人员并没有弄清楚产系统测试工作前功尽弃，原因是测试人员并没有弄清楚产品应该做什么。品应该做什么。虽然正确的功能都实现了，但是用户不满意，这是由于性虽然正确的功能都实现了，但是用户不满意，这是由于性能不好、易使用性差或存在其他质量缺陷。能不好、易使用性差或存在其他质量缺陷。维护费用很高，因为客户的对产品的许多增强要求没有在维护费用很高，因为客户的对产品的许多增强要求没有在需求获取阶段确定下来。需求获取阶段确定下来。开发组织名誉受损，因为客户不接受交付的软件。开发组织名誉受损，因为客户不接受交付的软件。3.过程变更要有的放

17、矢过程变更要有的放矢在开始运用更好的过程之前，一定要明确变更的目标是什在开始运用更好的过程之前，一定要明确变更的目标是什么么(Potter and Sakry 2002)。4.将改进活动视作小型工程将改进活动视作小型工程工程的总体方案应该包括过程改进的资源和任务。与所有工程的总体方案应该包括过程改进的资源和任务。与所有工程一样，改进工程也要执行方案、跟踪、测量和报告，工程一样，改进工程也要执行方案、跟踪、测量和报告，只是规模相应地缩小了。只是规模相应地缩小了。过程改进周期过程改进周期右图是一个有效右图是一个有效的过程改进周期。的过程改进周期。这一方法反映了这一方法反映了您在执行下一个您在执行下

18、一个任务之前先清楚任务之前先清楚自己所处位置的自己所处位置的重要性；反映了重要性；反映了绘制过程路线图绘制过程路线图的必要性，以及的必要性，以及以往的经验在持以往的经验在持续的过程改进中续的过程改进中的重要性。的重要性。.1 评估当前用的方法评估当前用的方法所有改进活动的第所有改进活动的第1步都是评估组织当前所使用的步都是评估组织当前所使用的方法，找出这些方法的优点和缺陷。方法，找出这些方法的优点和缺陷。设计结构化问卷表是一种更系统的方法，它能够设计结构化问卷表是一种更系统的方法，它能够以较低的费用对当前过程进行评估。与团队成员以较低的费用对当前过程进行评估。与团队成员进行面谈和讨论，可以更准

19、确更全面地了解当前进行面谈和讨论，可以更准确更全面地了解当前的过程。的过程。.2 规划改进活动规划改进活动战略性方案描述了组织的总体软件过程改进，战战略性方案描述了组织的总体软件过程改进，战术性的活动方案那么描述需要改进的专门领域。术性的活动方案那么描述需要改进的专门领域。需求管理改进方案，它包括下面这些活动条目：需求管理改进方案，它包括下面这些活动条目：1.起草一个需求变更控制过程草案。起草一个需求变更控制过程草案。2.评审并修订变更控制过程。评审并修订变更控制过程。3.在工程在工程A中试验变更控制过程。中试验变更控制过程。4.根据试验的反响信息，修订变更控制过程。根据试验的反响信息，修订变

20、更控制过程。5.评估问题跟踪工具，并从中选择一种工具来支评估问题跟踪工具，并从中选择一种工具来支持变更控制过程。持变更控制过程。6.购置并定制问题跟踪工具以支持变更控制过程。购置并定制问题跟踪工具以支持变更控制过程。7.在组织中使用新的变更控制过程和工具。在组织中使用新的变更控制过程和工具。.3 建立、实验并实现新过程建立、实验并实现新过程实现活动方案意味着开发一些过程，并相信这些实现活动方案意味着开发一些过程，并相信这些过程比当前的工作方式会带来更好的结果，但不过程比当前的工作方式会带来更好的结果，但不要期望新的过程第要期望新的过程第1次试用就很完美。次试用就很完美。请牢记下面这些关于指导过

21、程实验的建议：请牢记下面这些关于指导过程实验的建议：选择实验参与者，他们将尝试新方法并提供有用选择实验参与者，他们将尝试新方法并提供有用的反响信息。的反响信息。使改进过程的结果容易解释。使改进过程的结果容易解释。确定需要了解实验情况和实验原因的有关涉众。确定需要了解实验情况和实验原因的有关涉众。考虑在不同的工程中实验新过程的不同局部，这考虑在不同的工程中实验新过程的不同局部，这样可以使更多的人尝试新方法，因此提高了了解样可以使更多的人尝试新方法，因此提高了了解程度，增加了反响信息，更易于大家接受。程度，增加了反响信息，更易于大家接受。询问实验参与者。询问实验参与者。.4 评估结果评估结果过程改

22、进周期的最后一步是评估完成的活动和取过程改进周期的最后一步是评估完成的活动和取得的成果，这种评估有助于团队在未来的改进活得的成果，这种评估有助于团队在未来的改进活动中做得更好。动中做得更好。评估内容包括判断实验进行得是否顺利，在解决评估内容包括判断实验进行得是否顺利，在解决新过程的不确定性方面是否有效，下一次指导过新过程的不确定性方面是否有效，下一次指导过程实验时是否需要做些变更。程实验时是否需要做些变更。同时还要考虑新过程的总体执行情况是否顺利，同时还要考虑新过程的总体执行情况是否顺利，包括新过程或模板的可用性是否有效地传达给了包括新过程或模板的可用性是否有效地传达给了每一个人，参与者是否理

23、解并成功地应用了新过每一个人，参与者是否理解并成功地应用了新过程，下次工作中是否需要有所变更等。程，下次工作中是否需要有所变更等。其中关键的一步是，评估新实现的过程是否带来其中关键的一步是，评估新实现的过程是否带来了期望的结果。了期望的结果。8.3.1 软件风险管理根本原理软件风险管理根本原理除了与工程范围和需求有关的风险外，工程还面临着除了与工程范围和需求有关的风险外，工程还面临着许多其他风险。许多其他风险。对外部实体的依赖就是一种常见的风险来源。对外部实体的依赖就是一种常见的风险来源。工程管理一直面临各种风险的挑战：评估不准确、管工程管理一直面临各种风险的挑战：评估不准确、管理人员拒绝开发

24、人员的准确评估、对工程状态不了解理人员拒绝开发人员的准确评估、对工程状态不了解以及进行了人员调整等原因所引起的风险。以及进行了人员调整等原因所引起的风险。技术风险威胁着高度复杂或很前沿的开发工程。技术风险威胁着高度复杂或很前沿的开发工程。知识的缺乏是风险的另一种来源，另外还有参与者对知识的缺乏是风险的另一种来源，另外还有参与者对所用的技术或工程应用领域经验缺乏。经常变更的或所用的技术或工程应用领域经验缺乏。经常变更的或强制执行的一些政府规定可能会使最好的工程规划彻强制执行的一些政府规定可能会使最好的工程规划彻底作废。底作废。8.3.1.1 风险管理的要素风险管理的要素风险管理风险管理(risk

25、 management)就是使用某些工具和步骤把工程风险限就是使用某些工具和步骤把工程风险限制在一个可接受的范围内。制在一个可接受的范围内。风险管理提供了一种标准的方法，可以指出风险因素并将其编写成文风险管理提供了一种标准的方法，可以指出风险因素并将其编写成文档，评估这些风险的潜在威胁，并提出减少这些风险因素的战略档，评估这些风险的潜在威胁，并提出减少这些风险因素的战略(Williams，Walker和和Dorofee 1997)。风险管理包括以下图所示的这些活动。风险管理包括以下图所示的这些活动。风险评估风险评估(risk assessment)是一个对工程进行检查以确定潜在风险是一个对工程

26、进行检查以确定潜在风险领域的过程。领域的过程。风险防止风险防止(risk avoidance)是处理风险的一种方法，也就是尽量不要是处理风险的一种方法，也就是尽量不要做冒险的事。做冒险的事。8.3.1.2 编写工程风险文档编写工程风险文档只是认识到工程所面只是认识到工程所面临的风险是远远不够临的风险是远远不够的，我们还必须以某的，我们还必须以某种方式对风险进行管种方式对风险进行管理，以便在整个工程理，以便在整个工程开发过程中可以将风开发过程中可以将风险问题和状态传达给险问题和状态传达给工程的涉众。工程的涉众。右图展示了一个模板，右图展示了一个模板，用于对单个风险编写用于对单个风险编写文档。文档

27、。8.3.1.3 制定风险管理方案制定风险管理方案对于小型工程，可以把控制风险的方对于小型工程，可以把控制风险的方案包括在软件工程管理方案内。案包括在软件工程管理方案内。但对一个大型工程，那么应该编写一但对一个大型工程，那么应该编写一个单独的风险管理方案，详细说明打个单独的风险管理方案，详细说明打算采用哪些方法来识别、评估、编档算采用哪些方法来识别、评估、编档和跟踪风险。这一方案还应该包括风和跟踪风险。这一方案还应该包括风险管理活动的角色和职责。险管理活动的角色和职责。风险管理方案模板可以从风险管理方案模板可以从 :/获得。获得。要建立起周期性进行风险监控的措施。要建立起周期性进行风险监控的措

28、施。注意：不要想当然地以为，在识别出了风险并采取了降低风险的相应活动之后，风险就会处于您的控制之下。接下来还要实行风险管理活动。8.3.2 与需求相关的风险与需求相关的风险下面介绍的这些风险因素，是按照需求下面介绍的这些风险因素，是按照需求工程的分支过程组织的，即需求获取、工程的分支过程组织的，即需求获取、需求分析、编写需求规格说明、需求确需求分析、编写需求规格说明、需求确认和需求管理过程。认和需求管理过程。推荐的方法可以减小风险发生的可能性推荐的方法可以减小风险发生的可能性或风险发生后给工程造成的影响。或风险发生后给工程造成的影响。8.3.2.1 需求获取需求获取产品前景和工程范围产品前景和

29、工程范围应该在工程早期，编写一份包括业务需求在内的前景和范应该在工程早期，编写一份包括业务需求在内的前景和范围文档，并将它作为添加新需求和修改现有需求的指导。围文档，并将它作为添加新需求和修改现有需求的指导。需求开发所需的时间需求开发所需的时间 将每个工程中需求开发所消耗的实际工作量记录下来，这将每个工程中需求开发所消耗的实际工作量记录下来，这样就可以判断出需求开发是否充分，并可以改进未来工程样就可以判断出需求开发是否充分，并可以改进未来工程的工作方案。的工作方案。需求规格说明的完整性和正确性需求规格说明的完整性和正确性为了确保需求是客户真正需要的，应该以用户任务为中心，为了确保需求是客户真正

30、需要的，应该以用户任务为中心，应用用例技术来获取需求。应用用例技术来获取需求。创新产品的需求创新产品的需求对某类产品中的第对某类产品中的第1个产品，不太容易把握市场对产品的个产品，不太容易把握市场对产品的反映。反映。定义非功能需求定义非功能需求由于我们一般都会强调产品的功能，所以很容易忽略产品由于我们一般都会强调产品的功能，所以很容易忽略产品的非功能性需求。的非功能性需求。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)或后续开发或后续开发(ong

39、oing development)。程序维护的任务主要是纠正缺陷、为程序维护的任务主要是纠正缺陷、为现有系统添加新功能或新报表，以及现有系统添加新功能或新报表，以及对功能进行修改以便遵循修订后的业对功能进行修改以便遵循修订后的业务规那么。务规那么。8.4.1.1 开始捕获信息开始捕获信息缺少精确的需求文档，那么维护人员就必须进行逆向工缺少精确的需求文档，那么维护人员就必须进行逆向工程，通过代码来理解系统，我将此看作是软件考古学程，通过代码来理解系统，我将此看作是软件考古学(software archaeology)。为了能够从逆向工程中获得最大的收益，考古探险队应为了能够从逆向工程中获得最大的

40、收益，考古探险队应该将通过需求和设计描述表中所了解到的信息记录下来，该将通过需求和设计描述表中所了解到的信息记录下来，然后将有关当前系统某些局部的精确信息积累起来。然后将有关当前系统某些局部的精确信息积累起来。构建一个包含当前系统局部的需求表示可到达以下构建一个包含当前系统局部的需求表示可到达以下3个有个有用的目标：用的目标：消除知识鸿沟，使将来的维护人员能更好地理解所做的消除知识鸿沟，使将来的维护人员能更好地理解所做的变更。变更。收集当前系统的一些信息收集当前系统的一些信息当前系统在以前缺乏良好当前系统在以前缺乏良好的书面文档。当工程团队日后再完成其他的维护任务时，的书面文档。当工程团队日后

41、再完成其他的维护任务时，可以对这些零星分散的知识表示加以扩充，进而逐步完可以对这些零星分散的知识表示加以扩充，进而逐步完善系统文档。记录这些新发现的知识所需要增加的费用，善系统文档。记录这些新发现的知识所需要增加的费用，比起以后必须重新发现这些知识所需要的费用更少。比起以后必须重新发现这些知识所需要的费用更少。提供一个指标，说明当前的系统测试集对系统功能的覆提供一个指标，说明当前的系统测试集对系统功能的覆盖率。盖率。8.4.1.2 亲身实践一下新的需求技术亲身实践一下新的需求技术技能水平对工程的成功或失败有着至关重要的影响，技能水平对工程的成功或失败有着至关重要的影响，那么实践经验就可以减少在

42、一个零起点工程中第一那么实践经验就可以减少在一个零起点工程中第一次应用用例的风险。次应用用例的风险。我们还可以在小规模工程维护中试试其他一些技术：我们还可以在小规模工程维护中试试其他一些技术：创立数据字典创立数据字典绘制分析模型绘制分析模型指定质量属性和性能目标指定质量属性和性能目标构建用户界面和技术原型构建用户界面和技术原型审查需求规格说明审查需求规格说明根据需求编写测试用例根据需求编写测试用例制定客户验收标准制定客户验收标准 8.4.1.3 遵循跟踪链遵循跟踪链需求的跟踪数据有助于程序维护人员确定由于某一特定的需求的跟踪数据有助于程序维护人员确定由于某一特定的需求发生了变更。需求发生了变更

43、。由于许多软件修改都会引发很大的连锁反响，所以我们必由于许多软件修改都会引发很大的连锁反响，所以我们必须确保每次需求变更都要正确地传给下游工作产品，审查须确保每次需求变更都要正确地传给下游工作产品，审查就是检查这种一致性的一种好方法。就是检查这种一致性的一种好方法。4种来源的观点，也适用于维护工作：种来源的观点，也适用于维护工作：对需求进行修改或增强的作者。对需求进行修改或增强的作者。提出请求的客户或市场代表，他们能确保新的需求准确地提出请求的客户或市场代表，他们能确保新的需求准确地描述所需要的变更。描述所需要的变更。开发人员、测试人员或者其他必须以新的需求为根底来完开发人员、测试人员或者其他

44、必须以新的需求为根底来完成自己工作的人们。成自己工作的人们。其工作产品可能受这种变更影响的人们。其工作产品可能受这种变更影响的人们。外包工程的需求外包工程的需求将产品的开发承包给某个独立的公司，需要准备高质量将产品的开发承包给某个独立的公司，需要准备高质量的需求文档，因为与工程团队的直接交互可能很少。的需求文档，因为与工程团队的直接交互可能很少。需方将向供方发送一份建议请求、一份需求规格说明和需方将向供方发送一份建议请求、一份需求规格说明和一些产品验收标准，而供方那么要向需方返回完成的产一些产品验收标准，而供方那么要向需方返回完成的产品和支持文档，如以下图所示。品和支持文档，如以下图所示。外包

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