软件工程-2-需求工程20浩121.pptVIP

* 需求的不同层次 * * * 参见-需求分析方法 * * * * 也被称为提取需求的技术? 软件原型是指软件系统的一个早期的可运行版本,它能表现出目标系统的部分重要特征,但不一定符合其全部的实际需求 需求信息提取的方式： 原型法 场景 学徒 原型法应用的场合： 场景法： Software Engineering 软件工程 第二章 需求工程（1） 情景互动 如果要明确用户提出的任务，需要和用户进行沟通，我们应该获得哪些方面的信息？应该如何去做？ 产品介绍 产品的用途及意义 产品应用背景 面向用户 功能性需求 非功能性需求 需要获得的信息 步骤 从用户那里获得信息 整理并分析信息 确认信息 一、需求概述 什么是需求？ 用户解决问题或达到目标所需要的条件或权能； 系统或系统部件要满足合同、标准、规范或其他正式规定文档所要具有的条件或权能； 反映上面两条的文档说明。 需求工程 指系统分析人员通过细致的调研分析，准确地理解用户的需求，确定客户“需要”什么样的软件。将不规范的需求陈述转化为完整的需求定义，再将需求定义写成需求规约的过程。需求工程包含需求开发和需求管理两部分。 1. 需求的类型 功能需求和非功能需求 功能需求 描述系统所应提供的功能和服务，包括系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。 非功能需求 作为功能需求的补充，非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性、响应时间、存储空间等 。 非功能性需求的类型 针对不同需求来源的需求分类 领域需求 领域需求的来源不是系统的用户，而是系统应用的领域，反映了该领域的特点。它们主要反映了应用领域的基本问题，如果这些需求得不到满足，系统的正常运转就不可能。领域需求可能是功能需求，也可能是非功能需求，其确定所需的领域知识。它经常采用一种应用领域中的专门语言来描述。 业务需求 反映组织机构或客户对软件高层次的目标要求，这项需求是用户高层领导机构决定的，它确定了系统的目标规模和范围。 用户需求 用户使用该软件要完成的任务 系统需求 容易被忽视的要求通常是为了保证整个系统能够正常运行的辅助功能,用户一般不会意识到。 软件需求各组成部分之间的关系 需求的演变过程—需求的“沙漏” 2. 需求的演变 需求演变的三个过程 第一阶段：“访谈式”（Visitation） 这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，从宏观上把握用户的具体需求方向和趋势。 第二阶段：“诱导式”（Inducement） 这一阶段是在承建方已经了解了具体用户方的具体实际、客观的信息基础上，结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。 第三阶段：“确认式”（Afirm） 这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段。承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。 3. 需求工程的主要活动和文档 需求开发活动 需求获取 需求分析 编写需求规格说明书 需求评审 《用户需求说明书》 《产品(系统)需求规格说明书》 《需求评审报告》 需求管理活动 需求变更控制 版本控制 需求跟踪 需求状态跟踪 《需求跟踪报告》 《需求变更控制报告》 实行严格的产品控制 需求开发文档的区别 读者对象 客户 管理者 最终 用户 系统体系 结构工程师 承包商 管理者 客户 工程师 《用户需求说明书》 需求开发文档的区别 读者对象 软件 开发人员 系统体系 结构工程师 《需求规格说明书》 客户 工程师 最终用户 需求开发文档的区别 内容 用户需求 是用自然语言加图表的形式给出的关于系统需要提供哪些服务，以及系统操作受到哪些约束的声明。 软件需求规约(需求规格说明书) 详细地给出系统将要提供的服务以及系统所受到的约束。软件需求规约文档有时也称为功能描述，应该非常精确，它可能成为系统买方和软件开发者之间合同的主要内容 二、需求获取 需求获取（requirements elicitation）也称为需求收集（requirements capture），它是与发现目标系统应该提供的需求相关的活动的统称。 1. 需求获取的过程 需求获取的步骤 2.需求调查的主要内容 环境调查 包括与开发项目相关的企业的组织结构、规章制度、工艺流程、产品和服务等。 新系统目标的调查 将系统目标具体化，例如节约成本的手段，提高业务处理速度的方法等。 管理功能和决策方式 调查了解各级组织的职能和有关人员的工作内容，发现各种现存问题和薄弱环节，及对新系统的功能要求。 业务流程 详细了解各职能部门人