业务需求代表的是需求链的顶部。它们定义解决方案的愿景和实现该方案的项目范围。用户需求和功能需求和功能需求必须与业务需求建立的背景和目标保持一致。任何无助于项目达成业务目标的需求都不宜实现。
如果项目没有清晰的定义和充分沟通方向，肯定会带来灾难性的结果。参与者如果不能保持目标和优先级的一致性，工作方向就会不自觉地南辕北辙。如果对项目的业务目标缺乏共同的理解，干系人永远无法就需求达成一致意见。团队如果不能提前意识到这一点，即使劳神费力交付合格的产品，项目也很可能超期，预期也可能超支。
总的来说，“业务需求”是一组信息，描述的是需要，在此需要的指导下，一个或多个项目交付一个解决方案和符合预期的最终业务成果。业务机会、业务目标、成功标准和一个愿景声明共同构成了业务需求。
在完全指定功能和非功能需求之前，我们必须解决业务需求的问题。项目范围和限制声明在很大程度上有助于后期对提议特性和发布目标的讨论。业务需求为提议的需求变更和提供决策参考。我们建议在每个需求获取工作坊上重点展示业务目标、愿景和范围，以便让团队可以快速判断某个提议的需求是否在项目范围内。
业务需求设置业务背景，提供衡量体系业务希望通过该项目达成怎样的收益。组织如果不清楚项目能为业务增加什么价值，就不要启动任何项目。为业务目标设置为可度量的目标，然后定义指标，以便衡量是否在实现这些目标的正确轨道上。
业务需求可能来自出资方、企业高管、市场部经理或产品规划者。但是确定和沟通业务收益却不那么简单。团队成员有时并不确定项目想要达成什么目标。有时，赞助商不愿意以某种可度量的形式来设定目标并进而负担起实现这些目标的重担。还有可能多个重要干系人无法对目标达成一致。业务分析师应能够确保有合适的干系人设置业务需求和引导获取活动，优先级排序和解决冲突。
业务收益必须体现对项目发起人和产品客户的真正价值。
业务需求的两个核心元素是愿景和范围。产品愿景简要描述最终产品将要达成什么业务目标。该产品可以作为业务需求的完整解决方案或解决方案的一部分。愿景描述产品大约是什么并且最终变成什么。它提供整个产品生命周期中决策的背景，让所有干系人团结在一个共同目标之下。项目范围明确当前项目或开发迭代应强调最终产品愿景的哪些部分。范围声明描述的是项目内外的边界。
产品愿景保证我们都对最终目标心里有数。项目范围确保我们的讨论集中于当前项目或迭代中的同一件事。
愿景作为一个整体应用于产品。随着产品战略定位或公司业务目标随时间而演化，愿景也要做出相对缓慢的变更。范围适用于开发产品下个增量功能的项目或迭代。范围比愿景更动态，因为干系人会在进度、预算、资源和质量约束内调整每个版本的内容。当前版本的范围要清晰，但未来版本的范围越远越模糊。团队的目标是管理一个特定开发或改进型项目的范围，将其作为产品战略愿景中一个确定的子集。
业务需求收集来自多个来源，彼此可能有冲突。
各方干系人的目标有时也是一致的。
项目决策者不要指望软件团队来解决不同干系人之间的冲突。随着更多代表不同利益的干系人出现，范围会随之增长。如果范围蔓延失控，干系人试图兼顾利益各方面不断给系统施压，会导致项目不堪重负而崩溃。这时通过消除潜在冲突和互斥的假设，标记出有冲突的业务目标，对不能达成目标的特性给出说明，协调和解决冲突，业务分析师就能大展身手了。
项目周期比较长的话，决策者通常会中途改弦易辙。如果遇到此类问题，建议立即与新决策者检查业务基线业务需求。了解现有业务需求，并对其进行修改。项目经理调整预算、时间表与资源，而业务分析师需要与干系人共同更新和确定用户及功能需求，并重新设置他们的优先级。
愿景和范围文档将业务需求集合合为一个独立的交付物，为后续开发奠定基础。有些组织会为此创建一个项目章程或一个业务用例文档。构件商业软件的组织通常会建立一个市场（或营销）需求文档。需求文档（MRD）可能更侧重于目标市场细分和关乎商业成败方面的问题。
愿景和范围文档的所有者是项目的执行发起人、出资方或类似的角色。业务分析师可以和这个人一起明确业务需求并记录下愿景和范围文档。业务需求的来源应当是清楚知道项目动机的人。这些人可能包括客户或开发组织的高级管理人员、项目规划师、产品经理、主题专家或市场部门的成员。
下图5-3给出了一个愿景和范围文档的模板。
不管使用哪种模板，目的都是满足项目的具体需要。如果已经将此信息记录在其他地方，就不要将其复制到愿景和范围文档中。愿景和范围文档的一些元素可以重用于不同的项目如业务目标、业务风险和干系人简介。
愿景和范围文档只是在高层面上定义范围，团队定义的每个版本基线体现的是范围的细节。大多数新项目都有一个完整的愿景和范围文档以及一个SRS。每个迭代、版本或针对老产品的增强型项目都可以将其范围申明归入项目的需求文档，不需要创建一个独立的愿景和范围文档。
可以有多种方式表示项目范围。不需要创建所有这些模型，只需要考虑哪个模型可以为每个项目提供最有用的见解。这些模型可以记录在愿景和范围文档中或存储在其他位置，以备不时之需。
我们使用关联图、生态系统图、特性树和事件列表这些工具，目的是在项目干系人之间培养清晰和准确的沟通机制。这种清晰比硬性规定符合所谓“正确”的图表规则更重要。不过，我们仍然采用下面实例中的符号系统作为标准。
关联图、生态系统图、特性树和事件列表是最常见的范围可视化表示。当然，我们还可以使用其他技术手段。识别出受影响的业务过程也可以帮助定义范围边界。我们可以通过用例图来描述用例与角色之间的边界范围。
范围描述为我们正在开发的系统和周围所有事物之间建立的边界和连接。关联图直观展示了这个界限。它确定通过某一接口与系统相连的外部实体（也称“端点”），同时还包括数据、控制以及端点和系统之间的物料流转。关联图是按照结构化分析原则来制定的数据流图的最高抽象层，但它适用于所有项目。
图5-6展示了化学品跟踪系统的部分关联图。整个系统被描述为一个单循环，关联图有意不提供可视化的内部对象、流程或数据可视化表示。该循环内部的“系统”可以包括任意软件、硬件和人。因此，它还将人工操作作为整个系统的一部分囊括进来。
展示了所有与系统利益相关的系统相互作用以及这些互动的本质。生态系统图表示了系统的范围，表明所有系统都相互关联，因此需要修改以适应新系统。生态系统图表示系统的范围，表明所有系统都相互关联，因此需要修改以适应新系统。生态系统图与关联图的区别在于，它展示的是正在开发的系统与其他系统的关系，包括没有直接接口的系统。通过判断哪些系统正在使用你的系统数据，找出受影响的系统。一旦到达某一点，也就是项目不再影响其他任何数据的时候，就能发现参与解决方案的那个系统的范围边界。
图5-7是化学品跟踪系统的部分生态系统图。
上图表明，化学品跟踪系统不直接连接到OSHA/EAP报告接口。即便如此，也需要考虑化学品跟踪系统中是否有需求问题，因为有数据通过健康和安全事故数据库从系统中流出，并流向报告接口。
特性树形象地展示按逻辑分组的产品特性，并将每种特性逐级分解到下一级细节。特性树为项目所有计划功能提供了一个简洁的视角，使其成为一个理想模型，使管理者对项目范围有一个快速的印象。功能树可以显示三个层次的特性，通常称为一级（L1）、二级（L2）、三级（L3）特性。L2特性是L1的子特性，L3特性则是L2的子特性。
图5-8显示了化学品跟踪系统的部分特性树。树干表示正在实现的产品。
事件列表确定了可能引发系统行为的外部事件。它描述系统的范围边界，明确可能被用户触发的业务事件、由时间触发的事件或从外部组织接收到的信号事件，例如硬件设备。事件列表只列出事件的名称，SRS文档中的功能性需求通过“事件-响应表”描述系统如何应对事件的发生。
下面是化学品跟踪系统的部分事件列表：
化学品跟踪系统的外部事件：
注意，事件列表是对关联图和生态系统图的补充。关联图和生态系统图共同描述涉及的外部角色和系统，而事件列表确定这些角色和系统在特定系统中可能触发的行为。为了正确和完整，你可以使用关联图和生态系统图来检查事件列表。
范围定义的是结构，不是约束。业务需求和对用户如何使用产品的理解可以提供有价值的工具来处理范围变更。范围变更并不是坏事，它能够帮助你驾驭项目，满足客户不断变化的需求。愿景和范围文档中的信息可以让你评估是否把提出的需求加入该项目。如果合适的人明确提出，出于合适的商业目的，大家相互理解达成一致，就可以为将来的迭代或者整改项目修改范围。
业务目标是做范围决策时最重要的考虑因素。确定哪些特性或用户需求能够给业务目标带来更多价值，将这些内容安排到早期版本中。当干系人想要添加某功能时，考虑他的建议是否有助于达成业务目标。
如果可能，量化特性对业务目标的贡献，让人们可以基于事实而非个人感情做出范围决策。
当项目范围增加时，项目经理通常得重新计划预算、资源、排期和人员。理想情况下，最初时间表和资源能够容纳一定的变化，因为会预留缓冲空间。不然，需求变更审核通过后，需要重新制定计划。
范围变更的常见后果是完成的工作必须重做以响应这些变量。新功能添加时，资源和时间并没有相应增加，质量通常受损。伴随市场或者业务需求的变化，业务需求文档能使我们更合理地管理范围。
敏捷项目通常由一系列时间固定的迭代组成，这些项目管理范围采用不同的方法。敏捷项目中每个迭代的范围由用户故事组成，而用户故事是从一个动态的产品Backlog中结合相对优先级和团队速率挑选出来的。为了对抗范围的蔓延，团队对新需求和原有需求进行排序，然后分配到随后的迭代中。迭代的数量取决于整体项目的周期，依赖于总的功能数量，敏捷项目控制每个迭代的范围，确保其按时完成。还有一些敏捷项目固定时间，但接受范围的更改。迭代的数量可能保持不变，但剩下的迭代范围依照已有的和新定义的用户故事优先级做相应的改变。
团队可以在项目开始时定义一个概要的迭代路线图，每个迭代开始前安排用户故事。团队参考业务需求为每个迭代确定范围将有助于项目交付的产品满足业务目标。相同的策略可以应用与所有遵循时间盒开发流程的项目。
怎么知道什么时候该停止开发？传统意义上，项目经理管理项目直至完成。但是业务分析师其实更了解业务目标并能够帮助判断什么时候交付客户需要的价值（意味着工作完成）。
如果有一个解决方案清晰的愿景，每个版本或迭代是交付总体功能的一部分，那么完成预先计划的迭代就表明完成了整个项目。已完成的迭代应该完全实现产品愿景并且满足业务目标。
然而，在迭代开发中，终点可能并不清晰。每个迭代中，范围是为迭代定义的。随着项目进行，未完成的工作不断减少。并不总是有必要实现所有剩下的功能。拥有清晰的业务目标至关重要，随着信息逐渐可用，可以逐步满足这些目标。当成功指标显示你很可能达成了业务目标，项目就可以结束了。模糊的商业目标肯定出现一个开放式的项目，无法知道什么时候才算完成。出资方不喜欢这样，因为不知道如何为这样的项目做预算、排期和计划。客户不喜欢这样，因为他们也许会收到一个既按时又满足预算的解决方案，但就是无法提供他们想要的价值。项目之初不能清晰定义的部分目标如果仍然不在项目过程中加以细化，可能会酿成风险。
始终专注于为所有项目定义清晰的业务需求。不然，你会漫无目的地，摸索着完成一些看似有用的东西，却无从得知是否真正完成。
