需求管理如何做好需求控制

需求管理的任务

可以说需求是一种模型，是产品的早期雏形，通过进行需求分析，我们可以对最终产品做出优化。

需要始终保持注意的是，需求性是始终处于变化之中的。

需求管理需要完成的任务包括： ●明确需求并达成共识； ●建立关联； ●根据不同需求设计相应解决办法； ●进行系统优化； ●提出设计方案； ●监控和解决可能出现的问题以及需要做出的改变； ●控制不同开发任务的开展； ●对最终产品做出评测； ●监控可能出现的重复开发； ●提出项目实施时间表； ●确定最终用户界面。

有时候我们所进行的需求分析只停留于分析本身，而没有进一步去思索我们为什么要进行需求分析。

需求性是项目开发的源头，只有进行认真的需求分析，我们才能做到对症下药、量体裁衣，才能才设计开发中去伪存真，不断改进。

需求之需求正是强调了贯穿始终的需求分析的重要。

离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。

需求管理所产生的效益或许并不明显，或许要日后才能体现，但是无序的，没有经过精心策划的需求管理是不可能产生效益的。

以下篇幅分别介绍需求管理在系统工程中的不同应用。

首先，用户需求通过非术语的形式进行表述，这种表述应当使每一位开发者明确自己的职责所在，并且清楚知道不同开发工作之间的关联。

这里的用户泛指在实际应用环境中每一位可能使用最终产品的人。

如果一个产品不能满足客户所需，那么设计方案再出色也无济于事，许多方案有很高的技术设计水准却最终不能获得成功，其原因正在于此。

可以把产品功能说得天花乱坠，但却无法改变用户需求决定最终产品基本模式的事实。

需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识。

因此用来进行需求分析的语言组织应当使所有相关人员，包括用户，都能够理解，都能够进而对整个项目有一个整体把握，并明确每一个人在项目中所起的作用。

因而需求管理需要解决的第一位也是最基本的任务就是明确需求，并使所有相关人员达成共识。

根据需求设计解决办法 我们在进行系统设计时，应当首先建立一个需求模型，但不能是为了建模而建模，需求模型实际是最终产品的抽象化表现。

需求模型的建立使我们在明确需求的基础上更进一步，使我们知道我们将要生产何种产品，该产品都具有那些功能。

同时，创建需求模型的过程也使开发者明确自己的工作如何同整个项目有机地结合在一起。

建立需求模型应当充分研究不同类型、不同架构建模方式的可行性，切忌主观武断。

任何设计都应以考虑用户需求为优先，用户需求的满足程度即成为衡量设计优劣的标准。

在一个项目设计周期中，开发人员经常会面临选择，以提炼需求，决定开发的优先次序，并在不同的实施方案中作出选择。

这些选择必须考虑到收益与付出地平衡比例，这种选择的重要性尤其在建立需求模型的后期凸现出来。

基本需求在这时都已明确，而实施方案还未敲定，为了使用户的基本需求得到落实，一定程度的开销用于搭建不同构架的需求模式是合理的。

假使我们已经有了一套翔实的需求分析，我们甚至不必将每一套方案都付诸实行，就可以成功地对系统设计进行优化。

面对不同的可行性而需要作出选择时，我们也必须参照收益与付出的比例关系。

例如，在被要求提供计划书时（Request for Proposal），我们应当尽量做到每一份计划书的提供都物有所值。

一个大的开发项目可能涉及20-30组不同的开发队伍，人员包括技术工程师、软件工程师以及具体项目主管等等，而每一个模块都有它自己的开发工具和开发语言。

主持一个大项目的开发并不是件容易的事，总体项目主管的首要任务是对开发项目进行任务划分，将整体开发任务细化为多个子模块，从而使这些子模块能够平行开发而无需太多的干预。

总体项目主管可以将细化的不同模块的需求分析交给不同的开发队伍，对于开发进程的监控只需参照需求的解决情况，对于具体的开发细节则不必过问太多。

不同的开发队伍会使用不同的开发语言和开发工具，会使用不同的符号和标记。

相反，作为总体项目主管所使用的语言、符号和标记等则必须简单易懂，以使所有的开发人员都等理解。

换言之，总体项目主管应当使用自然语言，或只涉及少量的，简单的术语和专用词汇。

需求的满足情况是决定最终产品成败的判定基础，对最终产品的测试评估必须以产品所试图解决的需求为标准。

下图标示了不同的开发阶段所对应的测试需求。

这里有一个需求、产品和测试系统之间的关系问题，确定需要进行的测试属于总体开发主管的工作范畴，虽然具体工作并非都要由开发主管来亲自完成。

对于总体开发主管而言，针对方案设计的修改是一项经常性的工作（因为修改而造成的影响则应当尽可能减小）。

在进行项目开发时，随着开发进程的深入，各种修改的建议和问题的报告是屡见不鲜的，每解决一个问题，就是将产品同其需求性的结合又完善了一步。

存在问题正是需求性尚未满足的表现。

方案设计的完善和需求性的满足是同步的，因此真正的用户对于产品的评价和建议尤其具有重要意义。

在那些一步到位的产品设计中，真正用户无法左右开发进程；但在一个能够进行重复设计、重复开发的产品生命期中，开发人员应当及时搜集用户对于产品的反馈信息，并将这些信息结合到下一步的开发工作中去。

