需求管理

 

      需求管理（Requirement management）是完整管理模式中的一环，同其他特性诸如完整性、一致性等不可分割，彼此相关而成一体。一套需求管理应当是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足（甚至是充分满足），仅仅解决部分需求是没有意义的。对关键需求的疏忽很可能是灾难性的，试想一架飞机的安全设计不过关将会带来什么样的后果。不同的需求组合起来，构成了一套完整的需求模型。用户需求决定了系统设计所要解决的问题，所要带来的结果。可以说，需求管理指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。

      需求管理的过程，从需求获取开始贯于整个项目生命周期，力图实现最终产品同需求的最佳结合。通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。

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

      需求管理恰如裁缝的量体裁衣，它直接关系到最终产品的成型。仅从字面出发，如果一个产品满足了客户需求，那它无疑就是成功的。需求管理的过程，从需求分析开始贯穿整个项目始终，力图实现最终产品同需求性的最佳结合（参见Figure 1）。通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。

      需求管理能够确证：

      ●我们确知客户的需求是什么（质量）；
      ●满足客户需求的最佳解决办法（统一性）；

 

      著名学者Crosby对于质量的定义是"同需求保持统一"。从这个意义上说，需求管理正是从质量出发以确定需求。每个人都应当始终明白他们所做的具体任务其意义何在。然而，在一个产品的生命周期里，其需求性是能动的，是处于变化之中的。

      对于系统工程没有严格统一的定义，因此很难找到足够的数据以说明系统工程所起的作用。有些致力于研究需求分析的组织认为，一项开发计划应当至少将8-15%的资源投入到系统工程方面。如果低于这一标准，将很可能导致无法对客户群做出准确把握。如果该项开发计划含有许多创新或实验的成分，那么这一百分比还应当适度提高。

一、概述

定义需求（Define Requirement）

      在项目进展过程中，如何区分用户需求与需求分析中需求定义呢？

      当完成用户需求调查后，首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需。例如采用Rational 的Rose工具进行需求的建模分析。如果使用工具进行建模分析，对需求分析人员的要求比较高。

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

      邀请同行专家和用户（包括客户和最终用户）一起评审《需求规格说明书》，尽最大努力使《需求规格说明书》能够正确无误地反映用户的真实意愿。需求评审之后，开发方和客户方的责任人对《需求规格说明书》作书面承诺。具体的同行评审详见需求评审章节。

需求确认(Requirement Validate)

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

建立需求状态(Establish Requirement State)

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

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

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

      下面是一个简单的状态例子：
      CLOSED：经过确认，双方认可并达成共识；
      OPEN:双方确认，但没有达成共识的需求；
      待定：客户提出需求，但双方没有经过沟通或确认；

需求评审(Requirement Review)

      对工作产品的评审有两类方式，一类是正式技术评审，也称同行评审，另一类是非正式技术评审。对于任何重要的工作产品，都应该至少执行一次正式技术评审。在进行正式评审前，需要有人员对其要进行评审的工作产品进行把关，确认其是否具备进入评审的初步条件。

      需求评审的规程与其它重要工作产品（如系统设计文档、源代码）的评审规程非常相似，主要区别在于评审人员的组成不同。前者由开发方和客户方的代表共同组成，而后者通常来源于开发方内部。

      有人问：需求评审究竟评审什么？要细到什么程度？怎么样进行？

      严格地讲，应当检查需求文档中的每一个需求，每一行文字，每一张图表。评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。如果有可能，最好可以制定评审的检查表。

      需求评审面临的困难及对策如下：

      需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。当需求文档很长时，几乎没人能够坚持到最后。会议主持人事先要强调需求评审的重要性：认真评审一小时可能会避免将来数十天的“返工”，让大家足够重视。评审组长还要设法避免大家在昏昏沉沉中评审。如果评审时间比较长，建议每隔两小时休息一次。另外，如果系统比较大，也可以细分成不同的部分分别进行，严格控制每一次评审的文档规模及持续时间。

      需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。对于需求的工作产品《需求规格说明书》，我们可以标明几种文档状态，如草稿状态。评审状态，初始状态等。只有进入评审状态时，我们可以用不同的方式来对文档进行评审。但当其评审状态转化为初始状态时，需要进行严格的正式的同行评审。

      开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。对于自主研发的产品，由于需求评审人员大部分是开发人员，大家会不知不觉地谈论软件“如何做”。由于需求是否“可实现、可验证、可测试”本来就属于需求评审的范畴，所以强制大家“只谈做什么，不谈怎么做”几乎是不可能的。那么，在需求的评审会上，需要允许开发人员谈如何做，但不需太细，适而可止。同时，评审会必须明确一位评审组长，对时间与问题进行控制。

      开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了。争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。同时也解决不了问题。所以，在评审会的过程中，我们要尽可能的是在阐述事实与证据，而并不是从你心底要如何地说服别人。

      人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。试著从不同的角度去看同样的问题。

