龙去脉”，这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能。
5. 过于精简的规格说明
有时，客户并不明白需求分析有如此重要，于是只作一份简略之至的规格说明，仅涉及了产品概念上的内容，然后让开发人员在项目进展中去完善，结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况。但在大多数情况下，这会给开发人员带来挫折（使他们在不正确的假设前提和极其有限的指导下工作），也会给客户带来烦恼（他们无法得到他们所设想的产品）。
6. 忽略了用户分类
大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如果你不能在项目早期就针对所有这些主要用户进行分类的话，必然导致有的用户对产品感到失望。例如，菜单驱动操作对高级用户太低效了，但含义不清的命令和快捷键又会使不熟练的用户感到困难。
7. 不准确的计划
据统计，导致需求过程中软件成本估计极不准确的原因主要有以下五点：频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析。
对不准确的要求所提问题的正确响应是“等我真正明白你的需求时，我就会来告诉你”。基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右。要作出估计时，最好还是给出一个范围。未经准备的估计通常是作为一种猜测给出的，听者却认为是一种承诺。因此我们要尽力给出可达到的目标并坚持完成它。
6．需求分析人员和用户的合作关系
优秀的软件产品是建立在优秀的需求基础之上的。而高质量的需求来源于客户与开发人员之间有效的交流与合作。通常，开发人员与客户或客户代理人，如市场人员间的关系反而会成为一种对立关系。双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦，在这种情况下，不会给双方带来一点益处。
只有当双方参与者都明白要成功自己需要什么，同时也应知道要成功合作方需要什么时，才能建立起一种合作关系。由于项目压力与日渐增，所有风险承担者有着一个共同的目标这一点容易被遗忘。其实大家都想开发出一个既能实现商业价值，又能满足用户需要，还能使开发者感到满足的优秀软件产品。
软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员交流时的合法要求。每一项权利都对应着软件开发人员、分析人员的义务。而软件客户需求义务书也列出了十条关于客户在需求过程中应承担的义务。如果愿意，可以将其作为开发人员的权利书。
客户有如下权利：
1：要求分析人员使用符合客户语言习惯的表达
需求讨论应集中于业务需要和任务，故要使用业务术语，你应将其教给分析人员，而你 不一定要懂得计算机的行业术语。
2：要求分析人员了解客户的业务及目标
通过与用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使产品更好地满足你的需要。这将有助于开发人员设计出真正满足你的需要并达到你期望的优秀软件。为帮助开发人员和分析人员，可以考虑邀请他们观察你或你的同事是怎样工作的。如果新开发系统是用来替代已有的系统，那么开发人员应使用一下目前的系统，这将有利于他们明白目前系统是怎样工作的，其工作流程的情况，以及可供改进之处。
3：要求分析人员编写软件需求规格说明
分析人员要把从你和其他客户那里获得的所有信息进行整理，以区分开业务需求及规范、功能需求、质量目标、解决方法和其它信息。通过这些分析就能得到一份软件需求规格说明。而这份软件需求规格说明便在开发人员和客户之间针对要开发的产品内容达成了协议。软件需求规格说明书可以用一种你认
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
