第五章 需求工程之建立业务需求

建立业务需求

• 业务需求代表的是需求链的顶部
• 业务需求定义解决方案的愿景和实现该方案的项目范围
• 用户需求和功能需求必须与业务需求建立的背景和目标保持一致
• 任何无助于项目达成业务目标的需求都不宜实现。
• 如果项目没有清晰的定义和充分的沟通方向，肯定会带来灾难性的结果
• 参与者如果不能保持目标和优先级一致性，工作方向就会不自觉地南辕北辙
• 如果对项目的业务目标缺乏共同的理解，干系人永远无法就需求达成一致意见
• 团队如果不能提前意识到这一点，即使劳神费力交付合格产品，项目也很可能超期，预算也可能超支。

定义业务需求

业务需求是指一组信息，描述的是需要，再次需要的指导下，一个或多个项目 交付一个解决方案和符合预期的最终业务成果。业务机会、业务目标、成功标准和一个愿景声明共同构成了业务需求。

• 业务需求
  • 业务机会
  • 业务目标
  • 成功标准
  • 愿景申明
    在完全制定功能和非功能需求之前，必须先解决业务问题。项目范围和限制申明在很大程度上有助于后期对提议特性和发布目标的讨论。业务需求为体验的需求变更和提供决策参考。
    建议在每个需求获取工作坊上重点展示业务目标、愿景和范围，以便让团队可以快速判断某个提议的需求是否在项目范围内。

确定预期的业务收益

• 业务需求设置业务背景，提供衡量体系业务希望通过该项目达成怎样的收益。
• 组织不清楚项目能为业务增加什么价值，就不要启动项目
• 为业务目标设置可度量的目标，然后定义指标，以便衡量是否在实现这些目标的正确轨道上。
• 业务收益必须体现项目发起和产品客户的真正价值

业务需求的来源

• 出资方
• 企业高管
• 市场部经理
• 产品规划者

确定业务收益的障碍

• 赞助商不愿意以某种刻度量的形式来设定目标，并进而负担起实现这些目标的重担
• 多个重要干系人无法对目标达成一致

确定业务目标方法

• 业务分析师应该能够确保有合适的干系人设置业务需求和引导获取活动
• 解决优先级排序冲突
• 原则是为企业降本增效
• 设计法规和法律的项目也会有明确的业务目标，桶市场规避风险，比如避免被起诉或叫停等。

产品愿景和项目范围

• 业务需求的核心元素
  • 愿景
    • 简述最终产品将要达成什么业务目标
    • 该产品可以作为业务需求的完整解决方案或解决方案的一部分
    • 产品大约是什么最终能改变什么
    • 提供整个产品生命周期中决策的背景
    • 让所有干系人团结在一个共同目标之下
    • 干系人对最终目标心中有数
    • 愿景作为一个整体应用于产品
    • 随着产品战略定位或公司业务目标随时间而演化，愿景也要做出缓慢的变更
  • 范围
    • 申明描述项目内外的边界
    • 明确当前项目或开发迭代应强调最终产品愿景的那部分
    • 确保我们的讨论集中于当前项目或迭代中的同一件事
    • 范围适用于开发产品下个增量功能的项目或迭代
    • 当前版本的范围要清晰，但未来版本的额范围越是远期越模糊

业务需求冲突

• 起因
  • 业务需求来源多方，彼此可能有冲突
  • 价值或目标不一致
• 解决
  • 项目的决策者必须解决这些冲突
  • 通过消除潜在冲突和互斥假设
  • 标记出有冲突的业务目标
  • 对不能达成目标的特性给出说明
  • 协调解决冲突
  • 涉及政治斗争和权利斗争
• 原则
  • 重点应该集中于为首要干系人交付最大价值（如何定义首要干系人，需要分析价值链模型）
  • 人们很容易被肤浅的产品特征所迷惑，这些特征并不会实际解决业务目标。
  • 项目决策者不要指望软件团队解决不同干系人之间的冲突
• 后果
  • 随着更多代表不同利益的干系人出现特性围会随之增长，导致范围蔓延失控，干系人试图兼顾各方利益而不断给系统施压，会导致项目不堪重负二崩溃。