{项目名称}评审报告_需求 基本信息 工作产品.版本号 名称，标识符，版本，作者，时间 工作产品标识号 　 评审方式 第几次评审 　 工作产品存放路径 　 评审地点 评审时间 　 参与人员 　 评审人员名字 工作单位或部门 职务职称 签字 　 　 　 　 　 　 问题记录及处理意见 问题编号 位置 问题描述 问题类型 严重程度 Problem A 　 　 　 　 Problem B 　 　 　 　 评审结论 评审结论 [ ] 工作产品合格，“无需修改”或者“需要轻微修改但不必再审核”。 [√] 工作产品基本合格，需要作少量的修改，之后通评审组长检查即可。 [ ] 工作产品不合格，需要作比较大的修改，之后必须重新对其评审。 签字

　
 

需求承诺（Requirement Consent）

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

需求承诺 XXX项目需求文档_《XXX需求说明书》，版本号：X.X.X,是建立在XXX与XXX双方共同对需求理解的基础之上，同意后续的开发工作根据该工作产品开展。如果需求发生变化，双方将共同遵循项目定义的“变更控制规程”执行。需求的变更将导致双方重新协商成本、资源和进度等。 甲方签字 乙方签字

      不少人会草率地对待需求承诺：不就是在一张纸的最后一行文字下面签字吗，反正已经评审过了，我就签吧。但他将来变更需求时可能会表示不瞒：“不错，我是签字了，但是我并没有阅读文档。是你们要我在文档上签字的，我是相信你们才这么做的。”为了避免发生此类纠纷，人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么。

需求跟踪(Requirement Track)

      为什么要进行需求跟踪？在整个开发过程中，进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性。确保所有的实现是以用户需求为基础。对于需求实现是否全部的覆盖。同时确保所有的输出与用户需求的符合性。

      需求跟踪有两种方式，正向跟踪与逆向跟踪：

      正向跟踪：以用户需求为切入点，检查《用户需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。
      逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护《需求跟踪矩阵》。需求跟踪矩阵保存了需求与后续开发过程输出的对应关系。矩阵单元之间可能存在“一对一”、“一对多”或“多对多”的关系。见下表：简单的需求跟踪矩阵示例。

需求代号	需求规格说明书V1.0	设计文档V1.2	代码1.0	测试用例	测试记录
R001	标题或标识符	标题或标识符	代码文件名称		测试用例标识或名称
R002	…	…	…		…
…	…	…	…		…

