解；另一方面是指同一读者能用不同的方式来解释某个需求说明。多义性会使用户和开发人员等项目参与者产生不同的期望，也会使开发、测试人员为不同的理解而浪费时间，带来不可避免的后果便是返工重做。
7）忽略了用户的特点分析。分析人员往往容易忽略了系统用户的特点，系统是由不同的人使用其不同的特性，使用频繁程度有所差异，使用者受教育程度和经验水平不尽相同。如果忽略这些的话，将会导致有的用户对产品感到失望。
8）需求开发的时间保障。为了确保需求的正确性和完整性，项目负责人往往坚持要在需求阶段花费较多的时间，但用户和开发部门的领导却会因为项目迟迟看不到实际成果而焦虑，他们往往会强迫项目尽快往前推进，需求开发人员也会被需求的复杂和善变折腾的筋疲力尽，他们也希望尽快结束需求阶段。
在实际的工作中，我列了一些需要关注的问题，以避免一些不必要的麻烦。
1）抓住决策者最迫切和最关心的问题，引起重视。用户方决策者对项目的关心重视程度是项目能否顺利开展的关键，决策者的真实意图也是用户方的最终需求，因此，在开发过程中要利用一切机会了解决策者关心的问题，同时也要让他们了解项目的情况。在诸如谈判、专题汇报、协调会议、领导视察、阶段性成果演示等过程中用简短明确的语言或文字抓住领导最关心的问题，引导他们了解和重视项目的开发，当决策者认识到项目的重要性时，需求分析工作在人力、物力、时间上就有了保障。
2）建立组织保障，明确的责任分工。项目开发一般都会成立相应的项目组或工程组，目前，常见的组织形式是：产品管理组、质量与测试组、程序开发组、用户代表组和后勤保障组，各组的主要分工是：产品管理组负责确定和设置项目目标，根据需求的优先级确定功能规范，向相关人员通报项目进展。程序管理组负责系统分析，根据软件开发标准协调日常开发工作确保及时交付开发任务，控制项目进度。程序开发组负责按照功能规范要求交付软件系统。质量与测试组负责保证系统符合功能规范的要求，测试工作与开发工作是独立并行的。用户代表组负责代表用户方提出需求，负责软件的用户方测试。后勤保障组负责确保项目顺利进行的后勤保障工作。
3）建立良好的沟通环境和氛围。分析人员与用户沟通的程度关系到需求分析的质量，因此建立一个良好的沟通氛围、处理好分析人员与用户之间的关系显得尤其重要，一般情况，用户作为投资方会有一些心理优势，希望他们的意见得到足够的重视，分析人员应该充分的认识到这一点，做好心理准备，尽量避免与他们发生争执，因为我们的目的是帮助用户说出他们的最终需要。在沟通时分析人员应注意以下几个方面：
1）态度上要尊重对方，但不谦恭。谦恭可能会让用户一时感到满意，但对长期合作并没有好处，尤其是在发生冲突的时候，用户会习惯性地感到自己的优势，而忽略分析人员地意见。
2）分析人员要努力适应不同用户的语言表达方式。每个人都有自己的表达方式，所以优秀的分析人员应该是一个优秀的“倾听者”，他们能很快的适应用户的语言风格，理解他们的意思。
3）善于表达自己，善于提问。分析人员在开口前应该先让对方充分表达他的意思，在领会了后，自己再说，尽量不要抢话。
4）工作外的交流有助于增进理解，加强沟通。
4）需求质量控制要制度化需求的变化是软件项目不可避免的事实，因此需求质量控制是一项艰苦的工作，要保证该项工作的顺利实施，就必须有制度保证，这个制度可以在项目质量控制方案中制定，该方案主要是具体化、定量化的描述用户要求，形成全面、一致、规范的软件需求分析规格说明书，明确需求分析规格说明书的工作程序和要素，规范开发活动，为后续软件设计、实现、测试、评审及验收
提供依据。在方案中要明确项目组各部门关于需求质量控制的职责，制定需求分析的工作程序，包括编制需求分析工作计划、编制《需求分析说明书》、《需求分析规格说明书》的评审和确认、《需求分析规格说明书》修改控制、确定需求质量控制的质量记录文档规范等内容。
本文论述围绕于需求管理，需求管理是开发工作有效进行的确证。很明显需求管理是一种很高层次的系统行为，涉及整个开发过程和产品本身。需求管理首先要针对需求做出分析，随后应用于产品并提出方案。需求分析的模型正是产品的原型样本，优秀的需求管理提高了这样的可能性：它使最终产品更接近于解决需求，提高了用户对产品的满意度，从而使产品成为真正优质合格的产品。从这层意义上说，需求管理是产品质量的基础。