模板
教程
环境
性能
功能
管理
基于用例的需求管理
过程时代的软件和系统开发
对大多数软件和系统开发团队来说，与过去自由的日子相比，20 世纪 90 年代是一个强调流程的时代。评测和验证有效的软件开发流程的标准得到推广和普及。许多论述软件开发流程的书籍和文献以及关于业务建模和重建的的相关材料纷纷出版。不断涌现出的软件工具已经帮助人们制定和应用有效的软件开发流程。在这十年内，全球经济对软件的依赖程度加深，它推动着开发流程的发展，提高了系统质量。
既然如此，那么今天频频发生的软件项目失败的事件又如何解释呢？即使不是大多数，但为什么仍有那么多的项目受到延期、预算超支和质量问题的困扰呢？随着我们的业务、国家经济和日常活动越来越依赖于系统，如何才能提高系统的质量？
像往常一样，答案就在于该行业的人员、工具和流程。需求管理通常在软件开发出现问题时作为解决方案提出来，但对于这门学科的改进则较少关注。
本文介绍有效需求管理流程的元素，特别强调成功实施需求管理所面临的障碍。
需求管理除了应用于纯软件项目以外，同样也应用于软件只占最终结果的一部分或根本不包括在内的项目。为方便起见，本文以后将使用“系统”这个词来指代任何或所有这些项目。然而，正是软件开发的抽象本质本身，或者和硬件一起，使需求管理复杂化了，因此本文的重点在于软件开发。
为什么要进行需求管理？
简单地说，系统开发团队之所怨言。
以下最近收集的证据很有说服力： Standish Group 从 1994 年到 1997 年的 CHAOS Reports 证实，导致项目失败的最重要的原因与需求有关。[1] 1997 年 12 月，Computer Industry Daily 报导了 Sequent Computer Systems 公司的一项研究，该公司对美国和英国 500 名 IT 经理作调查后发现，百分之七十六的受访者在他们的事业中经历过完全的项目失败。其中提到最多的导致项目失败的原因就是“变更用户需求”。[2] 为什么要管理需求？避免失败就是一个很充分的理由。提高项目的成功率和需求管理所带来的其他好处同样也是理由。Standish Group 的 CHAOS 报告进一步证实了与成功项目关系最大的因素是良好的需求管理。
什么是需求？
理解需求管理的第一步就是对什么是需求管理达成共识。Rational 把需求定义为“（正在构建的）系统必须符合的条件或具备的功能”。电气和电子工程师学会 (IEEE) 使用的定义与此类似。
著名的需求工程设计师 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义，它特指软件方面 - 但不仅仅限于软件。
“软件需求可以定义为：
用户解决某一问题或达到某一目标所需的软件功能。
系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。”[3]
什么是需求管理
由于需求是正在构建的系统必须符合的事务，而且符合某些需求决定了项目的成功或失败，因此找出需求是什么，将它们记下来，进行组织，并在发生变化时对它们进行追踪，这些活动都是有意义的。
换句话说，需求管理就是： 一种获取、组织并记录系统需求的系统化方案。 以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。 这个定义与 Dorfman 与 Thayer 以及 IEEE 的“软件需求工程”的定义相似。需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制[4]。这里介绍的以及 Rational Software 提出的需求管理定义包括了所有这些活动。它们的区别主要在于这里选用了“管理”这个词，而不是“工程”。管理这个词更合适用来描述所有涉及到的活动，并且它准确地强调了追踪变更以保持涉众与项目团队之间共识的重要性。
对那些不熟悉“引出”这个词的人来说，它可定义为团队用来获取或发现涉众请求，确定请求后隐藏的真正需要，以及为满足这些需要对系统提出的一组适当需求。
需求管理问题
一个目的在于确保系统符合人们对其期望的流程面临着哪些困难呢？当它真正在实际项目实施时，困难就暴露出来了。图 1 显示了 1996 年对开发人员、经理和质量保证人员所做的一次调查结果。该图显示了经历过最常提到的需求相关难题的受访者比例。
图 1：常见的需求问题
下面列出了更多与需求有关的问题：
需求不总是显而易见的，而且它可来自各个方面。
需求并不总是容易用文字明白无误地表达。
存在不同种类的需求，其详细程度各不相同。
如果不加以控制，需求的数量将难以管理。
需求相互之间以及与流程的其他可交付工件之间以多种方式相关联。
需求有唯一的特征或特征值。例如，它们既非同等重要，处理的难度也不同。
需求涉及众多相关利益责任方，这意味着需求要由跨职能的各组人员来管理。
需求发生变更。
需求可能对时间敏感。
当这些问题与需求管理和处理技能不足以及缺乏易用工具等情况一同出现时，许多团队都对管理好需求不抱希望了。Rational Software
已经开发出指导团队提高需求管理技能和流程的专业技术。此外，Rational Requisite?Pro 是一个可获得的、有效进行自动化管理需求的工具。
需求管理技巧
为了解决上述问题，Rational 鼓励对关键技巧的开发。下面将要介绍的这些技巧是按顺序给出的，但在有效的需求管理流程中，它们以不同的顺序连续应用。在此，它们将以新项目在第一次迭代时可能使用的顺序出现。
图 2：问题分析步骤
关键技巧 1：分析问题
进行问题分析是为了理解业务问题，确定涉众的最初需要，并提出高层解决方案。这些推理和分析行为找出“隐藏在问题背后的问题”。
在问题分析过程中，将对实际问题的说明取得一致，并确定有关的涉众。初始解决方案的界限和约束从技术和业务两个方面来定义。在适当的时候，项目的商业理由还分析期望从系统获得的投资回报。
关键技巧 2：理解涉众需要
需求有许多来源。它们可能来自于对项目结果感兴趣的任何人。客户、合作伙伴、最终用户以及领域专家都是某些需求的来源。而管理人员、项目团队成员、业务策略和管理机构是另外一些需求源。
因此，掌握如何确定哪些人员应该是需求源、如何获得这些需求源以及如何从中获取信息是很重要的。作为提供这些信息主要来源的个人在本项目中称为“涉众”。
如果您正在开发一个在您公司内部使用的信息系统，那么在开发团队中应包括具有最终用户经验和业务领域专业知识的人员。讨论一般从业务模型一级开始，而不从系统一级开始。如果正在开发一个要在市场上出售的产品，那么您可以充分调动营销人员，以便更好地了解该市场中用户的需要。
获取需求的手段包括访谈、集体讨论、概念原型设计、问卷调查和竞争性分析等。需求获取的结果可能是一份图文并茂的请求或需要列表，并按相互之间的优先级列出。
关键技巧 3：定义系统
定义系统指的是解释涉众需求，并整理为对要构建系统的意义明确的说明。在系统定义初期，需要决定需求的构成、文档格式、语言规范、需求等级、请求优先级和预计工作量、技术和管理风险以及系统规模等。系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型。
我们使用了“说明”这个词而没有用“文档”，是为了避免在后者常见的使用中发现的固有缺陷。说明可以是书面文档、电子文件、图像或用于表达除系统本身以外的系统需求的任何表示方式。
系统定义的结果是用自然语言和图解方式表达的系统说明。后面几节将介绍推荐使用的一些说明格式。
关键技巧 4：管理系统规模
项目规模由分配给它的需求集定义。管理项目规模，使之适合可用资源（时间、人力和资金），是成功管理项目的关键。管理规模是一个持续不断的活动，需要迭代式和递增式开发，这就将项目细分为更易于管理的若干个小部分。
使用需求属性（如优先级、工作量和风险）作为协商应包含需求的基础，对管理规模而言是相当有用的技巧。侧重于属性，而不是需求自身，将减少通常对敏感问题的争论。
这也有助于培养小组负责人的谈判技巧，还有助于在项目中为组织培养推介人，对于客户而言也是如此。产品/项目推介人应能够代表组织拒绝那些超出可用资源的规模变更，也应有相应能力扩展资源以适应扩大的规模。
关键技巧 5：改进系统定义
对高层系统定义达成一致并充分理解了系统初始规模后，投入资源改进系统定义不仅有可能，而且也是经济的。改进系统定义包括两个重要的考虑事项：制定更详细的高层系统说明和验证系统是否符合涉众需要，是否按说明运行。
说明通常是项目团队的重要参考材料。在制定说明时一定要考虑受众。人们常会犯一个错误，那就是用复杂定义表示构建起来很复杂的东西，尤其是在受众无法或不愿意耗费精力去思考某些重要的需要取得一致认识时候。这就难以向项目团队内外的人员解释系统目的。相反，你可能会发现需要为不同的受众编制不同类型的说明。本文介绍了详细自然语言、正式文字和图解说明推荐使用的格式。确定说明格式后，改进将持续贯穿整个项目生命周期。
关键技巧 6：管理变更的需求
不管您多么认真地定义需求，需求终将改变。实际上，一些变更是非常值得的！这意味着您的团队需要与涉众保持密切联系。能否适应变更需求是评测团队的涉众敏感度和运作灵活性的一个尺度 - 敏感度和灵活性都是对项目成功有贡献的团队特征。变更不是敌人，而没有管理的变更才是真正的敌人。
图 3： 变更管理流程
需求变更表明多少需要耗费一些时间来实施某个特定的功能，而且对一个需求的变更对其他需求可能有影响。管理需求变更包括这样一些活动：设立基线、追踪每个需求的历史、确定哪些依赖关系值得追踪、在相关项之间建立可追踪关系以及维护版本控制等。如图 3 所示，建立变更控制或批准流程也很重要，它要求由指定的团队成员来复审所有提议的变更。有时候这一单一的变更控制渠道称为变更控制委员会 (CCB)。
重要的需求概念
为了在项目中运用需求管理技巧，参与项目的每个人理解某些基本的需求管理概念是很有裨益的。这些功能包括： 需求类型 功能交叉的团队 可追踪性 多维属性 变更历史 需求类型系统越大越复杂，出现的需求类型就越多。一个需求类型不过是指需求的一个类。通过确定需求类型，团队可以把大量需求组织成意义明确且更容易管理的组。在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类，并使相互之间的沟通更为清楚明确。
通常，一类需求可以细分即分解成其他类型的需求。业务规则和前景声明包括高层次的需求，团队可以从中导出用户需要、特性和产品需求类型。用例和其他建模形式驱动设计需求，该需求可分解为软件需求，并可以用分析设计模型来说明。测试需求源于软件需求，它被分解为具体的测试过程。如果既定项目中有成百上千个，甚至上万个需求实例时，对需求进行分类可以使项目更容易管理。
功能交叉的团队
与诸如测试或应用程序建模等流程不同（这些流程可在单个业务组中进行管理），需求管理涉及了每一个能够为开发流程提供专门技术的个人。其中应包括那些代表客户和业务预期的人。开发经理、产品经理、分析员、系统工程师甚至客户都应该参与进来。需求团队还应包括创建系统解决方案的人 - 工程师、构架设计师、设计员、程序员、技术文档编写员以及其他提供技术支持的个人。测试员和其他质量保证人员应当作重要的团队成员。
图 4: 功能交叉的需求团队
通常，创造和维护需求类型的职责可按照功能范围来分配，从而进一步优化大型项目的管理。需求管理的功能交叉性质是这门学科非常具有挑战性的一个方面。
可追踪性
如需求类型说明所述，没有一个需求表述是孤立存在的。涉众请求与提议用于满足这些请求的产品特性有关。产品特性与指定特性的功能性和非功能性行为的各个需求相关。测试案例与它们检验和验证的需求相关。有一些需求可能依赖于其他需求，也可能相互排斥。团队为了确定变更带来的影响，保证系统符合预期，就必须理解、记录并维护这些可追踪性关系。尽管可追踪性是需求管理中最难实施的概念之一，但它是适应变更所必不可少的。建立明确的需求类型，吸收功能交叉人员的参与，可使可追踪性更容易实施和维护。要了解需求可追踪性策略的更多信息，请参见白皮书“通过用例进行需求管理的可追踪性策略” [5]。
图 5：需求可追踪性
多维属性
每一个需求类型都有属性，每一个独立需求都有不同的属性值。例如，可为需求分配优先级，确定其来源和原理，委派给某个职能范围内的特定子团队进行管理，指定一定的难度，或者与系统的某个迭代关联关系起来。图 6 对此作了说明，该图显示了 Rational RequisitePro 需求管理工具中 Learning Project 的一个特性需求类型的属性。正如屏幕的标题所暗示，需求类型和每种类型的属性是为整个项目定义的，由此确保了团队上下使用的一致性。
图 6： 定义特性的需求属性
图 7 显示了 RequisitePro 中某个项目的特性需求实例。注意，即使未完整地显示每个需求，但我们从属性值即可了解每个需求的很多内容。在这个例子中，需求的优先级和难度 - 毫无疑问是由团队的不同成员指定的 - 有助于团队兼顾考虑涉众优先级，以及对难度属性值所反映工作量的大致估计，把项目规模限制在可用资源和时间的合理范围内。在更详细的需求类型中，优先级工作量属性可能有更多的具体值（如预计时间、代码行等），从而进一步改进规模。需求的多维性以及不同类型的需求（每种类型都有自己的属性）对于组织大量需求和管理项目的整体规模来说是不可或缺的。
图 7：设置各个需求的属性值
变更历史
单个需求和需求集合都有历史记录，并且内容随着时间的推移而更具有含义。变更在所难免，而且变更有助于与环境变化和技术发展保持同步。记录项目需求版本有助于团队领导人找出变更项目的原因，如新的系统发布等。需求集合可能与某一个软件版本相关，理解这一点有助于人们扩大对变更的管理，降低风险，提高实现重大里程碑的几率。随着单个需求发展，理解它们的变更历史是很重要的：变更内容、起因、时间和谁授权变更等。
实施需求管理工作
需求管理采用上面介绍的关键技巧和概念成功地识别并解决问题。
为了建立一个真正满足客户需求的系统，项目团队首先必须确定系统要解决的问题。然后，团队必须确定涉众，从中获得业务和用户需要，对其进行描述，并区分它们的优先级。从这一组高层期望或需求出发，对产品或系统特性集达成一致意见。
详细的软件需求应该以客户和开发团队都能理解的形式写下来。我们发现，使用客户的语言来描述这些软件需求在取得理解和共识的过程中是最有效的。这些详细的软件需求随后用作系统设计规约的输入，或者作为实施和验证所需的测试计划及过程的输入。软件需求还应该促进初始用户文档规划及设计。
图 8： 需求管理结构概述
需求管理：工作流程明细
根据领域的不同，需求管理可遵循的方案有无限多种。下面的方案给出了六个详细的工作流程，它们适用于每一个关键的需求管理技巧，但也可以应用到任何领域。
下面的工作流程图摘自 Rational Unified Process [6]，需求工作流程明细。这些工作流程用角色、活动和工件（输入或输出）表示，图 9 的活动图对它们进行了概括。旁边的文字简单描述了每个工作流程，希望藉此增进读者对改进需求管理流程的理解和兴趣。关于 Rational Unified Process 的更多信息，可参考 http://www-900.ibm.com/cn/software/rational/products/unified_process/index.shtml.
图 9： Rational Unified Process 中的需求工作流程
工作流程明细：分析问题
在问题分析中，主要的活动是制定项目前景。此活动的结果是产生了一个前景文档，它确定了待建系统的高级用户或客户视图。前景文档将初始需求作为关键特性表述，这些特性是系统为了解决重大问题并满足关键涉众需要而必须具备的。系统分析员在此工作流程中扮演主要角色。系统分析员应该具有问题分析领域的专业知识，对问题有一定的理解，还应该能描述其认为可以解决问题的流程。此阶段要求各个项目涉众积极参与，还应该考虑所有相关的涉众请求。
要开始管理依赖关系活动，应该为职责分配属性，如基本原理、相对值或优先级以及请求的来源等。随着前景的发展，分析员确定可能用例的用户和系统（主角）。主角是用例模型的首要要素，它们将定义系统的功能性和非功能性技术需求。
图 10： 分析问题
工作流程明细：分析问题
启动：一个或多个认识到问题存在的涉众启动工作流程。
开发团队中的系统分析员可以和这几个最初的涉众展开会话，帮助他们描述需要解决的问题。对所认识问题的简要说明达成一致意见是很重要的。下表列出了问题说明的关键元素：
问题