简单的需求跟踪矩阵示例1

      使用需求跟踪矩阵的优点是很容易发现需求与后续工作产品之间的不一致，有助于开发人员及时纠正偏差，避免干冤枉活。

      很多人有这样的误解：如果依照“需求开发－系统设计－编码－测试”这样的顺序开发产品，由于每一步的输出就是下一步的输入，所以不必担心设计、编程、测试会与需求不一致，因此可以省略需求跟踪。那么，需要指正的是，按照软件生命周期严格线性顺序的开发模型并不能保证各个开发阶段的工作产品与需求保持一致。因为开发者是人而不是机器。而且，大多数开发人员也都深有体会。

      生活中“以讹传讹”的例子，想必大家都很熟悉。学生甲在精工实习时被机器弄破了手指，于是到医院包扎。同学乙路过医院时看到甲的手血迹斑斑，以为甲的手指被机器割断，于是将这个坏消息告诉同学丙。丙急忙转告同学丁，说甲的手被机器割断，正躺在医院里。丁十万火急地告诉全班同学，大家陷入悲痛之中，都以为“甲的胳膊被机器割断了，正躺在医院里，人快不行了。”

      由于人们的表达能力、理解能力不可能完全相同，人与人之间的协作很难达到天衣无缝的境界。而使用需求追溯的本身也是一种传递的过程。

      需求追溯本身并不是一件复杂的事，而是我们的本身一种理念在支配著我们。也许就有人认为这本身就是在浪费时间，主要麻烦是，当需求或工作产品发生变更时，开发人员要及时更新需求跟踪矩阵。然而没想到的事，如果后来再花时间来做同样的事的时候，将会付出更多。也时也就丢去了本身做这件事的意义。

需求变更控制(Requirement Change Control)

      需求变更通常会对项目的进度、人力资源产生很大的影响，这是开发商非常畏惧的问题。也是必须面临与需要处理的问题。作为软件项目，特别在外地实施的工程软件项目而言，需求发生若干次变更似乎是不可避免的。需求发生变更的起因主要有：

      随著项目生命周期的不断往前推进，人们（包括开发方和客户方）对需求的了解越来越深入。原先的提出的需求可能存在著一定的缺陷，因此要变更需求。
      市场业务需求发生了变化，原先的需求可能跟不上当前的市场业务发展，因此要变更需求。由于市场变化而导致需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。
      如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的，双方应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的错误。

      总的而言，人们提出需求变更，本就是出于能够是产品更加符合市场或客户需求，出发点本身是好的。但对于开发小组而言，需求的变更则意味着要需要重新进行估计，调整资源、重新分配任务、修改前期工作产品等，而作为开发商，需要增预算与投资，开发组要为此付出较重的代价。假定每次需求变更请求都被接受的话，那么这个项目将会成为一个连环式的工程。

      需求变更控制的动机是：

      如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。
      如果需求变更带来的坏处大于好处，那么拒绝变更。
      当然，好处与坏处并不是主观的，而是通过客观的分析与评价而得出的。
      对于需求的变更，在某一个程度上来说，也就是项目的范围进行了变化。而需求同时又是项目进行的基础。是非常得要的基石。通常对于需求的变更需要客户与开发方共同参与，包括负责人及市场人员。当然，我们需要根据变更的内容来灵活运用。
      需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。客户会想当然地以为变更需求是他的权利，因为他付钱给开发方。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。怎么解决这个问题呢，通常情况下，每一类“游戏”都有一定的游戏规则，那么我们事先也需要建立“游戏规则”。
      如果事先没有“游戏规则”的话，开发方的负责人需要一些社交技巧来减缓矛盾。例如首先承认客户提出的需求变更请求是合理的，再阐述己方的难处，最后建议在开发该产品新版本时修改需求。这种方式比直接拒绝有效得多，既不得罪客户，又为自己争取了余地。
      另外还有一种方法，可以将变更需求先进行记录，并通知给客户，当其需求变化在开发组不能接受的范围时，可以通过市场进行相关的协调。
      需求变更本是正常的，并不可怕，可怕的是需求的变更得不到控制。

