第08讲-软件需求实现

1、2021/3/261第八章第八章 软件需求实现软件需求实现2021/3/262课程提纲课程提纲1.1.软件需求基本理论和概念软件需求基本理论和概念 2.2.软件需求工程过程软件需求工程过程 3.3.软件需求获取软件需求获取 4.4.软件需求分析软件需求分析 5.5.软件需求规格说明软件需求规格说明 6.6.软件需求验证软件需求验证 7.7.软件需求管理软件需求管理 8.8.软件需求实现软件需求实现 9.9.软件需求工程新进展软件需求工程新进展 10.10. 软件需求开发与需求管理工具软件需求开发与需求管理工具2021/3/263内容提要需求与其他项目过程的需求与其他项目过程的联系联系过程改进原

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

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

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

5、试需求的数量可单独测试需求的数量(Wilson 1995)。 功能点和特性点的多少功能点和特性点的多少(Jones 1996b),或者将数据、或者将数据、功能和控制三者整合在一起的三维功能点的数量功能和控制三者整合在一起的三维功能点的数量(Whitmire 1995)。 图形用户界面图形用户界面(GUI)元素的数量、类型和复杂度。元素的数量、类型和复杂度。 用于实现特定需求所需的源代码行数。用于实现特定需求所需的源代码行数。 对象类的数量或者其他面向对象系统的衡量标准对象类的数量或者其他面向对象系统的衡量标准(Whitmire 1997)。2021/3/267需求和进度安排需求和进度安排 主要

6、的规划失误包括主要的规划失误包括: 忽略了公共忽略了公共(用用)的的项目任务项目任务,低估了所需的工作量和时间低估了所需的工作量和时间,没没有考虑项目风险有考虑项目风险,没有考虑返工所需的时没有考虑返工所需的时间间,以及对自己的盲目乐观等。以及对自己的盲目乐观等。 有效的项目规划需要以下元素有效的项目规划需要以下元素: 根据对需求的清楚理解来估计产品规模的大小。根据对需求的清楚理解来估计产品规模的大小。 根据历史记录了解到的开发团队的工作效率。根据历史记录了解到的开发团队的工作效率。 一张任务列表一张任务列表,以便完全地实现和验证每一特以便完全地实现和验证每一特性或用例。性或用例。 相当稳定的

7、需求。相当稳定的需求。 有效的预测和规划过程。有效的预测和规划过程。 经验经验,这有助于项目经理对不可触及的因素和这有助于项目经理对不可触及的因素和每一个项目所特有的因素加以调整。每一个项目所特有的因素加以调整。注意:不要迫于压力而许下自己明知道不可能做到的诺言,这是避免最后两败俱伤的秘诀。 2021/3/268 8.1.2 从需求到设计和编码从需求到设计和编码 需求和设计之间存在差别需求和设计之间存在差别, 要防止规格说要防止规格说明造成实现上的倾向性明造成实现上的倾向性,除非是有迫不得已除非是有迫不得已的原因要有意地对设计加以约束。的原因要有意地对设计加以约束。 需求规格说明几乎总是包括某

8、些设计信息需求规格说明几乎总是包括某些设计信息,让设计人员或开发人员参与需求审查让设计人员或开发人员参与需求审查,这样这样可以确保需求为后续的设计打下坚实的基可以确保需求为后续的设计打下坚实的基础。础。 产品的需求、质量属性和用户特点可以决产品的需求、质量属性和用户特点可以决定产品体系结构。定产品体系结构。2021/3/269从需求到设计和编码从需求到设计和编码 对于同时包括软件组件和硬件组件的系统对于同时包括软件组件和硬件组件的系统,以及只包括软件的复杂系统以及只包括软件的复杂系统,体系结构就显体系结构就显得尤其关键。得尤其关键。 将系统功能分配给子系统或组件必须采用自将系统功能分配给子系统

9、或组件必须采用自顶向下的方法顶向下的方法(Hooks和和Farry 2001)。 在开始实现产品之前在开始实现产品之前,虽然不需要为整个产虽然不需要为整个产品开发完整的、详细的设计品开发完整的、详细的设计,但是但是,应该先对应该先对每一个组件进行设计每一个组件进行设计,然后再对其进行编码。然后再对其进行编码。2021/3/2610从需求到设计和编码从需求到设计和编码 下面的动作可以使所有的项目类型都从中受益下面的动作可以使所有的项目类型都从中受益: 为子系统和组件开发一个坚固的体系结构为子系统和组件开发一个坚固的体系结构,这一体系结构在产这一体系结构在产品改进的过程中可以保持不变。品改进的过程

