第八章 软件需求实现 周立新 博士 北京大学软件与微电子学院

课程提纲 软件需求基本理论和概念 软件需求工程过程 软件需求获取 软件需求分析 软件需求规格说明 软件需求验证 软件需求管理 软件需求实现 软件需求工程新进展 软件需求开发与需求管理工具

内容提要 需求与其他项目过程的联系 过程改进原则及周期 需求相关的风险控制 特殊软件项目(如维护、外包等)的需求实践等

8.1 需求与其他 项目过程的联系 需求是每个软件项目成功的核心所在，它支持其他技术活动和管理活动。 对需求开发方法和需求管理方法的变更会对项目的其他过程产生影响，反之亦然。 右图演示了需求和其他过程之间的某些连接，下面简要介绍一下这些过程之间的接口。

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

需求和预估 根据文本需求、图形分析模型、原型或用户界面设计来预估产品的大小。 虽然对于软件的规模没有完善的度量标准，但下面是一些常用的度量标准： 可单独测试需求的数量(Wilson 1995)。 功能点和特性点的多少(Jones 1996b)，或者将数据、功能和控制三者整合在一起的三维功能点的数量(Whitmire 1995)。 图形用户界面(GUI)元素的数量、类型和复杂度。 用于实现特定需求所需的源代码行数。 对象类的数量或者其他面向对象系统的衡量标准(Whitmire 1997)。

需求和进度安排 主要的规划失误包括: 忽略了公共(用)的项目任务，低估了所需的工作量和时间，没有考虑项目风险，没有考虑返工所需的时间，以及对自己的盲目乐观等。 有效的项目规划需要以下元素： 根据对需求的清楚理解来估计产品规模的大小。 根据历史记录了解到的开发团队的工作效率。 一张任务列表，以便完全地实现和验证每一特性或用例。 相当稳定的需求。 有效的预测和规划过程。 经验，这有助于项目经理对不可触及的因素和每一个项目所特有的因素加以调整。 注意： 不要迫于压力而许下自己 明知道不可能做到的诺言， 这是避免最后两败俱伤的 秘诀。

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

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

从需求到设计和编码 下面的动作可以使所有的项目类型都从中受益： 为子系统和组件开发一个坚固的体系结构，这一体系结构在产品改进的过程中可以保持不变。 确定需要构建的主要对象类或功能模块，定义它们的接口、职责以及与其他单元的协作。 对并行处理系统，要理解计划的执行线程或对并发进程的功能分配。 根据强内聚、低耦合和信息隐藏等这些良好的设计原则，定义每个代码单元的预期功能(McConnell 1993)。 确保设计满足所有的功能性需求，但不要包括不必要的功能。 确保设计能适应可能出现的异常条件。 确保设计能达到所陈述的性能、健壮性、可靠性和其他一些质量属性的目标。

8.1.3 从需求到测试 测试和需求工程是一种互相促进的关系。 8.1.3 从需求到测试 测试和需求工程是一种互相促进的关系。 需求是系统测试的基础，对产品的测试应该根据需求文档中所记录的产品的预期行为来进行，而不应该根据设计或编码来测试。 项目测试人员应该确定他们如何验证每一条需求，下面列出了一些可能的方法： 测试(执行软件以便发现缺陷)。 审查(检查代码，以便确保代码满足了需求)。 演示(显示产品的运作与所期望的相符)。 分析(推导在某些情况下系统应该如何运作)。 基于规格说明的测试可以运用若干测试设计策略：动作驱动、数据驱动(包括边界值分析和等价类划分)、逻辑驱动、事件驱动和状态驱动(Poston 1996)。

8.1.4 从需求到成功 使项目更成功的一种方法是，列出与特定的代码版本相对应的所有需求。 8.1.4 从需求到成功 使项目更成功的一种方法是，列出与特定的代码版本相对应的所有需求。 项目的质量保证(quality assurance，QA)小组通过对照相应的需求来执行测试，从而对每一个版本进行评估。这个项目的成功，在很大程度上得益于根据需求文档来决定何时发布产品。 软件开发项目最终的可交付工件应该是一个满足客户需要和期望的软件系统。 需求是从业务需要通向用户满意之路中必不可少的一步。 如果不以高质量的需求作为项目规划、软件设计和系统测试的基础，那么在试图发布优秀产品的过程中将浪费大量的工作。 精确的规格说明与可将产品失败的风险降至可接受程度的编码之间做出明智的选择。