二、为什么需要管理需求？

      简单地说,系统开发团队之所以管理需求,是因为他们想让项目获得成功.满足项目需求即为成功打下了基础.若无法管理需求,达到目标的几率就会降低. 以下最近收集的证据很有说服力: Standish Group 从 1994 年到 2001 年的 CHAOS Reports 证实,导致项目失败的最重要的原因与需求有关. 2001年,Standish Group 的CHAOS Reports报导了该公司的一项研究,该公司对多个项目作调查后发现,百分之七十四的项目是失败的,既这些项目不能按时按预算完成.其中提到最多的导致项目失败的原因就是"变更用户需求".

三、为什么要管理需求？

      避免失败就是一个很充分的理由.提高项目的成功率和需求管理所带来的其他好处同样也是理由.Standish Group 的 CHAOS 报告进一步证实了与成功项目关系最大的因素是良好的需求管理.

      什么是需求？

      理解需求管理的第一步就是对什么是需求管理达成共识.Rational 把需求定义为"(正在构建的)系统必须符合的条件或具备的功能".电气和电子工程师学会使用的定义与此类似. 著名的需求工程设计师 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义,它特指软件方面 - 但不仅仅限于软件:

      "软件需求可定义为: 用户解决某一问题或达到某一目标所需的软件功能. 系统或系统构件为了满足合同,规约,标准或其他正式实行的文档而必须满足或具备的软件功能."

      什么是需求管理

      由于需求是正在构建的系统必须符合的事务,而且符合某些需求决定了项目的成功或失败,因此找出需求是什么,将它们记下来,进行组织,并在发生变化时对它们进行追踪,这些活动都是有意义的. 换句话说,需求管理就是：一种获取,组织并记录系统需求的系统化方案,以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程.

      这个定义与 Dorfman 与 Thayer 以及 IEEE 的"软件需求工程"的定义相似.需求工程包括获取,分析,规定,验证和管理软件需求,而"软件需求管理"则是对所有相关活动的规划和控制.这里介绍的以及 IBM Rational提出的需求管理定义包括了所有这些活动.它们的区别主要在于这里选用了"管理"这个词,而不是"工程".管理这个词更合适用来描述所有涉及到的活动,并且它准确地强调了追踪变更以保持涉众与项目团队之间共识的重要性.

       对那些不熟悉"引出"这个词的人来说,它可定义为团队用来获取或发现涉众请求,确定请求后隐藏的真正需要,以及为满足这些需要对系统提出的一组适当需求.

      需求管理问题 一个目的在于确保系统符合人们对其期望的流程面临着哪些困难呢 当它真正在实际项目实施时,困难就暴露出来了.图 1 显示了年对开发人员,经理和质量保证人员所做的一次调查结果.该图显示了经历过最常提到的需求相关难题的受访者比例.

      下面列出了更多与需求有关的问题:

      需求不总是显而易见的,而且它可来自各个方面. 需求并不总是容易用文字明白无误地表达. 存在不同种类的需求,其详细程度各不相同. 如果不加以控制,需求的数量将难以管理. 需求相互之间以及与流程的其他可交付工件之间以多种方式相关联. 需求有唯一的特征或特征值.例如,它们既非同等重要,处理的难度也不同. 需求涉及众多相关利益责任方,这意味着需求要由跨职能的各组人员来管理. 需求发生变更. 需求可能对时间敏感. 当这些问题与需求管理和处理技能不足以及缺乏易用工具等情况一同出现时,许多团队都对管理好需求不抱希望了.IBM Rational 已经开发出指导团队提高需求管理技能和流程的专业技术,并使用相应的工具使得上述的流程和专业技术得以实现.

      需求捕获

      从上述的分析可以看出,需求的捕获是需求管理的基础和前提.在这里,将介绍一种为业界所广泛采用并经验证的需求捕获方法,即用例模型. 用例模型是系统既定功能及系统环境的模型,并作为客户和开发人员之间的契约.

      用例模型用作分析,设计和测试活动的基本输入.用例是贯穿整个系统开发的一条主线.同一个用例模型即为需求工作流程的结果,可当作分析设计工作流程以及测试工作流程的输入使用.参与者(Actor)和用例(UseCase)是用例模型中的主要元素. 下图显示了自动取款机系统用例模型的一部分:

客户

查询

提款

转帐

客户身份验证系统时钟

数据库服务器

(from )系统维护

信函打印机

打印对帐单

      用例图用于显示包含参与者和用例的用例模型示例.系统建模有许多种方法,每种建模方法可以满足不同的目的.然而,用例模型最重要的作用是将系统行为传达给客户或最终用户.可能与该系统交互的用户和任何其他系统都是参与者.由于参与者代表了系统用户,它们协助界定系统并提供十分明确的系统用途说明.编写用例依据参与者的需求来进行.这样就确保该系统成为用户期望得到的系统.

      参与者和用例都是通过将客户需求及潜在用户当作重要的信息查找到的.找到这些用例和参与者后,应对它们作简要说明.在详细说明这些用例之前,客户应复审该用例模型以核实所有的用例和参与者都已经找到,并且它们可以提供客户所需要的东西. 在迭代开发环境中,您可以选择用例的子集以便在每个迭代中详细描述.参与者和用例找到后,需要详细说明每个用例的事件流.这些说明指出系统与参与者交互的方式以及在各个独立用例中系统执行的有关操作.

      最后,对已完成的用例模型(包括用例说明)进行复审,开发人员和客户使用该模型对系统应执行的操作达成一致意见.

四、需求管理模型

      在需求管理的流程中,需求的捕获手段固然重要,但在需求的捕获和需求最终成型的过程中,我们会面临各种和需求相关的信息和资料(也可以把这些信息笼统地称做"需求"),如何发现这些信息之间的关系并有效组织,更为关键. 需求类型 在RUP中,我们采用一种金字塔方式的管理办法,来组织和管理我们获取的信息乃至最终的需求.

      为了建立一个真正满足客户需求的系统,项目团队首先必须确定系统要解决的问题.然后,团队必须确定涉众,从中获得业务和用户需要,对其进行描述,并区分它们的优先级.从这一组高层期望或需求出发,对产品或系统特性集达成一致意见.而后,由产品特性来抽取软件需求,在我们的模型中,软件需求是以用例模型的方式来描述.从测试的角度来看,测试项一定来自于软件需求,即软件需求中确定了哪些需求项,测试就要根据这些需求项来制定和实现.

      系统越大越复杂,出现的需求类型就越多.一个需求类型不过是指需求的一个类.通过确定需求类型,团队可以把大量需求组织成意义明确且更容易管理的组.在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类,并使相互之间的沟通更为清楚明确.从上述的分析中我们可以看到,通常,一类需求可以细分即分解成其他类型的需求.这里,我们就把需求分解为几种类型,并在他们之间建立相应的关联.业务规则和前景声明包括高层次的需求,团队可以从中导出用户需要,特性和产品需求类型.用例和其他建模形式驱动设计需求,该需求可分解为软件需求,并可以用分析设计模型来说明.测试需求源于软件需求,它被分解为具体的测试过程.如果既定项目中有成百上千个,甚至上万个需求实例时,对需求进行分类可以使项目更容易管理.上述的这些需求类型同时保存在对应的RUP文档和数据库中.

五、应用需求类型

      通过定义需求类型,以及他们之间的关系,我们就建立了一个需求管理模型的框架.当然,我们建立这样的一个模型,是为了方便我们使用需求,为了达到这一目的,我们还需要在此基础上添加相应的内容. 需要对各种需求类型添加它们的属性,以便于对需求进行查询等管理手段.比如,可以针对用户需要,确定该需要的必要性,优先级,确定性等属性.在实际的项目中,就可以确定这些属性的值,而后根据这些实际属性值来安排项目的进度表等.或是在项目进度紧急时,确定哪些需求是可以延期完成,而哪些是必须完成的,等等.

      需求的追踪性 其次,可以根据不同需求的导出情况,在不同的需求之间建立追踪关系.譬如,用户需要决定了要构建产品的特性,产品的特性又决定了产品的软件需求,等.在这些不同类型的需求之间建立关联,一旦其中的某些需求发生变化,就可以确定它可能带来的影响,从而制定相应的策略.