10、中可以保持不变。 确定需要构建的主要对象类或功能模块确定需要构建的主要对象类或功能模块,定义它们的接口、职定义它们的接口、职责以及与其他单元的协作。责以及与其他单元的协作。 对并行处理系统对并行处理系统,要理解计划的执行线程或对并发进程的功能要理解计划的执行线程或对并发进程的功能分配。分配。 根据强内聚、低耦合和信息隐藏等这些良好的设计原则根据强内聚、低耦合和信息隐藏等这些良好的设计原则,定义定义每个代码单元的预期功能每个代码单元的预期功能(McConnell 1993)。 确保设计满足所有的功能性需求确保设计满足所有的功能性需求,但不要包括不必要的功能。但不要包括不必要的功能。 确保设计能适

11、应可能出现的异常条件。确保设计能适应可能出现的异常条件。 确保设计能达到所陈述的性能、健壮性、可靠性和其他一些确保设计能达到所陈述的性能、健壮性、可靠性和其他一些质量属性的目标。质量属性的目标。2021/3/2611 8.1.3 从需求到测试从需求到测试 测试和需求工程是一种互相促进的关系。测试和需求工程是一种互相促进的关系。 需求是系统测试的基础需求是系统测试的基础,对产品的测试应该根据需求文档中对产品的测试应该根据需求文档中所记录的产品的预期行为来进行所记录的产品的预期行为来进行,而不应该根据设计或编码而不应该根据设计或编码来测试。来测试。 项目测试人员应该确定他们如何验证每一条需求项目测

12、试人员应该确定他们如何验证每一条需求,下面列出下面列出了一些可能的方法了一些可能的方法: 测试测试(执行软件以便发现缺陷执行软件以便发现缺陷)。 审查审查(检查代码检查代码,以便确保代码满足了需求以便确保代码满足了需求)。 演示演示(显示产品的运作与所期望的相符显示产品的运作与所期望的相符)。 分析分析(推导在某些情况下系统应该如何运作推导在某些情况下系统应该如何运作)。 基于规格说明的测试可以运用若干测试设计策略基于规格说明的测试可以运用若干测试设计策略:动作驱动、动作驱动、数据驱动数据驱动(包括边界值分析和等价类划分包括边界值分析和等价类划分)、逻辑驱动、事、逻辑驱动、事件驱动和状态驱动件

13、驱动和状态驱动(Poston 1996)。2021/3/2612 8.1.4 从需求到成功从需求到成功 使项目更成功的一种方法是使项目更成功的一种方法是,列出与特定的代码版本相对列出与特定的代码版本相对应的所有需求。应的所有需求。 项目的质量保证项目的质量保证(quality assurance,QA)小组通过对照相小组通过对照相应的需求来执行测试应的需求来执行测试,从而对每一个版本进行评估。这个从而对每一个版本进行评估。这个项目的成功项目的成功,在很大程度上得益于根据需求文档来决定何在很大程度上得益于根据需求文档来决定何时发布产品。时发布产品。 软件开发项目最终的可交付工件应该是一个满足客户

14、需要软件开发项目最终的可交付工件应该是一个满足客户需要和期望的软件系统。和期望的软件系统。 需求是从业务需要通向用户满意之路中必不可少的一步。需求是从业务需要通向用户满意之路中必不可少的一步。 如果不以高质量的需求作为项目规划、软件设计和系统测如果不以高质量的需求作为项目规划、软件设计和系统测试的基础试的基础,那么在试图发布优秀产品的过程中将浪费大量那么在试图发布优秀产品的过程中将浪费大量的工作。的工作。 精确的规格说明与可将产品失败的风险降至可接受程度的精确的规格说明与可将产品失败的风险降至可接受程度的编码之间做出明智的选择。编码之间做出明智的选择。2021/3/2613 8.2.1 软件过

15、程改进的基本原则软件过程改进的基本原则 应该牢记下面应该牢记下面4条软件过程改进的原则条软件过程改进的原则(Wiegers 1996a): 1.过程改进应该是不断演化的、连续的、周期性的过程改进应该是不断演化的、连续的、周期性的 不要期望一次就能改进全部过程不要期望一次就能改进全部过程,要知道在第要知道在第1次尝试变更时次尝试变更时,可能无法解决可能无法解决所有问题。所有问题。 2.只有人们和组织具有变更的动机时才可能实施变更只有人们和组织具有变更的动机时才可能实施变更 下面列出了一些典型的问题下面列出了一些典型的问题,也许能为需求过程的变更提供驱动力也许能为需求过程的变更提供驱动力: 项目超