8.2.1 软件过程改进的基本原则 应该牢记下面4条软件过程改进的原则(Wiegers 1996a)： 1.过程改进应该是不断演化的、连续的、周期性的 不要期望一次就能改进全部过程，要知道在第1次尝试变更时，可能无法解决所有问题。 2.只有人们和组织具有变更的动机时才可能实施变更 下面列出了一些典型的问题，也许能为需求过程的变更提供驱动力： 项目超出了最后期限，原因是需求比预期的扩展了很多，也复杂了很多。 开发人员频繁加班，原因是直到开发后期才发现了引起误解的需求和表达不明确的需求。 系统测试工作前功尽弃，原因是测试人员并没有弄清楚产品应该做什么。 虽然正确的功能都实现了，但是用户不满意，这是由于性能不好、易使用性差或存在其他质量缺陷。 维护费用很高，因为客户的对产品的许多增强要求没有在需求获取阶段确定下来。 开发组织名誉受损，因为客户不接受交付的软件。 3.过程变更要有的放矢 在开始运用更好的过程之前，一定要明确变更的目标是什么(Potter and Sakry 2002)。 4.将改进活动视作小型项目 项目的总体计划应该包括过程改进的资源和任务。与所有项目一样，改进项目也要执行计划、跟踪、测量和报告，只是规模相应地缩小了。

8.2.2 过程改进周期 右图是一个有效的过程改进周期。 8.2.2 过程改进周期 右图是一个有效的过程改进周期。 这一方法反映了您在执行下一个任务之前先清楚自己所处位置的重要性；反映了绘制过程路线图的必要性，以及以往的经验在持续的过程改进中的重要性。

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

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

8.2.2.3 建立、实验并实现新过程 实现活动计划意味着开发一些过程，并相信这些过程比当前的工作方式会带来更好的结果，但不要期望新的过程第1次试用就很完美。 请牢记下面这些关于指导过程实验的建议： 选择实验参与者，他们将尝试新方法并提供有用的反馈信息。 使改进过程的结果容易解释。 确定需要了解实验情况和实验原因的有关涉众。 考虑在不同的项目中实验新过程的不同部分，这样可以使更多的人尝试新方法，因此提高了了解程度，增加了反馈信息，更易于大家接受。 询问实验参与者。

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

8.3.1 软件风险管理基本原理 除了与项目范围和需求有关的风险外，项目还面临着许多其他风险。 对外部实体的依赖就是一种常见的风险来源。 8.3.1 软件风险管理基本原理 除了与项目范围和需求有关的风险外，项目还面临着许多其他风险。 对外部实体的依赖就是一种常见的风险来源。 项目管理一直面临各种风险的挑战：评估不准确、管理人员拒绝开发人员的准确评估、对项目状态不了解以及进行了人员调整等原因所引起的风险。 技术风险威胁着高度复杂或很前沿的开发项目。 知识的缺乏是风险的另一种来源，另外还有参与者对所用的技术或项目应用领域经验不足。经常变更的或强制执行的一些政府规定可能会使最好的项目规划彻底作废。

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

8.3.1.2 编写项目风险文档 只是认识到项目所面临的风险是远远不够的，我们还必须以某种方式对风险进行管理，以便在整个项目开发过程中可以将风险问题和状态传达给项目的涉众。 右图展示了一个模板，用于对单个风险编写文档。