六、需求管理的工作流程

      工作流明细简介

      问题分析

      问题分析可以通过了解问题及涉众的最初需要,并提出高层解决方案来实现.它是为找出"隐藏在问题之后的问题"而进行的推理和分析.问题分析期间,将对"什么是面临实际问题"和"谁是涉众"等问题达成一致.而且,您还要从业务角度界定解决方案,以及制约该解决方案的因素.您应该已经对项目进行过商业理由分析,这将便于您更好地预计能从构建中的项目中得到多少投资回报.

      理解涉众需要

      需求来自各个方面,比如来自客户,合作伙伴,最终用户或是某领域的专家.您需要掌握如何准确判断需求应来源于哪方面,如何接近这些来源并从中获取信息.提供这些信息主要出处的个人在本项目中称为涉众.如果您正在开发一个在您公司内部使用的信息系统,那么在开发团队中应包括具有最终用户经验和业务领域专业知识的人员.通常讨论将在业务模型这一级上展开,而不是在系统这一级上展开.如果正在开发一个要在市场上出售的产品,那么您可以充分调动营销人员,以便更好地了解该市场中用户的需要. 获取需要的活动可使用这样一些技巧:访谈,集体讨论,概念原型设计,问卷调查和竞争性分析等.获取结果可能是一份图文并茂的请求或需要列表,并按相互之间的优先级列出.

      定义系统

      定义系统指的是解释涉众需求,并整理为对要构建系统的意义明确的说明.在系统定义的初期要确定以下内容:需求构成,文档格式,语言形式,需求的具体程度(需求量及详细程度),需求的优先级和预计工作量(不同人在不同的实践中通常对这两项内容的看法大不相同),技术和管理风险以及最初规模.系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型.系统定义的结果是用自然语言和图解方式表达的系统说明.

      管理项目规模

      为使项目高效运作,应仔细根据所有涉众的需求确定优先级,并对项目规模进行管理.有的开发人员仅仅重视所谓的"复活节彩蛋"(即开发人员感兴趣或觉得有挑战性的特性),而不是及早将精力投入降低项目风险或提高应用程序构架稳定性方面,这已使太多的项目蒙受损失.为确保尽早解决或降低项目中的风险,应以递增的方式开发系统.要慎重选择需求,以确保每次增加都能缓解项目中的已知风险.要达到目的,您需要和项目的涉众协商每次迭代的范围.通常,这要求具备管理项目各个阶段的期望结果的良好技能.

      除了控制开发过程本身,您还需控制需求的来源,并控制项目可交付工件的外观. 改进系统定义 系统的详细定义应能让涉众理解,同意并认可.它不仅需要具备所有功能,而且应符合法律或法规上的要求,符合可用性,可靠性,性能,可支持性和可维护性.感觉构建过程复杂的系统就应该有复杂的定义,这是一种常见的错误看法.这会给解释项目和系统的目的造成困难.人们可能印象深刻,但他们会因不甚理解而无法给出建议.应该致力于

      了解您制作的系统说明文档的读者.您可能常会发现需要为不同的读者准备不同的说明文档.

      我们认为用例方法是传达系统目的和定义系统细节的一种行之有效的方法,它常与简单的可视化原型结合使用.用例有助于为需求提供一个环境,利用它可生动地说明系统使用的方式.

      系统详细定义的另一个构件是说明系统采用的测试方式.测试计划及要执行测试的定义将会说明要核实哪些系统功能.

      管理需求变更

      定义需求时无论怎样谨慎小心,也总会有可变因素.变更的需求之所以变得难以管理,不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性,而且也因为对某个需求的变更很可能影响到其他需求.应确保赋予需求一个有弹性的结构,使它能适应变更,并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系.管理变更包括建立基线,确定需要追踪的重要依赖关系,建立相关项之间的可追踪性,以及变更控制等活动.

