管理的辅助：
在有些地方，需求管理被作为一个技术问题来处理，需求管理所针对的对象只是产品，而同项目管理所涉及的问题例如进程安排或资源分配等无关。实际上，项目管理涉及三方面问题：进程安排、资源分配和质量管理（同需求的统一）。
试想以下三种情况：
●一场高水准的音乐会，预算合理，演出时间却晚了两天。
●质量优良的小轿车，交货及时，然而造价是市价的两倍。
●一套系统，完全满足了用户需求，但在开发过程中使用非法劳工。
这三种情况虽然都满足了用户所需，然而缺乏实际意义，因此都以失败告终。
"我付了钱，但这不是我想要的"，没有用户愿意这么说。要避免出现这种情况，在进行项目管理和财务预算时，也必须以需求管理为基础。仅仅完成了一件设计并不意味着工作的结束，只有这件设计充分解决了需求，它才具有里程碑般的意义。同样的，一件产品只有在测试和实际操作中完全满足了需求，已经完全准备好了投入到下一阶段的运营，才意味着这件产品在本阶段工作的结束。
开发进程中的每一块里程碑都意味着需求的解决又前进了一步，这样的每一块里程碑也都是委托商付款的重要参照，产品开发的整个进程都可以通过需求管理进行监控。
里程碑构造机制的基本方法之一就是进程管理，一项需求的满足就意味着一块里程碑的确立。我们应当对用户需求、针对需求而进行的模块设计以及每个子模块的开发进程之间的关联做到心中有数。
通过我们对需求管理实际应用的分析，几个关键因素凸现出来。首先，需求管理在开发周期中是自始至终存在的。注意：不要把它简单理解为"需求周期"，需求管理必须始终保持更新，它构成了技术管理的基础。
其次，需求管理同项目管理是密不可分的。如果我们把每一个需求的解决看作一个里程碑，并以此出发对整个开发进程进行监控，我们就应该对整体开发工作进行精密细致的划分，从而将需求分析具体化。
☆需求管理的概念化阐释
需求管理应当具有以下几个特征：能够在开发周期的初期就建立需求模型；建模的成本很低；易于以后的具体化和优化；本身能体现最终解决方案的特征。也许某些细节是抽象的，但需求管理模型本身必须是完整的。需求模型不应当具有诱导性或倾向性，必须为开发工作留有充分发挥和优化的空间。同时，我们能够通过需求模型对最终产品作出评估。但不幸的是，这些特征本身也不是彼此完全兼容的，很难在一个简单模型中做到面面俱到。
在开发初期针对需求而搭建产品模型（Early Models）是容易的，成本也不会太高，但是这样的模型是很抽象的，绝非等同于最终产品。随后的产品原型（Prototypes）或高级模型 (Qualification Models) 将更接近于最终产品，但搭建这样的模型会要求更高的成本，同时可供修改的余地也更少。
需求管理的多种模式：
需求管理所要搭建的不同模式是由系统工程所采用的标准决定的。传统上需求管理有两种模式：客户模式和系统需求模式。从这两种模式出发的方案应该分别进行设计，不幸的是我们常常将此二者混为一谈。
用户模式着重描述用户面临的问题或希望得到的结果。用户模式的语言组织很象使用场景的实地描述，指明时间，侧重结果。无论谁搭建用户模式，都必须从用户的角度出发。
系统需求模式实际是抽象化的解决方案。系统需求模式的语言组织经常运用功能描述或使用详解性的说明文字，事实上功能描述和使用详解正是系统需求模式语言组织的典型风格。
实际上设计方案应当是第三种模式，即具体化的解决方案。很明显这种模式已经非常接近于最终解决方案。很多不同的设计方案都能解决用户需求，而在用户需求既定的同时对设计方案作
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