• 异常情况
  • 项目周期较长，决策者通常会中途改弦易辙
  • 立即与新决策者检查基线业务需求
  • 了解现有业务需求，并对其进行修改
  • 调整预算、时间表、和资源
  • 业务分析师需要与干系人共同更新和确定用户及功能需求，并重新设置他们的优先级。

愿景和范围文档

• 愿景和范围文档将业务需求结合合为一个独立的交付物，为后续的开发工作奠定基础
• 有些组织会为此创建一个项目章程或一个用例文档
• 构件商业软件的组织通常会监理一个市场（或营销）需求文档（MRD，market requirements document）
• MRD可能更侧重于目标市场细分和关于商业成败方面的问题
• 愿景和范围文档的所有者是项目的执行发起人、出资方或某个类似的角色
• 业务分析师和这些人一起明确业务需求并记录下愿景和范围文档
• 业务需求的来源应当是清楚指导项目动机的人
• 愿景和范围文档只是在高层面上定义范围，团队定义的每个版本基线体现的是范围细节
• 大多数项目都有一个完整的愿景和范围文档以及一个SRS
• 每个迭代、版本或者针对老产品的增强型项目都可能将其范围声明归入项目的需求文档，不要创建一个独立的愿景和范围文档。

愿景和范围文档模板

1. 业务需求

• 项目启动往往基于一个想法：创造或修改一个产品，为某些人提供有价值的好处和一个合理的投资回报
• 业务需求描述新系统能为其出资方、卖家以及用户提供主要的收益
• 业务需求直接影响着用户需求的实现和顺序

1.1 背景

• 总结新产品或对现有产品进行变更的依据和环境
• 描述产品开发的历史背景或形式

1.2 业务机遇

• 对企业信息系统，描述要解决的业务问题或要改善的流程以及系统的应用环境。
• 针对商业产品，描述现有的业务机会和产品的竞争市场
• 描述对现有产品的对比性评估并指出提议产品为什么有吸引力及其优势
• 描述在没有预想解决方案的情况下，目前无法解决的问题。
• 说明提议产品如何符合市场潮流、技术演化或公司的战略方向。
• 李珏其他所有必要的技术、流程和资源，力求提供一个完整的客户解决方案。
• 描述典型客户或目标市场的需要
• 提出新产品要解决的客户问题
• 提供用户使用产品的范例
• 定义任何已知的关键接口或质量要求，但忽略设计或执行的细节。

1.3 业务目标

• 用定量和可测量的方式总结产品带来的重要商业利益。
• 财务目标
  • Y个月内占领X%的市场份额
  • 在Z个月内，在W国的市场份额从X%增加到Y%
  • 在Z个月内，实现X套销售量或Y元的收入
  • 在Y个月内实现X%的投资回报
  • 在Y个月内实现该产品的盈利
  • 每年节约X元遗留系统当前的高额维护费
  • 在Z个月内将每月的支出成本从X元降到Y元
  • 一年内，毛利率从当前X%增加到Y%
• 非财务目标
  • 在发布的Y月内，客户满意度至少要达到X
  • 交易处理率增加X%，并将数据错误率降到X%
  • 为相关产品系列开发一个可以扩展的平台
  • 发展具体的核心技术竞争力
  • 在产品公测的具体日期截止日时，被大家认为可靠性最高的产品
  • 符合具体的法律法规
  • 在发布Z月之内，将每个单位的服务电话控制在不超过X各，维保电话不超过Y各
  • 将支持电话中的Y%的周期时间降到X小时。
• 业务目标模型展示了一个层级术的相关业务问题和可衡量的业务目标
• 问题描述了当前使业务无法实现目标的真正原因
• 目标则定义了衡量这些目标是否实现的种种方式
• 目标和问题彼此交织，理解一个就能揭示另外一个。
• 启动项目是为了解决某个问题或抓住某个机会
• 确定问题的提问
  • “阻止我们实现这个目标是什么？”，目的确定一个更详细的业务问题
  • “为什么我们关心这个目标？”，目的是更好的立即概要性的业务问题或机会
  • “我们如何评估问题是否解决了？“，目的是确定可衡量的目标
  • 以上过程是循环迭代，逐层深入的。

