需求管理

需求管理假定生产要素的供给为既定的条件下对总需求的调整和控制。

根据凯恩斯经济学的国民收入均衡分析，由于社会总就业量取决于总需求和总供给的均势，如果在短期内生产技术、资本设备的数量和质量、劳动力的数量和技能等不变，即假定总供给不变，则经济调节的重点就应在总需求一边。

按照凯恩斯主义经济学的说法，在通常的情况下，经济中的有效需求是不足的。

所以，充分就业状态下的国民收入均衡不可能自行实现，而只有通过对总需求，即对有效需求的管理，才能实现充分就业均衡。

简介需求管理（Requirement management）是完整管理模式中的一环，同其他特性诸如完整性、一致性等不可分割，彼此相关而成一体。

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

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

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

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

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

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

通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。

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

需求管理恰如裁缝的量体裁衣，它直接关系到最终产品的成型。

仅从字面出发，如果一个产品满足了客户需求，那它无疑就是成功的。

需求管理的过程，从需求分析开始贯穿整个项目始终，力图实现最终产品同需求性的最佳结合（参见Figure 1）。

通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。

需求管理能够确证：●我们确知客户的需求是什么（质量）；●满足客户需求的最佳解决办法（统一性）；著名学者Crosby对于质量的定义是"同需求保持统一"。

从这个意义上说，需求管理正是从质量出发以确定需求。

每个人都应当始终明白他们所做的具体任务其意义何在。

然而，在一个产品的生命周期里，其需求性是能动的，是处于变化之中的。

对于系统工程没有严格统一的定义，因此很难找到足够的数据以说明系统工程所起的作用。

有些致力于研究需求分析的组织认为，一项开发计划应当至少将8-15%的资源投入到系统工程方面。

如果低于这一标准，将很可能导致无法对客户群做出准确把握。

如果该项开发计划含有许多创新或实验的成分，那么这一百分比还应当适度提高。

概述定义需求（Define Requirement）在项目进展过程中，如何区分用户需求与需求分析中需求定义呢？当完成用户需求调查后，首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需。

例如采用Rational 的Rose工具进行需求的建模分析。

如果使用工具进行建模分析，对需求分析人员的要求比较高。

当完成需求的定义及分析后，需要将此过程书面化，要遵循既定的规范将需求形成书面的文档，我们通常称之为《需求分析说明书》。

邀请同行专家和用户（包括客户和最终用户）一起评审《需求规格说明书》，尽最大努力使《需求规格说明书》能够正确无误地反映用户的真实意愿。

需求评审之后，开发方和客户方的责任人对《需求规格说明书》作书面承诺。

具体的同行评审详见需求评审章节。

需求确认(Requirement Validate) 需求确认是需求管理过程中的一种常用手段，也是需求控制的五一节之一；确认有两个层面的意思，第一是进行系统需求调查与分析的人员与客户间的一种沟通，通过沟通从而对需求不一致的进行剔除；另外一个层面的意思是指，对于双方达成共同理解或获得用户认可的部分，双方需要进行承诺。

建立需求状态(Establish Requirement State) 何谓需求状态；顾名思义，状态也就是一种事物或实体在某一个时刻或点所处的情况，此处要讲的需求状态是指用户需求的一种状态变换过程。

为什么要建立需求状态？在整个生命周期中，存在着几种不同的情况，在需求调查人员或系统分析人员进行需求调查时，客户存在的需求可能有多种，一类是客户可以明确且清楚的提出的需求；一类是客户知道需要做些什么，但又不能确定的需求；另一类是客户本身可以得出这类需求，但需求的业务不明确，还需要等待外部信息。

还有是客户本身也说不清楚的。

对于这些需求，在开发进展的过程中，存在著以下几种情况:有可能要取消的有的因为不明确而可以后延的，同时可能转化为被取消的需求与客户经过沟通或确认的，此处有两种情况，一类是确认双方达成共识，另一种情况是还需要再进一步沟通的。

下面是一个简单的状态例子：CLOSED：经过确认，双方认可并达成共识；OPEN:双方确认，但没有达成共识的需求；待定：客户提出需求，但双方没有经过沟通或确认；需求评审(Requirement Review) 对工作产品的评审有两类方式，一类是正式技术评审，也称同行评审，另一类是非正式技术评审。

对于任何重要的工作产品，都应该至少执行一次正式技术评审。

在进行正式评审前，需要有人员对其要进行评审的工作产品进行把关，确认其是否具备进入评审的初步条件。

需求评审的规程与其它重要工作产品（如系统设计文档、源代码）的评审规程非常相似，主要区别在于评审人员的组成不同。

前者由开发方和客户方的代表共同组成，而后者通常来源于开发方内部。

