第四章需求工程.ppt

第四章 需求工程 需求工程包括：需求开发和需求管理。 需求开发：需求的获取、分析、说明和验证。 需求管理：需求开发结果的控制、跟踪和管理。 需求工程的任务：确定软件项目的目标和范围。调查使用者的要求，分析软件必须做什么，编写需求规格说明书等它相关文档，并进行必要的需求审查。除此之外，还包括需求变更控制，需求风险控制，需求版本控制等对需求的管理工作。 4.1 需求工程的概念 1.需求分类 分类：业务需求、用户需求、功能需求和非功能需求 业务需求 反映组织机构或客户对软件高层次的目标要求。 这项需求是用户高层领导机构决定的，它确定了系统的目标、规模和范围。 业务需求一般在进行需求分析之前就应该确定，需求分析阶段要以此为参照制定需求调研计划、确定用户核心需求和软件功能需求。 业务需求通常比较简洁，大约三至五页纸就可以描述清楚，也可以将它直接作为需求规格说明书中的一章。 用户需求 用户使用该软件要完成的任务。 这部分需求应该充分调研具体的业务部门，详细了解最终用户的工作过程、所涉及的信息、当前系统的工作情况、与其它系统的接口等等。 用户需求是最重要的需求，也是出现问题最多的。 功能需求 定义了软件开发人员必须实现的软件功能。 用户从他们完成任务的角度对软件提出了用户需求，这些需求通常是凌乱的、非系统化的、有冗余的，开发人员不能以此编写程序。软件分析人员要充分理解用户需求，将用户需求整理成软件功能需求。开发人员根据功能需求进行软件设计和编码 非功能需求 是对功能需求的补充。 可以分为两类： 一类是对用户来说可能很重要的属性，包括：有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性。 另一类是对开发者来说很重要的质量属性，包括：可维护性、可移植性、可重用性、可测试性。 需求分类的例子：一个字词拼写检查程序 业务需求是：能够有效地检查和纠正文档中的字词拼写错误。 用户需求是：找出文档中的拼写错误，并且对每个错误提供一个更正建议表，更正建议表中列出可以替换的字词。 功能需求是：软件提供一个打开文档对话框，对打开的文档进行字词检查，发现拼写错误以高亮度提示出错的字词，对错误字词显示更正建议对话框，其中列出可选的字词，以及替换范围选择。 4.2需求工程主要活动 获得需求 分析需求 编写需求规格说明书 审查需求 需求变更控制 需求版本控制 需求跟踪 需求状态跟踪控制 4.3高质量需求的特征 完整性： 首先是不能遗漏任何必要的需求。丢失需求经常发生，并且危害极大，而且所丢失的需求通常不容易被发现。为了避免丢失需求，建议特别关注需求获取的方法，分析员应该注重用户的需求而不是系统的功能，这也是我们将需求分为用户需求和功能需求的原因之一。 需求完整性的第二层含义是每一项需求所要完成的任务必须要描述清楚、完整。 正确性 每项需求都必须准确地反映用户要完成的任务。判断需求正确性有两种途径： 由用户来判断。在进行需求调研时系统分析员记录了每项需求的来源和相关的详细信息，系统分析人员根据调研的结果使用自然语言和流程图或用例图等多种方式描述需求。在需求评审时用户和开发人员从不同角度，检查需求的正确性。 系统分析人员应该检查每项需求是否超出了业务需求所定义的软件范围。 可行性 每一个成功的软件系统其解决方案都是可行的。 技术可行 经济可行性 操作可行性 必要性 每项需求都应该是客户所需要，开发人员不要自作主张添加需求。检查需求必要性的方法是将每项需求回溯至用户的某项需求上 。 划分优先级 为每一项需求按照重要程度分配一个优先级，这有助于项目管理者解决冲突、安排阶段性交付，在必要时做出功能取舍，以最少的费用获得软件产品的最大功能。在开发产品时，可以先实现优先级高的核心需求，将低优先级的需求放在今后的版本中。 无二义性 不同的人员对需求的理解应该是一致的。一般情况下，描述需求都是用自然语言，因此很容易引起需求理解的二义性，如果需求使用简洁明了的语言描述对大家理解需求是有益的。 使用多种不同的方式从多个角度描述同一需求对于发现需求二义性也是有帮助的。避免二义性的另一个有效方法是对需求文档的正规检查，包括编写测试用例，开发原型。 可验证性 每项需求都是应该可验证的。系统分析员在需求分析时就要考虑每项需求的可验证性问题，为需求设计测试用例或其它的验证方法，如果需求不可验证，则要认真检查需求的有效性和真实性，一份前后矛盾、有二义性的需求是无法验证的。 4.4影响需求质量的因素 用户需求不断增加 在实际项目中最让开发人员头痛的问题就是用户需求不断增加。开发过程中需求不断变化，会使软件的整体结构越来越混乱，补丁代码也使得整个程序难以理解和维护。 为了减少用户需求变更，需要从两个方面入手： 从一开始就对项目的范围、目标、规模、接口、成功标准给予明确的定义。 在项