1.4 成功的标准

• 确定干系人用来定义和衡量项目成功的指标
• 确定对项目成功有重大影响的因素
  • 组织能掌握的因素
  • 组织部能掌握的因素
• 业务目标有时在项目完成前无法衡量
• 业务目标的实现可能取决于其他项目而非你当前的项目。
• 对每个独立的项目进行成功指标评估仍然很重要
• ![[业务问题目标模型.excalidraw]]

1.5 愿景声明

• 写一个简洁的愿景声明，总结产品的长远目标和意图
• 愿景声明应当折射出一个均衡的视角，满足不同干系人的期望。
• 适当理想化，但不宜脱离显示或预期的市场、企业架构、公司战略方向和资源限制
• 愿景关键字
  • 针对【目标客户】
  • 对象【陈述需求或】
  • 产品【产品名称】
  • 是【产品类型】
  • 具体的【主要的功能、关键收益、吸引人购买或使用的理由】
  • 不同于【主要竞争产品、当前系统、当前的业务过程】
  • 我们的产品【陈述产品的主要不同点和优势】
• 可以让不同的干系人单独写出各自的愿景声明
• 比较他们的愿景声明，可以发现大家对项目目标的不同理解
• 写愿景声明不分早晚，及时项目已经进行，制定愿景申明也可以帮助剩余的工作走上正轨并保持专注
• 制定正确的愿景声明，并与重要的干系人达成一致需要花费一些时间。

1.6 业务风险

• 总结与开发（或不开发）该产品有关的主要业务风险
• 如，市场竞争，时机问题、用户接受能力、实现过程中的问题、以及对业务可能造成的消极影响。
• 业务风险不同于项目风险
• 估算每个风险的潜在损失、发生的可能性，并采取任何潜在的应对措施

1.7 业务假设和依赖

• 所谓假设是在没有证据或确定知识的情况下先认定其为真的一种说明。
• 业务假设与业务需求是明确关联的。如果假设错误，业务目标就可能无法实现。
• 如果了解到某些假设是错误的，可能得变更范围、调整计划或启动其他项目来实现目标。
• 在构思项目并写愿景和范围文档时，记录干系人做出的任何假设。
• 通常一方所持的假设都不同于另一方的，需记录并审查，以防混淆和冲突。
• 将项目对外部因素的所有重要依赖都记录下来。
• 一些业务假设和依赖关系可能会变成风险。
• 依赖被破坏是造成项目延迟的常见因素
• 记录错误假设的影响或被破坏依赖的影响。

2. 范围和限制