七、需求管理所要完成的任务

      可以说需求是一种模型，是产品的早期雏形，通过进行需求分析，我们可以对最终产品做出优化。需要始终保持注意的是，需求性是始终处于变化之中的。需求管理需要完成的任务包括：

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

      有时侯我们所进行的需求分析只停留于分析本身，而没有进一步去思索我们为什么要进行需求分析。需求性是项目开发的源头，只有进行认真的需求分析，我们才能做到对症下药、量体裁衣，才能才设计开发中去伪存真，不断改进。"需求之需求"正是强调了贯穿始终的需求分析的重要。离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。需求管理所产生的效益或许并不明显，或许要日后才能体现，但是无序的，没有经过精心策划的需求管理是不可能产生效益的。

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

      需求共识：

      首先，用户需求通过非术语的形式进行表述，这种表述应当使每一位开发者明确自己的职责所在，并且清楚知道不同开发工作之间的关联。这里的"用户"泛指在实际应用环境中每一位可能使用最终产品的人。如果一个产品不能满足客户所需，那么设计方案再出色也无济于事，许多方案有很高的技术设计水准却最终不能获得成功，其原因正在于此。可以把产品功能说得天花乱坠，但却无法改变用户需求决定最终产品基本模式的事实。

      需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识。因此用来进行需求分析的语言组织应当使所有相关人员，包括用户，都能够理解，都能够进而对整个项目有一个整体把握，并明确每一个人在项目中所起的作用。因而需求管理需要解决的第一位也是最基本的任务就是明确需求，并使所有相关人员达成共识。

      根据需求设计解决办法：

      我们在进行系统设计时，应当首先建立一个需求模型，但不能是为了建模而建模，需求模型实际是最终产品的抽象化表现。需求模型的建立使我们在明确需求的基础上更进一步，使我们知道我们将要生产何种产品，该产品都具有那些功能。同时，创建需求模型的过程也使开发者明确自己的工作如何同整个项目有机地结合在一起。建立需求模型应当充分研究不同类型、不同架构建模方式的可行性，切忌主观武断。

      系统优化：

      任何设计都应以考虑用户需求为优先，用户需求的满足程度即成为衡量设计优劣的标准。在一个项目设计周期中，开发人员经常会面临选择，以提炼需求，决定开发的优先次序，并在不同的实施方案中作出选择。这些选择必须考虑到收益与付出地平衡比例，这种选择的重要性尤其在建立需求模型的后期凸现出来。基本需求在这时都已明确，而实施方案还未敲定，为了使用户的基本需求得到落实，一定程度的开销用于搭建不同构架的需求模式是合理的。假使我们已经有了一套翔实的需求分析，我们甚至不必将每一套方案都付诸实行，就可以成功地对系统设计进行优化。

      面对不同的可行性而需要作出选择时，我们也必须参照收益与付出的比例关系。例如，在被要求提供计划书时（Request for Proposal），我们应当尽量做到每一份计划书的提供都物有所值。

      方案设计：

      明确需求后，开发人员就可以进行方案设计。通过对用户需求和设计方案之间所存在关联性进行分析比较，我们就能够对设计方案进行评估。

      必要的修改：

      方案的设计不可能是一成不变的，经常会有方案设计同需求相悖的情况。如果我们无法准确把握用户需求同方案设计之间的关系，我们就无法在需要对方案进行必要修改时正确判断。优秀的需求分析应当非常精确细致地对用户需求作出描述，同时也应该最大程度地给予方案设计者充分发挥的余地。

      任务划分：

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

      主持一个大项目的开发并不是件容易的事，总体项目主管的首要任务是对开发项目进行任务划分，将整体开发任务细化为多个子模块，从而使这些子模块能够平行开发而无需太多的干预。总体项目主管可以将细化的不同模块的需求分析交给不同的开发队伍，对于开发进程的监控只需参照需求的解决情况，对于具体的开发细节则不必过问太多。

      不同的开发队伍会使用不同的开发语言和开发工具，会使用不同的符号和标记。相反，作为总体项目主管所使用的语言、符号和标记等则必须简单易懂，以使所有的开发人员都等理解。换言之，总体项目主管应当使用自然语言，或只涉及少量的，简单的术语和专用词汇。

      产品测试：

      需求的满足情况是决定最终产品成败的判定基础，对最终产品的测试评估必须以产品所试图解决的需求为标准。下图标示了不同的开发阶段所对应的测试需求。

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

      重复开发：

      对于总体开发主管而言，针对方案设计的修改是一项经常性的工作（因为修改而造成的影响则应当尽可能减小）。在进行项目开发时，随着开发进程的深入，各种修改的建议和问题的报告是屡见不鲜的，每解决一个问题，就是将产品同其需求性的结合又完善了一步。存在问题正是需求性尚未满足的表现。

      方案设计的完善和需求性的满足是同步的，因此真正的用户对于产品的评价和建议尤其具有重要意义。在那些一步到位的产品设计中，真正用户无法左右开发进程；但在一个能够进行重复设计、重复开发的产品生命期中，开发人员应当及时搜集用户对于产品的反馈信息，并将这些信息结合到下一步的开发工作中去。如下图所示，用户反馈同产品开发是统一的。

      项目管理的辅助：

      在有些地方，需求管理被作为一个技术问题来处理，需求管理所针对的对象只是产品，而同项目管理所涉及的问题例如进程安排或资源分配等无关。实际上，项目管理涉及三方面问题：进程安排、资源分配和质量管理（同需求的统一）。

      试想以下三种情况：

