通过与PD进行讨论实际所想表达的内容，对于文字描述不清楚的地方，建议用图片的方式进行页面的交互。由于自然语言极易导致二义性，如果有条件的话，建议还是用基于原型的方式进行开发，这样可以在早期杜绝掉交互上出现的问题。来看一个功能需求的例子：“销售出货要考虑到信用额度”。这里存在的问题就是出货与信用额度之间的依赖关系没有描述清楚,我们把它修改成：
1.销售出货的前提是该客户拥有超过出货价值的信用额度XXX, 否则,系统提示‘该客户信用额度不足,不予出货!’
2.正式出货后系统将扣减其信用额度很显然,修改后的需求把出货和信用额度的来由去向和系统的具体反应都说明清楚了。如果你接手的项目也存在这样类似的问题，则一定要在需求阶段明确要求PD 对需求做出调整。
要善于挖掘隐含需求，看一下下面的需求：“本月没有参加过竞价的会员显示0；本月参加过竞价的会员显示出价次数”这个需求看上去已经描述的很清楚了，但实际去测试的时候，我们必须覆盖以下的业务逻辑：从来没有出价记录的会员显示为0；上月有出价、本月没有出价的会员显示为0；本月有出价的会员显示出价次数。挖掘需求背后的测试要点，需要我们平时一点一滴的积累，不要被表象所迷惑。
我们一定要以测试目标为中心，去查找不充分的不完整的需求，通过以上的过程，我们可以把不直观的需求转变为直观的需求, 把不明确的需求转变为明确的需求，直到所有的问题都得到了解决并经过再测试OK，需求阶段的测试才可以结束
。
转载务必注明出处Taobao QA Team，原文地址：http://qa.taobao.com/?p=7401