• 陈述正在开发中的解决方案是什么和不是什么。
• 很多项目深受范围蔓延的困扰（产品中不断加入新功能），范围难以控制。
• 控制范围蔓延的第一步是定义项目范围。
• 范围对提议解决方案的概念和适用领域进行描述。
• 限制规则支出产品不包括的某些[[第一章 软件需求的本质#[[第一章 软件需求的本质特性，但有些人还是会假定其存在。
• 范围和限制会帮助干系人建立现实的期望，有时客户所要求的的特性不是过于昂贵就是超出预期的项目范围。
• 在高层面上，范围定义的是客户确定要实现哪些业务目标
• 在交底层面上，范围定义的是特性、用户故事、用例或事件和响应
• 范围最终实在计划某个具体的版本或迭代时通过一组功能需求定义的。
• 在每个层面上，范围必须限定要在其上一级的边界范围之内。
  • 范围内的用户需求必须与业务目标相匹配
  • 功能需求必须与范围内的用户需求相匹配
• 团队想尽早交付一个有用的产品，最好采用范围管理和增量式开发方法。

2.1 主要特性

• 列出产品的主要特性或用户功能
• 把不同于以前或竞品的部分标注出来
• 将看似有趣，但无法提供客户价值的不必要的特性排除在外
• 为每个特性打上独特而持久的标签，以便在其他系统要素中进行跟踪
• 考虑使用特性树示意图

2.2 最初版本的额范围

• 总结计划在首发版本中的功能
• 范围通常用特性的形式来定义，还可用用户故事、用例、用例流或外部事件等多种形式
• 描述质量特征，是产品能为其不同类型的用户提供预期的好处
• 避免将任何潜在客户想要的每一个特性都囊括在1.0版本中
• 潜在的范围“加料“造成软件臃肿和计划失败
• 关注的特性应当能够在最早的时间框架内、以最能接受的成本、向最广大的群体提供最多的价值

2.3 后续版本的范围

• 构建一个发布路线图，以实现阶段性演进或迭代或增量式的生命周期
• 指出哪些功能模块将被推迟以及后续版本的预期时间点
• 后期版本发布会实现更多的用例和特性，为首发版本不断附加价值
• 看得越远，未来的范围越模糊，同时变更的可能性越大
• 添加之外的需求时需要考虑从一个迭代移一些功能到另一个迭代中
• 短周期的版本可以提供频繁的机会让我们从客户反馈中学习

2.4 限制和排除

• 列出干系人期望，但不计划纳入在产品范围或特定版本中的产品功能或特性
• 列出从范围中去掉的条目，让大家清楚地记住这个范围决策

3. 业务背景

提出主要干系人类别的简介，项目优先级的管理和在规划解决方案部署时要考虑的一些因素。

3.1 干系人简介

• 干系人是主动参与项目的人、团队或组织，会受项目结果的影响或影响项目结果。
• 描述项目不同的客户类型和其他关键干系人
• 专注于不同的客户类型、细分的目标市场和细分市场里不同的用户类型。
• 每个干系人包含的属性
  • 干系人从产品中获得的主要价值或好处
    • 提高的生产力
    • 减少返工和浪费
    • 节约的成本
    • 简化的业务过程
    • 将之前的手工任务自动化
    • 执行全兴任务的能力
    • 符合有关标准或法规
    • 与现有产品相比，易用性有所提升
  • 他们对产品的预期态度
  • 感兴趣的主要功能和特点
  • 必须加以解决的任何已知约束

3.2 项目优先级

• 为了使决策有效，干系人必须对项目的优先级达成一致
• 从五个维度考虑
  • 功能
  • 质量
  • 进度
  • 成本
  • 员工
• 每个维度都要与下面三个因素之一相适应
  • 约束，项目经理必须管理的限制因素
  • 动机，一个重要的成功目标，灵活性有限，不能调
  • 自由度，项目经理可以根据其他维度来调整和平衡因素
• 项目经理面临的挑战是在约束施加的范围内调整自由度以驱动项目的成功

3.3 部署的注意事项

• 总结必要的信息和活动，确保解决方案可以有效部署到操作环境中
• 描述用户对该系统的访问方式，如跨时区还是彼此相邻
• 表明不同地方的用户分别在什么时间访问系统
• 如由于软件能力、网络访问、数据存储或数据迁移需要而变更基础设施，需要记录变更
• 如需要准备培训或为部署新的解决方案而修改业务过程，需要将信息记录下来。

范围表示技巧

• 目的是在项目干系人之间培养清晰和准确的沟通机制
• 这种清晰比硬性规定符合所谓的“正确”的图表规则更重要
• 范围描述为我们在正在发的系统和周围所有事物之间建立的边界和连接

关联图

• 确定通过某一接口与系统相连的外部实体（也成为“端点”）
• 还包括数据、控制以及端点和系统之间的物料流转
• 是按照结构化分析原则来制定的数据流图的最高抽象层，适用于所有项目
  

生态系统图

• 展示了所有与系统利益相关的系统相互作用以及这些互动的本质。
• 生态系统图表示系统的范围，表明所有系统都相互关联，因此需要修改以适应新系统
• 展示地 是正在开发的系统与其他系统的关系，包括没有直接接口的系统
• 通过判断哪些系统正在使用你的系统数据，找出受影响的系统
• 一旦到达某一点，也就是项目不再影响任何其他的数据的时候，就能发现参与解决方案的那个系统的范围边界。
• 一些数据流也可以出现在关联图中
  

特性树

• feature tree 形象的展示按逻辑分组的产品特性
• 将每种特性逐级分解到下一级细节
• 特性树为项目所有计划功能提供了一个简洁的视角，使其称为一个立项的模型，使管理者对项目范围有一个快速的印象
• 功能数可以显示三个层级的特性
  • L1级
  • L2级，是L1的子特性
  • L3级，是L2的子特性
• 树的主干代表正在实现的产品
• 每个特性都有它自己的线或从主干上延伸出来的“分支”
• 在做版本或迭代规划时，可以选择一组明确的特性和子特性定义其范围
• 可以在一个特定的版本实现一个完整的特性
  

事件列表

• 确定了可能引发系统行为的外部事件。
• 描述系统的范围边界，明确可能被用户触发的业务事件、由时间触发的事件、或从外部组件接收到的信号事件。
• 事件列表值列出事件的名称
• SRS文档中的功能性需求通过“事件-响应表”描述系统如何应对事件的发生。
• 时间列表是对关联图和生态系统图的补充
• 关联图和生态系统图共同描述涉及的外部角色和系统，事件列表确定这些角色和系统在特定系统中可能触发的行为。
• 使用关联图和生态系统图来检查事件列表。
  • 思考关联图中的每个外部实体是否是事件的来源，如“药剂师的任何事件是否都会触发系统的行为”
  • 考虑生态系统图中是否有某些系统会造成系统事件
  • 对于每个事件，考虑在关联图或生态图中是否有对应的外部实体。
  • 如果找到缺失环节，就要考虑模型中是否缺失元素。
    

聚焦于范围

• 范围定义的是结构，不是约束。
• 业务需求和对用户如何使用产品的理解可以提供有价值的工具来处理范围变更。
• 范围变更不是坏事，能帮助你驾驭项目，满足客户不断变化的需求。
• 愿景和范围文档的信息可以让你评估是否把提出的需求加入该项目
• 任何需求都要评估是否在范围内。
• 用户需求和范围需求之间存在一个反馈循环，要求不断更新愿景和范围文档，在文档被确认为基线后控制变更。

使用业务目标来做范围决策

• 业务目标是做范围决策时的重要考虑因素
• 确定哪些特性或用户需求能给业务目标带来最多的价值，将这些内容安排到早期版本中。
• 量化特性对业务目标的贡献，让人们可以基于事实而非个人感情做出范围决策。

评估范围变更的影响

• 范围增加时，项目经理通常重新计划预算、资源、排期和人员。
• 范围变更的后果是完成的工作必须重做以响应这些变量。
• 业务需求文档能使我们更合理地管理范围。

敏捷项目的愿景与范围

• 敏捷项目通常由一系列时间固定的迭代组成，范围管理采用不同的方法
• 敏捷项目中每个迭代的范围由用户故事组成
• 为了对抗范围的蔓延，团队对新需求和已有原需求进行排序，然后分配到随后的迭代中
• 敏捷项目控制每个迭代的范围，确保其按时完成。
• 团队在项目开始时定义一个概要的迭代路线图，每个迭代开始前安排用户故事
• 团队参考业务需求为每个迭代确定范围将有助于项目交付的产品满足业务目标。
• 敏捷项目虽然不创建正式的愿景和范围文档，但依然是与交付成功产品息息相关的要件。
• 许多敏捷项目都要做一个早期规划迭代定义总体产品愿景和其他业务需求。
• 所有软件项目都需要定义业务需求，不管他们采用哪种开发方法。
• 业务目标描述项目的预期价值，在敏捷中习惯用他们来帮助确定Backlog条目的优先级顺序。
• 愿景称述文档描述所有迭代要完成产品的长期计划。

使用业务目标来确定完成

• 已完成的迭代应该完全实现产品愿景并满足业务目标。
• 在迭代开发中，终点可能不清晰
• 每个迭代中范围是为迭代定义的
• 拥有清晰的业务目标至关重要，随着信息逐渐可用，可以逐步满足这些目标。
• 始终专注于为所有项目定义清晰的业务需求