需求的概念和的任务 需求分析与嘚关系 需求分析过程—需求分析的基本过程
对大多数人来说若要建一幢数百万元的房子，他 一定会与建房者详细讨论各种细节他们都奣白完 定会与建房者详细讨论各种细节，他们都明白完 工以后的修改会造成损失以及变更细节的危害性。 然而涉及到软件开发，人们卻变得“大
大咧咧” 起来 软件项目中百分之四十至百分之六十的问题都是在 需求分析阶段埋下的“祸根”。可许多组织仍在那 些基本的項目功能上采用 些不合规范的方法这 些基本的项目功能上采用一些不合规范的方法，这 样导致的后果便是一条鸿沟(期望差异)—开发者开 發的与用户所想得到的软件存在着巨大期望差异
需求分析就是分析软件用户的需求是什么.如果投入大量的人 力，物力,财力,时间,开发出的軟件却没人要,那所有的投入都 是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户 的要求,从而要重新开发过,这种返工是让人痛心疾艏的.(相信 大家都有体会)比如,用户需要一个for Linux的软件,而你在软件 开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而 想当然的认为是开發for
windows的软件,当你千辛万苦地开发 完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕 不得找块豆腐一头撞死. 需求分析之所以重要,就因為他具有决策性,方向性,策略性的作 需求分析之所以重要 就因为他具有决策性 方向性 策略性的作 用,他在软件开发的过程中具有举足轻重的地位.大家一定要对 需求分析具有足够的重视.在一个大型软件系统的开发中,他的 作用要远远大于程序设计.
风险承担者与需求分析阶段
在中所囿的风险承担者(stakeholder)(这个词很有 意思，原义是赌金保管者我看过很多的翻译，有翻译成涉众 的也有的翻译成参与者的，但是我想他的主要意思就是和这 个项目有密切相关利益的人)都感兴趣的就是需求分析阶段 这些风险承担者包括客户、用户、业务或需求分析员(负责收 集客戶需求并编写文档，以及负责客户与开发机构之间联系沟 通的人)、开发人员、测试人员、用户文档编写者、项目管理
者和客户管理者这蔀分工作若处理好了，能开发出很出色的 产品同时会使客户感到满意，开发者也倍感满足、充实若 处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价 处理不好 则会导致误解 挫折 障碍以及潜在质量和业务价 值上的威胁因为需求分析奠定了软件工程和项目管理嘚基础， 所以所有风险承担者最好是采用有效的需求分析过程
软件工程标准词汇表(1997年)中定义需 求为： 求为
(1)用户解决问题或达到目标所需嘚条件或权能 (Capability)。 (2)系统或系统部件要满足合同、标准、规范或 其它正式规定文档所需具有的条件或权能 (3)一种反映上面(1)或(2)所描述的条件或权能的 文档说明。
软件需求包括三个不同的层次—业务需求、 用户需求和功能需求—也包括非功能需求 用户需求和功能需求 也包括非功能需求
业务需求( business requirement)反映了组织机构或客户对 系统、产品高层次的目标要求，它们在项目视图与范围文 档中予以说明 用户需求(user requirement) 文档描述了用户使用产品必须 要完成的任务，这在使用实例(use case)文档或方案脚本 (scenario)说明中予以说明 功能需求(functional requirement)定义了开发人员必须实现
功能需求 定义 发人员必须實现 的软件功能，使得用户能完成他们的任务从而满足了业 务需求。所谓特性(feature)是指逻辑上相关的功能需求的集 合给用户提供处理能力並满足业务需求。
作为补充软件需求规格说明还应包括非功 能需求，它描述了系统展现给用户的行为和 能需求 它描述了系统展现给用户嘚行为和 执行的操作等它包括产品必须遵从的标准、 规范和合约；外部界面的具体细节；性能要 求；设计或实现的约束条件及质量属性。
所谓约束是指对开发人员在软件产品设计和构造上的限制 质量属性是通过多种角度对产品的特点进行描述，从而反 映产品功能多角喥描述产品对用户和开发人员都极为重 映产 功能 多角度描述产 户 发人 都极为重 要。 值得注意的一点是需求并未包括设计细节、实现细节、 项目计划信息或测试信息。需求与这些没有关系它关注 的是充分说明你究竟想开发什么。
开发软件系统最为困难的部分就是准确说明開发什 么最为困难的概念性工作便是编写出详细技术需 求，这包括所有面向用户、面向机器和其它软件系 统的接口同时这也是一旦做錯，将最终会给系统 带来极大损害的部分并且以后再对它进行修改也 极为困难。 为什么这么说呢因为在大多数的软件系统中，最 终用戶可能都不清楚他的需求是什么这是千真万 确的。如果你的用户告诉你需求就是这些了不要
相信他，继续刨根问底直到你们都筋疲仂尽了。
需求分析是指理解用户需求就软件功能与客户达 成 致，估计软件风险和评估项目代价最终形成 成一致，估计软件风险和评估項目代价最终形成 开发计划的一个复杂过程。（这个和的做法不 太一样微软的需求分析大多是市场人员和用户协 助小组的人去评估用戶的接受程度，这一点也可以 理解因为公司的性质有根本差别）在这个过程中， 用户的确是处在主导地位需求分析工程师和项目
经理偠负责整理用户需求，为之后的软件设计打下 基础需求分析阶段结束后，要求得到：
从广义上理解：需求分析包括需求的获取、分析、 規格说明、变更、验证、管理的 系列需求工程 规格说明、变更、验证、管理的一系列需求工程。 狭义上理解：需求分析指需求的分析、萣义过程
简言之,需求分析的任务就是解决"做什么" 的问题,就是要全面地理解用户的各项要 的问题 就是要全面地理解用户的各项要 求,并准确哋表达所接受的用户需求.
需求分析阶段的工作,可以分为四个方面:
问题识别; 问题识别 ; 制订规格说明; 评审.
需求分析可分为问题识别、分析与综匼、编制需求分析文档、 需求评审等四个阶段，包括以下几个方面：确定软件所期望的 用户类；获取每个用户的需求；了解实际用户任务囷目标以及 这些任务所支持的业务需求；分析员与用户的信息以区别用户 任务需求、功能需求、业务规则、质量属性、建议解决方法和 附加信息；将系统级的需求分为几个子系统并将需求中的一 部分分配给软件组件；了解相关质量属性的重要性；讨论得出
实施优先级；将所收集的用户需求编写成需求规格说明和模型； 评审需求规格说明，确保与用户达成共识
就是从系统角度来理解软件,确定对所开发系 统嘚综合要求,并提出这些需求的实现条件, 统的综合要求 并提出这些需求的实现条件 以及需求应该达到的标准.这些需求包括：功 能需求(做什么),性能需求(要达到什么指标), 环境需求(如机型,等),需求 (不发生故障的概率）,安全保密需求,用户界 面需求,资源使用需求(软件运行是所需的内 存,CPU等),软件成本消耗与开发进度需求,预
先估计以后系统可能达到的目标.
逐步细化所有的软件功能,找出系统各元 素间的联系,接口特性和设计上的限制,汾 素间的联系 接口特性和设计上的限制 分 析他们是否满足需求,剔除不合理部分,增 加需要部分.最后,综合成系统的解决方案, 给出要开发的系统嘚详细(做什 么的模型).
即编制文档,描述需求的文档称为软件需 求规格说明书.请注意,需求分析阶段的成 求规格说明书 请注意 需求分析阶段的成 果是需求规格说明书,向下一阶段提交.
对功能的正确性,完整性和清晰性,以及其 它需求给予评价.评审通过才可进行下一 它需求给予评价 评审通過才可进行下 阶段的工作,否则重新进行需求分析。
业务访谈 专题会议 业务过程/工作流程观察 遗留文档 原型试验 领域专题讨论会议
沟通的定義是人们分享信息、思想和情感的任何过 程另 种定义是沟通是通过信息交互作用来影响 程，另一种定义是沟通是通过信息交互作用来影響 看法、决策和行为在需求获取的沟通中信息就是 这个系统的需求。需求获取沟通的目的就是为了建 立系统需求的概念统一对系统需求的定义和理解， 即系统应该做什么不应该做什么。沟通的模式见 下图
注意这里沟通必须是双向的需求获取中的沟通要素包括： 传送 接收者 任何沟通参与者都不例外既是传送者也是接收 传送－接收者，任何沟通参与者都不例外既是传送者也是接收 者沟通参与者都扮演叻一定的角色，角色是在相互关系中 个体所起到的特定作用和可以用一组规范来比照的行为方式， 在需求获取中参与者主要是用户和开發人员； 信息,包括了与需求相关的符号、文章、思想和情感等等；
渠道通过、视觉或者触觉来实现沟通； 噪音，需求获取过程中噪音主偠是对需求定义不同的理解和产 生歧义的信息； 反馈传送者和接收者之间的相互作用，是沟通成立的必要条 件反馈不一定是语言，比洳回复的email、的答案 等等都是不同形式的反馈； 环境带有主观意味的选择和设定，是沟通发生的地方
沟通按照发生的主客体分类，可以汾成、 人机沟通和组织沟通是指组织成员之间 的信息交流和传递，需求获取是组织沟通的一种,组 织沟通分成了下行沟通、和下 行沟通為组织中上级对下级命令、指示或通报等形 成的沟通，上行沟通事下级对上层反应情况的沟通 平行沟通是组织统一层次之间的沟通，需求获取应 该就是这种沟通避免成为下行或者上行沟通。
"良好的沟通对于一个组织就如血液对于 生命 生命 “ 虽然沟通的最终目的是把信息传递给接收 者，它却有说、写、听等多种方式沟通 旨在和改善关系。怎样运用沟通 的技巧来提高沟通的效率这需要我们从 沟通的多個方面进行改进。 多个 行
口头沟通：通过口头沟通我们可以以一种更准确、 便捷的、及时性的方式获得信息，为讨论、澄清问 题、理解囷即刻反馈提供了场所
在口头沟通时候要观察对方身体语言、语音语调这些丰富 口头交流的重要因素。 口头沟通应该坦白、明确不要茬表达自己的意见的时候 产生误导或者难以理解，沟通交流的核心不是语言而是 理解，口头沟通的双方都应该重视聆听 在沟通过程中信息的发送者和接收者在某些问题上可能有 着截然不同的理解。
这时应该注意在交流之前尽量获取更多的信息做一个明晰的阐述要 比总提出问题好，太多的疑问会使你的可信度大大下降使人们没法 正确的理解你，人们会对你产生消极的印象 正确的理解你 人们会对你产苼消极的印象 尽量把问题阐述清楚,让对方理解你的意思和态度,如果你没弄明白对 方的意思，自己却产生了其他的某种理解或是设想大可鉯直接问对 方，要尽快地弄清对方的意思尽早解决在互相交流中产生的误解。
让每个人都把心思集中于目标上建立一个共同的立场，這能使人们 互相理解不会害怕捅什么娄子，不会自相残杀了解质询和辩护二 者的区别，花时间咨询其他人的意见也与对方分享为什麼你坚持自 己的立场。 口头沟通的时候人们必须谨慎不要使用可能被理解成是性别歧视、 种族歧视、偏见或者攻击性的言语。因为这种方式是同步的口头沟 通也要注意时机，闯进用户办公室打断对方工作或者在走廊里面遇到
用户聊上半个小时这都是不太合适的
会议和座谈：会议是加强组织建设，强化成员期望促进对 项目目标的投入的有效工具和手段。 为了使会议有效会前必须确定会议的目的、与會人员和议程， 并且把会议目的和议程和资料分发给每位与会人员； 会议期间必须按时召开会议，指定会议记录人员会议主持 人应该督促而不是支配会议，会议内容应该及时并尽可能记录 下来在会议或者面谈中应该使用笔记本电脑，指定一个打字
熟练的人把所有的讨論记录下来记录的同时还要做一定的整 理，另一种办法就是采用录音的方式会议参与者全心投入到 会议中，而事后通过录音整理如果不这样做，那么你结束会 会 中 事后 音整 如 这样做 么你结束会 议的时候就会发现所有的讨论只剩下一个模糊的印象，需求 对你来说仍然昰一件遥远的事情会议结束前总结会议成果并 文档化，请参与讨论的用户对记下的内容评论并更正控制会
见进度和讨论范围按时结束會议； 会后，公布会议结合要安排人员对项目决定和安排进行跟进。
会议与座谈技巧(7-1)
第一次用户和开发人员的会面就像两个陌生 人的第┅次见面一样大家都不知道说什么， 人的第 次见面 样 大家都不知道说什么 问什么都担心他们说的或做的带来分歧， 他们都在想自己要嘚到的东西也就是不同的 期望同时他们都希望同一件事件就是项目 的成功。下面建议的问题列表能够帮助会议 组织者有的放矢： 织者有嘚放矢
会议与座谈技巧(7-2)
第一阶段：从自由的问题开始得到一些基 本的了解，比如要解决的是什么问题需要 本的了解 比如要解决的是什麼问题 需要 解决方案的人，以及解决方案希望达到的效 果
1、谁是问题的提出者或者是解决方案的受益者？ 2、谁将使用这个解决方案 3、荿功的解决方案能够得到哪些经济上的利益 （不要涉及到用户的商业秘密）？ 4、是否有或者需要另一种解决方案
会议与座谈技巧(7-3)
第二阶段：得到问题的更好理解和用户表达 的想法
1、解决方案定位与解决哪些问题？ 2、成功的解决方案将产生什么样的输出 3、解决方案将在什麼样的环境下使用？ 4、有什么特殊的性能要求或者约束影响了解决 方案 方案
会议与座谈技巧(7-4)
第三阶段：关注于会议的效果
1、你认为是否囿更适合的人回答这些问题？ 1 你认为是否有更适合的人回答这些问题 2、是否会议的时间太长，问题太多 3、其他人是否能提供别的信息？ 4、是否我们还有其他的问题没有问到
会议与座谈技巧(7-5)
处理冲突：沟通过程中不可避免地会产生冲突，在目标、动机、 性格、气质上存茬差异产生分歧就会导致冲突我们必须重视并 且正视冲突。冲突也有其有利的 面它能够将问题暴露出来， 且正视冲突冲突也有其有利的一面，它能够将问题暴露出来 使之及早得到重视；它能够激起讨论，澄清观念；迫使寻求求新 的方法；培养创造性更好地解决问題。处理冲突有下面几种方 法：
1、回避或者撤出：卷入冲突的人员主动从这一情况中撤出来避免发生 争端。这种做法是一种消极的方法会使得冲突积累起来，导致后来的逐 步升级 2、竞争或者逼迫：把冲突当成胜－负的局势，认为获胜比相互之间的关 系更有价值可能會导致人们的怨恨心里，恶化工作气氛 3、调停或者消除：尽力在冲突中找出意见一致的地方，最多可能的忽视 差异对可能产生分歧的哋方不进行讨论，但是这并没有将问题彻底解决
4、妥协：寻求一个调和的折中解决方案，着重于分散差异 5、合作解决问题：直接正视問题，寻求双赢的结局尽力得到最好、最 全面的方案，卷入冲突的人员都把对方所持观点的假设理解清楚特别是 那些发生冲突的部分，愿意放弃或者重新定义之间的观点、意见可以看 出这是最积极最好的处理冲突方法。
会议与座谈技巧(7-6)
书面沟通：正视文件、备忘录或鍺邮件这些方式都 属于书面沟通它的特点是持久性。书面沟通应该 仅仅用在必要的时候并且不会增加双方的工作量情 况下使用我们往往不愿意在琐碎的文档中寻找那 些能够在下次会议上能口头沟通获得的信息，所有 书面的表达必须清楚、简洁不能附带与主题无关 的其怹内容，用短句来替代长句用主动语态替代 被动语态，避免使用双重否定或者古汉语词汇措 词要自然。 要
书面沟通也是帮助记忆的一種有效方式
会议与座谈技巧(7-7)
讲演和报告：讲演和报告前要明确目的，准备书面 提纲充分准备多多练习，内容要简明确认信息 能被清楚、正确的理解，不要以数量而要用质量来 打动接受者多用图片、表格来说明问题。在讲演 和报告过程中语言清晰流畅、句式简短、要點之间 过渡自然也应该尽量使用身体语言，有意识的微 笑同时放松双臂或者加上解释性的手势动作，会 显得更加自信一些并且能够消除紧张情绪讲演和
报告一定要在规定的时间内完成，不要拖延最好 留出一段时间与听众进行相互沟通。
需求调研需要充分细致的了解愙户目标 用户业务内容、流程等，这是一个对需求 用户业务内容 流程等 这是 个对需求 的采集过程是进行需求分析的基础准备。 当我们巳经了解、理解了用户的业务于 是可以开始分析需求了。软件系统的需求 分析可以由产品工程师或系统分析员或两 者分阶段合作完成全蔀的需求分析工作 者分阶段合作完成全部的需求分析工作
提取出核心、主要、急迫的业务， 明晰业务流程(2-1)
通过需求调研我们会发现用戶各方面的业务很多，从大处着 眼包括用户的各种业务项目、业务流程，再明细到业务过程 的每一个单据每一条记录，如生产过程中烸一个环节的记录 办公中的每一个通知，甚至包括文件报刊的收发计划生育指 标统计等等。如此繁杂的各类业务我们从何下手？这時需要 我们回头去查看软件的项目规格说明书再次温故客户对软件 项目或产品的最初提出的需求目标和范围，我们的软件主要是
为用户解决什么样的问题 从众多的业务中提取出用户核心的、主要的、急需的业务，这 些是我们软件需求主要关心所在写一篇文章需要重点突出， 些是我们软件需求主要关心所在 写 篇文章需要重点突出 主次分明我以为规划一个软件产品也是同理。
提取出核心、主要、急迫的業务 明晰业务流程(2-2)
从用户繁杂的业务中进行业务、业务流程的提取， 把那些分布在各个部门的同 种业务提取出来 把那些分布在各个部門的同一种业务提取出来。 比如物资的管理涉及到生产部门的需用计划，汇 总到物资部门的采购计划计划的审批，采购合同 物资采購，物资部门的收发存业务生产部门的物 资领用消耗等等，我门需要分析用户的这个业务流 程中哪些是系统能帮助管理的哪些是要在系统外
处理的，充分分析了用户现有的业务和业务流程 我们进入下一步骤。
运用管理思想优化业务流程
我们提供的是管理软件产品，偠帮助用户解决的是管理问题 那么用户是这样的业务流程，就需要我们分析这样的流程合理 吗还有缺陷吗，怎样做能提高效率、解决問题可以运用更 先进的管理思想吗……。 一般情况下我们需要从两个方面考虑业务流程的优化。
一方面是我们采用了网络计算机这些噺的技术手段较之原先手工、电话 等方式在信息的传递、信息的共享、数据的处理等方面将会带来新的方式， 必将改变原有的业务流程 另一方面就是我们根据对用户业务的理解，考虑是否可以运用先进的管理 思想比如MRPII、ERP、SCM、CRM、JIT、EIA、E-Business等等管 理模型，进行现有业务流程的偅组或优化当然一旦牵涉到业务流程的修
改一定要与客户的中高层管理者进行充分的沟通，只有客户认同方可确定 因为这一定会在软件实施时需要相应的管理制度配套执行。
进行业务分类规划系统蓝图(2-1)
以上都明确了以后，我们可以描绘系统蓝图了系统有几个子系统， 每个子系统有哪些模块各个模块处理哪些业务，很重要的一点还有 各子系统模块之间的数据接口关系基础数据从哪里进入，通过哪些 各子系统模块之间的数据接口关系 基础数据从哪里进入 通过哪些 处理生成哪些结果等等这个过程需要整理、抽象用户业务，规划软 件實现规划软件系统模块间的逻辑关系。因为系统的页面实现是按
照系统模块的规划所以应尽量采用用户易理解、熟悉的方式、词语 进荇模块的描述。
进行业务分类规划系统蓝图(2-2)
例如ERP系统中的物资管理子系统，首先明确这个子系统是ERP系 统中进行物资相关的业务处理系统同时它为主生产系统、成本管理 子系统提供生产物资供应、领用消耗核算等的数据支持。因此在规划 子系统提供生产物资供应 领用消耗核算等的数据支持 因此在规划 子系统模块时按照业务过程模型，应包含物资需用计划、物资采购 计划、出入库管理、库存管理等主要业務模块再考虑软件运行必须
的初始数据设置，增加一个基础信息维护模块(包括物资大类、物资 编码等信息维护)还有考虑到不同用户对此系统的不同需求，如更 多的生产人员、管理人员的需求再单独增加一个综合查询和分析模 块。另外还有与物资采购相关的业务如采购匼同可以放到合同管理 子系统统一考虑，这里只做查询这样规划出了软件系统对物资管理 业务的处理，检查 下是否包含了物资管理中所有核心、主要的业务 业务的处理
检查一下是否包含了物资管理中所有核心 主要的业务 这时我们发现还有比如物资采购、验收、盘库等業务还是需要物资管 理业务人员来完成，系统可以做到的就是记录结果软件系统是管理 的辅助系统，不能完全代替人的所有工作管理軟件再加上管理制度、 业务人员的操作才构成一套完整的管理体系。
收集与当前项目相关的需求方的文档资料 文档资料主要包含： 文档資料主要包含
业务相关的文档：业务报表、规章制度等等 决策相关的文档：会议纪要、会议视频等等 遗留相关软件文档 ……
问卷调查是以書面提出问题的方式搜集资料的一种研究方法， 即调查者就调查项目编制成表式分发或邮寄给有关人员，请 示填写答案然后回收整理、统计和研究。 问卷调查的最大优点是方法简便节约时间（就调查者而言）， 材料也比较容易整理和统计有时用无记名形式问卷可以獲得 面谈或开调查会不容易获得的某种有价值的资料。 问卷调查的局限性在于发出的问卷常常无法全部收回收回的
问卷太少，往往影响所取得材料的代表性其次，问卷调查应 用范围较广搜集的资料往往是表面的，不能了解深层次的问 题再次，问卷中的问题太多答鍺生厌、置而不理；问题太 次 问卷中的问 太多 答者 问 太 少，所得的数据不能说明问题有可能影响整个教育科学研究 结论的科学性。
原型囮方法是十分重要的.原型就是软件 的一个早期可运行的版本,它实现了目标 的 个早期可运行的版本 它实现了目标 系统的某些或全部功能.
原型囮方法就是尽可能快地建造一个粗糙的系统,这 系统实现了目标系统的某些或全部功能,但是这个系 统可能在可靠性,界面的友好性或其他方面仩存在缺 陷. 建造这样一个系统的目的是为了考察某一方面的可 行性,如算法的可行性,技术的可行性,或考察是否满 足用户的需求等.如,为了考察昰否满足用户的要求, 可以用某些软件工具快速的建造 个原型系统,这个 可以用某些软件工具快速的建造一个原型系统,这个
系统只是一个界面,嘫后听取用户的意见,改进这个 原型.以后的目标系统就在原型系统的基础上开发.
原型主要有三种类型:探索型,实验型,进化型.
探索型:目的是要弄清楚对目标系统的要求,确定 探索型 目的是要弄清楚对目标系统的要求 确定 所希望的特性,并探讨多种方案的可行性. 实验型:用于大规模开发和實现前,考核方案是否 合适,规格说明是否可靠. 进化型:目的不在于改进规格说明,而是将系统建 造得易于变化,在改进原型的过程中,逐步将原型 进囮成最终系统 进化成最终系统
在使用原型化方法是有两种不同的策略:废弃 策略,追加策略. 策略 追加策略
废弃策略:先建造一个功能简单而且質量要求不高 的模型系统，针对这个系统反复进行修改,形成比 较好的思想,据此设计出较完整,准确,一致,可靠的 最终系统. 系统构造完成后,原来嘚模型系统就被废弃不用. 探索型和实验型属于这种策略 探索型和实验型属于这种策略
研究提出本领域的战略目标和发展重点； 研究提出夲领域专题设置和项目立项建议； 研究提出本领域专题设置和项目立项建议 审核项目（标书）； 审核项目课题立项建议； 组织对重大项目實施方案的论证； 组织对项目、专题的评估和验收； 组织对项目 专题的评估和验收
需求与其他项目过程的联系 软件需求对其他项目风险承擔者的影响 软件过程改进的基础 过程改进周期 需求过程的积累材料 需求过程改进路标
软件开发过程改进的目标
从根本上说，改进过程包括使用更多有效的方法避 免使用过去使用过的令人头痛的方法然而，改进 之路却是从失败、错误开始还要历经诸如受人为 抵制的影响及洇任务的时间紧迫导致改进被搁置这 样的挫折。 软件开发过程的改进有以下两个主要目标：
解决在以前项目或目前项目中遇到的问题 防圵和避免你可能在将来的项目中要遇到的问题。
需求与其他项目过程的联系
需求是软件项目成功的核心所在它为其他许多技 术、管理活動奠定了基础。变更你的需求开发和管 理方法将对其他项目过程产生影响反之亦然。需 求与其他过程的联系见图
1) 制定项目计划需求是淛定项目计划的 基础。因为开发资源和进度安排的估计都 基础 因为开发资源和进度安排的估计都 要建立在对最终产品的真正理解之上通 瑺，项目计划指出所有希望的特性不可能 在允许的资源和时间内完成因此，需要 缩小项目范围或采用版本计划对功能特性 进行选择 进荇选择
2) 项目跟踪和控制监控每项需求的状态， 以便项目管理者能发现设计和验证是否达 到预期的要求如果没有达到，管理者通 常请求变哽控制过程来进行范围的缩减
3) 变更控制在需求编写成文档并制定基线以 后，所有接下来的变更都应通过确定的变更 后 所有接下来的变更嘟应通过确定的变更 控制过程来进行变更控制过程能确保：
变更的影响是可以接受的。 受到变更影响的所有人都接到通知并明白这一点 由合适的人选来作出接受变更的正式决定。 资源按需进行调整 保持需求文档是最新版本并是准确的更新文档。
4) 系统测试用户需求和功能需求是系统 测试的重要参考如果未说明清楚产品在 测试的重要参考 如果未说明清楚产品在 多种多样条件下的期望行为，系统测试者 将佷难明确正确的测试内容反过来说， 系统测试是一种方法可以验证计划中所 列的功能是否按预期要求实现了。同时 也验证了用户任務是否能正确地执行。 也验证了用户任务是否能正确地执行
5) 用户编制文档我曾在一个办公室里工作办公室 里有为商业产品准备用户文档嘚技术写作人员。我 咨询其中一位写作人员为什么他们要工作那么长时 间“我们是食物链的终结者”她回答道,“我们要 编写出用户显示堺面及性能的最终变更版本”。产 品的需求是编写文档的重要参考低质量和拖延的 需求会给编写用户文档带来极大的困难。
6) 构造软件项目主要产品是交付可执行软件而不 是需求说明文档。但需求文档是所有设计、实现工 作的基础要根据功能要求来确定设计模块，而模 塊又要作为编写代码的依据采用设计评审的方法 来确保设计正确地反映了所有的需求。而代码的单 元测试能确定是否满足了设计规格说奣和是否满足 了相关的需求跟踪每项需求与相应的设计和软件 代码。
软件需求对其他项目风险承担者的影响
当软件开发队伍改变他们的需求过程时与其他项 目风险承担者沟通的接口也会发生变化。 为能顺利进行这些接口操作要与其他领域的合作 者多交流，让他们知道伱的改进想法和调整计划 要向他们说明改进后的新过程会带来什么好处。 在开发过程中要遵从开发组与其他功能领域之间重 要交流接口嘚规范和内容如系统需求规格说明文 档或市场需求文档。通常重要项目的文档从写作者 档或市场需求文档
通常重要项目的文档从写作者 角度是严格规范的但往往不能给客户提供他们所 真正需要的全部信息。
条改进软件的原则(4-1)
改进过程应该是革命性的、彻底的、连续的、 妀进过程应该是革命性的 彻底的 连续的 反复的不要期望一次就能改进全部的过程 并且要能接受第一次尝试变更时，可能并没 做好每一件倳不要奢求完美，要从某一些 过程的改进、实施开始当你有一些新技术 的经验后，可逐渐调整你的方法
条改进软件的原则(4-2)
人们和组織机构都只有在他们获得激励时才 愿意变更而变更引起的最强烈的刺激是痛苦。 我的意思并不是要人为地制造痛苦（比如管 理者强加的进喥压力使开发人员工作异常痛 苦）而是你曾在以前项目中经历过的真正 艰辛。
条改进软件的原则(4-3)
过程变更是面向目标的在开始运用高级過程 之前先确保你知道变更的目标。是想减少 需求问题引起返工的工作量还是想更好地 控制需求变更？或是想在实施中不要遗漏某 项需求有一份明确规定的实施蓝图将会有 助于你在改进过程中取得成功。
条改进软件的原则(4-4)
将改进活动看作一些小项目许多改进活动一开始 将改进活动看作 些小项目许多改进活动 开始 就失败了因为缺乏计划或是因为所需资源并未 给予。为避免这些问题把每个改进行为看莋一 个项目。把改进所需的资源和任务纳入工程项目 的总计划中执行计划、跟踪、衡量和报告那些 已在软件开发项目中所做的改进，缩減改进项目 的规模为每个过程改进领域写 份活动计划。 的规模 为每个过程改进领域写一份活动计划
跟踪风险承担者们执行计划的情况看是否获得 了预期的资源并知道改进过程实际消耗的费用。
需求分析误区(6-1)
要想说什么是好的需求分析不如说什么 是不好的需求分析，知噵什么是不好的 是不好的需求分析 知道什么是不好的 自然也就知道了什么是好的。以下就是一 些不好的情况：
需求分析误区(6-2)
毋庸质疑的每个人都会为自己的 个新的Idea 毋庸质疑的 每个人都会为自己的一个新的Idea 而激动万分，特别是当这个Idea受到一些根本不 知道你原本要干嘛的人嘚惊赞时但是请注意， 当你激动得意的时候你可能已经忘了你原本是 在描述一个需求，而不是在策划一个创意、创造 一个概念很多剛开始做需求分析的人员都或多 或少的会犯这样的错误，陶醉在自己的新想法和
新思路中却违背了需求的原始客观性和真实性 新思路中 卻违背了需求的原始客观性和真实性 原则。 永远别忘了：需求不是空中楼阁是实实在在的 一砖一瓦。
需求分析误区(6-3)
几乎所有搞软件的人做需求分析的时候，一上 几乎所有搞软件的人 做需求分析的时候 上 来就会把用户告诉你的要求完完整整的作个解 剖，切开分成几个块再细分成几个子块，然后 再条分缕析可是当用户迷惑的看着你辛辛苦苦 做出来的分析结果问你：我想作一个数据备份的 任务，怎么做这时，你会发现需要先后打开 三个窗口才能完成这个任务。 三个窗口才能完成这个任务
永远别忘了：分解是必需的但最终的目的是為 了更好的组合，而不是为了分解
需求分析误区(6-4)
经常听到这样的抱怨： 用户怎么可以提出这样苛刻的要 经常听到这样的抱怨：“用户怎麼可以提出这样苛刻的要 求呢？”细细一了解，你会发现用户只不过是要求把 一个需要两次点击的功能，改成只有一次点击这样会導 致需要改变需求、改变编码、甚至重新测试，增加工作量 可是，如果换个角度来想想这个功能，开发的时候只用 了几次、几十次鈳是用户每天都要用几百次甚 至几千次
几万次，改动一下就减少了一半的工作量对他来说，这 样的需求难道会苛刻吗 永远别忘了：没囿任何需求是不对的，不对的只是你的需 求分析试着站在用户的思维角度想想，你的需求分析就 会更加的贴近用户更加的合理。软件應该是以人为本的
需求分析误区(6-5)
从程序员成长为系统分析员是一个普遍的轨迹，但并不是一个好 的程序员就必然能成为一个好的系统分析员一些程序员的固化 逻辑，使得他们在做需求分析的时候往往钻进了一些牛角里面 比如说１／０逻辑（或者是说黑白逻辑），认为鈈是这样就是那 样没有第三种情况。可实际情况往往是在一定的时候是这样， 其它时候是那样又比如穷举逻辑，喜欢上来就把所有┅二三可
能的情况列举出来然后一个一个分别处理，每个占用三分之一 的时间；可是实际的情况往往是三分之一的情况占了９９％的 仳例，其它两种情况一年都不会遇到一次实际中还有很多这样 的例子，不一一列举了 的例子 不 列举了 永远别忘了：需求分析和程序设計不尽相同，合理、可行是才是 重要的跳出程序设计的圈子，站在系统的角度上来看问题你 的结论会截然不同。
需求分析误区(6-6)
综合分析需求过程的失误的情况提出相 关的改进措施。 关的改进措施
任何过程改进活动的第一步都是评估当前组织中 任何过程改进活动的第 步嘟是评估当前组织中 使用的方法找出其优势和缺陷所在。评估本身 不能带来任何改进但能提供信息，评估为你正 确选择变更奠定了基礎 一种更彻底的方法是让来自外部的顾问客观地评 估你目前的软件开发方法。这种正式过程的评估 方法要以一种已建立的过程改进框架笁作为基础 方法要以 种已建立的过程改进框架工作为基础 如软件工程研究所（
C M U / S E I1 9 9 5）开发 的软件功能成熟度模型(CMM)。评估者将会检查 软件开发囷管理过程而不限于需求活动.
软件开发过程改进的周期
制定改进活动计划,一个需求管理改进的计划包括如 下活动条目
1) 起草一个需求变更控制过程草案。 2) 评审并修改变更控制过程 3) 以一个项目A来实验(pilot )变更控制过程。 4) 以实验反馈为基础修改变更控制过程 5) 评估问题跟踪工具并選择其一来支持变更控制过程。 6) 定制并购买问题跟踪工具以支持变更控制过程 7) 在组织中使用新的变更控制过程和工具。
建立、实验和实施新的过程
实施一项活动计划意味着开发新的、更好的方法 实施 项活动计划意味着开发新的 更好的方法 并且相信它能提供一个比目前过程更好的结果。 然而并非第一次就能使新过程完美无缺。许多 看起来很不错的方法付诸实施后会变得既不实用 又低效因此，要为你建竝的新过程或文档模板 计划一个“实验”运用在实验中获取的经验来 调整新技术，这样将它运用于整个目标群体时 调整新技术 这样将咜运用于整个目标群体时
改进活动会更有效果。请铭记下面这些关于引导 实验的建议：
选择实验参与者（ p a r t i c i p a n t）他们将尝试新方法并 提供反饋信息，这些参与者可以是生手也可以是老手但他们 不应该对过程改进持有强烈的反对意向。 确定用于评估实验的标准使得到的结果噫于解释。 通知那些需要知道实验是什么以及为什么要实施的工程风险承 担者 考虑在不同的项目中实验新过程的不同部分。用这个方式鈳使
更多的人尝试新方法因此能提高认知水平，增加反馈信息 作为评估的 部分工作，询问实验参与者如果他们不得不回 作为评估的┅部分工作，询问实验参与者如果他们不得不回 头采用他们原有的工作方法，他们会觉得怎样
过程改进周期的最后 步就是评估已实施嘚活动及取得的 过程改进周期的最后一步就是评估已实施的活动及取得的 成果。这样的评估有助你在将来的改进活动中做得更好 评估实驗工作进行得如何，采用新过程解决问题是否很有 效下一次在管理过程实验工作时是否需要稍作变更。
如果想要项目不断取得满意的结果你需要有效地 执行需求工程的各个过程：信息获取、分析、编写 规格说明、验证以及管理。为了执行这些步骤你 应当把过程中积累嘚材料收集起来。过程包含已完 成的活动和可交付的产品过程中积累的材料有助 于小组成员一致而有效地执行过程，还有助于大家 理解怹们遵从的步骤及要开发的产品积累的材料 包括下面几种类型的文档：
清单列出各项活动，交付的结果和其它应注意或验证 的条目检查清单是用来提示记忆的，有助于确保处 于忙碌中的工作人员不要忽略重要细节
一种特定类型工作产品的代表，积累起能在你组织中 运鼡的更好的实例
概括说明怎样完成目标与完成时需要什么样的文档。
确立活动期望、产品期望和交付产品期望的指导原则 过程都应遵從的方针。
描述完成某个活动的任务顺序或步骤说明要执行的 任务及其在项目中所扮演的角色。不要包括示范信息 任务 其在 中 扮演的角色 包括 范信息
一组完成某些目的活动文档的定义。过程描述应包括 过程目标、里程碑、参与者和执行任务的适合时间、 交流步骤期望結果以及与过程相关的输入和输出数 据。
一种完成整个工作产品的指导方式重要工程文档的 种完成整个 作产 的指 方式 重 程文档的 模板提醒你检查是否遗漏了什么。一个结构很好的模 板提供了许多捕获和组织信息的栏目( s l o t )模板 中包含的指导信息将帮助文档作者有效地使用它。
需求开发过程的积累材料
项目视图与范围模板 需求开发过程 需求分配过程 使用实例模板 软件需求规格说明模板 需求优先级确定过程 SRS和使鼡实例审查清单
需求管理过程的积累材料
变更控制过程 变更控制委员会过程 需求变更影响分析检查清单和模板 需求状态跟踪过程 需求跟踪能力矩阵模板
在需要把这些改进活动排序以便能用最小的投资得 到最多的收益过程改进流程图描述了改进活动的 一种前后次序。
软件风險管理基础 与需求有关的风险 风险管理是你的好助手
除了与项目范围和需求有关的风险外项目还面临 着许多风险。依赖于外界实体例洳 个转包承揽 着许多风险。依赖于外界实体例如一个转包承揽 者或生产重用部件的另一个项目就是一种常见的风 险来源。项目管理一直媔临各种风险挑战：不准确 的估计、对准确估计的否决、对项目状态不清楚及 资金的周转的困难 技术风险威胁着高度复杂或很前沿的开發项目，缺 乏知识是另 种风险源以及参与者对所用的技术
乏知识是另一种风险源，以及参与者对所用的技术 和应用领域很陌生等等强淛的或总是变更的政府 规范会使一个很好的计划彻底作废。
风险管理就是使用某些工具和步骤把项目风险限制 在 个可接受的范围内风险管理提供了 种标准 在一个可接受的范围内。风险管理提供了一种标准 的方法来指出风险并把风险因素编成文档评估其 潜在的威胁，以及確定减少这些风险的战略
仅仅认识到项目面临的风险是远远不够的。应该将 其编写成文档并妥善进行管理这样在整个项目开 发过程中囿利于风险承担者了解风险情况和状态。
一张风险列表还不等于一个风险管理计划对于一个小项目， 你可以把控制风险的计划放在软件項目管理计划里但一个大 项目则需要一份独立的风险管理计划，包括用于识别、评估、 编写、跟踪风险的各种方法与途径这份计划还應包括风险管 理活动的角色和责任。你可能希望专门让一个项目风险管理人 员负责可能引起麻烦的事
化学制品跟踪系统的风险条目样例
丅面介绍的风险因素是按需求工程中获取、分析、 编写规格说明、验证和管理汇总起来的，并推荐了 一些方法用于降低风险发生的可能性戓减轻风险发 生给项目带来的影响 下面列出了在做需求分析时一些很危险的做法，如 果你发现你的一些做法与之相似那么，给自己一 些时间好好思考一下，这些做法会对你的软件产 生致命的影响
需求获取相关风险(9-1)
如果团队成员没有对他们要做的产品功能达 成一个清晰的共识，则很可能导致项目范围 的逐渐扩大因此最好在项目早期写一份项 目视图与范围将业务需求涵盖在内，并将其 作为新的需求及修改需求的指导
需求获取相关风险(9-2)
紧张的工程进度安排给管理者造成很大的压 力，使他们觉得不赶紧开始编码将无法按时 完成项目因洏对需求一带而过。项目因其 规模和应用种类不同（如信息系统系统软 件，商业的或军事的应用）而有着很大的不 同粗略的统计表明：需求开发工作应占全 部 作量的 部工作量的1 5 %（Rubin 1999）。记录你参 （ ） 记录你参 与的每个项目中实际需求开发的工作量这
样就能知道所花的时間是否合适并改进将来 项目的工作计划。
需求获取相关风险(9-3)
需求规格说明的完整性和正确性
为确保需求是客户真正需要的要以用户的 为確保需求是客户真 需要的 要以用户的 任务为中心，应用使用实例技术获取需求 根据不同的使用情景编写需求测试用例，建 立原型使需求对用户来说更加直观，同时 获取用户的反馈信息让客户代表对需求规 格说明和分析模型进行正式的评审。
需求获取相关风险(9-4)
有时容易忽略市场对产品的反馈信息故要 有时容易忽略市场对产品的反馈信息 故要 强调市场调查研究，建立原型并运用客户 核心小组来获得革噺产品任务的反馈信息。
需求获取相关风险(9-5)
由于一般强调产品的功能性要求非常容易 由于 般强调产品的功能性要求 非常容易 忽略产品的非功能性的需求。询问客户关于 产品性能、使用性、完整性、可靠性等质量 特性编写非功能需求文档和验收标准， （像在S R S中一样）作为鈳接受的标准
需求获取相关风险(9-6)
如果不同的客户对产品有不同的意见，那最 如果不同的客户对产品有不同的意见 那最 后必将有些客户会鈈满意确定出主要的客 户，并采用产品代表的方法来确保客户代表 的积极参与确保在需求决定权上有正确的 人选。
需求获取相关风险(9-7)
愙户可能会有一些隐含的期望要求但并未 客户可能会有 些隐含的期望要求 但并未 说明。要尽量识别并记录这些假设提出大 量的问题来提示客户以充分表达他们的想法、 主意和应关注的一切。
需求获取相关风险(9-8)
把已有的产品作为需求基线
在升级或重做的项目中需求开发可能显得不很重 要开发人员有时被迫把已有的产品作为需求说 明的来源。“只是修改一些错误和增加一些新特 性”这时的开发人员不得鈈通过现有产品的逆 向工程(reverse engineering)来获取需求。可是 逆向工程对收集需求是一种既不充分也不完整的 方法。因此新系统很可能会有 些与现有系統同 方法 因此新系统很可能会有一些与现有系统同
样的缺陷将在逆向工程中收集的需求编写成文 档，并让客户评审以确保其正确性
需求获取相关风险(9-9)
用户推荐的解决方法往往掩盖了用户的实际 需求，导致业务处理的低效或者给开发人 员带来压力以至做出很差的设计方案。因此 分析人员应尽力从客户叙说的解决方法中提 炼出其本质核心
需求分析相关的风险(3-1)
划分出每项需求、特性或使用实例的优先级 划汾出每项需求 特性或使用实例的优先级 并安排在特定的产品版本或实现步骤中。评 估每项新需求的优先级并与已有的工作主体 相对比以做絀相应的决策
需求分析相关的风险(3-2)
分析每项需求的可行性以确定是否能按计划 实现。成功好象总是悬于一线的于是运用 项目状态跟踪嘚办法管理那些落后于计划安 排的需求，并尽早采取措施纠正
需求分析相关的风险(3-3)
不熟悉的技术、方法、语言、工具或硬件平台
不要低估了学习曲线中表明的满足某项需求所需要的新技 术的速度跟进情况。明确那些高风险的需求并留出一段充 裕时间从错误中学习、实验及測试原型
需求规格说明相关的风险(4-1)
开发人员和客户对需求的不同理解会带来彼 此间的期望差异，将导致最终产品无法满足 客户的要求對需求文档进行正式评审的团 队应包括开发人员，测试人员和客户训练 有素且颇有经验的需求分析人员能通过询问 客户一些合适的问题，从而写出更好的规格 说明模型和原型能从不同角度说明需求， 这样可使一些模糊的需求变得清晰
需求规格说明相关的风险(4-2)
时间压力對T B D的影响
将S R S中需要将来进 步解决的需求注上T S中需要将来进一步解决的需求注上T B D记号，但如果这些T B D并未解决则将 给结构设计与项目的继续進行带来很大风险。 因此应记录解决每项T B D的负责人的名字 如何解决的以及解决的截止日期。
需求规格说明相关的风险(4-3)
建立一本术语和数據字典用于定义所有的 建立 本术语和数据字典 用于定义所有的 业务和技术词汇，以防止它被不同的读者理 解为不同的意思特别是要说奣清楚那些既 有普通含义又有专用领域含义的词语。对S R S的评审能够帮助参与者对关键术语、概念等 达成一致的共识
需求规格说明相关的風险(4-4)
包含在S R S中的设计方法将对开发人员造成 不必要的限制并妨碍他们发挥创造性设计出 最佳的方案。仔细评审需求说明以确保它是 在强调解决业务问题需要做什么而不是在 说怎么做。
需求验证相关的风险(2-1)
审查相当篇幅的S R S是有些令人沮丧 正如要 S是有些令人沮丧正如要 在开發过程早期编写测试用例一样。但如果在构 造设计开始之前通过验证基于需求的测试计划和 原型测试来验证需求的正确性及其质量就能夶 大减少项目后期的返工现象。在项目计划中应为 这些保证质量的活动预留时间并提供资源从客 户代表方获得参与需求评审的赞同（承諾），并 户代表方获得参与需求评审的赞同（承诺） 并
尽早且以尽可能低的成本通过非正式的评审逐渐 到正式评审来找出其存在的问题
需求验证相关的风险(2-2)
如果评审人员不懂得怎样正确地评审需求文 如果评审人员不懂得怎样 确地评审需求文 档和怎样做到有效评审，那么很鈳能会遗留 一些严重的问题故要对参与需求文档评审 的所有团队成员进行培训，请组织内部有经 验的评审专家或外界的咨询顾问来讲课、授 教以使评审工作更加有效
需求管理相关的风险(4-1)
将项目视图与范围文档作为变更的参照可以 减少项目范围的延伸。用户积极参与的具囿 良好合作精神的需求获取过程可把需求变更 减少近一半（ Jones 1996a）能在早期发 现需求错误的质量控制方法可以减少以后发 生变更的可能。而為了减少需求变更的影响 将那些易于变更的需求用多种方案实现，并 在设计时更要注重其可修改性
需求管理相关的风险(4-2)
需求变更的风險来源于未曾明确的变更过程 或采用的变动机制无效或不按计划的过程来 做出变更。应当在开发的各阶层都建立变更 管理的纪律和氛围當然这需要时间。需求 变更过程包括对变更的影响评估提供决策 的变更控制委员会，以及支持确定重要起点 步骤的工具
需求管理相关嘚风险(4-3)
跟踪能力矩阵有助于避免在设计、结构建立 跟踪能力矩阵有助于避免在设计 结构建立 及测试期间遗漏的任何需求。也有助于确保 不會因为交流不充分而导致多个开发人员都 未实现某项需求
需求管理相关的风险(4-4)
如果开始未很好定义需求，那么很可能隔段 如果开始未很恏定义需求 那么很可能隔段 时间就要扩充项目的范围产品中未说明白 的地方将耗费比预料中更多的工作量，而且 按最初需求所分配好的項目资源也可能不按 实际更改后用户的需求而调整为减少这些 风险，要对阶段递增式的生存期制定计划 在早期版本中实现核心功能，並在以后的阶 段中逐步增加实现需求
项目管理人员可以运用风险管理来提高对造成项目 损失的条件的警惕，在需求获取阶段要有用户的積 极参与精明的管理者不仅能认识到它能带来风险 的条件，而且将它编入风险清单并依据以往项目 的经验估计其可能性和影响。 如果鼡户一直没有参与风险危害值将会扩大以至 危害项目的成功。我曾说服管理人员把项目延期是 由于缺少用户的积极参与我告诉他们不能把公司 的资金投入一项注定要失败的项目。
周期性的风险跟踪能使管理人员保持对风险危害变 化的了解对那些并未得到完全控制的风險能得到 高层管理人员的注意。他们要么开始采取一些修正 措施要么不管风险，依旧按原业务决策思路进行 即使不能控制项目可能遇箌的所有风险，风险管理 也能使你看清形势做出的决策是有所依据。
需求管理和过程能力成熟度模型 需求管理步骤 需求管 步骤 需求规格說明的版本控制 需求属性 度量需求管理的效果
将需求工程分为需求开发和需求管理需求开发包 括对 个软件项目需求的获取、分析、规格說明及 括对一个软件项目需求的获取、分析、规格说明及 验证。典型需求开发的结果应该有项目视图和范围 文档、使用实例文档、软件需求规格说明及相关分 析模型经评审批准，这些文档就定义了开发工作 的需求基线（ b a s e l i n e）这个基线在客户和 开发人员之间就构筑了计划产品功能需求和非功能
需求的一个约定（ a g r e e m e n t）。工程项目可 能会有其它的约定例如可交付性、约束条件、进 度安排、预算及合同约定等。但這些均超出了本书 范围
需求约定是需求开发和需求管理之间的桥梁， 需求管理包括在工程进展过程中维持需求约 定集成性和精确性的所囿活动需求管理强 调：
控制对需求基线的变动。 保持项目计划与需求一致 控制单个需求和需求文档的版本情况。 管理需求和联系链之間的联系或管理单个需求和 其它项目可交付品之间的依赖关系 跟踪基线中需求的状态。
为达到软件过程能力成熟度模型的第二级组织必 须具有在软件开发与管理的六个关键过程域（ key process areas，K PA）以展示达到目标的能力需 求管理是其中之一，它的目标如下：
1) 把软件需求建立一个基线供软件工程和管理使用 2) 软件计划，产品和活动同软件需求保持一致
需求管理的关键过程领域不涉及收集和分析项目需 求。而是假萣已收集了软件需求或已由更高 级的 求而是假定已收集了软件需求或已由更高一级的 系统给定了需求。一旦需求到手且文档化了软件 開发团队和有关的团队（例如质量保证和测试）需 要评审文档。发现问题应与客户或其它需求源协商 解决软件开发计划是基于已确认的需求。
开发团队在向客户、市场部或经理们作出承诺（ c o m m i t m e n t）之前应该确认需求和确认约束 条件、风险、偶然因素、假定条件。也许不得不媔 对由于技术因素或进度原因而不现实的需求作出承 诺但是，决不要承诺任何无法实现的事
关键处理领域同样建议通过版本控制和变哽控制来 管理需求文档。版本控制确保随时能知道在开发和 计划中正在使用的需求的版本情况变更控制提供 了支配下的规范的方式来统┅需求变更，并且基于 业务和技术的因素来同意或反对建议的变更当在 开发中修改、增加、减少需求时，软件开发计划应 该随时更新以與新的需求保持一致不反映现实的 计划于事无补。
当接受了所建议的变更时你可能在进程调度或质量上不能满 足这项变更。在这种情況下必须就约定的变更与所涉及的经 理、开发者以及其它相关组织进行协商。通过如下方法能使项 目反映最新的或变更过的需求
? 暂时擱置次要需求。 ? 得到一定数量的后备人员 ? 短期内带薪加班处理。 ? 将新的功能排入进度安排 ? 为了保证按时交工使质量受些必要的影响（通常，这是缺省反应）
由于项目在特性、进度、人员、预算、质量各个方 面的要求不同，所以不存在 个放之四海皆准的模 面的要求不同所以不存在一个放之四海皆准的模 式。根据早期计划阶段中项目风险承担者确定的优 先级顺序挑选各项选择不管你对变更需求或项目 凊况（如全体职工工作完成量）采取何种措施，必 要时调整一些约定仍是需要养成的一个好习惯这 总比不现实地期待所有新要求在原定茭付日期前魔
术般地实现且其他方面（例如预算或员工工作强度） 不受什么影响要好。
开发组织应该定义项目组执行管理他们需求的步骤文档化编 写这些步骤能使组织成员持续有效地进行必要的项目活动。请 考虑选择以下主题：
? 用于控制各种需求文档和单个需求版本的工具、技术和习惯做法 ? 建议、处理、协商、通告新的需求和变更给有关的功能域的方法。 ? 如何制定需求基线 ? 将使用的需求状态，并且是誰允许作出的变更 ? 需求状态跟踪和报告过程。 ? 分析已建议变动的影响应遵循的步骤 ? 在何种情况下需求变更将会怎样影响项目计划和约萣。 在何种情况下需求变更将会怎样影响项目计划和约定
你可以在一个文档中包含上面所有的信息或者，你可能喜欢 专题分述例如分荿变更控制过程，影响分析过程状态跟踪 过程。这些过程可能在多个项目中都有用因为他们反映每个 项目所应遵循的公共功能。
需求規格说明的版本控制
版本控制是管理需求的一个必要方面需求文档的 每 个版本必须被统 确定。组内每个成员必须能 每一个版本必须被统┅确定组内每个成员必须能 够得到需求的当前版本，必须清楚地将变更写成文 档并及时通知到项目开发所涉及的人员。为了尽 量减少困惑、冲突、误传应仅允许指定的人来更 新需求。这些策略适用于所有关键项目文档
每一个公布的需求文档的版本应该包括一个修正蝂 本的历史情况，即已做变更的内容、变更日期、变 更人的姓名以及变更的原因你应该使用标准修改 符，例如中划线代表取消，下化線代表添加在 页边空白的竖划线指示每个变动的位置。因为这些 符号会弄乱文档支持修改符的字处理软件使你能 够预览和打印编辑后嘚文档或最终的结果。可以考 虑给每个需求标记上版本号当修改需求后就增加 版本号。
除了文本每个功能需求应该有一些相关的信息戓 称之为属性与之相联系。这些属性在它的预期功能 性之外为每个需求建立了一个上下文和背景资料 属性值可以写在一张纸上，存储在┅个数据库或需 求管理工具中商业工具除由系统产生一些属性外， 还可以由你自己定义各种数据类型的其它属性这 些工具允许过滤、排序、查询数据库来察看按选择 的需求属性的需求集。
对大型的复杂项目来说丰富的属性类别显得尤为重要。在你 的每个需求文档中考慮明确如下的属性：
? 创建需求的时间 ? 需求的版本号 ? 创建需求的作者 ? 负责认可该需求的人员 ? 需求状态 ? 需求的原因或根据（或信息的出处） ? 需求涉及的子系统 ? 需求涉及的产品版本号 需求 版 ? 使用的验证方法或接受的测试标准 ? 产品的优先级或重要程度（例如高、中、低或把你能定义嘚属性来表示描述 的优先级的四个方面：收益、损失、成本、风险） ?
需求的稳定性（在将来需求可能变更的指示器不稳定的需求意味你應给予 较多的关注，因为你将面临不定的、混沌的、或不能重复的业务过程）
定义和更新这些属性值是需求管理成本的一部分。 精心挑選属性最小子集能帮助你有效管理项目例 如，你不必把负责认可需求的人员和需求涉及的子 系统都记录下来如果这样的属性在别的地方已经 设置了，在总的开发跟踪系统中就不必在需求数据 库中重复设置
在整个开发过程中，跟踪每个需求的状态是需求管 理的 个重要方媔在每 可能的状态类别中，如 理的一个重要方面在每一可能的状态类别中，如 果你周期性地报告各状态类别在整个需求中所占的 百分仳将会改进项目的监控工作假如你有清晰的 要求，指定了允许修改状态信息的人员和每个状态 变更应满足的条件跟踪需求状态才能正瑺工作。 工具能帮你跟踪每次状态改变的日期
状态值 已建议 已批准 定义 该该需求已被有权提出需求的人建议 该需求已被分析，估计了其對项目余下部分的影响（包 括成本和对项目其余部分的干扰）已用一个确定的产 品版本号或创建编号分配到相关的基线中，软件开发团 隊已同意实现该项需求 已实现需求代码的设计、编写和单元测试 使用所选择的方法已验证了实现的需求例如测试和检 测，审查该需求跟蹤与测试用例相符该需求现在被认 为完成
该计划的需求已从基线中删除，但包括一个原因说明和 做出删除决定的人员
在整个项目开发周期中跟踪需求状态的分布
在每个项目的工作分类细目结构中需求管 理活动应该表现为分配有资源的任务测 理活动应该表现为分配有资源嘚任务 测 算当前项目中的需求管理成本，是计划未 来需求管理工作或经费的最佳途径
一个从未度量过工程任何一个方面的组织通常发现 佷难开始保持 个耗时记录。测算实际开发和项目 很难开始保持一个耗时记录测算实际开发和项目 管理的工作量要求一个文化上的改变和養成记录日 常工作的习惯。然而测算并不像人们所担心的那 样花费时间，了解成员花费在各个项目任务上的确 切工作量会使你获得有价徝的资料应该注意到工 作量计算与翻过的日历时间不成正比，任务进度可
能被打断或因同客户协商造成拖延每个单元的工 作时数总和表明一个任务的工作量，这个数据没必 要随外界因素变化但总体上却要比原计划长一些。
跟踪实际的需求管理效果能使你了解组员是否采取 了措施进行需求管理执行需求管理措施不得力， 会由于不受约束的变更、范围延伸和遗漏需求等原 因而增加项目的风险考虑一下需求管理的下列活 动的效果：
? 提出需求变更和已建议的新需求。 ? 评估已建议的变更包括影响分析。 ? 变更控制委员会活动 ? 更新需求文档戓数据库。 ? 在涉及人员或团队中交流需求的变更 ? 跟踪和报告需求状态。 ? 定义和更新需求跟踪能力信息
尽管忽视和效率不高会随时发生，管理项目需求能 确保你投资到需求的收集、归档和分析的努力没有 白费有效的需求管理策略能在整个开发过程中使 项目参与者获悉需求的当前状态信息，从而减少大 家在需求认识上的差距
控制项目范围的扩展 变更控制过程 变更控制委员会 测量变更活动
不被控制的变更昰项目陷入混乱、不能按 进度执行或软件质量低劣的共同原因。为 进度执行或软件质量低劣的共同原因 为 了使开发组织能够严格控制软件項目应确 保以下事项：
? 应仔细评估已建议的变更 ? 挑选合适的人选对变更做出决定。 ? 变 应 时 知所有涉 的人 变更应及时通知所有涉及的人员 ? 项目要按一定的程序来采纳需求变更。
只有项目风险承担者在开发过程中能控制变更他 们才知道将交付什么，哪 项将会导致与目标的差 们才知道将交付什么哪一项将会导致与目标的差 距。对项目越深入了解后你就越能发现采纳变更 需求条件的苛刻。在需求文档中一萣要反映项目的 变更需求文档应精确描述要交付的产品，这就是 你的原则要是软件需求文档同产品不一致，那它 就毫无用处甚至就潒没有一个软件需求文档来指 导开发组开发一样。
当你不得不做出变更时应该按从高级到低级的顺 序对被影响的需求文档进行处理。举個例子 个 序对被影响的需求文档进行处理。举个例子一个 已建议的变更可能影响一个使用实例和功能需求但 不影响任何业务需求。改動高层系统需求能够影响 多个软件需求如果在最低层需求上做出变更， （典型的情况是一个功能性需求）可能会导致需 求同上层文档鈈一致。
扩展需求是指在软件需求基线已经确定后又要增添 新的功能或进行较大改动问题不仅仅是需求变更 本身，而是迟到的需求变更會对已进行的工作有较 大的影响要是每个建议的需求都被采纳，对于项 目出资者（ s p o n s o r）、参与者与客户来说项目 将永远也不会完成—事实仩这是不可能的。
对许多项目来说一些需求的改进是合理的且不可 避免。业务过程、市场机会、竞争性的产品和软件 技术在开发系统期间是可以变更的管理部门也会 决定对项目做出一些调整。 在你的项目进度表中应该对必要的需求改动留有余 地若不控制范围的扩展將使我们持续不断地采纳 新的功能，而且要不断地调整资源、进度、或质量 目标这样做极其有害。这儿 点小的改动那儿 目标，这样做極其有害这儿一点小的改动，那儿
一点添加很快项目就不可能按客户预期的进度和 预期质量交付使用了。
管理范围扩展的第一步就是紦新系统的视图、范围、 限制文档化并作为业务需求的 部分评估每 项 限制文档化并作为业务需求的一部分，评估每一项 建议的需求和特性将它与项目的视图和范围相比 较决定是否应该采纳它。强调客户参与的有效的需 求获取方法能够减少遗漏需求的数量只在做出提 交承诺和分配资源后才采纳该需求。控制需求扩展 的另一个有效的技术是原型法这个方法能够给用
户提供预览所有可能的实现，以帮助用戶与开发者 沟通从而准确把握用户的真实需求
一个好的变更控制过程给项目风险承担者提供了正 式的建议需求变更机制。通过这些处理過程项目 负责人（ l e a d e r）可以在信息充分的条件下做出 决策，这些决策通过控制产品生存期成本来增加客 户和业务价值你通过变更控制过程来跟踪已建议 变更的状态，确保不会丢失或疏忽已建议的变更 一旦你确定了一个需求集合的基线，你应该对所有 已建议的变更都遵循變更控制过程
变更控制过程并不是给变更设置障碍。相反地它 是 个渠道和过滤器，通过它可以确保采纳最合适 是一个渠道和过滤器通过它可以确保采纳最合适 的变更，使变更产生的负面影响减少到最小变更 过程应该做成文档，尽可能简单当然首要的是有 效性。如果变更过程没有效率且冗长又很复杂， 大家宁愿用旧方法来做出变更决定（或许他们应该 那样做）
控制需求变更同项目其它配置管理決策紧密相连。 管理需求变更类似于跟踪错误和做出相应决定过程 相同的工具能支持这两个活动。然而记住它是工具 而不是过程使用商业问题跟踪工具来管理已建议 的需求变更并不能代替写下变更需求的内容和处理 的过程。
项目管理应该达成一个策略它描述了如何处悝需求变更。策 略具有现实可行性要被加强才有意义。下述需求变更的策略 是有用的：
? 所有需求变更必须遵循的过程按照此过程，如果一个变更需求未 被采纳则其后过程不再予以考虑。 ? 对于未获批准的变更除可行性论证之外，不应再做其它设计和实 现工作 ? 简单请求一个变更不能保证能实现变更，要由项目变更控制委员会 （ C C B）决定实现哪些变更（本章将讨论C C B） ? 项目风险承担者应该能够了解变更数據库的内容 项目风险承担者应该能够了解变更数据库的内容。 ?
绝不能从数据库中删除或修改变更请求的原始文档 ? 每一个集成的需求变更必须必须能跟踪到一个经核准的变更请求。
有一个项目它由两大部分组成一个是用户集成界 面应用，另 个是内部知识库但缺乏变更过程。 面应用另一个是内部知识库，但缺乏变更过程 当知识库开发人员改变了外部界面但没有将此变更 通知应用开发人员，这个项目就碰到了麻烦还有 一个项目，开发人员在测试时才发现有人应用了新 的已被修改的功能却没有通知小组中其余人员导 致重做了测试程序囷用户文档。采用统一的变更控
制方法可以避免这样的问题所带来的错误、开发的 返工和耗费时间
下面主要讨论关于过程是如何处理需求变更 的。步骤中的4个组件和若干个过程描述将 的 步骤中的4个组件和若干个过程描述将 会是很有用的：
? 开始条件（ entry criteria）—在执行过程或步骤湔应该满足 的条件 ? 过程和步骤中所包含的不同任务（ t a s k）及项目中负责完 成它们的角色。 ? 验证（v e r i f y）任务正确完成的步骤 ? 结束条件（ exit criteria）—指出过程或步骤完成的条件。
b. 角色和责任 c. 变更请求状态 d. 开始条件 e. 任务
e.1 产生变更请求 e.2 评估变更请求 e.3 作出决策 e.4 通知变更人员 4
f. 验证 g. 结束条件 h. 变更控制状态报告 附录：存储的数据项
变更管理活动中可能的项目角色
挑选工具时可以考虑以下几个方面
可以定义变更请求的数据项 可以定義变更请求生存期的状态转换图。 可以定义变更请求生存期的状态转换图 可以加强状态转换图使经授权的用户仅能做出所允 许的状态变更 记录每一种状态变更的数据，确认做出变更的人员 可以定义在提交新请求或请求状态被更新后应该自 动通知的设计人员。 可以根据需偠生成标准的或定制的报告和图表
软件开发活动中公认变更控制委员会或C C B（有 时也称为结构控制委员会）为最好的策略之 时也称为结构控制委员会）为最好的策略之一 （McConnell 1996）。变更控制委员会可以由一个 小组担任也可由多个不同的组担任，负责做出决 定究竟将哪一些已建議需求变更或新产品特性付诸 应用典型的变更控制委员会同样决定在哪一些版 本中纠正哪一些错误。许多项目已经有负责变更决
策的人員而正式组建变更控制委员、制定操作步 骤会使他们更有效地工作。
广义上变更控制委员会对项目中任何基线工作产 品的变更都可做絀决定，需求变更文档仅是其中之 一大项目可以有几级控制委员会，有些负责业务 决策（例如需求变更）另一些负责技术决策 （ Sorensen 1999）。囿些变更控制委员会可以独 立做出决策而有些只是负责决策的建议工作。高 级变更控制委员会做出的决策对计划的影响应比低 级的大尛项目中，只需一两个人就可做出所有决 策
变更控制委员会的成员应能代表变更涉及的团体。 变更控制委员会可能包括如下方面的代表：
产品或计划管理部门 项目管理部门。 开发部门 测试或质量保证部门。 市场部或客户代表 制作用户文档的部门。 技术支持部门 帮助桌面或用户支持热线部门。 配置管理部门
设立变更控制委员会的第一步是写一个总则，描述 变更控制委员会的目的、授权范围、成员構成、做 出决策的过程及操作步骤（ Sorensen 1999）总 则也应该说明举行会议的频度和事由。管理范围是 指该委员会能做什么样的决策及哪种决策應上报 到高一级的委员会。
制定决策 交流情况 重新协商约定
变更总是有代价的即使拒绝的变更也因为决策行为（提交、 评估、决策）而耗费了资源。变更对新的产品特性会有很大的 影响向一个工程项目中增加很多功能，又要求在原先确定的 进度计划、人员安排、资金预算和质量要求限制内完成整个项 目是不现实的当工程项目接受了重要的需求变更时，为了适 应变更情况要与管理部门和客户重新协商约萣
软件测量是深入项目、产品、处理过程的调查研究比起主观 印象或对过去发生事情的模糊回忆要精确得多。测量方法的选 择应该由所媔临的问题和要达到的目标为依据测量变更活动 是评估需求的稳定性和确定某种过程改进时机（ o p p o r t u n i t y）的一种方法，这种时机可以减少未来嘚变更请求需 求变更活动的下列方面值得考虑
接收、未作决定、结束处理的变更请求的数量。 已实现需求变更（包括增、删、改）的合計数量（也可以用在基线上占需 求总数的百分比来表示） 每个 每个方面发出的变更请求的数量。 变 请求 数 每一个已应用的需求（是指已劃过基线）建议变更和实现变更的数量 投入处理变更的人力、物力。
需求跟踪 变更需求代价：影响分析 变更需求代价 影响分析
需求跟踪包括编制每个需求同系统元素之间的联系 文档这些元素包括别的需求、体系结构、其他设 计部件、源代码模块、测试、帮助文件、文档等。 跟踪能力信息使变更影响分析十分便利有利于确 认和评估实现某个建议的需求变更所必须的工作。
跟踪能力（联系）链（ traceability link） 使你能哏踪一个需求使用期限的全过程 使你能跟踪 个需求使用期限的全过程 即从需求源到实现的前后生存期，跟踪能 力是优秀需求规格说明书嘚一个特征为 了实现可跟踪能力，必须统一地标识出每 一个需求以便能明确地进行查阅。
客户需求可向前追溯到需求这样就能区分絀开 发过程中或开发结束后由于需求变更受到影响的 需求。这也确保了需求规格说明书包括所有客户 需求同样，可以从需求回溯相应的愙户需求 确认每个软件需求的源头。如果用使用实例的形 式来描述客户需求图上半部分就是使用实例和 功能性需求之间的跟踪情况。圖的下半部分指出： 由于开发过程中系统需求转变为软件需求、设计、 编写等所以通过定义单个需求和特定的产品元
素之间的（联系）鏈可从需求向前追溯。 素之间的（联系）链可从需求向前追溯
这种联系链使你知道每个需求对应的产品部件从 而确保产品部件满足每个需求。第四类联系链是从 产品部件回溯到需求使你知道每个部件存在的原 因。绝大多数项目不包括与用户需求直接相关的代 码但对于開发者却要知道为什么写这一行代码。 如果不能把设计元素、代码段或测试回溯到一个需 求你可能有一个“画蛇添足的程序”。然而若 这些孤立的元素表明了一个正当的功能，则说明需
求规格说明书漏掉了一项需求
一些可能的需求跟踪能力联系链
在某种程度上，需求哏踪提供了一个表明与合同或 说明 致的方法更进 步，需求跟踪可以改善产 说明一致的方法更进一步，需求跟踪可以改善产 品质量降低维护成本，而且很容易实现重用 需求跟踪是个要求手工操作且劳动强度很大的任务 要求组织提供支持。随着系统开发的进行和维护的 執行要保持关联链信息与实际一致。跟踪能力信 息一旦过时可能再也不会重建它了。
在项目中使用需求跟踪能力的一些好处
审核（c e r t i f i c a t i o n） 哏踪能力信息可以帮助审核确保所有需求被 应用 变更影响分析跟踪能力信息在增、删、改需求时可以确保不忽略每个受 到影响的系统元素。 维护可靠的跟踪能力信息使得维护时能正确、完整地实施变更从而提 高生产率。要是一下子不能为整个系统建立跟踪能力信息一佽可以只 建立一部分，再逐渐增加从系统的一部分着手建立，先列表需求然
后记录跟踪能力链，再逐渐拓展 项目跟踪在开发中，认嫃记录跟踪能力数据就可以获得计划功能当前 实现状态的记录。还未出现的联系链意味着没有相应的产品部件 再设计（重新建造） 你鈳以列出传统系统中将要替换的功能，记录它们 在新系统的需求和软件组件中的位置通过定义跟踪能力信息链提供一 种方法收集从一个現成系统的反向工程中所学到的方法。
重复利用跟踪信息可以帮助你在新系统中对相同的功能利用旧系统相关 资源例如：功能设计、相關需求、代码、测试等。 减小风险使部件互连关系文档化可减少由于一名关键成员离开项目带来 的风险 测试测试模块、需求、代码段之間的联系链可以在测试出错时指出最可 能有问题的代码段。
C M M（capability maturity model）的第三层次要 求具备需求跟踪能力（ CMU/SEI 1995） 软件产品工程活动的十个关键处悝领域有关于它的 陈述，“在软件工作产品之间维护一致性。工作 产品包括软件计划过程描述，分配需求软件需 求，软件设计代碼，测试计划以及测试过程。” 需求跟踪过程中还定义了一些关于一个组织如何处 理需求跟踪能力的期望
表示需求和别的系统元素之間的联系链的最普遍方 式是使用需求跟踪能力矩阵。 跟踪能力联系链可以定义各种系统元素类型间的一 对一一对多，多对多关系 手工創建需求跟踪能力矩阵是一个应该养成的习惯， 即使对小项目也很有效一旦确立使用实例基准， 就准备在矩阵中添加每个使用实例演化荿的功能性 需求随着软件设计、构造、测试开发的进展不断 需求 随着软件设计 构造 测试开发的进展不断
更新矩阵。例如在实现某一功能需求后，你可以 更新它在矩阵中的设计和代码单元将需求状态设 置为“已完成”。
表示跟踪能力信息的另一个方法是通过矩阵 的集合矩阵定义了系统元素对间的联系链。 的集合 矩阵定义了系统元素对间的联系链 例如：
一类需求与另一类需求之间 同类中不同的需求之間。 一类需求与测试实例之间
可以使用这些矩阵定义需求间可能的不同联 系，例如：指定/被指定、依赖于、衍生为以 及限制/被限制
跟踪能力联系链可能的信息源
工具允许定义“跨项目”或“跨子系统”的联系链 我了解到 个有2 我了解到一个有2 0个子系统的大项目，某些高层產 品需求建立在多个子系统之上有些情况下，分配 给一个子系统的需求实际上是由另一个子系统提 供的服务完成的。这样的项目采用商业需求管理工 具可以成功地跟踪这些复杂的跟踪能力关系
当你应用需求跟踪能力来管理工程时，可以考虑下列步骤：
决定定义哪几种聯系链； 选择使用的跟踪能力矩阵的种类； 确定对产品哪部分维护跟踪能力信息由关键的核心功能、高风险部分或 将来维护量大的部分開始做起。 通过修订过程和核对表来提醒开发者在需求完成或变更时更新联系链 制定标记性的规范，用以统一标识所有的系统元素达箌可以相互联系的 目的。若必要作文字记录，这样就可以分析系统文件便于重建或更新 跟踪能力矩阵。 确定提供每类联系链信息的个囚
培训项目组成员，使其接受需求跟踪能力的概念和了解重要性、这次活动 培训项目组成员 使其接受需求跟踪能力的概念和了解重要性 這次活动 的目的、跟踪能力数据存储位置、定义联系链的技术—例如使用需求管 理工具的特点。确保与会人员明白担负的责任 一旦有囚完成某项任务就要马上更新跟踪能力数据，即要立刻通知相关人 员更新需求链上的联系链 在开发过程中周期性地更新数据，以使跟踪信息与实际相符要是发现跟
踪能力数据没完成或不正确那就说明没有达到效果。
变更需求代价：影响分析
影响分析是需求管理的一个重偠组成部分（ Arnold and Bohner 1998）影响分析可以提供对建议的 变更的准确理解，帮助做出信息量充分的变更批准 决策通过对变更内容的检验，确定对现囿的系统 做出是修改或抛弃的决定或者创建新系统以及评 估每个任务的工作量。进行影响分析的能力依赖于 跟踪能力数据的质量和完整性
项目变更控制委员会通常会请资深开发人 员对提出的需求变更申请进行影响分析。 员对提出的需求变更申请进行影响分析 为了帮助影響分析员理解接受一个建议变 更的影响可设计一系列问题核对表。
建议的变更涉及的问题核对表
? 基准（线）中是否已有需求与建议的变哽相冲突 ? 是否有待解决的需求变更与已建议的变更相冲突？ ? 不采纳变更会有什么业务或技术上的后果 ? 进行建议的变更会有什么样的负媔效应或风险？ ? 建议的变更是否会不利于需求实现或其它质量属性 ? 从技术条件和员工技能的角度看该变更是否可行？ ? 若执行变更是否会茬开发、测试和许多其它环境方面提出不合理要求 ?
实现或测试变更是否有额外的工具要求？ ? 在项目计划中建议的变更如何影响任务的執行顺序、依赖性、工作量或进度？ ? 评审变更是否要求原型法或别的用户提供意见 ? 采纳变更要求后，浪费了多少以前曾做的工作 ? 建议嘚变更是否导致产品单元成本增加？例如增加了第三方产品使用许可证的费用 ? 变更是否影响任何市场营销、制造、培训或用户支持计划？
变更影响的软件元素核对表
? 确认任何用户接口要求的变更、添加或删除 ? 确认报告、数据库或文件中任何要求的变更，添加或删除 ? 确認必须创建 修改或删除的设计部件 确认必须创建、修改或删除的设计部件。 ? 确认源代码文件中任何要求的变更 ? 确认文件或过程中任何要求的变更。 ? 确认必须修改或删除的已有的单元、集成或系统测试用例 ? 评估要求的新单元、综合和系统测试实例个数。 ?
确认任何必须创建戓修改的帮助文件、培训素材或用户文档 ? 确认变更影响的应用、库或硬件部件。 ? 确认须购买的第三方软件 ? 确认在软件项目管理计划、質量保证计划和配置管理计划等中变更将产生的影响。 ? 确认在修改后必须再次检查的工作产品
使用需求管理工具的益处 商业需求管理工具 商业需求管 具 实现需求管理自动化
基于文档存储需求的方法有若干限制。例如：
? 很难保持文档与现实的 致 很难保持文档与现实的一致 ? 通知受变更影响的设计人员是手工过程。 ? 不太容易做到为每一个需求保存增补的信息 ? 很难在功能需求与相应的使用实例、设计、代 码、測试和项目任务之间建立联系链。 ? 很难跟踪每个需求的状态 很难跟踪每个需求的状态
需求管理工具使用多用户数据库保存与需求相关的 信息，让你不必担心以上的问题小 点的项目可 信息，让你不必担心以上的问题小一点的项目可 以使用电子表格或简单的数据库管理需求，既保存 需求文本又保存它的几个属性。大项目可以从使 用商业需求管理工具中获益其中包括让用户从源 文档中产生需求，定义属性值操作和显示数据库 内容，让需求以各式各样的形式表现出来定义跟
踪能力联系链，让需求同其他软件开发工具相连等 功能在考慮自行开发工具前先调查一下是否有可 用的成熟工具。
把这些工具称为需求管理而不是需求开发工具这 些工具不会帮助你确认未来的客戶或者从项目中获 得正确的需求。然而你可以获得许多灵活性，可 用来在整个开发期间管理需求的变动使用需求作 为设计、测试、项目管理的基础。这些工具不会代 替已定义用来描述如何获取和管理需求的处理过程 尽管其他方法同样可以完成工作，但为了高效率就 应該使用工具不要试图把使用工具作为缺乏方法、 训练或理解的补充。
一些商业的需求管理工具
这些工具最大的区别是以数据库还是以文檔为核心以数据库 为核心的产品（例如C a l i b e r- R M和D O O R S）把所有 的需求、属性和跟踪能力信息存储在数据库中。依赖于这样的 产品数据库可以或是商业（通用）的或是专有的，关系型或 面向对象的可以从不同的源文档中产生需求，但结果都存在 数据库中在大多数情况下需求的文夲描述被简单地处理为必
须的属性。有一些产品可以把每个需求与外部文件相联系（微 软的Wo r d文件 E x c e l文件，图形文件等等）。通过这 些文件提供额外补充性的需求说明
以文档为核心的方法使用Wo r d或A d o b e公司的F r a m e M a k e r等字处理程序制作和存储文档。R e q u i s i t e P r o通过允许选择文档作为离散需求 存储在數据库中以加强以文档为核心的处理方法的 能力只要需求存储在数据库中，你可以定义属性 和跟踪能力联系链如同以数据库为核心的笁具。 该工具同时提供一些机制同步数据库和文档的内容 Q S
S r e q u i r e i t不使用分离的数据库；而是在 Wo r d需求文档中的文本后面插入一个属性表。 RTM Wo r k s h o p两方面嘟包括在内尽管是以 数据库为核心，但允许从Wo r d中维护需求
使用需求管理工具的益处
即使你善于收集项目的需求，在开发过程中自动化嘚工具仍能可以帮助你处理这些需求 随着开发的进行，开发组成员慢慢记不清需求细节这时商业需求管理工具就变得十分有用。 以下昰一些工具可以帮你执行的任务： 1) 管理版本和变更项目应定义需求基线基线是每个版本所包括的需求的集合。一些 管理版本和变更项目應定义需求基线基线是每个版本所包括的需求的集合。 些
需求管理工具提供灵活的设定基线功能这些工具可以自动维护每个需求的变動历史，这比 手工操作要优越得多可以记录变更决定的基本原则并可根据需要返回到以前的需求版本。 通常这些工具包括一个内建的变動建议系统它可以与变更请求所涉及的需求直接联系。 2) 存储需求属性对每一个需求应该保存一些属性正如1 6章描述的，有关人员应能看
箌这些属性选择合适的人员更新这些属性值。需求管理工具产生几个系统定义的属性（例 如需求创建日期和版本号），同时允许定义鈈同数据类型的其它属性可以通过排序，过滤 查询数据库来显示满足属性要求的需求子集。 3) 帮助影响分析通过定义不同种类的需求孓系统的需求，单个子系统和相关系统部 件—例如：例子、设计、代码和测试—等各个部分之间的联系链工具可以确保需求跟踪。
联系鏈可以帮助用来对特定需求所做的变动进行影响分析即通过确定影响涉及的系统部件 来做到这一点。最好的是这些工具可以查到功能需求的来源 4) 跟踪需求状态利用数据库保存需求可以很容易知道某个产品包含的所有需求。在开 发中跟踪每个需求的状态将可以支持项目的铨程跟踪当项目管理者知道某个项目的下一版 发中跟踪每个需求的状态将 以支持项目的全程跟踪 当项目管 者知道某个项目的下 版
本中的百分之五十五的需求已经验证过了，百分之二十八 已经实现但还没有验证百分之十 七还没有实现时，他就对项目状况有了很好的了解 七还没有实现时 他就对项目状况有了很好的了解 5) 访问控制可以对个人、用户小组确定访问权限。绝大多 数工具允许共享需求信息 对于地域上分散的组可以通过We b网页使用数据库。数据 库在需求这一级别通过锁机制进行 多用户管理 6)
与风险承担者进行沟通典型的需求管理工具尣许小组成 员通过多线索电子对话讨论需 求。当讨论达成一个新的结果时或某个需求修改后自动 电子邮件系统就会通知涉及的人员。 7) 重鼡需求由于在数据库中保存了需求在其他项目或子 项目中重用需求变为可能。 还可以避免信息冗余
商业需求管理工具允许定义不同种類的数据库元素， 例如业务需求、使用实例、功能性需求、硬件需求、 非功能性需求和测试这样就可以区分软件需求规 格说明中的需求對象及其它有用信息。所有的工具 提供了强大的功能用来定义每类需求的属性这一 点是它们相对于基于文本的软件需求规格说明方法 的優势。
绝大多数需求管理工具某种程度上同Wo r d集成 典型的方式是在Wo r d上添加工具条。但Vital Link 是基于F r a m e M a k e r而不是Wo r d。高级的 工具提供丰富的输入、输出攵件格式有些工具允 许从文档中挑选特定的文本，把它们看作离散需求 就如同在数据库中添加新需求。 当你挑选好作为需求的文本时工具通常高亮显示 需求然后插入到Wo r
d书签和隐藏的文本中。还可 以把文档编成不同的风格来扩展每个需求文字处 理后的文档可能不太完媄，但可以通过使用文档风 格和关键字来纠正
工具对每个需求不仅有统一的内部标识符，还支持 层次编码的数字标签这些标识符通常昰 个短文 层次编码的数字标签。这些标识符通常是一个短文 本字首例如U R代表用户需求（ User Requirement），之后再跟一个唯一的整数高级 的工具提供類似于Wi n d o w s资源管理器的层次显 示方法用来操作需求层次树。D O O R S工具可以 使你看到层次结构的软件需求说明书
工具的输出能力包括以用户定义格式或表单报告格 式生成需求文档的能力。C a l i b e r R M强大的文 r档加工功能（称为“ Document Factory”）使你能 在Wo r d中用简单的命令定义一个软件规格说明模 板以指礻页面布局、样板文本、从数据库中选取 的属性及使用文字的方式。 Document Factory以用户定义的查询条件从数据库
中筛选信息并用所定义的模板产生 個定制的文 中筛选信息，并用所定义的模板产生一个定制的文 档因此，软件需求规格说明本质上是一个产生自 数据库筛选内容的报告
所有的工具都有在需求同其他系统元素间定义联系 链的健壮跟踪能力。RTM Wo r k s h o p允许为每 个项目中的存储对象类别建立一个E R图从而为 项目定义一個由E R图组成的类别图表。 通过定义两类别中（或同类别的）对象的联系和基 于图表中定义的类别联系可以实现跟踪能力当完 成以上工作後，一旦某个变更被采纳工具自动根 据跟踪信息把涉及的需求表示为 可疑的 。从而
据跟踪信息把涉及的需求表示为“可疑的”从而 帮助你分析需求变更的影响。
其他特点还包括：建立用户小组定义用户或用户 小组对项目、需求、属性和属性值的读、写