16、出了最后期限项目超出了最后期限,原因是需求比预期的扩展了很多原因是需求比预期的扩展了很多,也复杂了很多。也复杂了很多。 开发人员频繁加班开发人员频繁加班,原因是直到开发后期才发现了引起误解的需求和表达不明确的需原因是直到开发后期才发现了引起误解的需求和表达不明确的需求。求。 系统测试工作前功尽弃系统测试工作前功尽弃,原因是测试人员并没有弄清楚产品应该做什么。原因是测试人员并没有弄清楚产品应该做什么。 虽然正确的功能都实现了虽然正确的功能都实现了,但是用户不满意但是用户不满意,这是由于性能不好、易使用性差或存在其这是由于性能不好、易使用性差或存在其他质量缺陷。他质量缺陷。 维护费用很高维护费用很

17、高,因为客户的对产品的许多增强要求没有在需求获取阶段确定下来。因为客户的对产品的许多增强要求没有在需求获取阶段确定下来。 开发组织名誉受损开发组织名誉受损,因为客户不接受交付的软件。因为客户不接受交付的软件。 3.过程变更要有的放矢过程变更要有的放矢 在开始运用更好的过程之前在开始运用更好的过程之前,一定要明确变更的目标是什么一定要明确变更的目标是什么(Potter and Sakry 2002)。 4.将改进活动视作小型项目将改进活动视作小型项目 项目的总体计划应该包括过程改进的资源和任务。与所有项目一样项目的总体计划应该包括过程改进的资源和任务。与所有项目一样,改进项目也改进项目也要执行计

18、划、跟踪、测量和报告要执行计划、跟踪、测量和报告,只是规模相应地缩小了。只是规模相应地缩小了。2021/3/2614 8.2.2 过程改进周期过程改进周期 右图是一个有效右图是一个有效的过程改进周期。的过程改进周期。 这一方法反映了这一方法反映了您在执行下一个您在执行下一个任务之前先清楚任务之前先清楚自己所处位置的自己所处位置的重要性重要性;反映了绘反映了绘制过程路线图的制过程路线图的必要性必要性,以及以往以及以往的经验在持续的的经验在持续的过程改进中的重过程改进中的重要性。要性。 评估当前方法 发现和建议 新过程是否达 到了预期目标 规划改进活动 活动计划 建立，实验 并实现新过程 新过程；

19、实验结果；初次结果 计划下一个 改进周期 活动规划过程 进行得如何？ 这一过程 进行得如何？ 评估结果 2021/3/2615 8.2.2.1 评估当前用的方法评估当前用的方法 所有改进活动的第所有改进活动的第1步都是评估组织当前所使用步都是评估组织当前所使用的方法的方法,找出这些方法的优点和缺陷。找出这些方法的优点和缺陷。 设计结构化问卷表是一种更系统的方法设计结构化问卷表是一种更系统的方法,它能够以它能够以较低的费用对当前过程进行评估。与团队成员进较低的费用对当前过程进行评估。与团队成员进行面谈和讨论行面谈和讨论,可以更准确更全面地了解当前的过可以更准确更全面地了解当前的过程。程。2021

20、/3/2616 8.2.2.2 规划改进活动规划改进活动 战略性计划描述了组织的总体软件过程改进战略性计划描述了组织的总体软件过程改进,战术战术性的活动计划则描述需要改进的专门领域。性的活动计划则描述需要改进的专门领域。 需求管理改进计划需求管理改进计划,它包括下面这些活动条目它包括下面这些活动条目: 1.起草一个需求变更控制过程草案。起草一个需求变更控制过程草案。 2.评审并修订变更控制过程。评审并修订变更控制过程。 3.在项目在项目A中试验变更控制过程。中试验变更控制过程。 4.根据试验的反馈信息根据试验的反馈信息,修订变更控制过程。修订变更控制过程。 5.评估问题跟踪工具评估问题跟踪工具

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

22、牢记下面这些关于指导过程实验的建议: 选择实验参与者选择实验参与者,他们将尝试新方法并提供有用的反他们将尝试新方法并提供有用的反馈信息。馈信息。 使改进过程的结果容易解释。使改进过程的结果容易解释。 确定需要了解实验情况和实验原因的有关涉众。确定需要了解实验情况和实验原因的有关涉众。 考虑在不同的项目中实验新过程的不同部分考虑在不同的项目中实验新过程的不同部分,这样可这样可以使更多的人尝试新方法以使更多的人尝试新方法,因此提高了了解程度因此提高了了解程度,增加增加了反馈信息了反馈信息,更易于大家接受。更易于大家接受。 询问实验参与者。询问实验参与者。 2021/3/2618 8.2.2.4 评

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

