1) 产品视图与范围如果团队成员没有对他们要做的产品功能达成一个清晰的共识，则很可能导致项目范围的逐渐扩大。因此最好在项目早期写一份项目视图与范围将业务需求涵盖在内，并将其作为新的需求及修改需求的指导。
2) 需求开发所需时间紧张的工程进度安排给管理者造成很大的压力，使他们觉得不赶紧开始编码将无法按时完成项目，因而对需求一带而过。项目因其规模和应用种类不同（如信息系统，系统软件，商业的或军事的应用）而有着很大的不同。粗略的统计表明：需求开发工作应占全部工作量的1 5 %（Rubin 1999）。记录你参与的每个项目中实际需求开发的工作量，这样就能知道所花的时间是否合适并改进将来项目的工作计划。
3) 需求规格说明的完整性和正确性为确保需求是客户真正需要的，要以用户的任务为中心，应用使用实例技术获取需求。根据不同的使用情景编写需求测试用例，建立原型，使需求对用户来说更加直观，同时获取用户的反馈信息。让客户代表对需求规格说明和分析模型进行正式的评审。
4) 对革新产品的需求有时容易忽略市场对产品的反馈信息。故要强调市场调查研究，建立原型，并运用客户核心小组来获得革新产品任务的反馈信息。5) 明确非功能需求由于一般强调产品的功能性要求，非常容易忽略产品的非功能性的需求。询问客户关于产品性能、使用性、完整性、可靠性等质量特性，编写非功能需求文档和验收标准，（像在S R S中一样）作为可接受的标准。
6) 客户赞同产品需求如果不同的客户对产品有不同的意见，那最后必将有些客户会不满意。确定出主要的客户，并采用产品代表的方法来确保客户代表的积极参与，确保在需求决定权上有正确的人选。
7) 未加说明的需求客户可能会有一些隐含的期望要求，但并未说明。要尽量识别并记录这些假设。提出大量的问题来提示客户以充分表达他们的想法、主意和应关注的一切。
8) 把已有的产品作为需求基线在升级或重做的项目中需求开发可能显得不很重要。开发人员有时被迫把已有的产品作为需求说明的来源。“只是修改一些错误和增加一些新特性”，这时的开发人员不得不通过现有产品的逆向工程(reverse engineering)来获取需求。可是，逆向工程对收集需求是一种既不充分也不完整的方法。因此新系统很可能会有一些与现有系统同样的缺陷。将在逆向工程中收集的需求编写成文档，并让客户评审以确保其正确性。
9) 给出期望的解决办法用户推荐的解决方法往往掩盖了用户的实际需求，导致业务处理的低效，或者给开发人员带来压力以至做出很差的设计方案。因此分析人员应尽力从客户叙说的解决方法中提炼出其本质核心。