●一场高水准的音乐会，预算合理，演出时间却晚了两天。
●质量优良的小轿车，交货及时，然而造价是市价的两倍。
●一套系统，完全满足了用户需求，但在开发过程中使用非法劳工。

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

      "我付了钱，但这不是我想要的"，没有用户愿意这么说。要避免出现这种情况，在进行项目管理和财务预算时，也必须以需求管理为基础。仅仅完成了一件设计并不意味着工作的结束，只有这件设计充分解决了需求，它才具有里程碑般的意义。同样的，一件产品只有在测试和实际操作中完全满足了需求，已经完全准备好了投入到下一阶段的运营，才意味着这件产品在本阶段工作的结束。

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

      里程碑构造机制的基本方法之一就是进程管理，一项需求的满足就意味着一块里程碑的确立。我们应当对用户需求、针对需求而进行的模块设计以及每个子模块的开发进程之间的关联做到心中有数。

      通过我们对需求管理实际应用的分析，几个关键因素凸现出来。首先，需求管理在开发周期中是自始至终存在的。注意：不要把它简单理解为"需求周期"，需求管理必须始终保持更新，它构成了技术管理的基础。

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

八、需求管理的工具

      需求管理所用到的工具必须能够处理和应用于本文所提到的各种需求，应当有助于我们分析需求，确定相应开发和支持工具以处理相关信息，进而处理系统相应模块。系统工程师始终致力于用简单的工具将需求形象化的展现出来，常用的工具比如附有标注说明的系统发布工具以及相关数据库等。

      需求管理涉及到一系列复杂的对象，其任务面向很广，关系到整个设计开发的方方面面。其使用的工具应当提供如图列举的一些功能：

九、总结：需求管理

      本文论述围绕于需求管理工程。需求管理是开发工作有效进行的确证。很明显需求管理是一种很高层次的系统行为，涉及整个开发过程和产品本身。

      需求管理首先要针对需求做出分析，随后应用于产品并提出方案。需求分析的模型正是产品的原型样本，优秀的需求管理提高了这样的可能性：它使最终产品更接近于解决需求，提高了用户对产品的满意度，从而使产品成为真正优质合格的产品。从这层意义上说，需求管理是产品质量的基础。