- 建立业务需求
业务需求代表的是需求链的顶部。它们定义解决方案的愿景和实现该方案的项目范围。用户需求和功能需求必须与业务需求建立的背景和目标保持一致。任何无助于项目达成业务目标的需求都不宜实现。
定义业务需求
总的来说，“业务需求”指的是一组信息，描述的是需要，在此需要的指导下，一个或多个项目交付一个解决方案和符合预期的最终业务成果。业务机会、业务目标、成功标准和一个愿景声明共同构成了业务需求。
确定预期业务收益
业务需求设置业务背景，提供衡量体系业务希望通过该项目达成怎样的收益。组织如果不清楚项目能为业务增加什么价值，就不要启动任何项目。为业务目标设置可度量的目标，然后定义指标，以便衡量是否在实现这些目标的正确轨道上。
产品愿景和项目范围
产品愿景简要描述最终产品将要达成什么业务目标。
项目范围明确当前项目或开发迭代应强调最终产品愿景的哪些部分。范围声明描述的是项目内外的边界。
>产品愿景保证我们都对最终目标心里有数。项目范围确保我们的讨论集中于当前项目或迭代中的同一件事。
>随着产品战略定位或公司业务目标随时间而演化，愿景也要做出相对缓慢的变更。范围适用于开发产品下个增量功能的项目或迭代。
>范围比愿景更动态，因为干系人会在进度、预算、资源和质量约束内调整每个版本的内容。
业务需求冲突
>重点应该集中于为首要干系人交付最大的价值。
愿景和范围文档
>愿景和范围文档将业务需求集合合为一个独立的交付物，为后续的开发工作奠定基础。有些组织会为此创建一个项目章程或一个业务用例文档。
>愿景和范围文档的所有者是项目的执行发起人、出资方或某个类似的角色。业务分析师可以和这个人一起明确业务需求并记录下愿景和范围文档。业务需求的来源应当是清楚知道项目动机的人。
建议的愿景和范围文档模板
>愿景和范围文档只是在高层面上定义范围，团队定义的每个版本基线体现的是范围的细节。
1业务需求
业务需求描述新系统能为其出资方、买家以及用户提供的主要收益。业务需求直接影响着用户需求的实现和顺序。
1.1背景
描述产品开发的历史背景或形式。
1.2业务机遇
对企业信息系统，描述要解决的业务问题或要改善的流程以及系统的应用环境。针对商业产品，描述现有的业务机会和产品的竞争市场。本小节包括对现有产品的对比性评估并指出提议产品为什么有吸引力及其优势。描述在没有预想解决方案的情况下目前无法解决的问题。
描述典型客户或目标市场的需要。提出新产品要解决的客户问题。
1.3业务目标
用定量和可测量的方式总结产品带来的重要商业利益。
业务目标模型则展示了一个层级术的相关业务问题和可衡量的业务目标。
1.4成功指标
确定干系人用来定义和衡量项目成功的指标确定对项目成功有最大影响的因素，包括组织能掌握的因素和不能掌握的因素。
业务目标有时在项目完成前无法衡量。
1.5愿景声明
写一个简洁的愿景声明，总结产品的长远目标和意图。愿景声明应当折射出一个均衡的视角，满足不同干系人的期望。
>针对【目标客户】
>对象【陈述需求或机会】
>产品【产品名称】
>是【产品类型】
>具体的【主要的功能、关键收益、吸引人购买或使用的理由】
>不同于【主要竞争产品、当前系统、当前的业务过程】
>我们的产品【陈述新产品的主要不同点和优势】
1.6业务风险
总结与开发（或不开发）该产品有关的主要业务风险，例如市场竞争、时机问题、用户接受能力、实现过程中的问题以及对业务可能造成的消极影响。
1.7业务假设和依赖
>所谓“假设”，是在没有证据或确定知识的情况下先认定其为真的一种说明。业务假设与业务需求是明确关联的。
>在构思项目并写愿景和范围文档时，记录干系人做出的任何假设。
>将项目对外部因素的所有重要依赖都记录下来。一些业务假设和依赖关系可能会变成风险，所以项目经理必须定期监控。
2.范围和限制
>控制范围蔓延的第一步是定义项目的范围。
>范围和限制会帮助干系人建立现实的期望。
>在最高层面上，范围定义的是客户确定要实现哪些业务目标。
>在较低层面上，范围定义的是性、用户故事、用例或事件和响应。
>范围最终是在计划某个具体的版本或迭代时通过一组功能需求定义的。
>在每个层面，范围必须限定要在其上一级的边界范围之内。
2.1主要特性
列出产品的主要特性或用户功能，并把不同于以前或竞争产品的部分标注出来。
为每个特性打上独特而持久的标签，以便在其他系统要素中进行跟踪。
2.2首发版的范围
为了专注于开发并保持项目进度安排的合理性，要避免试图将任何潜在客户最终可能想要的每一个特性都囊括到1.0版本之中。
2.3后续版本的范围
构建一个发布路线图，指出哪些功能块将被推迟以及后续版本的预期时间点。
2.4限制和排除
列出干系人期望但不计划纳入在产品范围或特定版本中的产品功能或特性。
3.业务背景
3.1干系人简介
干系人是主动参与项目中的人、团体或者组织，会受项目结果的影响或影响项目结果。
干系人从产品中获得的主要价值或好处。干系人价值可以通过以下形式定义：
>提高的生产力减少返工和浪费节约的成本
>>简化的业务过程
>>将之前手工任务的自动化
>>执行全新任务的能力
>>符合有关的标准或法规
>与现有产品相比，易用性有所提升他们对产品的预期态度。
>感兴趣的主要功能和特点。
>必须加以解决的任何已知约束
3.2项目优先级
干系人必须对项目的优先级达成一致。
一种方法是从五个角度考虑：功能、质量、进度、成本和员工。对于任何一个特定的项目，每一个维度都要与下面三个因素之一相适应：
>约束 项目经理必须管理的限制因素。
>动机 一个重要的成功目标，灵活性有限，不能调。
>自由度 项目经理可以根据其他维度来调整和平衡的因素。
项目优先级会主导你的行为。
3.3部署注意事项
确保解决方案可以有效部署到操作环境中。
范围表示技巧
目的是在项目干系人之间培养清晰和准确的沟通机制。
关联图
范围描述为我们正在开发的系统和周围所有事物之间建立的边界和连接。关联图（context diagram）直观展示了这个界限。它确定通过某一接口与系统相连的外部实体（也称为“端点”），同时还包括数据、控制以及端点和系统之间的物料流转。关联图是按照结构化分析原则来制定的数据流图的最高抽象层。
生态系统图
生态系统图（ecosystem map)展示了所有与系统利益相关的系统相互作用以及这些互动的本质。生态系统图表示系统的范围，表明所有系统都互相关联。
生态系统图与关联图的区别在于，它展示的是正在开发的系统与其他系统的关系，包括没有直接接口的系统。通过判断哪些系统正在使用你的系统数据，找出受影响的系统。一旦到达某一点，也就是项目不再影响任何其他数据的时候，就能发现参与解决方案的那个系统的范围边界。
特性树
特性树（feature tree）形象地展示按逻辑分组的产品特性，并将每种特性逐级分解到下一级细节。（Beatty andChen2012）特性树为项目所有计划功能提供了一个简洁的视角，使其成为一个理想模型。
在做版本或迭代规划时，可以选择一组明确的特性和子特性定义其范围。
事件列表
事件列表（event list）确定了可能引发系统行为的外部事件。它描述系统的范围边界，明确可能被用户触发的业务事件、由时间触发的事件或从外部组件接收到的信号事件，例如硬件设备。
事件列表是对关联图和生态系统图的补充。
>思考关联图中的每个外部实体是否是事件的来源。
>考虑生态系统图中是否有某些系统会造成系统事件。
>对于每个事件，考虑在关联图或生态系统图中是否有对应的外部实体。
如果找到缺失的环节，就考虑模型是否缺失元素。
聚焦于范围
范围定义的是结构，不是约束。
愿景和范围文档中的信息可以让你评估是否把提出的需求加入该项目。
用户需求和业务需求之间存在一个反馈循环。
使用业务目标来做范围决策
业务目标是做范围决策时最重要的考虑因素。确定哪些特性或用户需求能够给业务目标带来最多价值，将这些内容安排到早期版本中。
如果可能，量化特性对业务目标的贡献，让人们可以基于事实而非个人感情做出范围决策。
评估范围变更的影响
>当项目范围增加时，项目经理通常得重新计划预算、资源、排期和人员。
>新功能添加时资源和时间并没有相应增加，质量通常受损。
使用业务目标来确定完成
>拥有清晰的业务目标至关重要，随着信息逐渐可用，可以逐步满足这些目标。当成功指标显示你很可能达成了业务目标，项目就可以结束了。
>项目之初不能清晰定义的部分目标如果仍然不在项目过程中加以细化，可能会酿成风险。
- 倾听用户的心声
为了听到用户的心声，可以采取以下三个步骤。
>识别产品的不同用户类别。
>挑选用户和干系人小组代表，并与他们一起工作。
>对谁是项目需求的决策者达成共识。
因为客户通常并不知道自己想要什么。
用户声称他们需要的特性并不等同于他们使用新系统完成任务时需要的功能。
如果不花时间达成这样的共识（对在建产品的共同愿景），后果自然是返工、延期、超支以及客户的不满。
用户类别
识别出各类用户及其在产品中的角色和权限。
用户分类
基于以下这些差别，可以将用户分成以下几类独立的用户群:
>他们的访问权限或安全级别（例如：普通用户、来宾、管理员）
>他们在业务操作中执行的任务
>他们使用的特性
>他们使用产品的频率
>他们在应用领域和计算机专业技能经验
>他们使用的平台（台式机、笔记本、平板、智能手机和定制设备）
>他们的母语
>他们是直接还是间接与系统交互
更好的划分用户类别的方法是考虑各种用户使用系统完成哪些不同的任务。
干系人、客户、用户以及用户类别层级结构
受优待的用户类别就是其满意度决定着项目是否达到业务目标的用户类别。在解决不同用户类别的需求冲突或是考虑优先级时，受优待的用户类别应当加以照顾。
不受欢迎的用户类别是指出于法律、保密或安全因素的考虑而不应使用此产品的用户（Gause and Lawrence 1999）。
每一类用户类别的成员为了完成任务都对系统有一些特定的需求。
间接客户仍然是客户。
用户类别未必是人。
需要更广泛地考虑需求的潜在来源而不能只局限于直接用户和间接用户。
识别用户类别
“发散后收拢”协作模式（Gottesdiener 2002）。
首先问项目出资人希望谁使用系统。然后通过头脑风暴想出尽可能多的用户类别。稍后进一步浓缩、分类。重要的是不遗漏用户类别，以免后期引起麻烦。下一步，识别有相同需求的小组，把他们归为一类或把他们当作一个主要用户类别的小分支。
公司组织结构图同样可以帮助发现潜在用户和其他干系人（Beatty and Chen 2012）。
>参与业务过程的部门
>受业务过程影响的部门
>可能找到的直接用户或间接用户的部门或角色名称
>横跨多个部门的用户群
>与公司外部的干系人有接口的部门
分析组织结构图可以降低遗漏组织内重要用户群的可能性。
将用户群及其特点、责任与物理位置记录在项目的需求规范说明（SRS）或需求计划中。
这将有助于团队后期为变更请求设定优先级和评估影响。
考虑建立一个能够用于多个应用上的用户群分类法。
如果要在项目的SRS中包含用户群的描述，可以引用可重用的用户群列表中的条目，再加入此应用的特殊用户群描述。
用户画像
为了让用户群鲜活，可以为每个用户群创建一个画像。
Dean Leffingwell(2011)提出，设计系统就是让你在用户画像中描述“他”能轻松使用这个应用。也就是说，你要专注于满足那个（想象中的）人的需求。建立一个能准确代表用户群的角色，帮助你很好地满足整个用户群的需求和期望。
与用户代表取得联系
这些用户应当全程参与开发，而不只是参与项目开始时独立的需求阶段。每个用户群都需要有一个人为他们代言。
不要猜用户想要什么，直接问。
确保焦点小组所代表的用户需求可以指引产品开发。同时包含专家和经验缺乏的客户。
需求。我们把这些人称为产品代言人（Wiegers1996）。产品代言人这种方
式能够有效促成第2章所提到的重要客户-开发人员合作伙伴关系。
每个产品代言人都是某个用户群与项目业务分析师之间的主要接口。在理想情况下，代言人应该是个真实用户，而不是某种代理人。产品代言人从用户群其他成员那里收集需求并且消除冲突。因此需求开发活动是业务分析师与这些挑选出的用户的共同责任。
最好的产品代言人对新系统有一个清晰的愿景。
外部产品代言人
如果有大量不同的客户群，首先要识别出所有客户共有的核心需求。
然后再定义适合于特定公司客户、细分市场或用户群的附加需求。
当产品代言人是前用户或虚拟用户时要小心，因为代言人的想法可能与目前真实用户的想法存在断层。
产品代言人的期望
为了帮助产品代言人取得成功，用文档记下你对代言人的期望。
产品代言人可能要承担的工作：
| 分类 | 活动 |
| 制定计划 | 细化产品的范围和约束条件识别需要与之交互的其他系统评估新系统对业务操作的影响定义一个由现有应用或手工操作迁移到新系统的路线图识别相关的标准和认证需求 |
| 需求 | 从其他用户那里收集需求开发使用场景、用例以及用户故事解决用户群内部需求提案之间的冲突定义实现的优先级对性能和其他质量方面的需求提供输入信息评估原型与其他决策者一起解决不同干系人之间的需求冲突提供特有的算法 |
| 确认和验证 | 评审需求规范书定义验收条件根据使用场景开发用户验收测试从业务中提供测试数据集执行beta测试或用户验收测试 |
| 协助用户 | 写部分用户文档以及帮助文档贡献培训资料或教程向同事展示系统 |
| 变更管理 | 评估缺陷的修订或增强请求并排列先级动态调整未来的版本或迭代范围评估变更申请对用户和业务过程产生的影响共同做出变更决策 |
多个产品代言人
一个人很难描述出一个应用所有用户的需要。
项目经理组织一个由业务分析师和产品代言人组成的小组，从正确的源头发掘正确的需求。
推广产品代言人理念
当你提出需要产品代言人参加项目的想法时，要做好被反对的心理准备。
将业务需求与用户需求区分开，有助于缓解以上部分问题。
遇到阻力时，要指出缺乏用户参与是导致软件项目失败的首要原因。
由于没有人能理解需求，所以开发出来的系统不合格。这样的系统无论是重构还是抛弃，其成本都是无法承受的。
产品代言人要避免的陷阱
警惕以下潜在问题。
>管理层推翻合格的被授权产品代言人所做的决定。
>产品代言人如果忘记自己代表的其他客户，而只是提出自己的需求,就说明他不尽责。
>如果对新系统缺乏一个清晰的愿景，产品代言人可能会将决策权推给系统分析师。
>资深用户可能会提名一个不太有经验的用户作为代言人，因为资深用户本身可能没有时间亲自完成这项工作。
>提防那些千方百计想替其他用户群说话的用户。
处理需求冲突
一定要有人解决不同用户群之间的需求冲突、协调不一致并对出现的范围问题做出仲裁。
解决需求争论的建议：
| 争论方 | 如何解决 |
| 单独用户之间 | 产品代言人或产品负责人决定 |
| 用户群之间 | 优先满足受优待的用户群 |
| 细分市场之间 | 对业务成功影响最大的细分市场优先 |
| 企业客户之间 | 由经营目标决定方向 |
| 用户和用户经理之间 | 产品负责人或产品经理为用户群做决定 |
| 开发人员和顾客之间 | 优待客户，不过要保证符合业务目标 |
| 开发人员与销售人员之间 | 受优待的销售人员 |
不要因为“客户至上”就盲目接受客户所有请求。
发表回复