24、一个人一个人,参与者是否理解并成功地应用了新过程参与者是否理解并成功地应用了新过程,下次工作中是否需要有所变更等。下次工作中是否需要有所变更等。 其中关键的一步是其中关键的一步是,评估新实现的过程是否带来了评估新实现的过程是否带来了期望的结果。期望的结果。2021/3/2619 8.3.1 软件风险管理基本原理软件风险管理基本原理 除了与项目范围和需求有关的风险外除了与项目范围和需求有关的风险外,项目还面临着项目还面临着许多其他风险。许多其他风险。 对外部实体的依赖就是一种常见的风险来源。对外部实体的依赖就是一种常见的风险来源。 项目管理一直面临各种风险的挑战项目管理一直面临各种风险的挑战:评

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

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

27、ment)是一个对项目进行检查以确定潜在风险领是一个对项目进行检查以确定潜在风险领域的过程。域的过程。风险避免风险避免(risk avoidance)是处理风险的一种方法是处理风险的一种方法,也就是尽量不要做也就是尽量不要做冒险的事冒险的事。 风险管理 评估 避免 控制 识别 分析 优先级 管理计划 解决方案 监控 2021/3/2621 8.3.1.2 编写项目风险文档编写项目风险文档 只是认识到项目所面只是认识到项目所面临的风险是远远不够临的风险是远远不够的的,我们还必须以某种我们还必须以某种方式对风险进行管理方式对风险进行管理,以便在整个项目开发以便在整个项目开发过程中可以将风险问过程中

28、可以将风险问题和状态传达给项目题和状态传达给项目的涉众。的涉众。 右图展示了一个模板右图展示了一个模板,用于对单个风险编写用于对单个风险编写文档。文档。 风 险 条 目 跟 踪 模 板 I D 号 ： 确 定 日 期 ： 撤 消 日 期 ： 描 述 ： 可 能 性 ： 影 响 ： 危 害 值 ： 降 低 风 险 计 划 ： 负 责 人 ： 截 止 日 期 ： 2021/3/2622 8.3.1.3 制定风险管理计划制定风险管理计划 对于小型项目对于小型项目,可以把控制风险的计划可以把控制风险的计划包括在软件项目管理计划内。包括在软件项目管理计划内。 但对一个大型项目但对一个大型项目,则应该编写

29、一个单则应该编写一个单独的风险管理计划独的风险管理计划,详细说明打算采用详细说明打算采用哪些方法来识别、评估、编档和跟踪哪些方法来识别、评估、编档和跟踪风险。这一计划还应该包括风险管理风险。这一计划还应该包括风险管理活动的角色和职责。活动的角色和职责。 风险管理计划模板可以从获得。风险管理计划模板可以从获得。 要建立起周期性进行风险监控的措施。要建立起周期性进行风险监控的措施。 注意:不要想当然地以为,在识别出了风险并采取了降低风险的相应活动之后,风险就会处于您的控制之下。接下来还要实行风险管理活动。2021/3/2623 8.3.2 与需求相关的风险与需求相关的风险 下面介绍的这些风险因素下

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

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

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

33、做出的任何假设。方式说明出来。尽量识别客户可能做出的任何假设。 把已有的产品作为需求基线来源把已有的产品作为需求基线来源 将通过逆向工程发现的需求编写成文档将通过逆向工程发现的需求编写成文档,让客户评审让客户评审这些需求这些需求,以确保其正确性和相关性。以确保其正确性和相关性。 根据需要提出解决方案根据需要提出解决方案 分析人员必须提炼出隐藏在客户提出的解决方案背分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图。后的真正意图。2021/3/2626 8.3.2.2 需求分析需求分析 设定需求优先级设定需求优先级 要确保对每一个功能需求、特性或用例都设定要确保对每一个功能需求、特性或用例

34、都设定了优先级了优先级,并安排在一个特定的系统版本或迭代并安排在一个特定的系统版本或迭代中实现它们。中实现它们。 技术上难以实现的特性技术上难以实现的特性 采用项目状态跟踪来监控落后于实现计划的需采用项目状态跟踪来监控落后于实现计划的需求求,并尽早采取纠正措施。并尽早采取纠正措施。 不熟悉的技术、方法、语言、工具或硬件不熟悉的技术、方法、语言、工具或硬件 留出足够的时间用于从错误中学习经验、实验留出足够的时间用于从错误中学习经验、实验及制作原型。及制作原型。2021/3/2627 8.3.2.3 编写需求规格说明编写需求规格说明 需求理解需求理解 开发人员和客户对需求的不同理解会导致彼此间的开

