软件工程-3-需求工程头巾20091.pptVIP

软件工程 第三章 需求工程 情景互动 需 求 评 审 会 项目名称：俄罗斯方块 报告人：项目小组代表 评审组：客户方代表、技术顾问、 相关各项目小组全体成员 * 一个优秀的需求文档应具备的特征 完整性、正确性 不能遗漏用户需求说明书中的必要需求。需求分析员必须在将需求进行细化时，不能丢失和改变信息，需求规格说明书必须经过用户确认。 具有准确性和一致性。 它是连接计划时期和开发时期的桥梁，也是软件设计的依据。任何含混不清、前后矛盾或者一个微小的错漏，都可能导致误解或铸成系统的大错，在纠正时付出巨大的代价。 可行性 描述的功能必须从技术上是可以实现的，并且满足时间、费用、质量等约束。 必要性 需求规格说明书中的内容对用户来讲都是必需的，不可或缺的。 划分优先级 根据需求“轻重缓急”进行分级表述，可以在有限的资源（资金、人员、时间等）情况下进行取舍，降低在实现过程遇到风险。 无二义性。 因为它是沟通用户和系统分析员思想的媒介，双方要用它来表达对于需要计算机解决的问题的共同理解。如果在需求说明中使用了用户不容易理解的专门术语，或用户与分析员对要求的内容可以做出不同的解释，便可能导致系统的失败。 可验证性 是软件需求的基本属性。需求必须是可验证的，否则软件评审和测试就没有相应的依据。 需求应尽量进行量化，使得其可以被验证、测试。 直观、易读和易于修改。 应尽 量采用标准的图形、表格和简单的符号来表示，使不熟悉计算机的用户也能一目了然。 如何才能有效地描述需求？ 需求到底要达到一种什么样的目标呢？ 一、需求概述 什么是需求？ 用户解决问题或达到目标所需要的条件或权能； 系统或系统部件要满足合同、标准、规范或其他正式规定文档所要具有的条件或权能； 反映上面两条的文档说明。 需求工程 指系统分析人员通过细致的调研分析，准确地理解用户的需求，确定客户“需要”什么样的软件。将不规范的需求陈述转化为完整的需求定义，再将需求定义写成需求规约的过程。需求工程包含需求开发和需求管理两部分。 1. 需求的演变 需求获取 又被称为需求捕获或需求启发 发现客户需求的过程 需求分析 一旦提出了最初的需求，推敲和扩充的过程 构建正式的需求文档 2. 需求工程的主要活动和文档 需求开发活动 需求获取 需求分析 编写需求规格说明书 需求评审 需求开发文档的区别 内容 用户需求 是用自然语言加图表的形式给出的关于系统需要提供哪些服务，以及系统操作受到哪些约束的声明。 软件需求规约(需求规格说明书) 详细地给出系统将要提供的服务以及系统所受到的约束。软件需求规约文档有时也称为功能描述，应该非常精确，它可能成为系统买方和软件开发者之间合同的主要内容 需求开发文档的区别 读者对象 需求开发文档的区别 读者对象 需求管理活动 需求变更控制 版本控制 需求跟踪 需求状态跟踪 3. 需求的类型 功能需求和非功能需求 功能需求 描述系统所应提供的功能和服务，包括系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。 非功能需求 作为功能需求的补充，非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性、响应时间、存储空间等 。 针对不同需求来源的需求分类 领域需求 领域需求的来源不是系统的用户，而是系统应用的领域，反映了该领域的特点。它们主要反映了应用领域的基本问题，如果这些需求得不到满足，系统的正常运转就不可能。领域需求可能是功能需求，也可能是非功能需求，其确定所需的领域知识。它经常采用一种应用领域中的专门语言来描述。 业务需求 反映组织机构或客户对软件高层次的目标要求，这项需求是用户高层领导机构决定的，它确定了系统的目标规模和范围。 用户需求 用户使用该软件要完成的任务 系统需求 容易被忽视的要求通常是为了保证整个系统能够正常运行的辅助功能,用户一般不会意识到。 软件需求各组成部分之间的关系 二、需求获取 需求获取（requirements elicitation）也称为需求收集（requirements capture），它是与发现目标系统应该提供的需求相关的活动的统称。 1. 需求获取的过程 需求获取的步骤 2.需求调查的主要内容 环境调查 包括与开发项目相关的企业的组织结构、规章制度、工艺流程、产品和服务等。 新系统目标的调查 将系统目标具体化，例如节约成本的手段，提高业务处理速度的方法等。 管理功能和决策方式 调查了解各级组织的职能和有关人员的工作内容，发现各种现存问题和薄弱环节，及对新系统的功能要求。 业务流程 详细了解各职能部门人员的业务分工情况和各单位人员之间业务关系、作业顺序和管理信息流动等。调查结果用业务流程图表示。 数据流程 收集各业务及管理岗