第一章 需求工程之软件需求的本质

第一章 软件需求的本质

需求的定义

需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。

需求的维度

• 时间纬度
  • 近期（高优先级）实现
  • 中期（中等优先级）实现
  • 想象中（低优先级）实现
• 空间维度
  • 业务需求
  • 用户需求
  • 功能需求

需求的种类

业务需求

• 开发产品的组织或者获取产品的客户所需的高层次业务目标。
• 为什么要执行系统，系统能给业务目标实现提供帮助。

业务规则

• 策略、纲领、标准或制度，能够定义或者约束某些方面的业务
• 包括公司政策、政府法规、工业标准以及计算算法等。
• 本身不是软件需求，但是又决定了系统必须具备的功能（制约因素）
• 特定的功能需求可以追溯到具体的业务规则

约束

对开发和设计人员在产品构建和设计的上的限制

外部界面需求

对软件系统和用户、其他软件系统或者硬件设备间的关联进行说明。

特性

• 单个或多个为用户提供价值的、有逻辑关系的系统性能，可以通过一个功能需求集合进行描述
• 客户预想的产品特性清单与描述客户的任务相关的需求不能画等号。
• 特性包含多种用户需求

功能需求

• 描述系统在特定条件下展现的行为
• 开发人员需要实现的功能
• 达成用户需求
• 进而达成业务需求

非功能需求

描述系统必须展现的属性或者特性，或者必须遵守的约束。

• 质量属性
  一种非功能性需求，描述的是服务或产品的性能特征
• 系统需求
  包含多个子系统的产品的顶层需求，子系统可以是软件或硬件。
• 用户需求
  • 特定用户群必须能够用系统所完成的目标或任务，或者是用户期望的产品属性
  • 能够为用户提供价值
  • 包括对用户满意度最为关键的产品特性或特征的描述。
  • 表达用户通过系统来完成哪些具体的工作。

需求模型

需求处理模型

需求交付物

• 愿景和范围文档
• 用户需求文档
• 软件需求规格说明书

需求工程

需求开发

需求开发的总体目标

积累优秀的需求共识，保证产品下一部分的开发，并将风险控制在可以接受的范围之内。

获取

• 获取活动
  • 识别产品的预期客户群和其他干系人
  • 了解客户任务、目标以及与这些任务相关的业务目标
  • 了解新产品的应用环境
  • 与每一类客户群代表一起工作，理解他们对功能有哪些需要以及对质量有怎么样的预期。
• 获取策略
  • 以用途为核心
    • 强调对用户目标的理解和探求，以便提取必要的系统功能
  • 以产品为核心
    • 侧重于特性，目的是领先市场或者业务取得成功

分析

分析需求设计深入并准确立即每个需求，然后将各个需求以不同的方式表达出来

• 分析基本活动
  • 分析来自用户的信息，将任务目标与功能需求、质量预期、业务规则、建议解决方案和其他信息区分
  • 将概要需求进行适当的细分
  • 从其他信息需求中引出功能需求
  • 理解质量属性的相对重要性
  • 将需求分配给系统架构所定义的软件组件
  • 协商需求实现的优先级别
    找出需求中的遗漏或多余的、不必要的需求、以便定义范围。

规范说明

需求规范说明以一种连贯并结构清晰的方式表达和存储收集到的需求知识

• 主要活动
  • 将收集到的用户需求转换为书面形式的需求和图表，工目标读者理解、检查和使用。

验证

需求验证是指确认需求信息是正确的，能使开发人员制定出能满足业务目标的解决方案。

• 中心活动
  • 检查记录下来的需求，交给开发团队认可之前解决所有问题
  • 开发验收测试盒标准，保证产品的开发是建立在需求基础之上的，能满足客户需要并达成业务目标。
    迭代式成功需求开发的关键，规划处多周期的需求探究活动，逐步优化概要需求，使其进一步准确和细化。并与用户共同确认得出正确的需求。

需求管理

需求管理活动

• 及时确定需求基线
  • 当前时间段可参考
  • 相关干系人达成一致的功能需求和非功能需求
  • 应用于具体的产品发布或开发迭代
• 评估提议需求变更可能产生的影响，然后已可控方式将获准的变更融入项目
• 随着需求的演化，保持项目计划与需求同步
• 根据预估的需求变更可能带来的影响，商定新的承诺
• 定义各个需求间存在的关系和依赖
• 跟踪每个需求到他们各自对应的设计、开发、测试。
• 在整个项目过程中跟踪需求状态和变更活动

需求管理的目标不是抑制变更或加大其难度，而是为了预测和协调不可避免且实际存在的变更，最终最小化变更对项目的破坏性影响。

需求管理模型

需求风险

• 用户参与度不够
• 规划不当
  • 频繁需求变更
  • 需求遗漏
  • 与用户沟通不足
  • 低质量的需求规范
  • 不完善的需求分析
• 用户需求蔓延
  • 一开始就明确业务目标、战略愿景、范围、边界和成功标准
• 需求模棱两可
  • 同一个人对需求可以用多种方式来解读
  • 不同的人对同一需求理解各不相同
  • 让具有不同视角的人来检查需求
• 镀金
  • 开发人员增加的功能并在需求范围之内。但开发人员认为“用户肯定喜欢”。
  • 客户提出的看似合理，但对产品不能增加的价值微乎其微。
  • 降低镀金风险，需要对每个功能单元跟踪溯源，了解功能的意义和价值。
• 忽视干系人

高质量需求过程的好处

有效的需求过程强调的是协同开发产品，并在整个项目过程中将干系人视为合作伙伴。
准确的讲需求分配给不同的软件、硬件和人工子系统是一种构件产品的系统方法。
有效的变更控制过程可以最小化需求变更可能带来的负面影响。
将需求清晰的记录下来对系统测试有着极大的帮助。

• 需求中的缺陷和交付产品中的缺陷更少
• 开发的返工减少了
• 开发和交付更快
• 不必要和无用的特性更少
• 减少成本追加
• 错误信息传达的现象减少了
• 范围蔓延减少了
• 项目混乱现象减少了
• 客户和团队成员的满意度更高了
• 产品按照人们当初的设想顺利进行。