跟着师傅做了几个日常，参加了几次需求的讨论，渐渐感觉到做需求还是需要花费不少精力的。如果说对原来的业务非常熟悉，相对来说做起来就轻松一些，而要是从来都没接触过这块内容，就会感觉有点像丈二和尚摸不着头脑：知道用户想要什么，但是却不知道如何跟现有的系统更好的结合起来，我们到底能够提供什么？用户的需求是否合理？做需求分析，不能跟着用户的感觉走，因为这样的话，只能是用户说一你做一，而如果用户不能很好的提炼需求的时候，我们就会进入一个死循环了。在和用户讨论的时候，我们首先要知道用户为什么会提出这个需求？能够帮助他解决什么样的问题？希望达到什么样的效果？并不是所有的用户都能正确的表达自己所想要的东东的。
一个比较典型的例子：最近跟一个营销平台的PD在聊用户一般会怎么样来提需求的時候，谈到曾经做过的一个营销活动的推广需求，运营人员为了推广某一项活动，往往会比较纠结在页面上这个按钮应该如何放置，需要新增加几个显示字段才能达到这次活动的效果，那这是用户最根本的需求吗？不是，实际上他真正需要的是应该给他提供几个维护活动的界面：类似什么样的活动时应该出现下拉的选择框进行维护，什么样的活动应该给他提供几个选项项。他们习惯上只会关注到现在他需要什么样的功能，在下次需要新的功能的时候，又会来提新的需求，所以对于类似这样的问题，PD的作用就显现出来了：透过现象看本质，要善于抓住用户描述问题的过程，引导他抛出隐含在这个需求背后的衍生内容，复述一下用户所说的目前存在的问题，了解一下用户可能会用的方式有哪些？并说明对流程的理解，再结合流程中的不明确点设计要询问的问题，并将客户的反馈记录下来，然后与客户确认一下是否有遗漏的内容，增加这些属性是否就都已经覆盖了他所想要的所有功能了？
我想这其实也就是需求分析的价值所在吧。这步工作如果没有做好，往往就会导致考虑得不够充分而引起新的需求变更，甚至关系到开发出来的软件产品能否得到用户的认可，客户能否真正运用我们的产品帮助他们解决业务或管理上的问题。当然要做到这一点，也不是一两天就能搞定的，需要一个逐渐积累的过程，学会如何巧妙的向客户提问也是一门非常值得我们去思考的学问。业务方在需求的提出方面起着主导作用，但PD必須要能够对客户的需求进行过滤，要在非常了解原有系统功能，架构设计的基础上来给出建议，这样才有可能在需求阶段规避掉一些具有比较大业务风险、技术风险的需求。
我们与运营方讨论的过程中会收集到一些新的需求，回来后一般需要对用户繁杂的业务进行流程的提取，把那些分布在各个部门的同一种业务提取出来进行初步的整理和分析， 把大致的功能点整理一下，遇到不明确的、有疑问的再咨询师傅，必要的时候还要跟开发进行讨论实现上是否可行。整体的思路是这样的：业务的目标是什么？用户需要怎么做才能完成业务目标？系统要能为用户提供哪些支持？系统必须符合哪些规则？展现的形式可以包括：用例的分析，业务流程和活动输入输出的分析，业务操作规则的整理，通过确定用户的任务，每项用户任务的步骤，定义对业务具有重要意义的数据并确定已有的逻辑关系。在确保业务描述基本没什么问题的前提下，邀请开发和业务方进行评审，并对业务流程上不对的地方进行修改。经过几次来回的交流，最终才能取得较全面的需求。需求分析关注的目标应该是“做什么”，而不是“怎么做”，所以在描述需求的时候，表述的方式应该是“实现什么”，而不是“如何实现”。
做需求分析的过程，其实跟我们的测试分析工作有非常相似之处：我们在测试活动中，也都是从理解业务的需求开始的，首先需要明确测试需求（What），才能决定怎么测（How），通过了解这个项目具体是做什么的，完成一个什么样的业务，哪些功能是最常用的？哪些功能是重点？还有就是用户在处理实际业务时都要作些什么，多个业务之间的先后顺序是怎样的，用户在处理业务时对于哪些地方有特别的要求，等等。这部分规则，就是我们的测试需求中最基本的一部分。测试需求不明确，只会造成获取的信息不正确，无法对所测项目有一个清晰全面的认识，活在自己世界里的人是可悲的。
测试需求并不等同于软件需求，它是以测试的观点根据项目需求整理出一个checklist，作为测试该项目的主要工作内容。根据所测的功能点进行分析、分解，从而得出着重于某一方面的测试，如界面、业务流、接口、数据等等。理解项目需求，需要从整体到局部，从局部到细节。测试人员不要总只了解自己模块的内容，要先从整个项目的业务流程入手，然后再到自己的功能模块，这样的好处是，测试人员了解上下游的交易功能，更加的能够了解业务的实现方法。经过一番狂轰乱炸式的深入理解之后，再将自己负责的模块有条有理的整理出来，然后讲解给项目组成员，这样也有利于模块之间的整合理解，再由他们提出各种各样的问题，若能很轻松的回答出各种各样的问题，说明你对项目的理解已经很到位了，而如果在提问的过程中有很多的问题，都是你之前没有考虑到的，那说明测试的需求分析做的还不够到位，这时你就需要好好总结一下，是因为自己经验方面的问题，还是由于其他方面的原因。总结起来测试需求的内容大致如下：
1、理解系统的流程：整理出业务的常规逻辑，一项一项列出各种可能的测试场景，同时借助于需求文档资料，来确定该场景应该导致的结果
2、进行功能的分解：系统包含哪些主要的功能，每个功能的期望值是什么；各个模块处理哪些业务，各子系统模块之间的数据接口关系，基础数据从哪里进入，通过哪些处理生成哪些结果等等。在做完以上步骤之后，将业务流中涉及的各种结果以及中间流程分支回顾一遍，确定是否还有其他场景可能导致这些结果，以及各中间流程之间的交互可能产生的新的流程，从而进一步补充与完善测试需求。
以上只是个人对如何进行需求的捕获以及怎么样做好需求理解的一些看法，同时也是对我自己前段时间的工作做的一点梳理，希望大家能多多交流，共同进步，把我们的测试工作做的更好。