35、发人员和客户对需求的不同理解会导致彼此间的期望差距期望差距,并最终导致交付的产品无法满足客户的需并最终导致交付的产品无法满足客户的需要。要。 尽管问题待确定但迫于时间压力而继续向前尽管问题待确定但迫于时间压力而继续向前 在软件需求规格说明中在软件需求规格说明中,将需要进一步研究的地方标将需要进一步研究的地方标上上TBD(to be determined,待确定待确定),不失为一个好主不失为一个好主意。意。 具有二义性的术语具有二义性的术语 对于不同的读者可能会有不同解释的业务术语或技对于不同的读者可能会有不同解释的业务术语或技术术语术术语,应该创建一个术语表对这些术语进行定义。应该创建一个术语

36、表对这些术语进行定义。 需求中包括了设计需求中包括了设计 软件需求规格说明中所包含的设计对开发人员做出软件需求规格说明中所包含的设计对开发人员做出有效选择造成了不必要的限制有效选择造成了不必要的限制,会妨碍他们发挥创造会妨碍他们发挥创造性设计出最佳方案。性设计出最佳方案。2021/3/2628 8.3.2.4 需求确认需求确认 未经确认的需求未经确认的需求 软件需求规格说明会令人望而生畏软件需求规格说明会令人望而生畏,在在开发过程早期编写测试用例的想法就开发过程早期编写测试用例的想法就是基于这一点。是基于这一点。 审查熟练程度审查熟练程度 要对参与需求文档审查的所有团队成要对参与需求文档审查的

37、所有团队成员进行培训员进行培训,请组织内部有经验的审查请组织内部有经验的审查人员或外界的咨询顾问来评述早先的人员或外界的咨询顾问来评述早先的审查。审查。 2021/3/2629 8.3.2.5 需求管理需求管理 变更需求变更需求 将前景和范围文档作为批准需求变更的参照将前景和范围文档作为批准需求变更的参照,可以减可以减少范围蔓延。少范围蔓延。 需求变更过程需求变更过程 与需求变更的处理方式相关的风险包括与需求变更的处理方式相关的风险包括,缺少已定义缺少已定义的变更过程的变更过程,采用无效的变更机制采用无效的变更机制,以及不遵循制定的以及不遵循制定的过程来做出变更。过程来做出变更。 未实现的需求

38、未实现的需求 需求跟踪矩阵有助于在设计、构造或测试期间避免需求跟踪矩阵有助于在设计、构造或测试期间避免遗漏任何需求。遗漏任何需求。 扩大项目范围扩大项目范围 如果最初的需求定义不够好如果最初的需求定义不够好,那么进一步定义需求就那么进一步定义需求就会扩大项目的范围。会扩大项目的范围。2021/3/2630 8.3.3 风险管理是我们的好帮手风险管理是我们的好帮手 周期性地进行风险跟踪可以使项目经理周期性地进行风险跟踪可以使项目经理了解风险对项目的威胁了解风险对项目的威胁,没有得到有效控没有得到有效控制的风险应该上报高层管理人员制的风险应该上报高层管理人员,他们可他们可能开始采取一些纠正措施能开

39、始采取一些纠正措施,也可能不管风也可能不管风险险,依旧按照原来的业务决策思路进行。依旧按照原来的业务决策思路进行。 即使不能控制项目可能遇到的所有风险即使不能控制项目可能遇到的所有风险,风险管理也能帮助我们看清形势风险管理也能帮助我们看清形势,做出合做出合理的决策。理的决策。2021/3/2631318.4 特殊软件项目的需求实践特殊软件项目的需求实践 一般所讲述的需求开发一般所讲述的需求开发,是针对一个新软件或是针对一个新软件或系统开发项目的情况系统开发项目的情况,这种项目有时也称为零这种项目有时也称为零起点项目起点项目(green-field project)。 大多数组织的主要精力集中于

40、维护现存的遗大多数组织的主要精力集中于维护现存的遗留系统留系统,或者为已有的商业产品构建新的版本或者为已有的商业产品构建新的版本;其他组织也很少是从零开始构建一个新系统其他组织也很少是从零开始构建一个新系统,而是对商用现货而是对商用现货(off-the-shelf,COTS)产品进产品进行集成、定制和扩充行集成、定制和扩充,以满足自己的需要。以满足自己的需要。2021/3/2632 8.4.1 维护项目的需求维护项目的需求 维护是指对当前运行的项目进行修改维护是指对当前运行的项目进行修改,有时也称为继续工程有时也称为继续工程(continuing engineering)或后续开发或后续开发(

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

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

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