8.3.1.3 制定风险管理计划 对于小型项目，可以把控制风险的计划包括在软件项目管理计划内。 8.3.1.3 制定风险管理计划 对于小型项目，可以把控制风险的计划包括在软件项目管理计划内。 但对一个大型项目，则应该编写一个单独的风险管理计划，详细说明打算采用哪些方法来识别、评估、编档和跟踪风险。这一计划还应该包括风险管理活动的角色和职责。 风险管理计划模板可以从http://www.processimpact.com/goodies.shtml获得。 要建立起周期性进行风险监控的措施。 注意： 不要想当然地以为， 在识别出了风险并采 取了降低风险的相应 活动之后，风险就会 处于您的控制之下。 接下来还要实行风险 管理活动。

8.3.2 与需求相关的风险 下面介绍的这些风险因素，是按照需求工程的分支过程组织的，即需求获取、需求分析、编写需求规格说明、需求确认和需求管理过程。 推荐的方法可以减小风险发生的可能性或风险发生后给项目造成的影响。

8.3.2.1 需求获取 产品前景和项目范围 需求开发所需的时间 需求规格说明的完整性和正确性 创新产品的需求 定义非功能需求 8.3.2.1 需求获取 产品前景和项目范围 应该在项目早期，编写一份包括业务需求在内的前景和范围文档，并将它作为添加新需求和修改现有需求的指导。 需求开发所需的时间 将每个项目中需求开发所耗费的实际工作量记录下来，这样就可以判断出需求开发是否充分，并可以改进未来项目的工作计划。 需求规格说明的完整性和正确性 为了确保需求是客户真正需要的，应该以用户任务为中心，应用用例技术来获取需求。 创新产品的需求 对某类产品中的第1个产品，不太容易把握市场对产品的反映。 定义非功能需求 由于我们一般都会强调产品的功能，所以很容易忽略产品的非功能性需求。

8.3.2.1 需求获取 客户对产品需求意见一致 未加说明的需求 把已有的产品作为需求基线来源 根据需要提出解决方案 8.3.2.1 需求获取 客户对产品需求意见一致 确定那些主要的客户，并采用产品代言人的方法，保证有足够的客户代表的积极参与。 未加说明的需求 客户经常会有一些隐含的期望要求，但并未以文档的方式说明出来。尽量识别客户可能做出的任何假设。 把已有的产品作为需求基线来源 将通过逆向工程发现的需求编写成文档，让客户评审这些需求，以确保其正确性和相关性。 根据需要提出解决方案 分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图。

8.3.2.2 需求分析 设定需求优先级 技术上难以实现的特性 不熟悉的技术、方法、语言、工具或硬件 8.3.2.2 需求分析 设定需求优先级 要确保对每一个功能需求、特性或用例都设定了优先级，并安排在一个特定的系统版本或迭代中实现它们。 技术上难以实现的特性 采用项目状态跟踪来监控落后于实现计划的需求，并尽早采取纠正措施。 不熟悉的技术、方法、语言、工具或硬件 留出足够的时间用于从错误中学习经验、实验及制作原型。

8.3.2.3 编写需求规格说明 需求理解 尽管问题待确定但迫于时间压力而继续向前 具有二义性的术语 需求中包括了设计 8.3.2.3 编写需求规格说明 需求理解 开发人员和客户对需求的不同理解会导致彼此间的期望差距，并最终导致交付的产品无法满足客户的需要。 尽管问题待确定但迫于时间压力而继续向前 在软件需求规格说明中，将需要进一步研究的地方标上TBD(to be determined，待确定)，不失为一个好主意。 具有二义性的术语 对于不同的读者可能会有不同解释的业务术语或技术术语，应该创建一个术语表对这些术语进行定义。 需求中包括了设计 软件需求规格说明中所包含的设计对开发人员做出有效选择造成了不必要的限制，会妨碍他们发挥创造性设计出最佳方案。

8.3.2.4 需求确认 未经确认的需求 审查熟练程度 软件需求规格说明会令人望而生畏，在开发过程早期编写测试用例的想法就是基于这一点。 8.3.2.4 需求确认 未经确认的需求 软件需求规格说明会令人望而生畏，在开发过程早期编写测试用例的想法就是基于这一点。 审查熟练程度 要对参与需求文档审查的所有团队成员进行培训，请组织内部有经验的审查人员或外界的咨询顾问来评述早先的审查。

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

