[软件工程-需求工程.pptVIP

第二章 需求工程 需求工程： 需求开发和需求管理组成 需求开发是指对一个软件项目需求的获取、分析、规格说明和验证。 需求管理是在软件项目开发过程中对需求开发结果的控制、跟踪和管理。 第一节 需求工程概念 1.需求分类 2.需求工程的主要活动 3.高质量需求的特征 4.影响需求质量的因素 1 需求分类 业务需求：这项需求是用户高层机构决定的，它确定了系统的目标、规模和范围 。 用户需求：用户需求是用户使用该软件要完成的任务。最终用户的工作过程、所涉及的信息、当前系统的工作情况、与其它系统的接口等等 。 功能需求：定义了软件开发人员必须实现的软件功能。 非功能需求：是对功能需求的补充，可以分为两类，一类是对用户来说可能很重要的属性，包括：有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性。另一类是对开发者来说很重要的质量属性，包括：可维护性、可移植性、可重用性、可测试性. 需求分类的例子-拼写检查 业务需求：“能够有效地检查和纠正文档中的字词拼写错误”。 用户需求：“找出文档中的拼写错误，并且对每个错误提供一个更正建议表，更正建议表中列出可以替换的字词”。 功能需求：“软件提供一个打开文档对话框；对打开的文档进行字词检查，发现拼写错误以高亮度提示出错的字词；对错误字词显示更正建议对话框，其中列出可选的字词，以及替换范围选择”。 2 需求工程的主要活动 需求开发活动 获得需求 分析需求 编写需求规格说明书 审查需求 需求管理活动： 需求变更控制 需求版本控制 需求跟踪 需求状态跟踪控制 3 高质量需求的特征 完整性：不能遗漏任何必要的需求；每一项需求所要完成的任务必须要描述清楚、完整。 正确性：正确性首先由用户来判断；系统分析人员应该检查每项需求是否超出了业务需求所定义的软件范围。 可行性：可行性体现在技术可行、经济可行性、操作可行性。在开发应用软件时要坚持使用成熟的技术，著名的UNIX操作系统之所以成功的原因之一就是尽其可能使用成熟技术和简单结构。这样的系统可靠性高，易于维护。 必要性：每项需求都应该是客户所需要，开发人员不要自作主张添加需求。检查需求必要性的方法是将每项需求回溯至用户的某项需求上。 划分优先级：为每一项需求按照重要程度分配一个优先级，这有助于项目管理者解决冲突、安排阶段性交付，在必要时做出功能取舍，以最少的费用获得软件产品的最大功能。 MUTIX操作系统的失败的教训 无二义性：不同的人员对需求的理解应该是一致的。 可验证性：每项需求都是应该可验证的。每项需求都可以设计测试用例对其进行测试，或其它的验证方法，如果需求不可验证，则要认真检查需求的有效性和真实性，一份前后矛盾、有二义性的需求是无法验证的。 4 影响需求质量的因素 用户需求不断增加 在实际项目中最让开发人员头痛的问题就是用户需求不断增加。开发过程中需求不断变化，会使软件的整体结构越来越混乱，补丁代码也使得整个程序难以理解和维护，同时它会影响软件模块高内聚、低耦合的设计原则。如果项目管理工作不完善，更会带来严重后果。 为了减少用户需求变更，需要从两个方面入手：首先，必须从一开始就对项目的范围、目标、规模、接口、成功标准给予明确的定义。第二点，在项目管理上要制定需求变更控制规范，一旦用户需求发生变更，严格按照规范的流程进行一系列的分析和审查。 模棱两可的需求 用户不配合 过于精简的需求说明 忽略了用户的分类 不准确的计划 不必要的特性 第二节 确定系统目标和范围 系统目标和范围的模板 第三节 需求获取方法 必须向用户交代的两个重要问题 软件开发与其它产品的开发过程一样是分阶段的，每个阶段都有阶段产品。只有每个阶段的产品符合要求，才可能生产出最终满足用户需要的产品 第二，分阶段审查产品时，产品的合格标准是什么？面对需求分析和设计的各种图形符号，用户不知道该如何下手。开发方要用多种形式来描述阶段产品，目的是让用户了解软件要做什么。 2 提交的文档 软件范围和目标说明书 软件调研报告 软件开发计划书 软件需求分析规格说明书 软件设计规格说明书 软件模块开发卷宗 软件测试计划书 软件测试报告 软件用户手册 软件开发月报 软件范围和目标说明书 在实际项目中这个文档通常是以用户为主确定。当用户认为有困难时，可以委托行业咨询公司协助完成。 规划项目的范围、确定规模和软件要达到的目标，是战略性的。 文档的提交时间是在项目正式启动之前。 软件调研报告 这个文档由开发方提供。 内容是开发方对用户现有系统的客观描述。反映当前用户业务的工作流程、设备情况、原始数据内容、输出数据格式和内容，同时还要记录用户对新系统的期望和建议，最后还要附上与所调研的业务相关的原始资料。报告强调的是客观实际，不需要软件分