2 日常需求分析
在信息化应用相当普及的当下，根据客户、市场、业务部门的需求反馈，针对已发布的产品、已投产的系统进行持续优化，是最典型的需求分析场景。因此，本章就针对这一工作任务进行详细讲解，同时帮助读者建立基本的需求分析观。
2.1 任务执行指引
日常需求分析任务执行指引如图2-1所示。
图2-1 日常需求分析任务执行指引
当我们收到一条变更、优化型的需求时，建议首先还原需求，确保需求的准确性；然后补充需求，提升需求的完整性；最后评估需求，以确保价值高的需求更早地投入研发。其处理过程如图2-2所示。
图2-2 日常需求分析任务板
2.2 知识准备
要做好日常需求分析工作，核心在于理解业务驱动思想，而该思想的基础就是理解需求的层次、透彻分析需求的价值评估维度。
2.2.1 需求的层次
在上一章中，我们提出了业务驱动的需求思想，也就是避免简单地从技术视角展开、细化“方案级需求”，而应该先从用户视角、业务视角探究背后的“问题级需求”，然后找到能够解决问题，并且开发成本更合适的解决方案。
案例分析
小王是一名实战经验还很少的需求分析师，在一次酒店管理系统的建设项目中，听到酒店前台人员提出一条需求：请在酒店入住界面中增加一张酒店平面图，在图中实时显示房型、房态和价格信息。
“这个变更你们给我们多少开发时间？有预算不？”这一段时间被变更折腾得不行的小王马上问道。前台人员瞪了他一眼，撇撇嘴说道：“就加这一点点东西，就别老提时间、钱了行不？多伤感情呀！”
<旁白：很多经验不足的需求分析人员在听到需求变更时，总会第一时间想到成本！虽然成本很重要，但先澄清问题、思考业务价值才是良好的习惯！>
小王被前台人员的一句话顶得无言以对，只好接着澄清需求：“那这个平面图是一层一张还是把所有楼层都整合在一张大图里呀？”前台人员一脸疑惑地反问道：“我们酒店有这么多层，都整合在一张大图里能用吗？”
小王接着问：“那实时是几秒呢？1秒、2秒还是0.5秒呢？”前台人员不假思索地说：“越快越好！”小王听到这里满脸愕然，思考了一下继续问道：“那房态有几种呢？是用颜色体现还是直接使用文字来体现呢？房型呢？价格又要如何显示呢……”前台人员在犹豫中给出了一些反馈。
小王边听边在纸上画了一些原型图，初步获得了一些确认，他心想希望前台人员以后别改变主意。“对了，在这个平面图上还要关联哪些功能呢？”小王突然想到了一个新问题。
“关联什么功能？现在暂时还没想到，以后想到再告诉你吧！”前台人员十分肯定地回应道。小王听到这里，只能愣愣地望了望对方。
从需求分析师小王和客户的交流中，大家发现问题了吗？是的，小王把所有问题都集中在“解决方案层面”，期望客户细化“如何实现”，但客户要么没想法，要么不确定，这样的沟通必然会带来巨大的隐患。
案例分析（续1）
小王和前台人员交流后，就整理了一份文字描述，将这个需求转交给了开发部。结果开发人员小李看到之后，第一反应就告诉他：“你不知道在B/S架构上实现平面图的工作量很大吗？为什么不劝客户放弃这样的需求？”
小王再次一脸愕然，只好动用感情牌：“我相信这样的需求对于你这种高水平的程序员来说不是什么难事，而且我已经答应客户了，你这次就帮我一个忙，改天我请你撮一顿！”小李听完后诡异地一笑，很自信地说：“好吧，你还好碰到我，碰到别人谁都不帮你干！”
几天之后，小王拿到小李给他的结果当场傻了眼，这哪里是平面图呀！分明就是用HTML中的表格搭建了一张示意图，简陋、难看！可是第二天就是和客户约好的交货期，他只好硬着头皮带着这个“丑媳妇”去“见公婆”了。
前台人员看到这样的解决方案顿时也傻了眼，不过她却很有技巧地提出了不满：“您觉得这是平面图吗？可以放大、缩小、平移吗？这些字这么小，怎么能够看得清呢？”
小王只好悻然地带着新的反馈去找开发人员小李：“不好意思哦，客户说还要能放大、缩小、平移……”小李听后脸上马上挂满了乌云，但一瞬间又变成了“多云转晴”，神秘地说：“好吧，交给哥们儿吧！”
两天后，小王看到小李传过来的新解决方案，更加无语了！小李只是把原来的HTML表格示意图放在一个帧里，然后加上了“放大”和“缩小”两个按钮！单击“放大”按钮，文字放大一号；单击“缩小”按钮，文字缩小一号；整个HTML表格也随之缩放。他马上找小李提出了自己的质疑……
小李撇撇嘴说道：“虽然丑了点，但也解决问题了不是？不是说看不清吗？现在放大就可以看清了呀！至于平移，直接拉滚动条不就可以了吗？”小王迫于时间的压力，只好带着“整容失败”的新解决方案去见客户。
前台人员看了一眼新解决方案，二话不说直接打电话给领导：“领导，您看他们新上线的入住功能……那个平面图……您看做成什么样了！他们就是这样应付我们的吗？”
客户领导震怒了，马上一通电话打给了小王所属的研发中心的大领导！从此，这个需求就升级成了极高优先级的需求……
从事态的发展中我们可以看到，如果基于一个目的不清晰、实现方案相当明确的需求进行开发，一旦开发成本比较高，就极易出现执行变形，严重的时候甚至还会使客户关系恶化。
案例分析（续2）
小王的项目团队开始开会研究这个需求，最后大家一致认为只有使用SVG（B/S架构下的一种矢量图解决方案）才是最合适的，可惜团队中没有人会操作。于是领导决定派一个资深的开发人员去研究学习一下。
这个资深的开发人员花了2周的时间学习、2周的时间开发调试，最后在一个资深美工的协助下打造出了一张很完美的平面图，效果很棒，大家一致认为客户应该会相当满意。
可惜这张看似完美的平面图也只是让客户开心了两天，两天后客户就反馈说平面图功能不好用！当大家问她为什么觉得不好用时，结果得到的反馈居然是“看运气，运气好时还不错，运气背时太难用了！”
当我们“完美”地满足了客户提出的“方案级需求”时，最终未必会得到完美的反馈。因为客户是问题专家，而非解决方案专家，他提出的解决方案未必能够完美地解决他遇到的问题。
因此，我们在进行需求分析时一定要清晰地理解需求的层次。
（1）方案级需求：用户想要的功能，是从技术实现的角度来描述的，它通常不够可靠。
（2）问题级需求：用户想要解决的问题，是站在用户视角、业务视角来描述的，通常可以通过回答“如果没有提供这样的功能，那么会对当前业务有什么影响？”来帮助思考；要做好这个层次的需求分析，业务知识与业务理解能力是关键。
（3）人性级需求：有时需求还可能涉及更深层次的原因，这可能就与需求提出者的动机相关了。对于行业应用系统而言，不常需要在这个层次上进行分析，但如果是ToC产品（C端产品，即面向个人客户的产品），则经常需要分析到这个层次。
2.2.2 需求的价值评估维度
由于市场、业务都在持续不断的变化，因此需求也是不断变化的，即使你拥有再大规模的开发团队，也一定会被无限的需求耗尽。作为需求分析人员，应该树立“力求公司IT投资发挥最大业务价值”的工作理念，也就是要掌握有效的需求价值评估方法，即需求优先级评估方法。
生活悟道场
很多团队在评估需求优先级时，通常会简单地定义为高、中、低三级，或者关键、重要、有用、一般、镀金五级，然后让需求提出者自己填写评估结果。我们期望这种评估结果能够呈现一个科学的橄榄球形结构：关键需求较少、重要需求较多、有用需求最多、一般/镀金需求较少。
但在实际执行时通常会发现，需求提出者把90%甚至95%以上的需求都评估为关键需求，剩下的基本上是重要需求，有用、一般、镀金需求很少见。
其实这背后的逻辑很简单，你可以换位思考一下：既然他们提出了一个需求，又怎么会觉得不重要呢？如果不重要，那么为什么要提呢？
因此，由需求分析/管理团队制订出优先级评估策略，并与业务团队达成共识，才是更科学的价值/优先级评估方法。
1.选择维度
选择最合适的评估维度，常用的有业务维、用户维、竞争维和运营维四个维度。
（1）业务维：与重要的业务关联的需求优先级更高，尽快实现业务上线；最常用的评估方法是“价值-频率双维评估法”。
（2）用户维：能使越多的用户满意或满意度提升越大的需求优先级越高；通常应该先进行用户分类，然后按不同的用户类型进行综合评估。
（3）竞争维：对产品、系统的竞争力提升越大的需求优先级越高；最常用的评估方法是“卡诺模型”。
（4）运营维：与产品运营价值、企业业绩提升越相关的需求优先级越高；通常应该结合产品、系统的类型选择合适的模型，如“北极星指标”和“RFM模型”等。
要注意的是，不应该按四个维度分别评估，再加权得出最终的优先级，因为很多需求可能在某个维度低价值，而在其他维度高价值，一平均就被“埋没”了。正确的做法有两种，具体如下。
（1）按产品/系统所处的阶段选择主评估维度：通常在0～1的建设期，建议使用业务维；在1～10的发展期，建议重点关注用户维、竞争维；在10～100的成熟期，建议重点关注运营维。
（2）组合使用维度：针对每个维度进行排序，然后按一定比例选择不同维度的高价值需求；例如，每一次开发迭代，完成业务维优先级最高的3条需求、竞争维优先级最高的3条需求、运营维优先级最高的1条需求。
2.构建策略
根据不同的维度，进一步细化出评估因子，然后构建出与业务部门达成共识的评估表，从而确定必须做、应该做、可以做、可不做四个等级。下面我们针对四个维度分别给出参考模板，如表2-1～表2-5所示。需要注意的是，这些模板不应该直接套用，而应适度扩展。
表2-1 业务维优先级评估表（价值-频率双维评估法）
表2-2 用户维优先级评估表
续表
表2-3 竞争维优先级评估表（追赶期）
表2-4 竞争维优先级评估表（领先期）
表2-5 运营维优先级评估表
注1：在评估前，首先应定义产品的核心运营公式，例如，
①电商：客流量×转化率×客单价。
②通用：RFM模型（R，回头率；F，使用频率；M，使用量）。
这里列出的就是一级指标。
注2：对一级指标可以进行进一步分解，例如，转化率=下单率×（1-退货率），等号后面就是二级指标。
2.3 任务执行要点
日常需求分析这一关键工作任务，可以分为还原需求、补充需求、评估需求三个步骤执行。
2.3.1 还原需求
还原需求，核心要素有三个：Who（谁的需求）、Why（解决什么问题）、How（解决问题、成本合适的解决方案）；在执行时应该澄清问题（Who+Why）、了解背景（相关的业务场景）、建议并确定解决方案（How）。
1.澄清问题
还原需求的核心思路如图2-3所示，澄清问题的思考过程也就是使用“过去时”回答这个需求要解决“谁”的“什么问题”。
图2-3 还原需求的核心思路
在明确是“谁”的需求时，不应仅把关注点放在需求提出者身上，还应该思考三个问题。
（1）需求提出者和需求使用者是否一致？如果不一致，则应该尽可能地收集需求使用者的真实反馈。
（2）该需求是否涉及潜在的影响者？他们有什么不同的想法？通常当需求涉及业务操作流程时，业务的管理者会是影响者；当涉及业务数据时，数据的上游采集者和下游应用者可能是潜在影响者；当涉及业务规则时，风控、审计等相关部门可能是潜在影响者。
（3）该需求是否能代表主流用户的声音？通常很多需求源于专家型用户，因为这类用户通常热衷于提出反馈，但提出的需求经常偏向复杂的解决方案，所以需要找相对沉默无语的主流用户进行进一步验证。
案例分析（续3）
我找到了最初提出这个需求的前台人员，问她：“您为什么会觉得这个平面图有时好用，有时不好用呢……”我话还没说完，她马上就打断我说道：“你知道我想要用这个平面图干什么吗？”
我会意地笑了，顺着她的话说道：“我这次来就是想了解您想通过这个平面图解决什么问题，以便给您构思一个更加有效的解决方案。”
她接过话题，缓缓地说：“因为有时客人过来入住，会要两间甚至多间相邻的客房，这时我经常会遇到困难。你知道的，房间号相邻通常不意味着房间相邻。”[澄清谁的、什么问题。]
“嗯，那现在您遇到这样的问题是如何解决的呢？”我顺着她的思路继续发问。“现在我遇到这种情况，首先会找出哪些楼层有足够多的客人所需房型的空房间；知道哪些楼层有之后，再判断这些房间是不是挨着的……”她不紧不慢地说道。[澄清现状，也就是现在是如何解决的。]
“嗯，由于不好判断，因此你想通过平面图直观地找出挨着的房间，但有时多个楼层都有足够的空房间，所以你纠结应该从哪层看起……”我知道自己找到了问题所在！
她微微一笑，说道：“的确是这样的，有一次我发现3、5、7、8、9、15、18、20、30楼都有空房间，结果我从30楼开始找，一直找到3楼才找到合适的！唉，早知道从3楼开始找就好了……”
“那您认为什么是‘挨着’呢？”我突然问了一个有点怪异的问题。果然，她一脸困惑地看着我：“挨着就是挨着嘛，还有什么叫挨着……”我淡淡一笑，说道：“我当然知道两个房间紧挨着叫挨着，那对面的房间能满足客人的需求吗？斜对面呢？如果斜对面也能，那么中间隔一间房能不能呢？”
“这还真是一个有趣的问题。”她马上给予了肯定的回应。我们花了几分钟的时间进行分析，最后达成了共识：两间房间的门口步行距离在2米内完全满足，5米内可以推荐，毕竟客人就是希望方便同行者交流、联络。[对模糊概念进行澄清。]
通过上面的对话，我们可以明确该需求的提出者和使用者是一致的，都是酒店前台人员，该需求并不涉及潜在的影响者；该需求要解决的问题是当客人提出需要多间相邻客房的入住请求时，能够快速、准确地找到合适的房间，如图2-4所示。
图2-4 日常需求分析——还原需求1
这段对话是否能够让你对“问题级”需求有更清晰的理解呢？是否让你看到了更清晰的需求呢？在这里我们澄清了问题、了解了当前遇到该问题时的临时解决方案（现状），并对模糊概念进行了澄清。当然，为了给出更准确的解决方案，我们还需要对相关背景进行更进一步的了解。
2.了解背景
案例分析（续4）
“那么您当时提出做一张平面图，主要还是自己用吧？应该是在办理入住的时候使用吧？”我虽然已经有了十成把握，但还是习惯性地和她进行了确认。得到她的肯定回答之后，我继续问：“那您可以简单说一下办理入住的过程吗？”
她耐心地解释道：“首先根据客人的需要找出合适的房间，然后记录客人信息，最后给钥匙卡，整个过程挺简单的！”[这一步是在澄清业务场景，谁、什么时候、怎么做的；了解了办理入住的过程之后，如果最后仍然使用平面图解决方案，那么我们很容易得出在平面图上选中房间后直接跳转到客人信息录入界面，因为关联功能源于用户的使用场景。]
由于之前小王在需求沟通过程中已经明确了房态、房型、价格几个业务术语的定义，因此我就跳过了这一步。[明确业务术语的定义，是做好数据需求分析的基础。]
“在您的印象中，要几间挨着的房间的客人多不多呢？每天都有吗？”我希望了解这个需求的使用频率。前台人员很快就回答了这个问题：“不算多，一天2～3次的样子吧！”听到这样的回答，我心中明确了一个事实，当这个需求未实现时生气的只是酒店前台人员，她一天大概生气2～3次。
“你们酒店是连锁的吗？其他前台人员也有类似的困扰吗……”我继续对一些业务环境进行了了解，以便明确相关的非功能需求。[非功能需求源于业务环境。]
对话到这个阶段，我相信大家都已经很清晰地理解了这个需求，接下来我们就可以建议并确定解决方案了，你还觉得应该开发平面图吗？
3.建议并确定解决方案
案例分析（续5）
通过前面的沟通，我认为这是一个基层操作者（前台人员）非常用的功能，当其未实现时只会添加一些工作上的不便，因此我认为应该采用更加简单的解决方案（见图2-5）。
图2-5 日常需求分析——还原需求2
“您平时工作这么忙碌，遇到客人需要几间挨着的房间时，还要自己一层一层地看平面图去找，多麻烦；我觉得直接让系统帮您挑出来更方便一些，您觉得呢？”我开始引导用户接受更加简单的方案。
前台人员马上接过话题说道：“那敢情好！具体怎么做呢？”我拿出笔在纸张上边画原型边解释道：“在原来查询空房间的界面上，增加间数、相邻选项，当您指定间数并要求相邻时，系统会查询出满足条件的房间，并说明在2米内还是5米内，您觉得如何？”
前台人员听懂了我提出的解决方案之后，爽快地说：“太好了，就这样办！这样省事多了……”
正如对话中所示，我们在提出解决方案时应该站在用户的立场，说明这种方案的优点，毕竟需求分析师是“问题解决者”，而不是简单的需求传递者。
2.3.2 补充需求
由于需求提出者很难一步到位地想清需求，因此为了确保需求的完整性，我们还应该适当地对需求进行补充，也有人称之为需求挖掘。这一工作主要可以从如图2-6所示的三个角度开展。
图2-6 补充需求的三个角度
对于是否应该挖掘、补充需求，有人赞成，认为不考虑周全，客户迟早也会提出，后面开发更麻烦；有人反对，认为很容易产生需求蔓延，而且当你提出更多的建议时，会提升客户的期望值。
针对这样的两难问题，我个人的经验是“只挖掘问题，不挖掘方案”。因为对于问题级的探讨，客户是理性的；而对于方案级的探讨，客户是感性的。但无论怎么做，这些工作都需要投入更多的精力和时间，因此在实战中要有所取舍。
1.提高广度——同类问题横推法
由于很多需求提出者经常会进入“点状思维”，也就是想到一个问题提出一个问题，就像玩“打地鼠”游戏一样；因此我们可以举一反三，首先从需求的“Why”出发，将其提炼为“问题类型”，启发用户回忆遇到的“同类别的其他问题”。
案例分析（续6）
当她接受了我所建议的解决方案之后，我考虑还是应该做一些需求挖掘，以避免未来需求不断以“挤牙膏”的形式被提出。首先我在心中概括了一下这个需求的问题类型，显然是“客人提出了特殊的入住请求”，因此我问她“：另外，请您回忆一下，除了客人要挨着的房间，您还遇到过其他特殊的入住请求吗？”
她微微仰起头回忆了一下，回答了我的问题：“嗯，你这么一说我倒想起来了，还真有一种比较常见的情况，客人交代要一间不吵的房间。”我点了点头，顺着她的话问道“：那如果您给了一间比较吵的房间，会有什么后果吗？”
“遇到不太挑剔的客人也无所谓，但有些客人会马上要求换房，如果没有空房间可换，那么他还会马上投诉。”她脸上流露出一丝无奈。
“那么除了客人要挨着的房间、要不吵的房间，您还遇到过其他特殊的入住请求吗？”我继续追问道。
她思考了一下，说道：“对了，有些客人还要求不住楼道尽头的房间，部分独自一人出差的女士会觉得这样的房间缺乏安全感。”
我把她提的两个需求写在“同类问题”一栏中，如图2-7所示。
"……"
图2-7 日常需求分析——补充需求1
在这段对话中，我又得到了两个潜在的可能需要解决的问题：“找到一间不吵的房间”“找到不在楼道尽头的房间”，它们出现的频率更低，前者处理不好引发的后果更严重一些，后者处理不好影响则更小一些。因此，这两个问题未必需要第一时间解决，只是为了让开发人员在设计时考虑到未来实现这种需求。
2.提高深度——关联行为纵推法
除了“点状思维”，需求提出者还容易出现“步进性思维”，也就是解决一步是一步，等解决方案上线之后，会马上提出关联的需求。
例如，在本章贯穿案例中，用户的需求是“快速找到多间相邻的客房”，它会产生什么样的关联需求呢？思考这个问题的技巧在于，我们可以把“Who”和“Why”整合成一个场景——“酒店前台人员在办理入住”。那么针对这个场景，工作步骤如下。
（1）找到符合客人要求的空房间。
（2）记录客人的信息。
（3）收取押金，提供房卡。
关联行为纵推法的核心思考问题是“前中后有关联行为要支持吗？”而“快速找到多间相邻的客房”这一需求发生在第一步中，所以没有“前置关联行为”。
那么“后置关联行为”是记录客人的信息，因此我们可以推测出，当酒店前台人员可以快速找到多间相邻的客房时，很可能提出希望能够批量处理多间客房的入住信息登记。
“中”则是“本步骤可能发生其他例外吗？”在本案例中并不明显，因此暂时没有发现。因此，我们通过该方法补充了一条潜在的新需求，如图2-8所示。
对比上一种方法，你应该会发现，关联行为纵推出来的新需求和原需求通常是“同一个需求”，而同类问题横推出来的需求都与原需求完全无关。
3.提高全面性——360度分析法
除了“点状思维”“步进性思维”，需求提出者还可能陷入“个性体思维”，也就是只站在自己的立场上思考问题，而未考虑到其他需求影响者的需求。
因此，对于相对重要的需求（通常是发生在关键业务中的需求），可以考虑采用360度分析法进一步补充需求，如图2-9所示。
图2-8 日常需求分析——补充需求2
图2-9 360度分析法
该方法的思考过程分为两步。
（1）识别潜在影响者：首先将“Who+Why”整合而成的业务场景放入流程中，然后识别出流程上游环节、下游环节，以及流程的管理者、协作者（例如秘书、内勤等不一定出现在流程中，但为流程环节负责人提供事务协助的角色）。
（2）分析影响者的需求：针对识别出来的影响者，逐一站在其视角识别出其关注的问题，以及问题衍生出的需求。
针对前面这个案例，由于该需求本身影响者少，因此可以跳过这一分析步骤。
2.3.3 评估需求
需求分析人员平时会收到大量的需求，同时为了确保需求的完整性，我们还会补充一些新的需求；因此，最后应该针对这些需求进行价值、成本、优先级评估，才能确保“IT投资获得最大化业务价值”。
为了更好地完成该工作，我们建议针对已投产的系统、已发布的产品，构建各自的Backlog（待处理需求合集），然后从Backlog中根据优先级、成本评估，筛选出每个开发迭代要处理的需求集合，如图2-10所示。
图2-10 日常需求管理逻辑示意图
评估需求的执行过程如图2-11所示，首先选择评估维度，然后针对每条需求进行逐一评估。
图2-11 评估需求的执行过程
案例分析（续7）
通过前面的分析，我们完成了需求还原——“快速找出多间相邻的客房”，并补充了3条需求：“快速找出噪声小的房间”“快速找出不在楼道尽头的房间”“找出多间相邻的客房后快速完成多间客房的入住信息登记”，如图2-8所示。
接下来的工作是针对这些需求进行优先级评估。首先明确评估维度，由于该系统处于从0到1的建设阶段，也就是为酒店构建一套酒店入住管理系统，因此最适合的评估维度是业务维。所以，我们将根据表2-6的评估逻辑，对这4条需求进行优先级评估。
要使用业务维的“价值-频率双维评估法”进行评估，首先应该明确需求发生在什么业务中。显然，这4条需求都发生在“办理入住”这一业务场景中，而“办理入住”是主营业务且是高频的，因此属于“关键业务场景”。
接下来我们应该思考必备性。必备性应该有一个重要的前提，那就是如何用系统支持这一业务场景，该功能是否是必不可少的。例如，要用系统支持“办理入住”，那么“快速找到空闲客房”就是必不可少的，而“快速找出多间相邻的客房”则是非必备的。
然后我们应该评估每条需求的问题发生频率，以及不解决该问题可能产生的后果（在表2-6中采用了影响效益、影响效率来简单评估后果，在实际工作中，应该针对系统的业务特点进行更详细的定义）。
表2-6 业务维优先级评估表（节选）
问题发生频率的高低如何界定，我们认为这应该是一种相对的概念；根据过去的经验，一般与所属业务场景的频率级（秒级、多秒级、分钟级、多分钟级、小时级、多小时级、天级、多天级、周级……）差小于3级的，都理解为高频。
例如，“办理入住”的发生频率应该是“多分钟级”的（也就是不到每分钟一笔，但每小时也可能有多笔），那么“天级”的频率都属于高频；大于“天级”就可以理解为低频。
“快速找出多间相邻的客房”，通过和客户交流发现，此需求并不会每天都有，因此属于低频；即使未能解决也不会带来经济损失，主要影响还是办理效率降低。因此，如表2-6所示，此需求是关键业务中的非必备需求、低频发生、未实现影响效率，优先级应该是“可以做”。
而“找出多间相邻的客房后快速完成多间客房的入住信息登记”是与该需求直接关联的，因此它们的优先级相同，可以得到如图2-12所示的结果。
图2-12 日常需求分析——评估需求1
“快速找出噪声小的房间”是关键业务中的非必备需求、低频发生、未实现影响效益（客户不满意会换房，从而带来更大的清洁成本；客户会投诉，从而带来更多潜在的经济损失），根据表2-6，优先级为“应该做”。
而“快速找出不在楼道尽头的房间”是关键业务中的非必备需求、低频发生、未实现影响效率，根据表2-6，优先级为“可以做”，但考虑到这样的用户比例低，因此可再降级为“可不做”，最终得到如图2-13所示的分析结果。
图2-13 日常需求分析——评估需求2
2.4 任务产物
在实践中，针对每个变更/优化型需求（也称为日常需求），可以根据需要用“变更/优化型需求分析模板”整理出分析结果。
2.4.1 变更/优化型需求分析模板
针对变更/优化型需求分析，有些公司在实践中也采用了厚重的需求规格模板，导致产生了大量无效信息，这里建议使用一个简单的模板，如表2-7所示。
表2-7 变更/优化型需求分析模板
续表
与前一节中讲解的分析过程相对应，该模板中主要包括原始需求、问题澄清、业务环境描述、业务场景描述、业务术语说明、解决方案概述6个部分。
（1）原始需求：说明需求是谁提出的（提出人，必填），他属于哪个部门（客户信息，建议填），原话是什么（原始描述，必填）；如果有需要，则还可以对其进行编号（编号）。
（2）问题澄清：说明这个原始需求背后的问题级需求是什么（要解决的问题，必填），现在如何应对该问题（现状，选填），问题描述中是否有需要澄清的定义（概念澄清，选填），以及是否还有相关的其他需求（相似问题场景挖掘，选填）。
（3）业务环境描述：说明该需求未实现会对谁产生直接影响（不做谁生气，建议填），产生这种影响的频率如何（多久生气一次，建议填），存在哪些对非功能需求产生影响的因素（其他非功能需求，选填）。
（4）业务场景描述：当需求分析人员或开发人员不理解该问题发生在什么样的业务场景中时，可以选填本部分。它主要包括该需求发生在哪个业务场景中（场景名称），这个场景是怎么样的（建议采用子任务、任务变体的形式整理）。
（5）业务术语说明：如果需求分析人员或开发人员对该需求中相关的业务术语有理解歧义，那么建议选填本部分。也就是列出易有理解歧义的术语名称，以及术语意义、构成等说明信息。
（6）解决方案概述：必填，针对该问题可以有哪几种解决方案，各有什么优缺点，推荐哪种？为什么？
2.4.2 变更/优化型需求分析示例
针对前一节的案例分析结果，我们可以整理出如表2-8所示的任务输出，大家在具体的实践中可以参考。
表2-8 变更/优化型需求分析示例
续表
