对于一个需求而言，它不是简简单单一个功能上的操作，它有可能是一个性能需求，也有可能是安全保密需求，甚至还有可能是用户接口需求、成本消耗需求、可靠性需求等，所以在需求分析的阶段，不是说跟客户简单的几句交流就能把这个需求完全理解，而且即使清楚了这个需求，能不能做（可行性）也不可能一步完成。
4.3需求评审与实现
　需求评审的规程与其它重要工作产品(如系统设计文档、源代码)的评审规程非常相似，主要区别在于评审人员的组成不同。前者由开发方和客户方的代表共同组成，而后者通常来源于开发方内部。
有人问：需求评审究竟评审什么?要细到什么程度?怎么样进行?严格地讲，应当检查需求文档中的每一个需求，每一行文字，每一张图表。评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。如果有可能，最好可以制定评审的检查表。
需求实现阶段其实严格来说不算在需求过程里，而是在开发阶段，它是系统的实现进行的一系列具体的分析。
4.4建立需求管理模型
需求建模是表达需求的一种形式，是对需求的一种描述与阐释，它使用标准的语言，利用类似积木的概念来建模，最大的好处是大家可以直接根据需求，轻易地反复修改需求模型。并且不会产生歧义，从而可以使大多数人快速地理解。
需求建模的目的是要消除人际沟通随意性很强的弱点，所以需要致力于将沟通标准化、自动化、准确化，而且责任到人负责的具体阶段。具有可测试、可验证性的特点。建模的过程就是通过需求的特点和要求进行分析，以建模标准为基础进行准确、完备和有效的阐述，以确保客户和开发方都能够明确无误地、通用的理解。
5．对需求管理的进一步理解
前一章节把简单介绍了需求处理过程的四个阶段，对于需求管理，要着重理解“管理”的含义。一个软件或者硬件必然是许多的功能组合而成的，而一般情况下每个功能其实都是来源于一个需求的，当然一个需求可能也会有很多个功能来实现的。所以对于需求的管理，我们不是在管理一个需求，而是在管理若干需求，需求管理好了，这个产品才有可能做得好。所以对于需求的管理，我们必然需要有很多严格的要求：
5.1 需求管理必须流程化
什么事需求管理流程化？因为需求的管理涉及了需求从被获取到分析到设计最后去实现一连串的过程，每个过程其实都是缺一不可的（虽然在敏捷中可能过程的概念被弱化，但是事实上最基本的管理还是有的），而且过程之间是有必然的联系，比如我不可能获取了需求就去设计开发了，最后却发现做出来的东西不是客户需要的，这是因为你绕过的分析的阶段。
所以需求的管理对于过程的流程化很重视，需求需要严格按照流程来处理，每个过程最好由不同的人的来处理，并且过程之间转换时，需要有审核程序。需求管理的流程化入下图所示：

图 2 需求管理流程图
5.2 需求管理必须审核
其实第一条也提到了审核，审核这个程序也是非常重要的，因为需求涉及到的这么多过程都是需要人处理的，人处理的好坏会直接影响到这个需求的实现，获取得是否正确?分析得好与坏?设计得是否得当?开发得是否正确?只要有一点做得不好，都会导致这个产品失败，所以我们需要审核，一般情况下每一个过程都需要一次审核，审核失败就重新来过，有些公司甚至有几重审核机制。
5.3 需求管理必须欢迎变更 软件开发质量管理提升系统之需求管理(4):http://www.youerw.com/jisuanji/lunwen_532.html