网上很多类似需求分析的帖，还有少许高人挂名，无非都是写些抓住显性需求，深挖隐性需求之类云云，再问的深入点的话回答多半就是结合实际项目分析等等。有 时候大道理看多了会让人有深陷泥泞的感觉，在面对实际项目时就有点找不到出路。现在我就说点实际的，谈谈我在项目中所遇到的问题。

　　在实际项目中，需求一般经历三个活动，即：评审、基线和变更;相对应的测试活动有：评审、用例和测试，具体时间点的对应分别是需求评审中、需求基线后和需求变更前后，当然在需求变更完成后也会穿插一些用例修改工作。

　　我们先来看看测试三项活动中，哪一个环节最重要。我之前写过这么一句话，叫做：方法影响用例，用例指导执行，执行显示结果。当然，方法自在人 心，由此可见用例很重要。用例一般在需求基线后进行编写，但实际项目中由于项目紧急，PM就希望在需求基本逻辑稳定后先同步进行编写用例，之后再根据需求 变动而修改相应的测试用例。在这里我比较赞赏的是用例前置这么一个好的提议，但是我个人又不太认可这么一个做法。

　　首先根据缺陷放大模型，我们肯定是希望能够将所有可能触发的缺陷给扼杀在摇篮里，即在需求评审的时候就提出相应的问题，我们都知道，编写测试 用例是发现需求问题的一个重要手段，那么如果我们在需求基线后再去写测试用例，那么就一定会有更多的需求问题会在开发那里衍生成为系统缺陷，所以我赞赏用 例前置这个提议。

　　但是这样一来，另外一个问题就摆上台面了。基线前编写好的测试用例在需求基线之后的修改量是十分巨大的，而且在某些需求大改动的地方，我们只 有选择重新编写用例，因为历史用例会禁锢我们的思想导致测试点缺失。这不仅仅是一个工作量的问题，它同样会诱发消极怠工情绪，这也是为什么我并不大认可需 求基线前就编写测试用例。

　　有时候人真是一个矛盾综合体啊，下面谈谈我的做法。首先我需要充足的评审时间，因为我需求评审的时候会看的相当仔细，不仅关注基本的逻辑问 题、措辞严谨问题，还关注角色权限、功能入口、返回界面、默认排序、字段长度、字符限制、流程的合理性已经相应UI原型布局、交互、菜单层级之类的问题， 将写测试用例时所想的在评审的时候发挥出来，以便理清需求、尽早的发现更多的问题，这时候用例不会写出来，但是在脑海里应该有个大概的轮廓。用记事本记录 所有问题，时刻关注需求文档的修改，并实时将最新版本需求文档与之前版本的需求文档在SVN中进行对比，确保自己关心的问题得到修改，并记录他人提出的修 改意见在需求中的修改情况，并根据相应的修改情况重新整理脑海中用例的映射集，在需求基线后就可以用最快的方式写出最完整的测试用例。

　　合理的需求分析还应该结合一个合理的功能点划分，一般情况下我们功能点的划分直接按照工作量来划分，其实还应该结合功能点之间的关联程度、相 应需求人员的分工以及相应测试人员的能力进行划分。具体原因细节我不愿在这过多累述，虽然在实行上有些困难，但是我觉得这个大致方向是可取的。

　　以上为本人愚论，欢迎广大舆论来批评指正。