一个系统非常难确定明确的范围并把所有需求一次性提出来，这会导致研发人员在项目进展中去不断完善需求，先建立系统结构再完成需求说明，造成返工的可能性非常大，会给研发人员带来挫折感，降低他们完成项目的信心。
（5）需求的细化程度。需求到底描述到多细，才算能结束了？虽然国家标准有需求说明的编写规范，但具体到某一个需求上，非常难给出一个具体的指标，可谓仁者见仁，智者见智，并没有定论。需求越细，周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取需求也越高，相反，需求越粗，研发人员在技术设计时不清晰的地方就越多，影响技术设计。
（6）需求描述的多义性。需求描述的多义性一方面是指不同读者对需求说明产生了不同的理解；另一方面是指同一读者能用不同的方式来解释某个需求说明。多义性会使用户和研发人员等项目参和者产生不同的期望，也会使研发、测试人员为不同的理解而浪费时间，带来不可避免的后果便是返工重做。
（7）忽略了用户的特点分析。分析人员往往容易忽略了系统用户的特点，系统是由不同的人使用其不同的特性，使用频繁程度有所差异，使用者受教育程度和经验水平不尽相同。如果忽略这些的话，将会导致有的用户对产品感到失望。
（8）需求研发的时间保障。为了确保需求的正确性和完整性，项目负责人往往坚持要在需求阶段花费较多的时间，但用户和研发部门的领导却会因为项目迟迟看不到实际成果而焦虑，他们往往会强迫项目尽快往前推进，需求研发人员也会被需求的复杂和善变折腾的筋疲力尽，他们也希望尽快结束需求阶段。
3 怎么做好需求工作
需求分析是软件项目研发中最困难的一项工作，他不仅需求分析人员具有丰富的需求分析经验和良好的专业素质，还需求分析人员具有良好的学习能力、公关能力、语言能力和组织能力。在实际工作中分析人员要面对不同的单位、不同的部门、不同的人员、不同的文化、不同的关系、不同的管理水平等等不同的情况，面对如此纷繁复杂的环境，怎么做好需求分析工作？首先需要建立一个有效的工作机制，只有建立了工作机制，才能确保需求工作按照既定方案执行，需求研发和管理的参和者才会在一种有序的状态下工作。其次才是充分运用工作机制和个人能力去获取问题、分析问题、编写需求文件和进行需求管理。
3.1 建立需求分析工作机制需考虑的几个因素
（1）抓住决策者最迫切和最关心的问题，引起重视。用户方决策者对项目的关心重视程度是项目能否顺利开展的关键，决策者的真实意图也是用户方的最终需求，因此，在研发过程中要利用一切机会了解决策者关心的问题，同时也要让他们了解项目的情况。在诸如谈判、专题汇报、协调会议、领导视察、阶段性成果演示等过程中用简短明确的语言或文字抓住领导最关心的问题，引导他们了解和重视项目的研发，当决策者认识到项目的重要性时，需求分析工作在人力、物力、时间上就有了保障。
（2）建立组织保障，明确的责任分工。项目研发一般都会成立相应的项目组或工程组，目前，常见的组织形式是：产品管理组、质量和测试组、程式研发组、用户代表组和后勤保障组，各组的主要分工是：产品管理组负责确定和设置项目目标，根据需求的优先级确定功能规范，向相关人员通报项目进展。程式管理组负责系统分析，根据软件研发标准协调日常研发工作确保及时交付研发任务，控制项目进度。程式研发组负责按照功能规范需求交付软件系统。质量和测试组负责确保系统符合功能规范的需求，测试工作和研发工作是独立并行的。用户代表组负责代表用户方提出需求，负责软件的用户方测试。后勤保障组负责确保项目顺利进行的后勤保障工作。
&nbs