项目管理的辅助：
在有些地方，需求管理被作为一个技术问题来处理，需求管理所针对的对象只是产品，而同项目管理所涉及的问题例如进程安排或资源分配等无关。实际上，项目管理涉及三方面问题：进程安排、资源分配和质量管理（同需求的统一）。
试想以下三种情况：
●一场高水准的音乐会，预算合理，演出时间却晚了两天。
●质量优良的小轿车，交货及时，然而造价是市价的两倍。
●一套系统，完全满足了用户需求，但在开发过程中使用非法劳工。
这三种情况虽然都满足了用户所需，然而缺乏实际意义，因此都以失败告终。
"我付了钱，但这不是我想要的"，没有用户愿意这么说。要避免出现这种情况，在进行项目管理和财务预算时，也必须以需求管理为基础。仅仅完成了一件设计并不意味着工作的结束，只有这件设计充分解决了需求，它才具有里程碑般的意义。同样的，一件产品只有在测试和实际操作中完全满足了需求，已经完全准备好了投入到下一阶段的运营，才意味着这件产品在本阶段工作的结束。
开发进程中的每一块里程碑都意味着需求的解决又前进了一步，这样的每一块里程碑也都是委托商付款的重要参照，产品开发的整个进程都可以通过需求管理进行监控。
里程碑构造机制的基本方法之一就是进程管理，一项需求的满足就意味着一块里程碑的确立。我们应当对用户需求、针对需求而进行的模块设计以及每个子模块的开发进程之间的关联做到心中有数。
通过我们对需求管理实际应用的分析，几个关键因素凸现出来。首先，需求管理在开发周期中是自始至终存在的。注意：不要把它简单理解为"需求周期"，需求管理必须始终保持更新，它构成了技术管理的基础。
其次，需求管理同项目管理是密不可分的。如果我们把每一个需求的解决看作一个里程碑，并以此出发对整个开发进程进行监控，我们就应该对整体开发工作进行精密细致的划分，从而将需求分析具体化。
☆需求管理的概念化阐释
需求管理应当具有以下几个特征：能够在开发周期的初期就建立需求模型；建模的成本很低；易于以后的具体化和优化；本身能体现最终解决方案的特征。也许某些细节是抽象的，但需求管理模型本身必须是完整的。需求模型不应当具有诱导性或倾向性，必须为开发工作留有充分发挥和优化的空间。同时，我们能够通过需求模型对最终产品作出评估。但不幸的是，这些特征本身也不是彼此完全兼容的，很难在一个简单模型中做到面面俱到。
在开发初期针对需求而搭建产品模型（Early Models）是容易的，成本也不会太高，但是这样的模型是很抽象的，绝非等同于最终产品。随后的产品原型（Prototypes）或高级模型 (Qualification Models) 将更接近于最终产品，但搭建这样的模型会要求更高的成本，同时可供修改的余地也更少。
需求管理的多种模式：
需求管理所要搭建的不同模式是由系统工程所采用的标准决定的。传统上需求管理有两种模式：客户模式和系统需求模式。从这两种模式出发的方案应该分别进行设计，不幸的是我们常常将此二者混为一谈。
用户模式着重描述用户面临的问题或希望得到的结果。用户模式的语言组织很象使用场景的实地描述，指明时间，侧重结果。无论谁搭建用户模式，都必须从用户的角度出发。
系统需求模式实际是抽象化的解决方案。系统需求模式的语言组织经常运用功能描述或使用详解性的说明文字，事实上功能描述和使用详解正是系统需求模式语言组织的典型风格。
实际上设计方案应当是第三种模式，即具体化的解决方案。很明显这种模式已经非常接近于最终解决方案。很多不同的设计方案都能解决用户需求，而在用户需求既定的同时对设计方案作出修改也是切实可行的。在硬件系统设计中，最终进行规模生产的产品体现的往往是第四种模式。
其他设计模式：
搭建多种系统设计模式需要付出相当的工作量，因为每种设计都做到条理清晰并不是件容易的事。如果设计构架和最终方案是一致的，那么工作量可能会减少一些。有些设计方案从产品角度出发，认为不同设计模式最好采用相同构架。但在实际应用当中，设计模式必须采用不同构架，这是因为：
●有些设计中同功能无关的需求，放在其他条件下则可能引起变化；
●出于重复利用现存模块的考虑；
●出于对机构效率的考虑；
●不同设计方案涉及的步骤要求，我们并不是都要实现；
以上每种因素都会导致设计方案同最初模式不尽相同。设计开发仅仅采用一种模式是很脆弱的。
我们必须记住，一套完整的系统开发要求有不同侧重点的多种设计模式与之配合，例如：框架配置模式侧重于大致的工作方向，而工作细化模式则标明了需要完成的各种具体工作。各种模式之间并不是孤立的，在实际需求和各种设计模式之间存在着多种关系。这些关系表现在：
●关联性：不同模式下开发的产品应当具有一致性（系统需求和用户需求）。
●应用性：非功能需求同功能需求之间的联系。
●评估测试：需求管理同评测系统之间的联系（以及产品）。
●设计开发：需求管理同设计模式或产品之间的联系，我们必须清楚每一部分工作同相应需求之间的对应关系。
何谓需求管理
以下段落将通过分析传统需求管理模式的特点，看看传统需求管理模式同"需求管理之需求"是如何发生关联的。
需求管理模型的特点：
顾名思义，需求管理是完整管理模式中的一环，同其他特性诸如一体性（completeness）、一致性（consistency）等不可分割，彼此相关而成一体。一套需求管理应当是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足（甚至是充分满足），仅仅解决部分需求是没有意义的。对关键需求的疏忽很可能是灾难性的，试想一架飞机的安全设计不过关将会带来什么样的后果。不同的需求组合起来，构成了一套完整的需求模型。用户需求决定了系统设计所要解决的问题，所要带来的结果。可以说，需求管理指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。
需求的特点：
需求的提出是进行切实可行的系统开发而存在的客观必然。需求性的描述可以是抽象的，也可以是具体的；它针对的可以是产品本身，也可以是产品开发的方式。
需求性的提出是建立在可验证的基础上的，就是说，我们能够根据需求而通过设定某种检验标准对最终产品进行评估，并给出或是或非的唯一回答。在测试中，我们永远不能说产品完全解决了需求，只能说它更加接近于满足需求。
存在的各种关联：
需求管理的一项重要工作就是在整个计划不同项目之间建立联系，这也许是在进行系统工程设计时自然而然得到的一种结果。如果我们对需求模式的阐释正确，并对需求与设计的统一性有了确证，那么我们就有了进行成功开发的坚实基础。在出色的系统设计中，系统各部分所存在的各种联系应当是清晰简明的。系统的相关性、可追溯性保证了从不同侧重点出发的系统设计能取得一致的结果。举例来说：
●系统需求满足于用户需求；
●设计方案满足于系统需求；
关联性是客观存在的，对它的描述常被用于展示：
●非功能性需求同功能性需求适用性之间的关系；
●方案设计同需求性的满足关系；
●开发框架内部的关系（例如目标管理、进度安排、任务细分等）；
●开发过程中各类信息的存档与交换；
●对每一需求的验证；
●对于核心需求的合理阐释。
需求管理的工具：
需求管理所用到的工具必须能够处理和应用于本文所提到的各种需求，应当有助于我们分析需求，确定相应开发和支持工具以处理相关信息，进而处理系统相应模块。系统工程师始终致力于用简单的工具将需求形象化的展现出来，常用的工具比如附有标注说明的系统发布工具以及相关数据库等。
需求管理涉及到一系列复杂的对象，其任务面向很广，关系到整个设计开发的方方面面。其使用的工具应当提供如图列举的一些功能：
☆总结：需求管理
本文论述围绕于需求管理工程。需求管理是开发工作有效进行的确证。很明显需求管理是一种很高层次的系统行为，涉及整个开发过程和产品本身。
需求管理首先要针对需求做出分析，随后应用于产品并提出方案。需求分析的模型正是产品的原型样本，优秀的需求管理提高了这样的可能性：它使最终产品更接近于解决需求，提高了用户对产品的满意度，从而使产品成为真正优质合格的产品。从这层意义上说，需求管理是产品质量的基础。
文章来源于领测软件测试网 https://www.ltesting.net/