如下图所示，用户反馈同产品开发是统一的。

在有些地方，需求管理被作为一个技术问题来处理，需求管理所针对的对象只是产品，而同项目管理所涉及的问题例如进程安排或资源分配等无关。

实际上，项目管理涉及三方面问题：进程安排、资源分配和质量管理（同需求的统一）。

试想以下三种情况： ●一场高水准的音乐会，预算合理，演出时间却晚了两天。

●质量优良的小轿车，交货及时，然而造价是市价的两倍。

●一套系统，完全满足了用户需求，但在开发过程中使用非法劳工。

这三种情况虽然都满足了用户所需，然而缺乏实际意义，因此都以失败告终。

我付了钱，但这不是我想要的，没有用户愿意这么说。

要避免出现这种情况，在进行项目管理和财务预算时，也必须以需求管理为基础。

仅仅完成了一件设计并不意味着工作的结束，只有这件设计充分解决了需求，它才具有里程碑般的意义。

同样的，一件产品只有在测试和实际操作中完全满足了需求，已经完全准备好了投入到下一阶段的运营，才意味着这件产品在本阶段工作的结束。

开发进程中的每一块里程碑都意味着需求的解决又前进了一步，这样的每一块里程碑也都是委托商付款的重要参照，产品开发的整个进程都可以通过需求管理进行监控。

里程碑构造机制的基本方法之一就是进程管理，一项需求的满足就意味着一块里程碑的确立。

我们应当对用户需求、针对需求而进行的模块设计以及每个子模块的开发进程之间的关联做到心中有数。

通过我们对需求管理实际应用的分析，几个关键因素凸现出来。

首先，需求管理在开发周期中是自始至终存在的。

注意：不要把它简单理解为需求周期，需求管理必须始终保持更新，它构成了技术管理的基础。

其次，需求管理同项目管理是密不可分的。

如果我们把每一个需求的解决看作一个里程碑，并以此出发对整个开发进程进行监控，我们就应该对整体开发工作进行精密细致的划分，从而将需求分析具体化。

为什么需要进行需求管理

需求管理的意义在于，通过需求管理可以准确进行经营运营，避免无效运营。

需求管理应当是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足（甚至是充分满足），仅仅解决部分需求是没有意义的。

对关键需求的疏忽很可能是灾难性的，试想一架飞机的安全设计不过关将会带来什么样的后果。

不同的需求组合起来，构成了一套完整的需求模型。

用户需求决定了系统设计所要解决的问题，所要带来的结果。

可以说，需求管理指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。

需求管理的过程，从需求获取开始贯于整个项目生命周期，力图实现最终产品同需求的最佳结合。

如何运用需求管理来治理通货膨胀

主要手段就是压缩总需求，这主要针对的是需求拉上型通胀。

①如果此时已严重通胀，一般采用紧缩性财政政策+紧缩性货币政策，提高利率，降低总需求水平，此时辅以紧缩性财政政策，防止利率过分提高。

②如果此时通胀不太严重，一般采用紧缩性财政政策+扩张性货币政策，用扩张性货币政策降低利率。

如何做好需求控制

当开发人员做了一个已经被取消的功能，你能想想他有多沮丧；当测试人员按照老的测试案例去测试新的需求规格的开发结果时，他可能要抓狂。

出现了这些情况，都是因为需求的版本控制出现了问题。

说到需求的版本管理，是不是就是需求文档放到配置库就可以了呢？答案是——不仅仅如此。

因为需求有它的特殊性，有它分析和管理的特殊要求，所以在实际的工作中的需求版本我们考虑更多层次： 对整个文档进行版本的管理是最基础的。

当谈及最新版本时，项目团队的成员“应该”都知道它指的是哪个版本的文档，比如说2.1版。

应该上面加引号是有用意的，因为实际的情况是每个人往往都是指向自己的机器上的文档版本，以为是最新版本。

需求条目的版本是什么意思呢？需求条目的版本表示了对每个需求对象进行更细粒度的控制。

需求文档里面有若干条需求组成，两个需求我嫩大版本之间可能是几个需求项发生了变化，有时候我们需要更清楚的知道某条关键的需求，何人何时创建，何人何时做出何种修改，并且能够知道修改的开始和结束的状态，并且显示出其中的差异，最好能可以自动的回退到某个历史状态。

这些工作中的需求，实际上都体现了对需求条目层次上版本管理的要求。

今天，越来越多的公司采用迭代或增量开发模式。

为了降低风险，将开发过程分为多个增量部分可以加快整个开发过程。

那每个阶段结束后，是不是要将整个项目的文档做一个快照呢？通常是需要的，那此时的项目基线也就是我们这里说的需求体系的版本。

需求体系的版本包含自需求而来的多个相关文档，此时的版本管理不仅应将这些文档打上统一的基线，并且将该组文档之间的追踪关系也进行基线化的管理。

对文档之间的追踪关系也进行基线化的管理意味着什么呢？项目的每一个阶段，需求文档会有不同，那需求文档之间追踪关系也会有不同。

那当我们记录下项目每个阶段的需求文档及其追踪关系的版本后，在日后的工作中，我们可以回溯到以前的某个需求版本，并能够按照当时的项目追踪关系，追踪分析当时的分析设计结果，实现对整个需求体系的掌握，能够更好的理解，利用以至复用已完成的工作成果。