8.3.3 风险管理是我们的好帮手 周期性地进行风险跟踪可以使项目经理了解风险对项目的威胁，没有得到有效控制的风险应该上报高层管理人员，他们可能开始采取一些纠正措施，也可能不管风险，依旧按照原来的业务决策思路进行。 即使不能控制项目可能遇到的所有风险，风险管理也能帮助我们看清形势，做出合理的决策。

8.4 特殊软件项目的需求实践 一般所讲述的需求开发，是针对一个新软件或系统开发项目的情况，这种项目有时也称为零起点项目(green-field project)。 大多数组织的主要精力集中于维护现存的遗留系统，或者为已有的商业产品构建新的版本；其他组织也很少是从零开始构建一个新系统，而是对商用现货(off-the-shelf，COTS)产品进行集成、定制和扩充，以满足自己的需要。 31

8.4.1 维护项目的需求 维护是指对当前运行的项目进行修改，有时也称为继续工程(continuing engineering)或后续开发(ongoing development)。 程序维护的任务主要是纠正缺陷、为现有系统添加新功能或新报表，以及对功能进行修改以便遵循修订后的业务规则。

8.4.1.1 开始捕获信息 缺少精确的需求文档，那么维护人员就必须进行逆向工程，通过代码来理解系统，我将此看作是软件考古学(software archaeology)。 为了能够从逆向工程中获得最大的收益，考古探险队应该将通过需求和设计描述表中所了解到的信息记录下来，然后将有关当前系统某些部分的精确信息积累起来。 构建一个包含当前系统部分的需求表示可达到以下3个有用的目标： 消除知识鸿沟，使将来的维护人员能更好地理解所做的变更。 收集当前系统的一些信息——当前系统在以前缺乏良好的书面文档。当项目团队日后再完成其他的维护任务时，可以对这些零星分散的知识表示加以扩充，进而逐步完善系统文档。记录这些新发现的知识所需要增加的费用，比起以后必须重新发现这些知识所需要的费用更少。 提供一个指标，表明当前的系统测试集对系统功能的覆盖率。

8.4.1.2 亲身实践一下新的需求技术 技能水平对项目的成功或失败有着至关重要的影响，那么实践经验就可以减少在一个零起点项目中第一次应用用例的风险。 我们还可以在小规模项目维护中试试其他一些技术： 创建数据字典 绘制分析模型 指定质量属性和性能目标 构建用户界面和技术原型 审查需求规格说明 根据需求编写测试用例 制定客户验收标准

8.4.1.3 遵循跟踪链 需求的跟踪数据有助于程序维护人员确定由于某一特定的需求发生了变更。 8.4.1.3 遵循跟踪链 需求的跟踪数据有助于程序维护人员确定由于某一特定的需求发生了变更。 由于许多软件修改都会引发很大的连锁反应，所以我们必须确保每次需求变更都要正确地传给下游工作产品，审查就是检查这种一致性的一种好方法。 4种来源的观点，也适用于维护工作： 对需求进行修改或增强的作者。 提出请求的客户或市场代表，他们能确保新的需求准确地描述所需要的变更。 开发人员、测试人员或者其他必须以新的需求为基础来完成自己工作的人们。 其工作产品可能受这种变更影响的人们。

8.4.2 外包项目的需求 将产品的开发承包给某个独立的公司，需要准备高质量的需求文档，因为与工程团队的直接交互可能很少。 8.4.2 外包项目的需求 将产品的开发承包给某个独立的公司，需要准备高质量的需求文档，因为与工程团队的直接交互可能很少。 需方将向供方发送一份建议请求、一份需求规格说明和一些产品验收标准，而供方则要向需方返回完成的产品和支持文档，如下图所示。

8.4.2 外包项目的需求 对外包项目准备需求文档时，要牢记以下几点建议： 提供细节。 避免二义性。 安排与承包方的接触点。 8.4.2 外包项目的需求 对外包项目准备需求文档时，要牢记以下几点建议： 提供细节。 避免二义性。 安排与承包方的接触点。 定义双方都能接受的变更控制过程。 为需求的多次迭代和评审预留时间。 制定验收标准。

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