讲一个小王跟小李的故事，小李是程序员，小王是产品经理。当小李接到一个新的需求，让他开发一个单点登录。经过几天的奋战，他顺着写完代码，这时产品经理小王路过他身边，顺便问了他一下。
小王：单点登录做的咋样了？
小李：做完了我给你演示一下。
小李演示了一遍自己的功能，小王看上去很满意。
小王：不错，不过怎么没有支持验证码？
小李：为什么要做这个？
小王：这不就是登陆了一部分吗？
小李：哪里规定要做验证码了？
小王：现在登录哪有不用验证码的？
双方的对话都充满了火药味，有可能控制不好情绪，那么就会一触即发。在工作中你是否也会遇到过这样的情况？他俩为什么会有这么大的分歧？其中一个重要的原因就是开始这个需求之前没有把需求给定义好。
这在软件开发的过程中是一个很重要的问题。我们一般如何去定义需求？有些需求你直接听到还好，但是有些需求是他人转述的，可能就会存在一些偏差，因为信息在传递的时候，它是呈衰减的。你不可能把你理解的信息的100%传递给另一个人，在传递的过程中它是存在衰减的。
如何处理这样的问题，一般像产品经理就会有比较详细的需求文档，具体到某一需求都会罗列出来相关功能列表。用功能列表式的需求描述方式，将一个完整的需求打成一个个碎片，按照类似于清单的方式，一条一条列出来。这样开发人员再去开发的时候，就知道自己有到底有没有把它给弄完。只有当所有的功能完成后，然后将它对接在一起，才算是“破镜重圆”的时刻。
那么，我们一般如何去描述一个新的描述需求。通常我们会“用户故事”方式去阐述。简单的说就是站在用户的角度，你提供一个什么样的功能？他要经过什么样的路径？达到怎样的结果，这就是一个完整需求的场景。
用户故事大致分为四个部分：
第一个是标题，这个需求是什么？就比如说注册用户使用用户名和密码登录。
第二个是概述，概述的格式可以按照：你作为一个什么样的角色？做的事情要达到怎样的效果？比如说作为一个注册用户，我想通过用户和密码登录，然后才可以使用注册用户的使用的服务，
第三个是详述，就是把一些操作流程和用户界面的信息展示出来，比如说我登录成功之后跳到什么页面，登陆失败又是怎样的效果？这些都是要描述出来。
第四个是验收标准，它一般是一个正常的流程，同时我们还需要考虑一些异常的流程，这往往是我们比较欠缺的。
怎样才算做完了需求？验收标准说了算。验收标准会给出这个需求的测试用例，他会保证开发人员完成需求的最基本的质量。这就是我们所说的行为驱动开发，可以按照这样的标准去给出测试用例。
实际工作中许多产品经理的需求，把需求交给开发人员之前，很多细节没有想清楚，那种功能列表式的需求常常只包含了正常路径，而缺失的细节就是在后续过程中有开发人员补的。用户故事就是一种固定的格式，让他们把这些应该想清楚的问题想清楚。所以，如果你的团队是采用用户故事的格式进行需求描述，固然如果不能在功能仪表中补充验收标准，也会极大地程度改善双方协作的效率。
至此，今天要聊的就这些，如果你只能记住一件事的话，那么请记住：在做任何需求和任务之前先定义好验收标准。