有人问：需求评审究竟评审什么？要细到什么程度？怎么样进行？严格地讲，应当检查需求文档中的每一个需求，每一行文字，每一张图表。

评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。

如果有可能，最好可以制定评审的检查表。

需求评审面临的困难及对策如下：需求评审的一个通病是“虎头蛇尾”。

需求评审的确乏味，也比较费脑子。

刚开始评审时，大家都比较认真，越到后头越马虎。

当需求文档很长时，几乎没人能够坚持到最后。

会议主持人事先要强调需求评审的重要性：认真评审一小时可能会避免将来数十天的“返工”，让大家足够重视。

评审组长还要设法避免大家在昏昏沉沉中评审。

如果评审时间比较长，建议每隔两小时休息一次。

另外，如果系统比较大，也可以细分成不同的部分分别进行，严格控制每一次评审的文档规模及持续时间。

需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。

没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。

这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。

对于需求的工作产品《需求规格说明书》，我们可以标明几种文档状态，如草稿状态，评审状态，初始状态等。

只有进入评审状态时，我们可以用不同的方式来对文档进行评审。

但当其评审状态转化为初始状态时，需要进行严格的正式的同行评审。

开评审会议时经常会“跑题”，导致评审效率很低。

有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。

主持人应当控制话题，避免大家讨论与主题无关的东西。

对于自主研发的产品，由于需求评审人员大部分是开发人员，大家会不知不觉地谈论软件“如何做”。

由于需求是否“可实现、可验证、可测试”本来就属于需求评审的范畴，所以强制大家“只谈做什么，不谈怎么做”几乎是不可能的。

那么，在需求的评审会上，需要允许开发人员谈如何做，但不需太细，适而可止。

同时，评审会必须明确一位评审组长，对时间与问题进行控制。

开评审会议时经常会发生争议。

适当的争议有利于澄清问题，比什么东西都一致赞成要好。

然而当争议变为争吵时就坏事了。

争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。

同时也解决不了问题。

所以，在评审会的过程中，我们要尽可能的是在阐述事实与证据，而并不是从你心底要如何地说服别人。

人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。

毫不妥协或者轻易妥协都不是好办法。

我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。

试著从不同的角度去看同样的问题。

需求承诺（Requirement Consent）什么是需求承诺，是指开发方和客户方的责任人对通过了同行评审的需求阶段的工作产品，作出承诺，同时该承诺具有商业合同的同等效果。

需求承诺如下：很多人有这样的误解：如果依照“需求开发－系统设计－编码－测试”这样的顺序开发产品，由于每一步的输出就是下一步的输入，所以不必担心设计、编程、测试会与需求不一致，因此可以省略需求跟踪。

那么，需要指正的是，按照软件生命周期严格线性顺序的开发模型并不能保证各个开发阶段的工作产品与需求保持一致。

因为开发者是人而不是机器。

而且，大多数开发人员也都深有体会。

生活中“以讹传讹”的例子，想必大家都很熟悉。

学生甲在精工实习时被机器弄破了手指，于是到医院包扎。

同学乙路过医院时看到甲的手血迹斑斑，以为甲的手指被机器割断，于是将这个坏消息告诉同学丙。

丙急忙转告同学丁，说甲的手被机器割断，正躺在医院里。

丁十万火急地告诉全班同学，大家陷入悲痛之中，都以为“甲的胳膊被机器割断了，正躺在医院里，人快不行需求管理相关图片了。

”由于人们的表达能力、理解能力不可能完全相同，人与人之间的协作很难达到天衣无缝的境界。

而使用需求追溯的本身也是一种传递的过程。

需求追溯本身并不是一件复杂的事，而是我们的本身一种理念在支配著我们。

也许就有人认为这本身就是在浪费时间，主要麻烦是，当需求或工作产品发生变更时，开发人员要及时更新需求跟踪矩阵。

然而没想到的事，如果后来再花时间来做同样的事的时候，将会付出更多。

也时也就丢去了本身做这件事的意义。

需求变更控制(Requirement Change Control) 需求变更通常会对项目的进度、人力资源产生很大的影响，这是开发商非常畏惧的问题。

也是必须面临与需要处理的问题。

作为软件项目，特别在外地实施的工程软件项目而言，需求发生若干次变更似乎是不可避免的。

需求发生变更的起因主要有：随著项目生命周期的不断往前推进，人们（包括开发方和客户方）对需求的了解越来越深入。

原先的提出的需求可能存在著一定的缺陷，因此要变更需求。

市场业务需求发生了变化，原先的需求可能跟不上当前的市场业务发展，因此要变更需求。

由于市场变化而导致需求发生变更，开发商大可不必为此烦恼，应当高兴才对。

倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。

正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。