全文共 11047 字 3 图，阅读超过 25 分钟
———— / BEGIN / ————
无论是互联网产品、软件产品、硬件产品或服务，需求就是它们要做的事或要成为的样子。
不论你发现还是没发现，写下来或没写下来，需求都是存在的。
一个需求的形成，期间会经历一个严谨的流程，好的产品需求，能帮助我们准确地反映出用户的需要和想法，能帮助我们做出正确的产品。
本文将从项目启动开始，一步一步给大家带来创建需求的科学流程。
一、确定业务范围
在本阶段，通常会通过一场项目启动会开启我们的项目，在项目启动会上我们会大致了解到产品要实现的目标、产品的大体利益相关者。
在项目启动会上，我们可能会从项目经理那里得到一部分的项目相关资料，当然，大部分的资料还是需要我们自己去挖掘。
在会议上，务必要明确项目的目标，通过一段简短的、定量的陈述，说明产品要做的事，以及产品所带来的业务好处。
这个目标是很有用处的，它能解释为什么我们的业务需要这个项目，也能说明期望实现的业务收益。
它为项目提供了理由，同时也是需求发现过程关注的焦点。
这里有三个关键词：范围、利益相关者和目标
范围是受产品影响的业务领域的部分。因为它确定了真实组织机构的一部分，所以范围会指出一些利益相关者，他们对项目的成功有影响。
利益相关者反过来又决定了产品的目标，即产品使用后期望获得的业务上的完善或改进。
这样就构成了项目前期很重要的：“范围—利益相关者—目标”的三位一体关系链。
1.1 范围，是产品实现的边界
这里的范围指的是产品的工作范围，也就是产品要去改变或改进的那部分工作。只要它涉及一些处理内容和数据，我们就称之为“工作”，而我们必须知道它的范围。
任何一部分工作，都必须至少和另一部分工作有联系；如果没有联系，工作将没有作用，它不会有任何输出。
同理，这项工作内的模块都至少和另一个模块有联系。
了解了这一点，我们就可以分离出相应的模块，即在产品的工作之内的模块。
要完成工作模块的分离，我们要知道一个简单的事实，即所有的模块都是由数据驱动的。
我们刚才提到：模块与其他模块有联系，这种联系就是数据流。
也就是说，每一个模块都会产生某种数据，然后将数据传递给其他的模块。后续的模块收到进入的数据流，触发执行它要做的处理，并生成不同的数据输出，这些输出再次传递给其他模块。因此这些数据流就是模块之间的联系。
通过确定这些数据联系，就能确定工作的边界。
我们可以通过画一条线来代表工作边界，区分类似的、耦合的模块，创造了一个区域，最终包含了所有构成工作的范围。
1.2 利益相关者，是需求的来源
利益相关者包括全部对产品的结果有影响的人。
产品的核心用户是最明显的利益相关者，但是还有其他利益相关者。
每个项目都可能有几十种利益相关者。
我们要考虑到全部利益相关者，这可能意味着与很多人交谈，他们都可能是需求的来源。
在和利益相关者交谈时，要向他们解释，为什么他们是利益相关者以及为什么需要就产品需求向他们咨询 。
一种友好的做法是通知他们将需要他们多少时间，以及他们应该以何种方式参与。
关于利益相关者的最大问题就是：如果没有找齐所有的利益相关者，或者在需求收集过程中把某些利益相关者排除在外，将遗漏一些需求。
1.3 产品目标，是最高层次的需求
产品要解决的问题，就是产品的目标。
项目的目标应该不仅仅是解决问题，还要提供业务上的好处。
这里的好处指的是：产品的核心用户以及利益相关者可以从产品中得到的好处 。
一般的团队在明确了产品的目标后，就着手去实施了。但是，这里欠缺很重要的一点，就是度量产品目标。
度量产品目标可以回答以下问题：
这是一个合理的产品目标吗？比如，企业CRM系统，为了实现企业管理、跟进客户关系，开发该系统花费的成本，是否值得？我们可以收集一些数据，比如市面上的CRM系统，在采购半年后，所创造的客户数据大概在多少，我们自己研发一套CRM系统，在半年内要达到这个数据量所涉及的成本是多少，二者是否平衡等。
产品目标是否可行？在项目启动会上，相关的利益相关者可以对此进行评估。比如，经验丰富的技术负责人可以大体评估出产品目标的可行性。
产品目标是否可达到？同样，项目启动会上可以大体评估出产品目标能否达到。
通过以上问题，我们可以总结出关于产品度量的标准：比如，在半年内，通过CRM系统，将公司有效客户数量增加至20000。
综上，我们可以得到一个描述产品目标的模板：
目标：产品要做什么的业务描述。
好处：产品能提供怎样的业务好处。
度量：对产品目标进行度量的数据描述。
合理性：综合考虑全部因素，产品是否有可能实现业务好处。
可行性：考虑到在启动会议上得到的信息，产品能达到度量标准。
可达成性：组织机构是否具备构建该产品的技能。
二、拆解业务用例
在明确了项目的目标之后，接下来要做的就是得到产品中全部的业务用例（用例，用来描述系统与用户之间的交互）。
2.1 业务事件与业务用例
产品的用户在使用产品过程中涉及到的工作或业务，统称为业务事件。
比如，用户在网上买书时，挑选好了需要的书籍，这时可能会有两种情况：
1. 决定做些别的事情，先放弃此次交易；
2. 决定买下这本书。
此时，决定要买这本书就是一个业务事件——当然，只是决定想要这本书还不够，用户必须告诉系统想要买书。
用户点击了购买按钮，提供了手机号、收货地址等信息——此时，用户的操作触发了系统，系统会完成下单，并且快递这本书到用户手中。
从这里我们可以顺带引出业务用例的概念：
在这个例子中，用户决定买书和完成买书的操作就是业务事件；总是有一些数据源自业务事件（触发数据流），这会调用预先计划的对该事件的响应——这种响应就是业务用例。
（当业务事件发生时，系统通过发起一个业务用例进行响应）
2.2 发现业务事件
业务事件其实就是发生的一些事情，这些事情让系统以某种方式做出反应。
在业务事件发生时，在系统工作中至少会显示一条数据流。
进入或离开系统的每个信息流都会是一个业务事件的结果，外部通信的存在没有其他的理由。
看一下每个信息流，就可以确定引发它的事件。
在某些情况下，可能有多个信息流跟随同一事件。
因为一辆卡车已停止服务，必须重新安排其他的卡车来弥补，由此导致的输出信息流可能是“修改卡车调度计划”。
业务事件通常由事件名称和输入输出数据流组成，业务事件的模板如下：
例如：物流公司派出卡车服务的业务事件
在挖掘业务事件时，有一个需要注意的要点，就是要看到整个业务过程 。
比如，上述物流公司提供物流服务的例子，如果只是站在用户侧，看到的业务事件有可能是“收件人收到发货并登记信息”，可是站在整个业务链侧，业务事件就是“物流公司派送货物”。
2.3 拆解业务用例
上面已经说到，针对每个业务事件，有一个预先计划的对它的响应，被称为业务用例。
业务用例包含一些业务处理的过程，一些被存取的数据，产生的一些输出，发送的一些消息，或是这些事情的组合。换言之，业务用例就是一个功能的单元。
这种单元是编写功能需求和非功能需求的基础。
业务用例 = 业务处理过程 + 存取的数据 + 输出信息
通过找到的业务事件，按照上述公式，可以得到具体的业务用例，通常多个业务用例单元会组成一个完整的功能描述。
研究业务用例，就是要考虑系统要做哪些事以及预期的结果。
在拆解并理解了业务用例的全部工作之后，也就确定了对业务用例贡献最大的产品范围。
三、进行业务调研
在得到了项目启动阶段的输出信息，即系统的范围、项目的目标、系统的业务事件与用例。
启动阶段也确定了项目涉及的利益相关者和潜在用户。
我们接下来就需要进行工作调研，取得对系统的深入理解。
工作调研，可以帮助我们有效地深入了解项目业务的本质。
3.1 建模
建模作为工作调研的一种方式，最好是在需要理解中到大型工作领域，又没有文档时进行。
如果当前的利益相关者很难描述整体工作，也可以采用这种方法。
我们可以利用模型帮助理解系统的工作。要限制在当前系统模型中所展示细节的数量。
理想的模型包含足够让你理解工作的信息。
也就是说：模型要展示当前情况的主要部分。这样的模型允许利益相关者验证它是否足够好地代表了他们工作的实际情况，让我们可以有进一步问问题的基础。
常见的建模方式包括业务流程图、思维导图、UML时序图等，不限于形式，只要能帮助更好地梳理业务事件和业务用例就好。
3.2 现场调研
现场调研对于开发企业内部的B端产品很有用。
现场调研的基本假定是用户正在完成工作，作为产品经理，必须理解他们的工作。
现场调研是一种观察实际工作的很好的方法，有点像以前的“学徒工”。
在这种情况下，产品经理是徒弟，各利益相关者是师父。
产品经理与利益相关者一起坐在他们工作的场所，通过观察，问问题，或者通过在利益相关者指导下完成一些工作来进行学习。
如果用户正在他工作的地方做他的事情，他就能提供连续不断的解说，并提供在其他情况下会遗漏的细节。
所以，如果你想得到工作的准确解释，就要去工作现场，坐在用户身边，在工作发生时获得连续不断的解说。
现场调研可以与建模结合起来。在观察工作和用户的解释时，可以勾勒出每项任务的模型，以及它们与其他任务的联系。在建模时，将它反馈给用户以求得确认。
然后我们会利这种反馈，对所有不确定的地方提出问题。
3.3 利益相关者访谈
利益相关者访谈是最常用的需求收集方法。
几乎每一个项目都离不开利益相关者访谈。在访谈过程中，利益相关者不应该是完全被动的。
相反，应该尽量让他们参与建模（业务事件响应、用例、场景等）的过程中来。
这样我们就和利益相关者之间建立起了一个反馈环，也意味着可以迭代式地测试你听到的东西的准确性。
在利益相关者访谈中，有如下需要注意的要点：
确定好访谈的背景。这样可以有效避免利益相关者和你谈一些无关的问题。
限制访谈的时间。国外有研究表明，超过1小时的访谈，会使访谈逐渐失去焦点。
使用业务用例作为访谈的核心。准备好业务用例，挨个讨论业务用例，这样也会增强访谈的方向性。
问问题、听取回答、然后反馈理解。
画出草图、模型，鼓励利益相关者改正它。及时画出一些能表明谈话内容的原型草图、流程图或用例图，可以有效帮助我们理解每一个处理过程。
了解利益相关者的术语。在访谈中，难免会遇到利益相关者在实际工作中的术语，及时请教他们，理解其含义。
记录笔记，写下所了解到的一切。
总结下来，在利益相关者访谈中，做到两点即可：正确提问，聆听回答。
3.4 快速绘制低保真原型图
原型和草图可以有效地提取需求，基本思路是用草图勾画产品，然后进行逆向工程，从草图导出需求。
这种方式适用于：产品的利益相关者对这种产品或建议的技术没有经验 ；利益相关者很难说出他们的需求；产品经理很难理解需求是什么。
此时，原型为利益相关者提供了一些真实的东西，或者至少是具有真实的外观。
原型让利益相关者感到产品足够真实，从而提出用其他方法可能遗漏的需求。
当利益相关者看到原型所展示的功能时，他们会想到一些其他需求。
用这种方式，通过原型来展示产品雏形，并让利益相关者身临其境的去浏览或使用，就可以捕捉到一些需求，如果不是这样，这些需求可能要到产品开发完真正使用时才能发现。
3.5 录像或照相
录像或照相是记录某些时刻的一种方式，以便稍后能对它们进行研究。
录像或照相可以用于研究业务。
利用这种方式，录像的作用先是记录进展过程，然后是确认。
录像或照相可以结合利益相关者访谈一起使用。利益相关者有自己完成任务的方式。
他们用自己的方法对使用的信息分类整理，用自己的方法来解决问题。他们发现这些方法非常适合他们的情况。
因此，通过录像来捕捉利益相关者工作的情形，就记录了他们完成工作的方法、方式。
当然，录像或照相的使用可以更加结构化。
例如，选择一个业务用例，让利益相关者走一遍他们遇到的典型场景的流程，并通过录像进行记录。在利益相关者工作的同时，他们会描述特殊的情况、他们用到的辅助信息、异常情况等。记笔记时通常会丧失的信息都能被记录下来，以备将来进行剖析。
3.6 总结
在工作调研的时候，要适当结合上述方式的多种，目的是能让我们深入理解系统业务的本质，能达到这个目的的方法都是好方法。
四、完善业务用例
这里的完善业务用例，指的就是为业务用例加上场景，因为场景将树立业务用例的故事。
在这里通过举一个乘客登机的过程的例子，来说明如何为用例加入场景。
首先，我们来草拟一个乘客登机的场景：
得到乘客的机票或电子客票记录编号。
确定乘客、航班、目的地是否正确。
检查护照有效并属于这名乘客。
记下乘客的编号。
为乘客分配一个座位。
安检行李。
打印登机牌和行李标签，并递给乘客。
祝乘客“旅途愉快”。
4.1 为场景取了一个有意义的名称
业务用例名称：为航班的乘客检票
4.2 为业务用例加入启动机制
启动机制：乘客的机票、电子客票记录编号，或者身份和航班信息
在用场景对系统建模时，应该一直询问自己是否能改进工作。
例如，除了让乘客在值机柜台前面等，是否能在乘客到达之前就开始？例如，他能在家检票，或在来机场的路上，或在排队时？所有这些选择在技术上都是可行的，可能带来一些业务上的好处。
4.3 加前置条件
现在加入一些前置条件，业务用例触发时必须满足这些条件。前置条件表明了工作初始的状态。
通常这意味着有一些业务事件必须已经发生，这个业务事件才有意义：
前置条件：乘客必须已预订航班
4.4 加入影响利益相关者
还可以考虑为场景加入影响利益相关者。这些利益相关者对这个业务用例的结果有影响。
也就是说，他们会受到工作完成方式和工作产生的数据的影响：
影响利益相关者：检票员、市场部门、行李部门、航班预订机构、航班乘客名单系统、安全部门、目的地国的移民局
4.5 主要的利益相关者
主要的利益相关者是完成这个业务用例工作的人或系统。通常，一个主要的利益相关者触发业务用例，然后一个或多个其他的主动利益相关者参与这项工作：
主动利益相关者：乘客（触发者）、检票员
4.6 总结
现在，通过以上的分析，我们可以得到一个具备场景的业务用例描述模板：
业务事件：乘客决定检票。
业务用例名称和编号：为航班的乘客检票，0101。
启动机制：乘客的机票、电子客票、记录编号，或者身份和航班信息。
前置条件：乘客必须已预订航班。
影响的利益相关者：检票员、市场部门、行李部门、航班预订机构、航班乘客名单系统、工作流、安全部门、目的地国的移民局。
主要利益相关者：乘客（触发者）、检票员。
（1）查出乘客的预订信息。
（2）确保乘客身份正确，并确定预定信息。
（3）检查护照有效并属于这名乘客。
（4）记下经常飞行的乘客的编号。
（5）分配一个座位。
（6）询问安全问题并得到正确回答。
（7）检入行李。
（8）打印登机牌和行李标签并递给乘客。
（9）祝乘客旅途愉快。
成果：记录下乘客已检入这次航班，行李分配到这次航班，分配一个座位，乘客拿到登机牌和行李票根。
五、设计解决方案
经历了前面的四个步骤，我们已经明确了产品的全部业务事件、业务用例，现在就要着手设计产品的解决方案了。
设计产品解决方案有很多文章进行讨论，这里只做一些简单的总结。
5.1 再次明确产品的范围
前面说过，业务用例是工作对外界服务请求的响应。所以最好的响应就是以最少的时间、原材料或工作量成本（从企业的视角），提供最有价值的服务（从用户的视角）。
因此我们打造的产品应该对最好的业务用例做出贡献，即让产品更便宜、更快、更方便，并且能达到我们的项目要实现的其他目标。
5.2 设计产品的用户体验
用户体验设计的理论就不在这里详述了，体验设计的目的是得到一种使用体验，令人满意且令人激动，同时符合用户的文化和期望。
这样的设计更专注于用户对产品的感觉，而不是为产品增加功能。
简单来说：如果你提供了令人满意的体验，用户很享受并愿意重复，那么这些用户就很愿意接受你的产品，并且不要求改变。
5.3 考虑成本、收益和风险
我们有责任得到最有价值的产品，即对拥有者最有价值。
这意味着：解决方案的成本必须与它给拥有者带来的收益相称——花10元钱开发的产品只带来1元钱的收益是没意义的。
风险必须与收益和成本相符。这里的风险包括潜在问题变成真正问题的可能性，以及问题成真所带来的负面的影响。
例如，假定我们建议的解决方案会使用近场通信（NFC）技术。
之前从未用过这种技术，没有内部的专家：风险在于也许不能成功地实现NFC。现在还要加上一项风险：即使这种技术成功地实施，业务客户也可能拒绝使用。
应该将这些风险加起来，与收益进行比较。对于这个级别的风险，我们可能需要一些实质性的收益，才值得去做新产品。如果收益不大，那就应该考虑不同的解决方案。
相反，如果收益巨大，那风险就值得承担。
那如何评价可选的产品边界？这就是要和利益相关者一起花时间的地方，判断哪一种解决方式提供了成本、收益和风险的最佳组合。
六、编写产品需求说明
6.1 功能需求
功能需求指明了产品必须做的事情，即产品为了满足它存在的根本理由而必须执行一些动作。
同时，功能需求是产品为了支持工作而必须做的事情——它们的表述应该尽可能独立于实现需求的技术。
比如，登录功能、购物车功能、收藏功能、支付功能等。
在编写功能需求时，要为需求加上理由，说明需求为什么存在——在大多数情况下，这是需求的关键部分。
接着以物流公司那个为例：
需求描述：对于卡车的调度，产品应该记录开始和结束的时间。
需求理由：卡车在24小时内最多被安排20小时，以便进行维护和清理。
这条理由非常重要，如果该需求没有实现，物流公司就会遇到麻烦，车辆的保养就会不及时。
由此可以看到：一条好的需求理由也能决定需求的优先级。
6.2 非功能需求
非功能需求描述了产品必须具备的品质；这些需求让产品有吸引力、易于使用、快速、可靠，或安全。
用非功能需求来指定响应时间，或计算时达到的精度。
如果产品必须具有某种特的外观，或者必须在特定的环境下使用，或者必须遵守适用于业务法律，我们就要编写非功能需求。
把功能需求看成是使产品工作的需求，把非功能需求看成是为工作增加某些特征的需求。
非功能需求是需求规格说明的重要组成部分。如果产品满足了它所要求的功能需求，非功能属性，如可用性、方便性、打动人心，是否得到满足可能造成产品被接受、深受喜欢或无人使用。
用户对产品的看法和感觉大部分来自于非功能需求。
非功能性需求包括如下内容：
1.观感需求
观感需求描述了对产品外观期望的精神实质、情绪或风格。
要注意：观感需求描述了外观的意图，不是界面的设计。
2.易用性和人性化需求
易用性和人性化需求使产品符合用户的能力和期望。
易用性需求包括：用户的接受率或采用率；因为引入该产品而导致的生产效率的提高或错误率的降低；在产品使用的国家被不说该国语言的人使用；个性化和国际化，让用户改成本地拼写方式及其他选项；对残障人士的可用性；被没有计算机使用经验的人使用；在黑暗的时候可以使用（夜间模式）
礼貌是易用性中一个常常被忽略的方面。在过去的网站，通常是要求创建账户，填写所有个人信息，然后输入密码。
在这之后，用户得到一条消息：“密码应该是8个字母或数字，包括一个大写字母和一个数字，请重新输入密码。”
同时，前面为了创建账户而输入的所有个人信息都被清除，要求用户再来一次——我们不能容忍这样的行为，这对用户的这种行为表明缺少礼貌需求。
此案例的非功能性需求应该这样写：
描述：产品应该避免要求用户重复已输入的数据
理由：为了建立用户对产品的信心
易用性需求源自两个方面，一方面是用户期望产品达到的易用性水平，另一方面是预期用户具有怎样的经验。
自然，用户的特征不同导致他们的期望不同。
作为产品经理，我们必须发现这些特征，并确定怎样的易用性水平将给用户带来舒适有用的体验。
3. 执行需求
如果产品需要在给定的时间，或以特定的精确度来执行某些任务，或者产品需要有一定容量，就要写下执行需求。
执行需求主要来自于操作环境。每种环境都有自己的情况和条件。人、机器、设备、环境条件等都会对产品有要求。产品响应这些情况的方式（它应该多快、多健壮、多大、多频繁），就是相应的执行需求。
4. 操作和环境需求
操作需求规定了如果要在产品的环境中正确操作，产品必须做的事。
在某些情况下，操作环境创造了一些特殊的情况，会影响产品构建的方式。
为了发现操作需求，要查看产品边界并考虑每一个相邻的系统和利益相关者。
如果需要，要与每个利益相关者或系统的代表进行访谈，发现与该产品相关的工作方式所导致的需求。
5. 可维护性和支持需求
可维护性和支持需求描述的是预期的改变，以及完成改变允许的时间，也包括对产品的支持的规定。
在需求阶段，通常不知道产品在它的生命周期里所需的确切维护工作量，而且也不会总是知道它所需的维护类型。
然而，产品在构建时总可以在一定程度上预见维护的类型。
比如：产品应该能够移植到Android和iOS上。
要让研发知道，希望在将来某个时候，产品能移植到另一个平台上，让产品有适应新设备的能力。
6.安全需求
安全需求涉及到三个方面：
可得性
可得性是可以访问数据，产品保存数据的方式让用户能得到数据，同时能理解数据。
在安全方面，可得性需求规定了产品必须做什么，来确保数据只能由授权的用户访问。
在编写这类需求时，要在规定允许的访问，即谁有授权，在哪些情况下授权是有效的，每个授权的用户可以访问哪些数据和功能。
私密性
私密性表示产品尊重用户的隐私，产品必须满足一些需求来确保用户数据的私密性。
完整性
完整性是指：产品所保存的数据与相邻系统发送给产品的数据完全保持一致。
必须考虑防止数据冲突的需求，如果发生了最坏的情况，就要及时恢复丢失的数据。
比如：我们的产品如果投入运行，将保存用户组织机构的重要数据，完整性需求就是要保护些数据。
7.文化需求
文化需求规定了一些特殊因素，它们可能导致产品不被接受，原因是习惯、宗教、语言、禁忌、偏见，或几乎是人类行为的任何方面。
如果试图把产品卖到另一个国家，特别是文化和语言与我们自己的有很大不同的国家，就带来了对文化需求的不同要求。
比如：产品不应该显示与主流宗教有关的宗教符号和文字；产品不应该使用可能激怒任何人的术语和图标；产品提供的语言选择顺序应该符合所在的地区等。
8.法律需求
我们并不想摊上法律诉讼，我们必须注意到那些适用于自己产品的法律，为产品写下符合这些法律的需求。
即使我们的产品是在组织机构内部使用，也要注意到有一些适用于工作场所的法律可能会有关系。
公司里要是有法律顾问就太好了，可以随时请教他。
我们可以考虑如下问题：
考虑用户的法律需求和权利。例如，是否有一些对残障人士的法律是适用的？
相邻系统对保存的数据是否拥有隐私权？是否需要留下交易的证据？是否不能暴露产品拥有的关于某些系统的信息？
是否存在与该产品相关的法律？例如，数据保护、隐私法律、担保、消费者保护、消费者信用、知情权等法律是否适用？
6.3 为需求增加验收标准
如果产品有一项需求，要执行某个功能或具备某种属性，那么测试时必须保证产品确实执行了该项功能，或具备了该项期望的属性。
为了进行这样的测试，需求必须有一个测试基准，这样测试者才能比较提交的产品和最初的需求。
测试基准就是验收标准，即需求的量化，它说明了产品必须达到的标准。
1.非功能性需求的验收标准
非功能需求是产品必须具备的品质，诸如易用性、观感、执行特点等。
因此，验收标准是对这些品质进行量化。
比如：
a.描述：产品应该很酷。
验收标准：40%的目标受众在商店看到展示的产品，会拿起它，至少玩5秒钟，并向同伴展示
b.描述：产品应该使用户感觉到友好。
我们可以测量“喜欢”：如果用户喜欢该产品，他们就会使用它。我们可以测量他们多快开始使用它，使用的时间和频率，或过了多少时间大家开始说该产品是好的，用户之间互相建议使用它。
所有这些验收标准量化了用户的期望，即职员喜欢并使用该产品。
验收标准：在引入该产品的 3 个月之内，60%的用户应该用它来完成规定的工作；在这些用户之中，应该有75%以上的用户对产品表示赞许
c.描述：产品应该直观。
为了测量“直观”，必须考虑“直观”是针对什么用户而言的，比如，让用户可以易于学习。
验收标准：在经过一天的培训后，10个用户中应该有9个能够成功地完成任务
d.描述：响应应该足够快，以避免打断用户的思路。
验收标准：在95%的情况下，响应时间将不超过0.5秒，在其他情况下不超过2秒。
2.功能性需求的验收标准
功能需求是产品必须做的某件事情，即产品必须完成的动作。
验收标准指明了如何得知产品已经成功地完成了该动作。对功能需求来说，不存在测量的尺度：动作要么完成，要么没完成。
例如：
描述：产品首页应该记录涨跌数据
理由：用户需要实时了解交易品的涨跌数据信息
验收标准：首页记录下来的交易品涨跌数据要与国际交易中心的数据一致
3.总结
验收标准既不是测试，也不是对测试的设计，而是测试提交的产品时必须采用的测试基准。
它是构建测试用例的输入信息，测试者通过测试用例来确保产品的每项需求都符合它的验收标准。
6.4 产品需求模板
综上所述，我们可以得到一个描述需求的模板：
6.5 总结
编写需求规格说明不是一项独立的工作，而是与需求过程的其他部分一起完成的。无论何时，如果产品经理或其他利益相关者有所发现，就写下需求或部分需求。并非所有需求都是同时完成的。
正确地编写需求是很重要的。
一组好的需求能得到数倍的回报：构建工作更精确，维护成本更低，完成的产品更准确地反映用户的需要和想法。
七、排列需求优先级
排列优先级让我们能选择哪些需求在产品的哪些版本中实现。
确定优先级很复杂，因为它们涉及不同的因素，而这些因素彼此之间常常产生冲突。
要排列需求的优先级，可以将它们分成逻辑上的小组。这些小组分别作为一个单元来排列优先级。
一个小组可能是一个业务用例、一个组件、一项功能，或其他需求分组，只要能够作为一个单元来排列优先级，而不用单独处理就行。
影响需求优先级的因素包括：
实现的成本
对用户的价值
实现产品所需的时间
技术实现的容易程度
业务或组织机构实现的容易程度
对业务的好处如何
遵守法律的要求
不是所有因素都适用于每个项目，而且每个因素对每个项目的相对重要性也不一样。
在一个项目中，对不同的利益相关者来说，这些因素的相对重要性也不同。
由于这些复杂性，我们需要对优先级达成一致意见，以提供决策。
八、总结
产品需求从不是拍拍脑袋就想出来的，它也是需要一个缜密、完整的过程。希望本文总结的需求流程能给你带来一些启发。
———— / END / ————
———— / 推荐阅读 / ————
小班授课+小组学习+模拟训练
BAT产品大咖手把手带你
实战演练体验产品从0到1全过程！
点击“阅读原文”，了解更多信息
