软件需求工程第一章需求概述小结
一．软件需求工程概述 1.1 需求工程的重要性 1. 需求在软件项目中的重要地位 ： 软件系统开发过程中最难的部分是对要开发什么作出准确的判断。 所有概念性工作中最难的是建立详细的技术需求，包括所有与用户、机器和其他软件 系统的接口 1.2 软件需求工程的概念 1. 什么是需求? IEEE 的软件工程标准术语表则将需求定义为: 第一项．用户为解决某个问题或达到某个目标而需具备的条件或能力。 第二项．系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条 件或必须具备的能力。 2. 什么是工程? 工程的定义: 工程就是运用科学知识，对现实问题提供性能价格比合理的解决方案。 性价比合理：涉及性能价格的权衡，尤其是在资源的使用方面。 解决方案： 工程是有创造性和实效性的。 现实问题：问题是受人们关注的。 科学知识：用到应用科学中的分析方法 3. 软件工程的特殊性 软件的特殊性 （1） 软件具有抽象性 软件是不能独立存在的，其作用在于驱动硬件进行某种操作 （2） 软件行为不受物理定律约束 （3） 软件复杂性不受物理限制 （4） 软件无磨损 传统的可靠性度量方法不再适用 （5） 软件复制无损耗 复制品与原件无区别 4. 什么是需求工程？ 需求工程是系统工程及软件工程的重要分支。 需求工程旨在了解软件系统设计的真实意图，具体功用及限制条件。并精确定义上 述因素与系统行为的关系及系统随时间和产品线变化而发生的各种演化 5. 需求的层次 软件需求包括三个不同的层次 （1）业务需求 反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视 图与范围文档中予以说明。 （2）用户需求 描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本 说明中予以说明。 （3）功能需求（包括非功能需求） 定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从 而满足了业务需求。 6. 需求层次实例： （1）业务需求 用户能有效地纠正文档中的拼写错误。 （产品包装盒封面上可能会标明这是个满足
业务需求的拼写检查器。 ） （2）用户需求 找出文档中的拼写错误并通过一个提供的替换项列表来供选择替拼错的词。 （3）功能需求 包含多个功能需求 如：找到并高亮度提示错词的操作； 显示提供替换词的对话框； 可以实现整个文档范围的替换。 7. 需求开发与需求管理 需求工程域的层次分解示意图：
包括软件类产品中需求收集、评价、编写文档等所有活动 <1> 需求开发活动包括： 确定产品所期望的用户类。 （1）获取每个用户类的需求。 （2）了解实际用户任务和目标以及这些任务所支持的业务需求。 （3）分析用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建 议解决方法和附加信息。 （4） 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 （5） 了解相关质量属性的重要性。 （6） 商讨实施优先级的划分。 （7） 将所收集的用户需求编写成规格说明和模型。 （8） 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开 发小组接受说明之前将问题都弄清楚。 <2> 需求管理活动包括： (1) 定义需求基线（迅速制定需求文档的主体） 。 (2) 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。 (3) 以一种可控制的方式将需求变更融入到项目中。 (4) 使当前的项目计划与需求一致。 (5) 估计变更需求所产生影响并在此基础上协商新的承诺（约定） 。 (6) 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。 (7) 在整个项目过程中跟踪需求状态及其变更情况 8. 常见的需求问题 知识技能问题 合作关系 用户参与不足 用户需求扩展 有岐义的需求 镀金问题 过于抽象的需求 忽略了某类用户 不准确的计划
9. 软件生命周期中的需求活动 (1) 瀑布模型 核心思想： 系统开发是逐步求精的过程 各步骤相对独立，便于管理 存在的问题： 忽略了需求的动态性 需求完成后，用户对项目的参与即停止 需求描述与设计分开 不支持原型的使用和软件重用 (2) 原型法 适用范围： 用于获取关于系统用户界面的需求 用于检验设计方案的可行性，或探讨系统性能问题 存在的问题： 用户将原型误认为最终系统 原型所反映的系统是不全面的 (3) 增量式开发与演化式开发
(4) 螺旋模型 螺旋模型主要用于风险分析 每一轮开发活动具体包括: 制定下一轮计划 决定设计目标和限制条件 评估候选方案, 风险降解 产品开发 需求工程有关步骤为： 需求风险分析 规划设计 可以减少需求变更所带来的风险 存在的问题： 无法应付不可预见的需求变化 (5) 关于敏捷模型 基本原则： 减少沟通障碍 程序员与客户直接交流 减低繁重的文档负担 文档代价昂贵但用途有限
对开发人员给予充分信任 无需运用花样翻新的过程模型给与提示 响应客户要求 而非严格遵循合同条文 缺点： 依赖程序员的记忆力 源代码是难于维护的 依赖口头交流 易发生误解 假定只有唯一的客户代表 不可能反映多视角 制作短期计划 无长期及前瞻性规划
