软件工程3

null第二章 需求工程第二章 需求工程 软件开发过程中遇到的许多问，都是由于需求获取和需求文档编写过程中的失误造成的。 例如：信息收集不全、功能不明确、交流不充分、文档描述不准确、需求发生变化等。 据统计，软件项目40%—60%的问题都是在需求阶段埋下的“祸根”。 3.1 需求工程的概念3.1 需求工程的概念需求工程包括：需求开发和需求管理。 需求开发：需求的获取、分析、说明和验证。 需求管理：需求开发结果的控制、跟踪和管理。 需求工程的任务：确定软件项目的目标和范围。调查使用者的要求，分析软件必须做什么，编写需求规格说明书等它相关文档，并进行必要的需求审查。除此之外，还包括需求变更控制，需求风险控制，需求版本控制等对需求的管理工作。3.1.1 需求分类3.1.1 需求分类实际项目中，需求可分解为四个层次： 业务需求、用户需求、功能需求和非功能需求1.业务需求1.业务需求反映组织机构或客户对软件高层次的目标要求。 这项需求是用户高层领导机构决定的，它确定了系统的目标、规模和范围。 业务需求一般在进行需求分析之前就应该确定，需求分析阶段要以此为参照制定需求调研计划、确定用户核心需求和软件功能需求。 业务需求通常比较简洁，大约三至五页纸就可以描述清楚，也可以将它直接作为需求规格说明书中的一章。2.用户需求2.用户需求用户使用该软件要完成的任务。 这部分需求应该充分调研具体的业务部门，详细了解最终用户的工作过程、所涉及的信息、当前系统的工作情况、与其它系统的接口等等。 用户需求是最重要的需求，也是出现问题最多的。3.功能需求3.功能需求定义了软件开发人员必须实现的软件功能。 用户从他们完成任务的角度对软件提出了用户需求，这些需求通常是凌乱的、非系统化的、有冗余的，开发人员不能以此编写程序。 软件分析人员要充分理解用户需求，将用户需求整理成软件功能需求。开发人员根据功能需求进行软件设计和编码 4.非功能需求4.非功能需求是对功能需求的补充。 可以分为两类： 一类是对用户来说可能很重要的属性，包括：有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性。 另一类是对开发者来说很重要的质量属性，包括：可维护性、可移植性、可重用性、可测试性。需求分类的例子：一个字词拼写检查程序需求分类的例子：一个字词拼写检查程序业务需求是：能够有效地检查和纠正文档中的字词拼写错误。 用户需求是：找出文档中的拼写错误，并且对每个错误提供一个更正建议表，更正建议表中列出可以替换的字词。 功能需求是：软件提供一个打开文档对话框，对打开的文档进行字词检查，发现拼写错误以高亮度提示出错的字词，对错误字词显示更正建议对话框，其中列出可选的字词，以及替换范围选择。 3.1.2 需求工程主要活动3.1.2 需求工程主要活动需求开发： 获得需求 分析需求 编写需求规格说明书 审查需求 需求管理： 需求变更控制 需求版本控制 需求跟踪 需求状态跟踪控制3.1.3 高质量需求的特征3.1.3 高质量需求的特征1.完整性： 首先是不能遗漏任何必要的需求。丢失需求经常发生，并且危害极大，而且所丢失的需求通常不容易被发现。为了避免丢失需求，建议特别关注需求获取的方法，分析员应该注重用户的需求而不是系统的功能，这也是我们将需求分为用户需求和功能需求的原因之一。 需求完整性的第二层含义是每一项需求所要完成的任务必须要描述清楚、完整。2.正确性2.正确性每项需求都必须准确地反映用户要完成的任务。判断需求正确性有两种途径： 由用户来判断。在进行需求调研时系统分析员记录了每项需求的来源和相关的详细信息，系统分析人员根据调研的结果使用自然语言和流程图或用例图等多种方式描述需求。在需求评审时用户和开发人员从不同角度，检查需求的正确性。 系统分析人员应该检查每项需求是否超出了业务需求所定义的软件范围。3.可行性3.可行性每一个成功的软件系统其解决都是可行的。 技术可行性 经济可行性 操作可行性4.必要性4.必要性每项需求都应该是客户所需要，开发人员不要自作主张添加需求。 检查需求必要性的方法是将每项需求回溯至用户的某项需求上 。5.划分优先级5.划分优先级为每一项需求按照重要程度分配一个优先级，这有助于项目管理者解决冲突、安排阶段性交付，在必要时做出功能取舍，以最少的费用获得软件产品的最大功能。 在开发产品时，可以先实现优先级高的核心需求，将低优先级的需求放在今后的版本中。 6.无二义性6.无二义性不同的人员对需求的理解应该是一致的。一般情况下，描述需求都是用自然语言，因此很容易引起需求理解的二义性，如果需求使用简洁明了的语言描述对大家理解需求是有益的。 使用多种不同的方式从多个角度描述同一需求对于发现需求二义性也是有帮助的。避免二义性的另一个有效方法是对需求文档的正规检查，包括编写测试用例，开发原型。7.可验证性7.可验证性每项需求都是应该可验证的。 系统分析员在需求分析时就要考虑每项需求的可验证性问题，为需求设计测试用例或其它的验证方法，如果需求不可验证，则要认真检查需求的有效性和真实性，一份前后矛盾、有二义性的需求是无法验证的。3.1.4 影响需求质量的因素3.1.4 影响需求质量的因素1.用户需求不断增加 在实际项目中最让开发人员头痛的问题就是用户需求不断增加。开发过程中需求不断变化，会使软件的整体结构越来越混乱，补丁代码也使得整个程序难以理解和维护。 为了减少用户需求变更，需要从两个方面入手： 从一开始就对项目的范围、目标、规模、接口、成功给予明确的定义。 在项目管理上要制定需求变更控制规范，一旦用户需求发生变更，严格按照规范的流程进行一系列的分析和审查。2.模棱两可的需求2.模棱两可的需求不同的开发人员看了同一条需求后，产生了不同的理解，这就是需求二义性问题。 早期发现模棱两可的需求非常重要。在技术上可以用多种不同的方法描述需求，在审查时从不同角度审查需求。在审查需求时，一个人主讲需求，其它人聆听并对描述不清的地方及时提问常常会发现需求二义性的问题。在审查需求时，最好请两名非本项目组的工程师，他们以旁观者的角度往往提出大家比较容易忽视的问题。3.用户不配合3.用户不配合实际工作中，用户的热情参与是项目成功的重要因素。 对待这个问题主要是与用户沟通，引导他们对你正在做的事情感兴趣，同时将一些成功实例演示给用户，提高用户的信任度。4.过于精简的需求说明4.过于精简的需求说明这是开发中最经常犯的错误。尽管开发人员和用户都认为应该花大精力进行需求分析，但在实际项目中仍然难抵御编程的诱惑。 5.忽略了用户的分类5.忽略了用户的分类一个软件中每个功能的使用频率、使用方式和使用人员水平都可能不同，如果在项目的早期没有将需求按主要用户进行分类的话，最终的软件产品可能会使有些主要用户产生抱怨。7.不准确的计划7.不准确的计划用户在项目的初期，常常问开发人员“系统什么时候能够完成？”，而在需求不深入的时候这个问题是很难回答的。随着需求的深入，计划才能比较准确。通常，开发人员总是比较乐观，而实际上，在项目进行过程中总会遇到许多问题导致不能按计划实施。这些问题主要是：变更需求、遗漏需求、与用户交流不够、对开发环境不熟悉、开发人员经验不足等。8.不必要的特性8.不必要的特性有时开发人员会心血来潮，自作主张添加一些额外的功能。这看上去似乎不错，但是对于规范化开发来讲是不允许的。这些锦上添花的功能会使系统变得比较庞大，另外，开发人员的这类行为会造成管理上的麻烦。首先添加的内容必须要有相应的文档说明、程序代码、测试用例、操作帮助，这些都给项目添加了许多工作量。更多的麻烦还在漫长的维护阶段，当系统需要修改时，要考虑对这些添加的功能的影响。因此，软件工程不提倡开发人员擅自添加软件功能。3.2确定系统目标和范围 3.2确定系统目标和范围 业务需求代表了需求链中最高层的抽象，它为软件系统定义目标和范围。 主要内容包括：项目背景、要达到的目标、市场前景、软件的适用范围和局限性、经济效益和社会效益、主要风险和策略。目标和范围模板目标和范围模板参见40页null3.3 需求获取方法 3.3 需求获取方法 为了获得需求，项目经理必须先仔细阅读系统目标和范围说明书，对软件涉及的范围有所了解，然后制定调研计划。 调研计划包括：调研的部门、调研前的培训内容、调研的时间和地点、设计调研访谈表、调研结果分析、调研报告的格式和内容。 培训培训在调研之前，最好安排两项培训： 1.用户培训，请有经验的系统分析人员讲解需求的重要性，以及用户如何配合开发人员的调研 2.内部开发人员的培训，对调研的格式和内容作统一部署。两点注意两点注意1.发现问题及时与开发人员沟通：时间就是金钱、就是生命。软件中的问题较早发现可降低成本。 B o e h m（1 9 8 1）发现要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改正这个错误要多付出6 8倍的成本。 近来很多研究表明这种错误导致成本放大因子可以高达2 0 0倍。2.用户必须坚持需求审查 2.用户必须坚持需求审查 需求审查有助于确定需求，减少需求的变更。 3.3.1 必须向用户交代的两个重要问题 3.3.1 必须向用户交代的两个重要问题 第一，软件开发与其它产品的开发过程一样是分阶段的，每个阶段都有阶段产品。 第二，分阶段审查产品时，产品的合格标准是什么？ 可以参考《计算机软件工程规范国家国标汇编》（简称“软件工程国标”），其中对每个文档的内容要求都写的很明确。 “软件工程国标”是针对所有软件项目编写的，它含盖了可能出现的各种情况，因此，在实际使用时应该对其进行适当的裁减。 具体方法具体方法--首先检查所提交文档的目录，看内容是否全面。 --检查完文档的目录后，再检查具体的内容，用户有权利要求开发方对阶段产品进行详细解释，以便更好的理解。 提交的阶段产品及其主要内容提交时间提交的阶段产品及其主要内容提交时间（1）软件范围和目标说明书： 在实际项目中这个文档通常是以用户为主确定。 当用户认为有困难时，可以委托行业咨询公司协助完成。 这个文档是规划项目的范围、确定规模和软件要达到的目标，是战略性的，因此，建议用户一定要自己把关。 该文档的提交时间是在项目正式启动之前。（2）软件调研报告（2）软件调研报告由开发方提供。 主要内容是开发方对用户现有系统的客观描述。现有系统是指目前使用的计算机系统或人工处理过程或其它自动化处理系统。它反映当前用户业务的工作流程、设备情况、原始数据内容、输出数据格式和内容，同时还要记录用户对新系统的期望和建议，最后还要附上与所调研的业务相关的原始资料，例如：各种单据、报表、操作规范、工作流程描述和岗位职责等等。 报告强调的是客观实际，不需要软件分析人员的主观臆想。提交的时间是调研结束之后、分析需求之前。（3）软件开发计划书 （3）软件开发计划书 由开发方提供。 在项目调研之后，基本上已经能够确定待开发软件的规模和工作量了。这时，开发方应该提交一份比较详细的开发计划，以便于用户配合工作。 计划的内容包括：每个阶段的时间安排、负责人、参加者、需要的其它资源；每个阶段提交的产品（文档）形式和内容说明；每个阶段的审查时间、参加的人员；阶段审查的合格标准。 提交时间是在需求分析阶段的后期，一般是同需求分析规格说明书同时提交。 （4）软件需求分析规格说明书 （4）软件需求分析规格说明书 由开发方提供。 是软件开发的重要阶段产品，用户必须给予高度重视。软件需求分析规格说明书的主要内容是使用自然语言和一些图形符号描述用户需求和软件要实现的功能，详细描述数据关系和数据存储。开发人员经过分析整理出的软件处理流程、与外部系统（角色）的接口，以及软件安全性、可靠性、可扩充性、可移植性等非功能性需求描述。 提交时间是需求分析阶段结束之前。（5）软件设计规格说明书：（5）软件设计规格说明书：由开发方提供。 软件设计包括总体设计和详细设计，总体设计是反映软件的结构框架，不涉及具体的内部控制流程；详细设计是反映具体的实现步骤和内部控制流程。它主要是约束开发人员的，用户了解一些内部结构有助于今后的维护工作。 提交时间是在设计阶段结束之前 （6）软件模块开发卷宗 （6）软件模块开发卷宗 由开发方提供。 主要包含源程序清单，以及单元测试记录。如果用户自己不进行软件维护，这份文档对用户来讲意义不大。但是如果用户要接手这个软件产品，并且还要进行维护，这份文档是需要的。提交时间提交时间如果用户对程序完全陌生，建议在整个系统验收测试结束后要求开发方提交。因为在软件验收交付之前，开发者可能不断地修改源程序，这样用户拿到的文档与最终产品不符。 如果用户比较精通程序设计方面的知识，可以在验收测试之前拿到这份文档，以便对照该文档补充验收测试的测试用例。特别是对控制流程复杂的模块补充一些测试用例。（7）软件测试计划书 （7）软件测试计划书 验收测试计划由用户提供，集成测试计划由开发方提供。 测试计划包括测试时间、测试需要的环境、计划测试的条目、测试用例和正确结果，以便于测试时比较。 这份文档应该测试之前提交。 （8）软件测试报告 （8）软件测试报告 验收测试报告用户提供，集成测试报告由开发方提供。 该文档包括测试的时间、地点、环境、约束条件、测试条目，测试用例、预期结果、实际结果、评价。 软件测试报告在测试之后提交。 （9）软件用户手册（9）软件用户手册由开发方提供。 包括软件范围和目标、应用环境、主要功能、约束条件、操作方法、注意事项等。 初步的用户手册应该在需求分析阶段结束时与用户见面，最终的用户手册在验收测试前提交。用户验收测试包括对文档的验收。（10)软件开发月报 （10)软件开发月报 为了使用户了解软件开发的情况，开发方有义务向用户提交软件开发月报。用户可以及时发现软件开发中的问题，随时与开发方沟通。 3.3.2 制定调研计划 3.3.2 制定调研计划 调研计划在调研工作开始之前由项目经理和用户负责人共同协商确定。 首先，根据项目的规模和范围确定要调研的部门，然后根据项目的总体计划安排调研的访谈时间。为了保证调研的质量，在调研开始前，要安排对用户的软件工程培训，使用户了解软件开发的各个阶段，以及每个阶段用户的职责。对开发人员要进行用户业务培训，使开发人员了解用户业务的专业术语和基本业务流程。 最后，确定调研报告的内容和格式 调研计划的模板 调研计划的模板 XXX项目调研计划 1．项目的目标和范围 注意：项目目标和范围几乎在项目的每份文档中都需要，在制作文档时不要直接将项目范围和目标的内容拷贝到这里，应该使用文档链接方法链接到唯一的内容上。这样可以避免出现冗余和文档内容不一致。null2．调研的部门及部门主要职责 3．设计访谈问题和调研表格 4．培训计划 培训内容、讲授人、时间、地点、参加者 5．调研时间安排表 部门、负责人、接待人、业务介绍人、时间、地点、调研负责人、参加人 注意：安排调研时间要根据所调研部门的规模，通常安排一次访谈后，要留一段时间，以便于开发人员消化调研结果，分析整理出问题，然后，再安排下一次的调研时间，一般的部门最少需要访谈三次。null6．调研结果分析 当项目涉及多个部门时，调研一般分小组进行，每个小组调研的结果要在一起进行汇总，整理出整个系统的调研报告。 7．调研报告审查 参加调研报告审查的人员有各个部门的用户代表、调研人员、系统分析和设计人员。审查时间安排的要宽松一些，因为这是需求分析的第一关。 3.3.3 准备调研的资料 3.3.3 准备调研的资料 调研前系统分析人员应该有充分的准备，针对具体项目的特点设计一些问题和表格，每位调研者事先应该仔细阅读这些问题。 这些问题和表格在调研开始之前也要给用户一份，使他们对调研内容有所准备。在实际项目中应该根据项目的规模，涉及的业务领域，有针对性地设计一些特别问题 调研基本问题（26项）：调研基本问题（26项）：部门的名称、人员数量和结构。 部门发展或变化简单介绍。 部门的主要任务。 业务处理流程。 部门各岗位的职责。 业务处理过程中涉及哪些专业领域的知识。 工作需要的审批流程是什么？ 主要处理方法或算法描述。 哪些业务需要实时处理？ 哪些业务需要交互操作？null部门接受哪些部门或外界的信息？信息内容和格式要求是什么？ 部门产生哪些信息？部门产生的信息送到哪些其它部门？格式要求？ 对信息的输入和输出方式有要求吗？输入输出设备是什么？ 数据要求实时备份吗？备份的设备是什么？ 业务处理有高峰期吗？高峰时间是什么时候？业务量有多少？ 现有的哪些设备要继续使用？ 对产品的运行环境有要求吗？null对界面风格和操作方式有要求吗？ 在系统运行过程中允许停机吗？ 操作方式要根据操作环境和使用人员分类吗？ 需要的操作权限有哪些？ 需要记录系统操作和运行日志吗？ 用户有能力进行系统维护吗？ 需要分布式处理吗？ 需要什么方式的用户操作培训。 需要制作联机帮助吗？10个调研表10个调研表调研表1：部门基本情况表 调研表2：部门业务流程表 调研表3：部门业务所涉及的信息流和信息存储 调研表4：信息项描述表 调研表5：输入/输出信息格式说明表 调研表调研表调研表6：部门建议表 调研表7：系统性能要求表 调研表8：质量属性要求表 调研表9：可能的限制/假设 调研表10：部门提供的原始材料一览表 3.3.4 访谈用户3.3.4 访谈用户这个阶段只是深入了解用户的实际业务流程和相关数据、现有的环境、设备，听取用户对现有系统的改进建议。 收集各个相关部门的操作规范、岗位职责、各种图表和业务往来单据等原始资料。 在调研前项目经理与系统分析人员一起制定调研问题和调研表格，以提高调研的效率和质量。 在调研过程中应尽可能细致地了解用户部门的业务处理流程，建议采用流程图快速记录用户的叙述，然后再用自然语言将理解内容讲给用户，由用户确认你的理解是否正确。 null每天访谈结束后，调研人员要立刻整理调研表格，根据调研时画出的流程图写出文字说明。发现模糊的需求，调研人员要将问题记录下来，再次访谈用户。 这种往复通常要有三至五次。项目经理每天都要召集项目组开会，将调研结果汇总，这样可以及时发现问题，改进工作过程。 3.3.5 编写调研报告3.3.5 编写调研报告1. 项目范围和目标 2．项目背景 3．现系统工作描述 4．信息处理流程 5．数据说明 6．输入输出格式 7．现有设备情况 8．现有软件系统 9．系统使用对象说明 10．用户对原系统的意见 11．用户对新系统的建议 12．用户提出的非功能性需求 3.3.6 需求的其他来源3.3.6 需求的其他来源通过阅读与行业相关的标准、规则和文件获取需求。 通过市场调查和用户问卷调查，了解目前市场上用户对同类产品的意见和建议。 收集同类产品的用户手册、操作说明、演示版本等，然后对它们进行比较，汲取精华，去其糟粕。3.4 定义软件的质量属性3.4 定义软件的质量属性有效性 高效性 灵活性 安全性 互操作性 可靠性 健壮性 易用性 可维护性 可移植性 可重用性 可测试性 可理解性质量属性分为两类：一类是针对用户来说重要的特性, 另一类是针对开发者来说重要的特性null软件质量要素的构成 产品 修正产品 转移产品 运行 可维护性 灵活性 可测试性 可移植性 可重用性 可互操作性正确性 可靠性 有效性 完整性 可用性（1）有效性（1）有效性有效性——有效性指的是在预定的时间内，系统正常运行时间的比例。 它是系统的平均无故障时间除以系统平均无故障时间与故障维修时间之和。有时用户的需求可能会对时间要求更严格，例如，交易系统可能会要求在交易时间内系统的有效性要达到99.95%，其它时间只要达到80%就可以了。 在调研用户时要询问用户需要多高的有效性，是否在所有时间对有效性的要求都是相同的。 （2）高效性（2）高效性高效性——系统效率是用来衡量处理器优化、磁盘和内存空间利用率、通讯带宽利用率等系统资源的使用情况。 如果软件运行占用了系统的所有可用资源，其结果就是系统性能的急剧下降。 因此，在进行需求调研和分析时要对高峰负载进行计算，并且，在满足高峰负载的情况下，预留出一定的处理器能力、和内存空间余量、通讯带宽余量。由此计算出系统的最小配置。 （3）灵活性/可修改性（3）灵活性/可修改性灵活性/可修改性——灵活性反映的是在软件中添加新功能时所需要的工作量。当用户要求灵活性时，会迫使开发者考虑系统今后的扩充问题。在国内的应用开发项目中，灵活性通常是一个陪衬词，很难定量地描述。 这里我们给出一个描述灵活性需求的例子：在库存管理系统中，一个具有6个月以上开发经验的软件维护人员能够在4个小时之内为系统添加一个统计报表，并且这个统计报表的数据项不超过20项，所涉及的数据库表不超过5个”。 用这种非常量化的指标要求系统的灵活性，设计人员在设计系统时就会考虑如何实现灵活性的要求。 （4）安全性（4）安全性安全性——保证系统不被非法访问，防止数据丢失、防止病毒入侵、防止私人数据进入系统。 要用明确的术语描述安全性的需求，如身份验证、用户特权级别、访问约束、需要保护的数据等等。 一个安全性需求的描述可以是这样的：“只有具有查帐特权的用户才能够进行库存统计查询”。（5）互操作性（5）互操作性互操作性——表明了产品与其它系统交换信息和使用服务的难易程度。 为了使产品满足互操作性需求，系统分析员必须要了解你的产品将要与哪些系统连接、需要交互什么数据。（6）可靠性（6）可靠性可靠性——可靠性指标是软件在给定时间间隔内，按照规格说明书的规定正常运行的概率。 它反映软件正确执行操作所占的比例，以及在发现新的缺陷之前系统运行的时间和缺陷出现的密度。 一个描述可靠性需求的例子：“由于软件失效引起的库存成本计算错误的概率不能超过1‰”。 （7）健壮性（7）健壮性健壮性——是指当软件遇到非法输入数据，或相关的运行环境出现异常时，软件仍能正确运行的程度。 健壮的系统可以从发生问题的环境中恢复正常，并且容忍用户的一些错误。在需求调研时，要询问用户当软件出现缺陷时，用户希望系统如何响应。在需求分析时，分析人员要列出软件所有可能出现的异常和常见的操作失误，并且针对每条失误写出健壮性需求。 一个健壮性需求的描述可能是：“当远程用户向中心数据库发送信息被线路故障中断后，系统每隔10秒钟重新连接一次中心数据库，直到数据库被连接上，然后重新发送所有要发送的信息”。 （8）易用性（8）易用性易用性——易用性的定量描述可以是对用户某项操作的时间要求，也可能是用户学习操作软件所用的时间要求，或者是对软件操作形式的要求。它所描述的是与用户友好性相关的各种因素。 例如，“软件的操作菜单必须有热键、按钮”，“一个新用户经过不到30分钟的环境适应，就可以进行基本的查询操作”，“一个新的操作人员经过一天的培训就可以独立完成他所需要的95%的工作”，“一个入库操作的时间应该小于2分钟”等。（9）可维护性（9）可维护性可维护性——它描述纠正一个缺陷或进行一个变更的简易程度。可维护性取决于软件的可理解性、软件的结构和选择的软件开发工具。 为了使软件易于维护，通常需要规范设计和实现，例如：“调用不能超过两层，以便于执行跟踪”，“每个模块中的源代码与注释的比例为2：1”，“对库存统计报表格式变化的修改时间不能超过一周”等类似的定量描述。（10）可移植性（10）可移植性可移植性——可移植性是度量把软件从一种环境移到另一个环境中所花费的工作量。为了实现可移植性，需要研究软件要移植的环境。 可移植性与高效性可能会有冲突，为了软件具有更好的可移植性，系统分析人员会做更多的限制，例如，为了提高软件的可移植性，尽量不使用运行环境提供的库函数，等等。 可移植性对软件的成功不是最重要的，因此，分析人员要与用户一起协商，平衡性能的取舍。（11）可重用性（11）可重用性可重用性——表明一个软件组件可用于其它软件的程度。可重用软件的开发成本会比较高，因为可重用软件必须标准化、资料齐全、不依赖于特定的应用程序和运行环境，并具有一般性。 但是，软件的可重用性是软件走向构件化的途径，是几十年来软件开发人员所追求的最高境界。（12）可测试性（12）可测试性可测试性——指测试软件时查找缺陷的简易程度，如果软件中包含复杂的算法和处理逻辑，或者使用了复杂的数据结构，或者功能模块间的关系复杂，都会影响可测试性。另外，经常更改软件时，可测试性指标也是相当重要的。 定量的可测试性需求描述的例子有：“一个模块的最大循环复杂度不能超过20”，循环复杂度是衡量一个模块源代码中逻辑分支数目的参数，一个模块中的逻辑分支过多会影响可测试性。（13）可理解性（13）可理解性可理解性——可理解性是指人们通过阅读程序源代码和相关文档，了解程序功能、结构和运行方式的容易程度。 可理解性可理解性模块结构良好，功能完备。 程序算法简明，没有含糊不清的代码，使用有意义的过程名。 代码风格和设计风格一致。 采用结构化编程，程序只使用顺序、分支和循环三种基本语句结构，并且每个模块都是单入口单出口。 尽量使用简单的数据结构，使用有意义的数据名和变量名。 程序处理完整，程序不仅实现了基本的功能，而且还要有数据检查、出错处理等辅助功能。 可理解性可理解性可以使用一种叫做“90-10测试”法来衡量。即把一段相对完整的源程序清单拿给一位经验丰富的程序员阅读10分钟，然后由这位程序员凭自己的理解和记忆，写出该程序的90%内容，如果程序员能够写出，说明这个程序具有较好的可理解性 null其中， 表示有利影响， 表示不利影响。 质量特性之间的竞争质量要素间的关系质量要素间的关系3.5 需求优先级3.5 需求优先级为每项需求设置优先级有助于规划软件，以最小的费用提供软件的最大功能。 项目经理可以根据需求的优先级计划进度、安排资源、解决冲突。 一般地，优先级设定为高、中、下三级。 null高优先级需求是指：一个关键任务的需求，只有在这些需求上达成一致意见，软件才可能被接受，这种级别的需求必须要完美地实现。 中优先级的需求是指：最终所要求的，但如果有必要的话，可以延迟到下一个版本，实现这类需求将会增加软件的性能，但是如果忽略这些需求，软件也可以被接受，开发这类需求时要付出努力，但不必做得太完美。 低优先级需求是指：对系统功能和质量属性上的增强，如果资源允许的话，实现这些需求会使软件更加完美。但是，如果不实现它们，对系统也没有影响，这类需求实现时可以有缺陷。参与人员参与人员项目经理、重要的用户代表和开发者代表一起参加制定需求优先级的工作。 项目经理负责协调、指导； 用户代表：提供每项需求实现后的受益程度，失败后造成损失程度； 开发人员提供实现每项需求的费用和可能的风险。3.6 需求验证技术 3.6 需求验证技术 在实际的开发中，开发活动总是与测试活动并行展开的。验收测试是以用户需求为基础的，系统测试是以功能需求为基础的，集成测试是以系统总体设计为基础的，单元测试是以详细测试为基础的。开发与测试的关系用软件工程中著名的V字模型表示 null3.6.1 需求文档的评审3.6.1 需求文档的评审需求文档的评审是一项精益求精的工作，有两种评审方法： 非正式需求评审：是把需求阶段的产品即软件需求规格说明书发给其他人员预览，然后召集评审会，通常由一个有经验的系统分析员描述软件需求，与会的人员发表自己的意见。 正式评审：按预先定义的好的一系列步骤审查需求规格说明书的内容，重点是查找其中的缺陷。软件开发过程中始终伴有评审，每个阶段有不同的审查内容。3.6.5正式的需求评审3.6.5正式的需求评审过程由五步组成： 第一步是规划。由项目经理和高级系统分析人员共同拟订审查计划，确定参加人员，准备需要的资料，安排审查会议的具体程序。 第二步是准备。根据规划制定的任务，将审查需要的资料预先分发给有关人员。每个拿到资料的审查员以典型缺陷单为指导，检查需求规格说明书中可能出现的错误。如果项目很大，可以将需求规格说明书划分成几个部分分别发给不同的审查人员，因为一个人阅览的内容太多，可能会影响审查的质量。null第三步是召开审查大会。准备工作完成后就可以召开审查大会了。会上由一个分析人员主要发言，描述需求，其它人员可以随时提出疑问或指出缺陷，记录员记录会议发言。会后，由记录人员整理出缺陷建议表，提交给开发小组。如果项目大，可以每次审查一个主题，以保证审查的质量。正式的需求评审正式的需求评审正式的需求评审第四步修改缺陷。根据整理出的缺陷建议表修改需求规格说明书或相关的其它文档。 第五步重审。对修改后的需求规格说明书重新审查，方法同第三步。从第三步到第五步是一个循环往复的过程，这一过程直到所有缺陷都已改正、整个需求规格说明书通过会议审查为止。 3.6.3 审查人员的职责3.6.3 审查人员的职责项目经理负责制定审查计划，协调各项活动，分配任务。 软件设计人员参见评审，以便了解需求的全貌，并且从设计角度审查需求的可行性、完备性、无二义性等重要指标。 测试人员要以需求规格说明书为依据设计验收测试用例。 用户能够发现大部分遗漏的需求。 秘书负责资料整理、人员联系、会议记录等3.7 需求管理3.7 需求管理需求管理的目的有三个： 一是保障需求规格说明书与软件产品的一致性； 二是控制需求变更对项目开发的影响； 三是使需求活动与计划保持一致。3.7.1 管理需求变更3.7.1 管理需求变更需求变更是指在软件需求基线已经确定之后又要添加新的需求或进行较大的需求变动。 软件工程研究的主要问题之一就是如何降低需求变更的影响，控制需求变更的过程，减小因需求变更带来的风险。 需求变更失控的例子。需求变更控制的步骤需求变更控制的步骤(1)通过一个合适的渠道接受一项需求变更请求，注意，所有的变更都要发送到统一的位置，有专人管理，每项变更赋予一个唯一的编号。 填写需求变更请求表：主要描述重要级别、变更编号、是否新增需求、更改原因、变更内容描述。null(2)变更控制委员会评估申请的变更，分析变更的技术可行性，估计实现变更的代价和可能产生的影响。 变更委员会应该由项目经理、软件产品计划或管理部门的代表、开发部门的代表、测试和质量保障部门的代表、文档制作部门的代表、技术支持部门的代表、配置管理部门的代表、用户方代表组成。 为了清楚地反映需求变更的影响，我们给出一个需求变更影响图 ：需求变更控制的步骤（2）null需求变更问题表需求变更问题表变更的内容与系统目标有冲突吗？ 变更的需求在系统业务需求范围之内吗？ 变更的需求需要改变硬件环境吗？ 变更的需求需要改变软件环境吗？ 变更的需求在实现上存在技术障碍吗？攻克技术障碍需要的人员、时间有保障吗？ 请列出在项目当前的状态下接受变更的影响矩阵。 申请的变更与需求规格说明书中描述的需求有冲突吗？如果有冲突请申请者详细解释冲突的原因。 如果拒绝变更会导致项目不成功吗？ 共计23条null(3)分析需求变更可能影响的软件元素。下面给出一个软件模板，用户可以参照该模板检查需求变更影响的软件因素 ：需求变更控制的步骤（3）需求影响分析表需求影响分析表列出变更影响的数据库表和文件。举例列出需要变更、添加和删除的信息结构和信息项。 变更影响的系统设计元素，包括：数据流程图、数据实体关系图、数据字典、处理说明、类和对象定义、类的方法、过程或函数。分别列出要更改、添加和删除的内容。 确认对开发文档、用户文档、培训文档、联机文档和管理文档的更改。 确认需要变更的源程序。 确认需要变更的单元测试、集成测试、系统测试和验收测试方案。 确认需要更改的软、硬件环境。 确认项目管理计划、质量保证计划、配置管理计划，风险控制计划的合理性。 确认变更对系统接口的影响。 需求变更控制的步骤（4）需求变更控制的步骤（4）（4）根据上面的结果，仔细填写一份需求变更工作量统计表 null需求变更控制的步骤（5）需求变更控制的步骤（5）（5）填写需求变更影响分析报告表，由该需求变更控制委员会作出是否采纳变更的决策。 null变更请求号： 标题： 分析者： 日期： 优先权评估：工作量估计：需求变更影响分析报告表影响： 预计对进度影响 天，对成本影响金额 元。 对人员组成要求： 。 对系统环境影响： 。 对质量影响： 。对其它需求的影响： 。 对其它任务的影响： 。 要更新的计划： 。 综合影响： 。 变更可能影响的其它部件： 需求变更控制的步骤（6）需求变更控制的步骤（6）（6）一旦决定变更应该及时通知所有相关的人员，最后，要按一定的程序来实施需求变更。3.7 需求跟踪3.7 需求跟踪需求跟踪包括编制每项需求同其它系统需求、其它设计部件、源程序模块、测试用例、帮助文件、文档等系统元素之间的联系文档。它使得你能够跟踪一个需求使用期的全过程，能够将每项需求从最基础的业务需求→用户需求→功能需求或非功能需求一直追踪下来，也可以沿这条路径反方向回溯到业务需求。 建立这种跟踪关系链可以清楚每个需求对应的软件产品部件，以及每个部件是满足哪个需求的。如果不能把一个设计模块、代码段、测试回溯到一项需求上，则说明在软件产品中可能有一段多余的内容，或者是需求规格说明书上遗漏了一项需求描述 null练习：练习： 软件开发各个阶段产生的文档有哪些？ 为什么用户发现需求问题要尽早向开发人员提出？ 需求分类的目的是什么？ 业务需求和用户需求的区别？用户需求和功能需求的区别？ 什么是高质量的需求？ 影响需求质量的因素有哪些？ 开发人员向用户交待软件开发具有阶段性质，有什么意义？ 业务需求的主要内容是什么？ 需求获取的主要步骤？ 请拟订一份学校图书馆图书信息管理系统的需求调研计划？ 请按照需求调研表的格式获取学校图书馆图书信息管理系统的需求，有哪些内容和格式需要修改？为什么？null再见！