议题
需求的概念和需求分析的任务 需求分析与软件生命周期的关系 需求分析过程—需求分析的基本过程

建筑需求与软件需求
对大多数人来说，若要建一幢数百万元的房子，他 一定会与建房者详细讨论各种细节，他们都明白完 定会与建房者详细讨论各种细节，他们都明白完 工以后的修改会造成损失，以及变更细节的危害性。 然而，涉及到软件开发，人们却变得“大

 

大咧咧” 起来。 软件项目中百分之四十至百分之六十的问题都是在 需求分析阶段埋下的“祸根”。可许多组织仍在那 些基本的项目功能上采用 些不合规范的方法，这 些基本的项目功能上采用一些不合规范的方法，这 样导致的后果便是一条鸿沟(期望差异)—开发者开 发的与用户所想得到的软件存在着巨大期望差异。

为什么要需求分析
需求分析就是分析软件用户的需求是什么.如果投入大量的人 力，物力,财力,时间,开发出的软件却没人要,那所有的投入都 是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户 的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信 大家都有体会)比如,用户需要一个for Linux的软件,而你在软件 开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而 想当然的认为是开发for windows的软件,当你千辛万苦地开发 完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕 不得找块豆腐一头撞死. 需求分析之所以重要,就因为他具有决策性,方向性,策略性的作 需求分析之所以重要 就因为他具有决策性 方向性 策略性的作 用,他在软件开发的过程中具有举足轻重的地位.大家一定要对 需求分析具有足够的重视.在一个大型软件系统的开发中,他的 作用要远远大于程序设计.

风险承担者与需求分析阶段
在软件工程中，所有的风险承担者(stakeholder)(这个词很有 意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众 的，也有的翻译成参与者的，但是我想他的主要意思就是和这 个项目有密切相关利益的人)都感兴趣的就是需求分析阶段。 这些风险承担者包括客户、用户、业务或需求分析员(负责收 集客户需求并编写文档，以及负责客户与开发机构之间联系沟 通的人)、开发人员、测试人员、用户文档编写者、项目管理 者和客户管理者。这部分工作若处理好了，能开发出很出色的 产品，同时会使客户感到满意，开发者也倍感满足、充实。若 处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价 处理不好 则会导致误解 挫折 障碍以及潜在质量和业务价 值上的威胁。因为需求分析奠定了软件工程和项目管理的基础， 所以所有风险承担者最好是采用有效的需求分析过程。

软件需求的定义
IEEE软件工程标准词汇表(1997年)中定义需 求为： 求为
(1)用户解决问题或达到目标所需的条件或权能 (Capability)。 (2)系统或系统部件要满足合同、标准、规范或 其它正式规定文档所需具有的条件或权能。 (3)一种反映上面(1)或(2)所描述的条件或权能的 文档说明。

需求工程领域中常见术语(1)
软件需求包括三个不同的层次—业务需求、 用户需求和功能需求—也包括非功能需求。 用户需求和功能需求 也包括非功能需求
业务需求( business requirement)反映了组织机构或客户对 系统、产品高层次的目标要求，它们在项目视图与范围文 档中予以说明。 用户需求(user requirement) 文档描述了用户使用产品必须 要完成的任务，这在使用实例(use case)文档或方案脚本 (scenario)说明中予以说明。 功能需求(functional requirement)定义了开发人员必须实现 功能需求 定义 发人员必须实现 的软件功能，使得用户能完成他们的任务，从而满足了业 务需求。所谓特性(feature)是指逻辑上相关的功能需求的集 合，给用户提供处理能力并满足业务需求。

非功能需求
作为补充，软件需求规格说明还应包括非功 能需求，它描述了系统展现给用户的行为和 能需求 它描述了系统展现给用户的行为和 执行的操作等。它包括产品必须遵从的标准、 规范和合约；外部界面的具体细节；性能要 求；设计或实现的约束条件及质量属性。
所谓约束是指对开发人员在软件产品设计和构造上的限制。 质量属性是通过多种角度对产品的特点进行描述，从而反 映产品功能。多角度描述产品对用户和开发人员都极为重 映产 功能 多角度描述产 户 发人 都极为重 要。 值得注意的一点是，需求并未包括设计细节、实现细节、 项目计划信息或测试信息。需求与这些没有关系，它关注 的是充分说明你究竟想开发什么。

准确说明开发什么?
开发软件系统最为困难的部分就是准确说明开发什 么。最为困难的概念性工作便是编写出详细技术需 求，这包括所有面向用户、面向机器和其它软件系 统的接口。同时这也是一旦做错，将最终会给系统 带来极大损害的部分，并且以后再对它进行修改也 极为困难。 为什么这么说呢，因为在大多数的软件系统中，最 终用户可能都不清楚他的需求是什么，这是千真万 确的。如果你的用户告诉你需求就是这些了，不要 相信他，继续刨根问底，直到你们都筋疲力尽了。

需求分析定义
需求分析是指理解用户需求，就软件功能与客户达 成 致，估计软件风险和评估项目代价，最终形成 成一致，估计软件风险和评估项目代价，最终形成 开发计划的一个复杂过程。（这个和微软的做法不 太一样，微软的需求分析大多是市场人员和用户协 助小组的人去评估用户的接受程度，这一点也可以 理解，因为公司的性质有根本差别）在这个过程中， 用户的确是处在主导地位，需求分析工程师和项目 经理要负责整理用户需求，为之后的软件设计打下 基础。需求分析阶段结束后，要求得到：
1.SRS文档(System Requirement Specification); 2.DRM 文档； 3.Acceptance Plan.

需求分析广义定义
从广义上理解：需求分析包括需求的获取、分析、 规格说明、变更、验证、管理的 系列需求工程。 规格说明、变更、验证、管理的一系列需求工程。 狭义上理解：需求分析指需求的分析、定义过程。

需求分析的任务
简言之,需求分析的任务就是解决”做什么” 的问题,就是要全面地理解用户的各项要 的问题 就是要全面地理解用户的各项要 求,并准确地表达所接受的用户需求.

需求分析的过程
需求分析阶段的工作,可以分为四个方面:
问题识别; 问题识别 分析与综合; 制订规格说明; 评审.

需求分析的几个方面
需求分析可分为问题识别、分析与综合、编制需求分析文档、 需求评审等四个阶段，包括以下几个方面：确定软件所期望的 用户类；获取每个用户的需求；了解实际用户任务和目标以及 这些任务所支持的业务需求；分析员与用户的信息以区别用户 任务需求、功能需求、业务规则、质量属性、建议解决方法和 附加信息；将系统级的需求分为几个子系统，并将需求中的一 部分分配给软件组件；了解相关质量属性的重要性；讨论得出 实施优先级；将所收集的用户需求编写成需求规格说明和模型； 评审需求规格说明，确保与用户达成共识。

问题识别
就是从系统角度来理解软件,确定对所开发系 统的综合要求,并提出这些需求的实现条件, 统的综合要求 并提出这些需求的实现条件 以及需求应该达到的标准.这些需求包括：功 能需求(做什么),性能需求(要达到什么指标), 环境需求(如机型,操作系统等),可靠性需求 (不发生故障的概率）,安全保密需求,用户界 面需求,资源使用需求(软件运行是所需的内 存,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系 统中进行物资相关的业务处理系统，同时它为主生产系统、成本管理 子系统提供生产物资供应、领用消耗核算等的数据支持。因此在规划 子系统提供生产物资供应 领用消耗核算等的数据支持 因此在规划 子系统模块时，按照业务过程模型，应包含物资需用计划、物资采购 计划、出入库管理、库存管理等主要业务模块，再考虑软件运行必须 的初始数据设置，增加一个基础信息维护模块(包括物资大类、物资 编码等信息维护)，还有考虑到不同用户对此系统的不同需求，如更 多的生产人员、管理人员的需求，再单独增加一个综合查询和分析模 块。另外还有与物资采购相关的业务如采购合同，可以放到合同管理 子系统统一考虑，这里只做查询。这样规划出了软件系统对物资管理 业务的处理，检查 下是否包含了物资管理中所有核心、主要的业务， 业务的处理 检查一下是否包含了物资管理中所有核心 主要的业务 这时我们发现还有比如物资采购、验收、盘库等业务还是需要物资管 理业务人员来完成，系统可以做到的就是记录结果。软件系统是管理 的辅助系统，不能完全代替人的所有工作。管理软件再加上管理制度、 业务人员的操作才构成一套完整的管理体系。

遗留文档
收集与当前项目相关的需求方的文档资料， 文档资料主要包含： 文档资料主要包含
业务相关的文档：业务报表、规章制度等等 决策相关的文档：会议纪要、会议视频等等 遗留相关软件文档 ……

问卷调查
问卷调查是以书面提出问题的方式搜集资料的一种研究方法， 即调查者就调查项目编制成表式，分发或邮寄给有关人员，请 示填写答案，然后回收整理、统计和研究。 问卷调查的最大优点是方法简便，节约时间（就调查者而言）， 材料也比较容易整理和统计。有时用无记名形式问卷可以获得 面谈或开调查会不容易获得的某种有价值的资料。 问卷调查的局限性在于发出的问卷常常无法全部收回，收回的 问卷太少，往往影响所取得材料的代表性。其次，问卷调查应 用范围较广，搜集的资料往往是表面的，不能了解深层次的问 题。再次，问卷中的问题太多，答者生厌、置而不理；问题太 次 问卷中的问 太多 答者 问 太 少，所得的数据不能说明问题，有可能影响整个教育科学研究 结论的科学性。

原型化方法(4-1)
原型化方法是十分重要的.原型就是软件 的一个早期可运行的版本,它实现了目标 的 个早期可运行的版本 它实现了目标 系统的某些或全部功能.

原型化方法(4-2)
原型化方法就是尽可能快地建造一个粗糙的系统,这 系统实现了目标系统的某些或全部功能,但是这个系 统可能在可靠性,界面的友好性或其他方面上存在缺 陷. 建造这样一个系统的目的是为了考察某一方面的可 行性,如算法的可行性,技术的可行性,或考察是否满 足用户的需求等.如,为了考察是否满足用户的要求, 可以用某些软件工具快速的建造 个原型系统,这个 可以用某些软件工具快速的建造一个原型系统,这个 系统只是一个界面,然后听取用户的意见,改进这个 原型.以后的目标系统就在原型系统的基础上开发.

原型化方法(4-3)
原型主要有三种类型:探索型,实验型,进化型.
探索型:目的是要弄清楚对目标系统的要求,确定 探索型 目的是要弄清楚对目标系统的要求 确定 所希望的特性,并探讨多种方案的可行性. 实验型:用于大规模开发和实现前,考核方案是否 合适,规格说明是否可靠. 进化型:目的不在于改进规格说明,而是将系统建 造得易于变化,在改进原型的过程中,逐步将原型 进化成最终系统。 进化成最终系统

原型化方法(4-4)
在使用原型化方法是有两种不同的策略:废弃 策略,追加策略. 策略 追加策略
废弃策略:先建造一个功能简单而且质量要求不高 的模型系统，针对这个系统反复进行修改,形成比 较好的思想,据此设计出较完整,准确,一致,可靠的 最终系统. 系统构造完成后,原来的模型系统就被废弃不用. 探索型和实验型属于这种策略。 探索型和实验型属于这种策略

领域专题讨论会议
研究提出本领域的战略目标和发展重点； 研究提出本领域专题设置和项目立项建议； 研究提出本领域专题设置和项目立项建议 审核项目（标书）； 审核项目课题立项建议； 组织对重大项目实施方案的论证； 组织对项目、专题的评估和验收； 组织对项目 专题的评估和验收

议题
需求与其他项目过程的联系 软件需求对其他项目风险承担者的影响 软件过程改进的基础 过程改进周期 需求过程的积累材料 需求过程改进路标

软件开发过程改进的目标
从根本上说，改进过程包括使用更多有效的方法避 免使用过去使用过的令人头痛的方法。然而，改进 之路却是从失败、错误开始，还要历经诸如受人为 抵制的影响及因任务的时间紧迫导致改进被搁置这 样的挫折。 软件开发过程的改进有以下两个主要目标：
解决在以前项目或目前项目中遇到的问题。 防止和避免你可能在将来的项目中要遇到的问题。

需求与其他项目过程的联系
需求是软件项目成功的核心所在，它为其他许多技 术、管理活动奠定了基础。变更你的需求开发和管 理方法将对其他项目过程产生影响，反之亦然。需 求与其他过程的联系见图。

各过程间的接口
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）—指出过程或步骤完成的条件。

简单变更控制步骤模板
a. 绪论
a.1 目的 a.2 a 2 范围 a.3 定义

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图组成的类别图表。 通过定义两类别中（或同类别的）对象的联系和基 于图表中定义的类别联系可以实现跟踪能力。当完 成以上工作后，一旦某个变更被采纳，工具自动根 据跟踪信息把涉及的需求表示为 可疑的 。从而 据跟踪信息把涉及的需求表示为“可疑的”。从而 帮助你分析需求变更的影响。

其他特点还包括：建立用户小组，定义用户或用户 小组对项目、需求、属性和属性值的读、写、创建 和删除权限。甚至还有些工具允许把非文本的E x c e l工单或图像对象作为需求的一方面。还包括一些 学习帮助功能，例如示教和例子项目，帮助尽快上 手。

在R e q u i s i t e P r o中不仅可以建立需求与Rational Rose 的使用实例间的联系，还可以建立与Rational Te a m Te s t的 测试实例间的联系。 DOORS允许建立需求与Rational Rose 的设计元素间的联系。 RequisitePro和D O O R S能够建立需求与Microsoft Project中 的项目任务间的连接。 C a l i b e r- R M通过一个中央通信框架允许需求不仅能建立 Select Software Tools’ SelectE n t e r p r i s e的使用实例、类 或处理设计元素间的联系，还可以建立存储在M e r c u r yI n t e r a c i t v e ’s Te s t D i r e c t o r的测试实体间的联系。在C a l i b e r- R M的数据库中就可以直接使用这些联系。

实现需求管理自动化
在对平台、价格、使用方式和需求范例（是以数据库还是以文档为核 心）进行考虑之后选择一个适合你开发环境的工具。下列过程可帮助 选择一个好的工具： 选择 个好的工具
1) 为需求管理工具定义项目需求。确定下列事项：最重要的功能是什么，是否要与 其它使用的工具连接以及通过We b远程数据处理是否重要。决定是使用数据库存储 全部数据还是只存储一部分。 2) 列出影响决策的1 0 ~ 1 5个因素。既要有主观的也要有客观的因素（如裁剪能力、 有效性及G U I的效率）。 3) 对步骤2中列出的因素打分（总计1 0 0分）。对更重要的因素可以打更高的分。 4) 获得有关可用的需求管理工具的最新信息，根据影响决策的因素对候选工具排序。 对客观因素的评分只有在使用每个工具后才能进行。开发商的展示可能会增加一些 感性认识。但展示往往不全面，所以最好还是亲自使用一下（几个小时）。 5) 根据给每个因素的加权值来计算每个候选工具的得分，从而确定最合适的产品。 6) 从候选工具的其他用户那里获得一些体会，可以通过在线论坛获得经验，对自己 的判断和开发商的投标进行补充。 7) 从候选工具中前三名的开发商处得到评估拷贝。确定候选工具前先定义一个评估 处理过程，确保获得足够的信息做出好的决策。 8) 最好用一个实际的项目来评估工具，不要仅用工具所带的示教项目进行评估。完 成评估后，如有必要调整排名分数。找出得分最多的工具。 9) 经过对排名、许可权费、开发商后续支持费、当前用户的输入、工作小组主观印 象等的考虑之后做出决定。

结构化分析方法（传统方法）

结构化分析
结构化分析关注数据通过业务和软件和软件过程的 流程，又称 以过程为中心的 。 流程，又称“以过程为中心的”。 过程为中心：强调的是信息系统框架中的“知识” 构件。 结构化分析是以模型驱动的、以过程为中心的技术， 用于分析一个现有系统，定义新系统的业务需求。 模型是展示系统组建的图形，内容包括过程及其相 关输入、输出和文件。
软件设计时采用数据流图 业务流程重组采用各种过程模型

结构化分析方法（传统方法）
数据分析 功能分析 数据字典

数据分析
数据对象、属性与关系 数据对象 属性与关系 数据之间的关系：基数与形态、实体关系图 （ERD）

实体关系图（ERD）

8.2.1 实体
实体Entity——是我们需要收集数据和存储数据的人、 地点、对象、事件或概念的类 由单数名词命名
Persons 人员: 代理、承包人、客户、部门、分部、雇员、导师、学生 、供应商。人实体类可以表示个人、小组或组织。 Places 地点: 销售地区、建筑物、房间、分支办公室、校园。 Objects 对象: 图书、机器、部件、产品、原材料、软件许可证、软件 包、工具、汽车模型、汽车。对象实体可以表示实际的对象（例如：软件 包 工具 汽车模型 汽车 对象实体可以表示实际的对象（例如 软件 许可证）或者一类对象的说明（例如，不同的软件包的说明）Events 事 件: 应用、奖励、取消、分类、飞行、开发票、订单、注册、续借、获 取、预订、销售、旅行。 Concepts 概念: 账号、时间段、债券、课程、基金、资格、股票

8.2.1 实体
实体实例 Entity instance——实体的具体值 Entity 实体

Student ID 2144 3122 3843 9844 2837 2293

Last Name Arnold Taylor Macy Leath Wrench

First Name Betty John Bill Heather Tim

Instance 实例

Simmons Lisa

8.2.2 属性
Attribute 属性 – 是实体的描 述性性质或特征。同义词包括要 素、性质和域。 Just as a physical student can have attributes, such as hair color, height, etc., a data entity has data attributes Compound attribute 组合属性 – 实际上是由其他属性构成的属 性。它在不同的数据建模语言中 有很多同义词：串联属性、合成 属性和数据结构。

8.2.2 属性
Data type 数据类型 – 是属性的一个参数，定义了这个属性中可以存储 什么类型的数据。
表8-1 逻辑数据类 型 NUMBER TEXT 逻辑业务含义 任何数、实数或整数。 一个字符串，包括数字。当数字包含在TEXT属性中时，意味着我们不希望进行 那些数字的算术或比较运算。 同TEXT一样，但具有不确定的大小。某些业务系统要求能够附加潜在的长注解 信息到一个给定的数据库记录中 任何格式的日期 任何格式的时间 只能取这两个值中的一个值的属性 一个有限值集合。在大多数情况下，应该建立一个编码方案 （例如, FR=Freshman, SO=Sophomore, JR=Junior, SR=Senior). 任何图形或图像。 属性的有代表性的逻辑数据类型

MEMO DATE TIME YES/NO VALUE SET IMAGE

8.2.2 属性
Domain 域 – 是属性的一个参数，定义了这个属性可以取的 合法值
表8-2 数据类型 NUMBER 域 对于整数，指定范围：{最小-最大} 对于实数，指定范围和精度：{精度最小值-精度最大 值} TEXT（属性的最大长度）实际值通常是无限的，但 是用户可以指定某个较小的限制范围 Variation on the MMDDYYYY format. For AM/PM times: HHMMT For military (24-hour times): HHMM {YES, NO} {value#1, value#2,…value#n} {table of codes and meanings} 逻辑数据类型的有代表性的域 例子 {10-99} {1.000-799.999} Text(30) MMDDYYYY MMYYYY HHMMT HHMM {YES, NO} {ON, OFF} {M=Male F=Female}

TEXT DATE TIME YES/NO VALUE SET

8.2.2 属性
Default value 默认值 – 是如果用户没有指定值的话将被记录 的值。 表8-3
默认值 A legal value from the domain NONE or NULL Required or NOT NULL 解释 For an instance of the attribute, if the user does not specify a value, then use this value.

属性允许的默认值
例子 0 1.00

For an instance of the attribute, if the user NONE does not specify a value, then leave it blank. NULL value blank For an instance of the attribute, require that REQUIRED the user enter a legal value from the NOT NULL domain. (This is used when no value in the domain is common enough to be a default but some value must be entered.)

8.2.2 属性
标识符（键）

Key 键 – 是一个属性（或一组属性）， 它们对每个实体实例具有唯一的值。它有 时也被称为标识符。 时也被称为标识符 Concatenated key 复合键 – 是唯一地 标识实体的一个实例的一组属性。同义词 包括组合键和合成健。 Candidate key 候选键 – 是一组可以作 为一个实体的主键的键。它有时被称为候 选标识符。 选标识符 Primary key 主键 – 是最常被用来唯一 地确定一个实体实例的候选键。 Alternate key 替代键 – 是没有被选中 作为主键的任何候选键。

8.2.2 属性
标识符（键） Key 键 – 是一个属性（或一组属性），它们对每 个实体实例具有唯一的值。它有时也被称为标识 符。 Concatenated key 复合键 – 是唯一地标识实体 的一个实例的一组属性。同义词包括组合键和合 成健。 Candidate key 候选键 – 是一组可以作为一个实 体的主键的键。它有时被称为候选标识符。 Primary key 主键 – 是最常被用来唯一地确定一 个实体实例的候选键。Alternate key 替代键 – 是没有被选中作为主键的任何候选键。 子集准则Subsetting criteria ——是一个属性（ 或组合属性），其有限的取值范围把所有的实体 实例分成了有用的子集。这有时也称为反向条目 。

8.2.3 关系
关系relationship – 是存在于一个或多个实体之间 的业务联系。 连接线表示了一个关系，动词短语描述了这个关系。 所有的关系隐含地都是双向的，意味着它们可以从两 个方向上解释。数据建模方法可能在关系的命名上会 有所不同—有些包括两个动词，而另一些仅包括一个 动词。

Student

Is being studied by

is enrolled in

Curriculum

8.2.3 关系
Cardinality 基数 – 定义了一个实体相对于另一个关联实体的某个 具体值的最小和最大具体值数量。

bidirectional

Student

Is being studied by

is enrolled in

Curriculum

8.2.3 关系
基数符号 基数符号：

8.2.3 关系
度数Degree——是参与那个关系的实体数量。 关系存在于两个实体之间称为二维关系。 关系存在于两个实体之间称为二维关系 关系也可以存在于同一实体的不同实例之间，我们 称之为递归关系。 关系还可以存在于两个以上不同实体之间，这种关 系有时被称为N维关系。

8.2.3 关系
关系还可以存在于两个以 上的不同实体之间，这种 关系有时被称为N维关系。 右图演示了一个三维关系。 N维关系用一个新的称为 关联实体的实体结构说明。 关联实体是一个从多个其 他实体（称为父实体）继 承其主键的实体，其复合 键的每个部分指向每个连 接实体的一个且仅一个实 例。

8.2.3 关系
Associative entity 关联实体 – 是一个从多个其他 实体继承其主键的 实体。其复合键的 每个部分指向每个 连接实体的一个且 仅一个实例。

关联实体

8.2.3.3-外键
Foreign key 外键 – 是一个实体的主键， 它被贡献给（复制到）另一个实体以确定一 它被贡献给（复制到）另 个实体以确定 个关系实例. 外键总是与另一个实体的主键匹配 获得外键的实体为子实体 贡献主键的实体是父实体

8.2.3.3-外键
主键 Student ID 2144 3122 3843 9844 2837 2293 主键 外键 Duplicated from primary key of Major entity (not unique) Last Name Arnold Taylor Simmons Macy Leath Wrench First Name Betty John Lisa Bill Heather Tim Smith Jones Dorm Smith Jones Smith

Dorm Smith Jones

Residence Director Andrea Fernandez Daniel Abidjan

8.2.3.3-外键
Nonidentifying relationship 非确定性关系 – 是每个 参与关系的实体都有各自的独立主键的关系
–不共享主键属性 不共享主键属性 –实体被称为独立实体（强实体）

8.2.3.3-外键
Identifying relationship 确定性关系 – 是父实体贡献其主键成为 子实体的主键的一部分的关系
–子实体被称为弱实体。

8.2.3.3-外键
弱实体和非确定性关系的符号表示

8.2.3.3-外键
用一个关联实体 分解非特定关系
Nonspecific N f relationship 非 特定关系 – 是一 个实体的多个实例 同另一个实体的多 个实例相关联的关 系，也称为多对多 关系。 非特定关系可以被 分解为两个一对多 关系。每个实体都 成为一个父实体， 一个新的关联实体 被引入作为每个实 体的子实体

8.2.3.4-泛化
Generalization 泛化 – 是指将几 类实体公共的属性 组合成独立的实体。 Supertype 超类 – 是一个实体， 其实例存储了一个 或多个实体子类的 公共属性。 Subtype 子类 – S bt 是一个实体，其实 例从一个实体超类 中继承了一些公共 属性。
泛化层次体系

何为数据分析
数据分析的前提是数据收集，整个市场走访是获得 数据的 个主要方面，但不是唯 的方面。从获得 数据的一个主要方面，但不是唯一的方面。从获得 数据的渠道可将数据分为为市场走访数据和媒体媒 介披露数据，也可以分为微观数据和宏观数据两类。 数据分析是宏观性的概念，其中包括感性问题整理 归纳，语言信息向数字信息转化，数字信息再转化 为文字加数据的信息；或者是定性信息整理归纳成 定量信息，将定量信息转化为定量信息。

数据收集
数据的收集一般可分为直接和间接两类，我们将在 市场走访中获得的都称为直接数据，而通过电视、 报纸、刊物、网络等获得的称为间接数据。我们重 视每一种来源的数据，专人负责数据的收集，将收 集到数据分门别类地进行收藏，为以后数据的整理 分析做准备，是公司研究问题的原材料。数据的收 集是根据市场和公司的需要，在市场方面做到市场 的细分，依据细分的市场获取材料。

数据整理
对数据的整理是我们创造性工作的第一阶段，是将 原材料初次加工，制造半成品或毛胚的过程。数据 的整理没有阶段性，是一个持续性的行为，其为下 步获得数据提供参考，也为以后数据分析提供依据。 数据整理是找到核心的价值性的数据和信息，剔除 不需要的部分。对调查问卷，则是首先筛选出有效 的问卷，根据问卷的要求统计出每一个问题答案的 绝对数字，再算出其相对值，将所有问题的绝对数 和相对值整理出来。对其统计可以是手工，也可以 是电脑，关键是到时候能找到某一问题的偏重或趋 向。

数据分析
定性分析和定量分析是两种基本的分析方法，具体 的方法可以是回归性分析、交叉分析、聚类分析等， 我们对众多数据的分析不限制某种分析方法，关键 是能最好地说明问题，可以比喻为制造为成品零部 件。 数据的基础分析和高级分析为调研报告提供足量的 材料，我们的基础分析提供单项问题的说明或解释， 而高级说明是寻找众多问题之间潜在的、深层的、 逻辑性的问题。我们努力地将定性分析和定量分析 相结合，发现和挖掘数据中的市场信息和企业问题， 为企业和自身提供行事的依据和参考。

对数据的需求分析
信息资源规划第一阶段的需求分析，包括 对功能的需求分析和对数据的需求分析。 对功能的需求分析和对数据的需求分析 这种需求分析与一般软件工程需求分析的 最大不同点是：面向全组织，需要业务人 员参加，在分析过程中开始建立全组织的 数据标准。

从用户视图开始的数据需求分析
用户视图(UserView)是一些数据的集合，它反应了 最终用户对数据实体的看法，包括单证、报表、帐 册和屏幕格式等。基于用户视图的数据需求分析， 可大大简化传统的实体-关系（E-R）分析方法，有 利于发挥业务分析员的知识经验。 用户视图的分析过程，就是调查研究和规范化表达 用户视图(用户视图标识、用户视图名称和用户视图 的组成)的过程。例如，用户视图标识D041309是按 一定的规则编码的，其名称是“材料申报单”。

复杂企业信息化项目数据梳理
一个制造厂的人力资源、生产管理、物资采购、产 品销售等职能域， 般都有几十个至几百个用户视 品销售等职能域，一般都有几十个至几百个用户视 图，对它们进行如上例的分析和规范化表述，实际 上是一次从未做过的、工作量较大的数据流梳理的 基础工作，对全面把握信息需求有重要意义。 尤其是，分析人员在业务人员提供所需的信息内容 的基础上，按照数据结构规范化理论，对需要存储 的用户视图结构做标准化的 范式 重新组织，直 的用户视图结构做标准化的“范式”重新组织，直 接为数据库设计做好准备。

数据模型与IRM基础标准
数据库设计是为了获得支持高效率存取的数据结构， 在信息资源规划第二阶段的数据建模工作，就是数 据库设计最重要的前导性工作。 数据模型分为概念数据模型和逻辑数据模型。概念 数据模型是由一系列概念数据库构成的。
概念数据库(ConceptualDatabase)是最终用户对数据存储 的看法，反映了用户的综合性信息需求。 逻辑数据库(LogicalDatabase)是系统分析设计人员的观点， ( g ) 是对概念数据库的进一步分解和细化，一个逻辑数据库是 由一组规范化的基本表(Base Table)组成的。

实例
人力资源管理中的“员工主题数据库”，其概念数据库可表达 为：
职工（职工编号，职工姓名，出生日期，文化程度，简历，培训记 录，……）

而其逻辑数据库的规范化表达为：
“主键”是唯一确定一条记录的机制； 基本表“员工基本信息”的一条记录会对应多条“员工简历”记录。

一个制造厂会有50个左右主题数据库，把它们列出来就是全 域概念数据模型；而每个主题数据库会有几个到十几个基本表， 所以，全域逻辑数据模型会有数百个基本表（按主题分为50 所以 全域逻辑数据模型会有数百个基本表（按主题分为50 个左右组）。如果按子系统来分，比如“人力资源子系统”， 概念数据模型会有十个左右主题数据库，而基本表则有30-40 个。

与信息资源管理的关系
信息资源管理（IRM）基础标准中的前三个（数据 元素标准、信息分类编码标准、用户视图标准）和 这里谈的后两个标准（概念数据库标准、逻辑数据 库标准），是紧密联系的。 如上例，概念数据库和逻辑数据库基本表中的数据 内容要遵循数据元素标准和信息分类编码标准；而 用户视图标准为数据库标准建立提供了依据，同时 也为数据库的使用提供了依据。

功能分析
数据流程分析->DFD 数据流程分析 DFD 控制流程分析->CFD 控制规约

数据字典

议题
用例分析 系统分析

用例分析
以用户角度看待系统（业务模型分析）
业务用例（本质用例） 涉众、场景、用户故事 用例图 如何编写用例

用例分析过程实践
团队实践

系统分析
以技术视角看待系统（需求规格化）
从业务用例到系统用例 静态分析：识别对象、类图、对象图 动态分析：活动图、交互图（顺序图、通信 图）、状态图等等

系统分析实践
团队实践

Agenda

? 横切关注点 ? 横切关注点的建模与分离 ? 弹性体系结构演变 ? AOSD的应用

横切关注点1 横切关注点1—扩展

? ? ?

嗯，一切似乎很完美。是什么打破了这一宁静？ 横切关注点是打乱这一规则的“破坏分子”！ 横切关注点包括两类：

扩展：在基组件之上定义的组件，它用来表示附加的服务或功能 非功能属性 缠绕与分散 –AOP原先的发现 对等关注点：相互独立的功能点，各组件中参与类有较大的交叠 –Ivar博士的补充发现 弥补用例分析与实现的鸿沟

横切关注点1 横切关注点1—扩展

?

AOP就是基于对非功能属性实现中发现的“重复”。

?

例如：留存、事务处理、安全、 性能优化、错误处理、日志、 调试、度量等。

横切关注点2 横切关注点2—对等关注点

?

各个组件包含满足不同关注点的实现—缠绕状态

?

某个特定的关注点的实现分散在多个组件中 分散状态 某个特定的关注点的实现分散在多个组件中—分散状态

横切关注点现行实行的不足

? ?

横切关注点1—扩展

代码的大量重复，涉及到多个功能性类 当横切关注点的需求发生变化时，会造成大量修改 横切关注点的更新难以实现一致性
横切关注点2—对等功能点

捕获对等功能点的用例本身就涉及了多个类，容易使分析与设计 的结果不能够有效地对应起来，影响了跟踪 功能的修改，可能涉及多 个类，从而影响系统的弹性 原有的用例建模在管理横 切关注点时存在问题

面向方面技术

?

本质：合成机制，分离横切关注点的方法

可以实现将类之外的附加行为合并到类本身 可以在编译时或运行时进行 可以将不同的关注点的实现分离到不同模块中

?

核心概念

aspect：核心类元，模块化单元 intertype：aspect的方法，定义为“原有类名.新操作名” –类扩展 pointcut：在aspect中说明原有类中的扩展点（连接点） –操作扩展 advice：捕获pointcut出现的特定事件 –操作扩展

Agenda

? 横切关注点 ? 横切关注点的建模与分离 ? 弹性体系结构演变 ? AOSD的应用

基于用例对横切关注点建模

? ? ?

用例是对横切关注点建模的最好工具 用例描述的关键是事件流

用例扩展：
预订房间的 执行点

扩展点 更新房间可用性 =基本事件流步骤5 扩展事件流 房间等候队列

pointcut

基于用例对横切关注点建模

?

用例包含：

?

用例泛化：

基于用例捕获横切关注点

? ? ? ?

应用（application）用例和基础结构（infrastructure）用例 理解涉众关注点
理解问题域（领域类，领域模型） 抽取系统特性（Feature List） 处理功能和非功能需求（应用用例、基础结构用例）

捕获应用用例
从特性中识别出参与者，合并为用例 识别用例变量，并处理用例变量 处理扩展用例

捕获基础结构用例
抽象为<执行事务>用例对基本事务进行建模 基础结构用例的结构化、描述基础结构用例 处理系统范围的关注点

用例切片

?

用例的实现是协作 ：

? ?

协作标识了类及类的扩展 用例切片包括：协作 （交互图、类图）、特定的类、特定的扩展

基于用例切片实现分离

?

合并特定于某用例的类 ：

?

合并用例特定的类扩展：

基于用例切片组成系统

?

通过用例切片（use case slice）和非特定用例切片（non-uc-specific slice）来叠加出系统：

用例模块

?

对于某个用例而言，都包括不同的模型（用例描述、分析、设计、 实现、测试设计、测试实现），每个模型都可以组成一个切片，而 将这些切片放在一个单独的包中，就称为用例模块

Agenda

? 横切关注点 ? 横切关注点的建模与分离 ? 弹性体系结构演变 ? AOSD的应用

架构（Architecture） 架构（Architecture）

?

什么是架构（体系结构）？
系统元素如何组织？ 系统如何实现所需功能？ 系统如何满足预期性能、可靠性和其它质量特性 系统需要什么技术？ 系统内部组织的结构是否能够弹性响应功能、技术、平台变化？ 标准是否能够确保系统开发始终保持一致？采用什么设计模式？

?

什么是好的架构
分离功能需求 从功能需求中分离出非功能需求 分离平台特性 将测试从已测单元中分离出来

架构基线

? ?

架构基线：最终系统的早期版本，Skinny System！
包含了最终系统所具有的子系统、组件和节点的骨架 UP过程中，这一任务主要是在精化阶段完成

用例驱动架构基线：寻找出关键用例子集
演练了系统的关键功能和特性 涵盖了大部分的功能性、基础结构、平台特性等方面的风险 突出了系统中的一些具有高复杂度或高风险性的部分 是系统剩余系统的基础

?

迭代地建立架构基线

平台无关的结构（PIM） 平台无关的结构（PIM）

? ?

元素结构：基于包和类的分层结构
组成部分主要是领域相关的类 通常包括“应用层”和“领域层” 应用层的元素主要实现用中支持系统的主要参与者的工作流 领域层则要包括了描述重要领域概念的元素

用例结构：在元素结构的基础上添加了实际的内容

叠加平台相关特性（PSM） 叠加平台相关特性（PSM）

? ?

选择平台
系统的平台特性基于架构师选定的部署结构和进程结构 我们需要将平台特性与平台无关的部分分离—最小化用例设计 我们需要将平台特性与平台无关的部分分离 最小化用例设计

最小化用例设计（minimal use-case design）
可执行，并采用默认编程语言实现 是通过程序接口来激活的 分布性、内部进程的通信和平台相关消息通信都与其分离 所需的信息都在内存中

使功能需求保持分离 1

? ? ?

分离功能需求的最好办法是用例（应用用例）
什么是特定于某用例的、什么是独立于用例的，什么是特定于某应用的、什么是 应用通用的 ，什么是领域通用的、什么是领域特定的。 这些问题的答案用于指导：如何将类归入到层、包，如果将类扩展归入到相应的 切片、模型中

应用用例的分析
考虑用例规约，必要时进行更新 分析用例：识别出参与用例实现的分析类，并将行为分配给这些类 在系统元素结构中将类组织成为层和包，在用例结构中将类和类扩展组织成切片 将分析元素映射为设计元素、识别出接口及附加的设计元素

使功能需求在分析模型中保持独立
根据类参与实现的用例，形成合适的元素结构 将用例结构分为：针对某个特定用例行为的“用例切片”，不属于特定的某个用 例的“非用例特定切片”

使功能需求保持分离 2

? ?

应用用例设计
识别设计元素：从分析模型中标识设计元素，根据实现需要引入新的设计元素 识别组件和接口：将分析为中的一部分演化为设计组件 完善设计元素

使功能需求在设计模型中保持独立
使类扩展保持分离：ReserveRoom类需要updateAvailability()和retrieveDetails()两 个方法。前者是“预订房间”特用，后者是公用。其处理方法有四种：

现行选择

编程困难

使功能需求保持分离 3

?

使功能需求在设计模型中保持独立
使操作扩展保持独立 1）总和：两个用例切片需要从相同操作得到不同的输出，并且操作的职责是提 供两种输出的合并 2）选择：当用例切片需要从同一个操作得到不同的输出，并且要求组合结果只 有一种输出

操作扩展声明包括 1）结构上下文：说明哪个操作是要增加的 2）行为上下文：说明扩展何时执行 3）说明附加行为

使扩展的功能需求保持分离 1

?

面向方面技术能够使我们更好地在原有系统上进行扩展

该扩展流程应该在pointcut UpdatingRoomAvailability返回没有空闲房时 系统建立一个针对选定房间类型的带唯一标识符的待处理订单，然后将其放到等 候列表中，再将此唯一标识符返回给客户，用例结束。

?

识别类：

使扩展的功能需求保持分离 2

?

识别Pointcut，并将用例行为分配给类
标识结构上下文：确定在何处运行这些操作扩展来调用扩展用例 标识行为上下文：定义职责中的何处需要调用

使扩展的功能需求保持分离 3

?

因此，得到了一个独立的用例切片完成该扩展用例

使非功能需求保持分离 1

?

分离非功能需求最有效的工具是基础结构应用
识别类 标识Pointcut 将用例行为分配给类

使非功能需求保持分离 2

?

使基础结构用例保持分离
细化元素结构 在用例切片中使基础结构保持分离

使平台特性保持分离
最小设计视角

合并了平台特性

Agenda

? 横切关注点 ? 横切关注点的建模与分离 ? 弹性体系结构演变 ? AOSD的应用

保持关注点分离带来的生产率提高

? ? ? ?

假设某系统有N个独立的需求，假设每个的工作量需X，则总工作 量就是NX 若N个需求未良好分离，就意味着每个需求的实现与其它需求的实 现相互交迭，最坏时可能是每个需求的实现与N-1个需求相关，如 果交迭部分的开发量是Y，则任务量就成了NX+N(N-1)Y 假设N=20，X=20，Y=1，良好分离时工作量为400，未良好分离时 显然就是780，接近一倍。 随着Y值的增加，未良好分离的 体系结构就会带来越大的成本。

从何处入手

? ? ?

用例建模与分析：对涉众关注点捕获的正确性和精确性是十分重要 的。用例建模与分析适用于任何软件开发，不管是面向方面、面向 对象还是其它的。建议针对基础结构服务编写用例。建议多练习， 编写出客户和开发团队都易于理解的有效用例。 设计和实现：用例切片、用例结构、AOP都比较新，需要学习如 何对aspect和用例切片进行建模，如何描述Pointcut。建议选择一 个适用该方法解决的特定关注点。通过用例来描述它，并从此驱动 到编码、测试的全过程。 测试：基于用例切片，可以很轻松地 将测试引入的控制和工具代码轻松地 去除。

在项目的不同阶段采用

? ? ? ? ?

计划阶段：很容易着手，从需求开始，从头贯穿AOSD； 细化阶段前期：已经完成了一部分迭代，有一些可以工作的用例和 几个基础结构服务，则可以在没有开发的部分上应用用例切片，对 已开发的基础结构服务可以考虑重新设计用例切片是否有价值； 细化阶段后期：如果已有一个可靠的架构，基本上不建议做修订和 改变。但可以考虑用参数化pointcut来帮助你把基础结构服务和平 台特性融合到系统中。还可以使用AspectJ来判断层和包之间是否 存在依赖注入。 构建阶段：如果项目接近尾声，不必有太大改变，可以考虑会该方 法进行测试。 完善阶段：可以用来对原系统更好的进行扩展。

议题
系统边界与上下文关系 人、机职责的划分 人 机职责的划分 分层描述 用户界面处理

系统边界与上下文关系
原型法与系统边界 系统边界与上下文

人、机职责的划分
职责驱动法 人、机分离 人 机分离

分层描述
产品目标层：范围限定 领域层：用户与系统的交互（任务级） 领域层 用户与系统的交 （任务级） 对话层：完成某一任务（事务）的具体( 操作)过程

用户界面处理
需求阶段的界面处理 规划阶段的界面处理 规划阶段的界面处

非功能需求
用户总是强调确定他们的功能、行为或需 求—软件让他们做的事情。除此之外，用 求 软件让他们做的事情 除此之外 用 户对产品如何良好地运转抱有许多期望。 这些特性包括：产品的易用程度如何，执 行速度如何，可靠性如何，当发生异常情 况时，系统如何处理。这些被称为软件质 量属性(或质量因素)的特性是系统非功能 （也叫非行为）部分的需求。

质量属性是很难定义的，并且他们经常造成 开发者设计的产品和客户满意的产品之间的 差异。就像指出的那样：“真正的现实系统 中，在决定系统的成功或失败的因素中，满 足非功能需求往往比满足功能需求更为重 要”。优秀的软件产品反映了这些竞争性质 量特性的优化平衡。如果你在需求的获取阶 段不去探索客户对质量的期望，那么产品满 足了他们的要求，这只能说你很幸运。但更 多的可能是客户失望和开发者沮丧。

质量属性
根据不同的设计可以把质量属性分类。一种属性 分类的方法是把在运行时可识别的特性与那些不 可识别的特性区分开.另一种方法是把对用户很重 要的可见特性与对开发者和维护者很重要的不可 见特性区分开。 那些对开发者具有重要意义的属性使产品易于更 改、验证，并易于移植到新的平台上，从而可以 间接地满足客户的需要。

在表中，分两类来描述每个项目都要考虑的质量属 性；还有其它许多属性。 些属性对于嵌入式系统 性；还有其它许多属性。一些属性对于嵌入式系统 是很重要的（高效性和可靠性），而其它的属性则 用于主机应用程序（有效性和可维护性）或桌面系 统（互操作性和可用性）。在一个理想的范围中， 每一个系统总是最大限度地展示所有这些属性的可 能价值。系统将随时可用，决不会崩溃，可立即提 供结果，并且易于使用。因为理想环境是不可得到 的，因此，你必须知道表中那些属性的子集对项目 的成功至关重要。然后，根据这些基本属性来定义 用户和开发者的目标，从而产品的设计者可以作出 合适的选择。

对用户最重要的属性
有效性（ a v a i l a b i l i t y） 高效性( 高效性 e fficiency) 灵活性( f l e x i b i l i t y ) 完整性(integrity) 互操作性( i n t e r o p e r a b i l i t y ) 可靠性( r e l i a b i l i t y ) 健壮性( r o b u s t n e s s ) 可用性( u s a b i l i t y )

对开发者最重要的属性
可维护性( m a i n t a i n a b i l i t y ) 可移植性( p o r t a b i l i t y ) 移植性 可重用性( r e u s a b i l i t y ) 可测试性( t e s t a b i l i t y )

定义质量属性
在一个项目中，分析员想出了对于不同的用 户类可能很重要的属性，并根据每一个属性 户类可能很重要的属性 并根据每 个属性 设计出许多问题。他们利用这些问题询问每 一个用户类的代表，可以把每个属性分成一 级（不必多加考虑的属性）到五级（极其重 要的属性）。这些问题的回答有助于分析员 决定哪些质量特性用作设计标准是最重要的 决定哪些质量特性用作设计标准是最重要的。

分析员与用户一起为每一属性确定特定的、可测量的和可验证 的需求（ R o b e r t s o n and Robertson 1997）。如果质量 目标不可验证，那么就说不清你是否达到这些目标。在合适的 地方为每一个属性或目标指定级别或测量单位，以及最大和最 小值。如果你不能定量地确定某些对你的项目很重要的属性， 那么至少应该确定其优先级。I E E E关于软件质量度量方法 的标准提出了一个在综合质量度量基准体系下定义软件质量需 求的方法（ IEEE 1992）。

另一个定义属性的方法是确定任何与质量期望相冲 突的系统行为（ Voas 1999）。通过定义不悦人意 行为—一种反向需求—你可以设计出强制系统表现 出那些行为的测试用例。如果你不能强制系统，那 么你可能达到了你的属性目标。这种方法最适用于 要求安全性能很高的应用程序，在这些应用程序中， 系统的差错可能会导致生命危险。

对用户重要的属性(8-1)
有效性
有效性指的是在预定的启动时间中，系统真正可用并且完 全运行时间所占的百分比。更正式地说，有效性等于系统 的平均故障时间（ M T T F）除以平均故障时间与故障修复 时间之和。有些任务比起其它任务具有更严格的时间要求， 此时，当用户要执行一个任务但系统在那一时刻不可用时， 用户会感到很沮丧。询问用户需要多高的有效性，并且是 否在任何时间，对满足业务或安全目标有效性都是必须的。 一个有效性需求可能这样说明：“工作日期间，在当地时 间早上6点到午夜，系统的有效性至少达到9 间早上 点到午夜 系统的有效性 少达到 9 . 5 %，在下 在下 午4点到6点，系统的有效性至少可达到9 9 . 9 5 %。

对用户重要的属性(8-2)
效率
效率是用来衡量系统如何优化处理器、磁盘空间或通信带 宽的（ Davis 1993）。如果系统用完了所有可用的资源， 那么用户遇到的将是性能的下降，这是效率降低的一个表 现。拙劣的系统性能可激怒等待数据库查询结果的用户， 或者可能对系统安全性造成威胁，就像一个实时处理系统 超负荷一样。为了在不可预料的条件下允许安全缓冲，你 可以这样定义：“在预计的高峰负载条件下， 1 0 %处理器 能力和1 5 %系统可用内存必须留出备用。”在定义性能、 能力和效率目标时，考虑硬件的最小配置是很重要的。 能力和效率目标时 考虑 件的最小配置是很重要的

对用户重要的属性(8-3)
灵活性
就像我们所知道的可扩充性、增加性、可延伸性和可扩展 性一样，灵活性表明了在产品中增加新功能时所需工作量 的大小。如果开发者预料到系统的扩展性，那么他们可以 选择合适的方法来最大限度地增大系统的灵活性。灵活性 对于通过一系列连续的发行版本，并采用渐增型和重复型 方式开发的产品是很重要的。在我曾经参与的一个图形工 程中，灵活性目标是如下设定的：“一个至少具有6个月产 品支持经验的软件维护程序员可以在一个小时之内为系统 添加一个新的可支持硬拷贝的输出设备。” 添加 个新的 支持 拷 的输出设备 ”

对用户重要的属性(8-4)
完整性
完整性（或安全性）主要涉及：防止非法访问系统功能、防止数据丢失、 防止病毒入侵并防止私人数据进入系统。完整性对于通过W W W执行的 防止病毒入侵并防止私人数据进入系统 完整性对 执行的 软件已成为一个重要的议题。电子商务系统的用户关心的是保护信用卡信 息， We b的浏览者不愿意那些私人信息或他们所访问过的站点记录被非 法使用。完整性的需求不能犯任何错误，即数据和访问必须通过特定的方 法完全保护起来。用明确的术语陈述完整性的需求，如身份验证、用户特 权级别、访问约束或者需要保护的精确数据。一个完整性的需求样本可以 这样描述：“只有拥有查账员访问特权的用户才可以查看客户交易历史。”

对用户重要的属性(8-5)
互操作性
互操作性表明了产品与其它系统交换数据和服务 的难易程度。为了评估互操作性是否达到要求的 程度，你必须知道用户使用其它哪一种应用程序 与你的产品相连接，还要知道他们要交换什么数 据。“化学制品跟踪系统”的用户习惯于使用一 些商业工具绘制化学制品的结构图，所以他们提 出如下的互操作性需求： 化学制品跟踪系统应 出如下的互操作性需求：“化学制品跟踪系统应 该能够从C h e m i D r a w和C h e m – S t r u c t 工具中导入任何有效化学制品结构图。”

对用户重要的属性(8-6)
可靠性
可靠性是软件无故障执行一段时间的概率.健壮性 可靠性是软件无故障执行 段时间的概率 健壮性 和有效性有时可看成是可靠性的一部分。衡量软 件可靠性的方法包括正确执行操作所占的比例， 在发现新缺陷之前系统运行的时间长度和缺陷出 现的密度。根据如果发生故障对系统有多大影响 和对于最大的可靠性的费用是否合理，来定量地 确定可靠性需求。如果软件满足了它的可靠性需 确定可靠性需求 如果软件满足了它的可靠性需 求，那么即使该软件还存在缺陷，也可认为达到 其可靠性目标。要求高可靠性的系统也是为高可 测试性系统设计的。

对用户重要的属性(8-7)
健壮性
健壮性指的是当系统或其组成部分遇到非法输入 数据、相关软件或硬件组成部分的缺陷或异常的 操作情况时，能继续正确运行功能的程度。健壮 的软件可以从发生问题的环境中完好地恢复并且 可容忍用户的错误。当从用户那里获取健壮性的 目标时，询问系统可能遇到的错误条件并且要了 解用户想让系统如何响应。 解用户想让系统如何响应

对用户重要的属性(8-8)
可用性
可用性也称为 易用性 和 人类工程 ，它所描述的是 可用性也称为“易用性”和“人类工程”，它所描述的是 许多组成“用户友好”的因素。可用性衡量准备输入、操 作和理解产品输出所花费的努力。你必须权衡易用性和学 习如何操纵产品的简易性。“化学制品跟踪系统”的分析 员询问用户这样的问题：“你能快速、简单地请求化学制 品并浏览其它信息，这对你有多重要？”和“你请求一种 化学制品大概需花多少时间？”对于定义使软件易于使用 的许多特性而言，这只是一个简单的起点。对于可用性的 讨论可以得出可测量的目标，例如“一个培训过的用户应 论 出 的 标 例如 个培训 的 户应 该可以在平均3分钟或最多5分钟时间以内，完成从供应商 目录表中请求一种化学制品的操作。”

对开发者重要的属性(4-1)
可维护性
可维护性表明了在软件中纠正一个缺陷或做一次 可维护性表明了在软件中纠正 个缺陷或做 次 更改的简易程度。可维护性取决于理解软件、更 改软件和测试软件的简易程度，可维护性与灵活 性密切相关。高可维护性对于那些经历周期性更 改的产品或快速开发的产品很重要。你可以根据 修复（ f i x）一个问题所花的平均时间和修复正 确的百分比来衡量可维护性。 确的百分比来衡量可维护性

对开发者重要的属性(4-2)
可移植性
可移植性是度量把一个软件从一种运行环境转移 可移植性是度量把 个软件从 种运行环境转移 到另一种运行环境中所花费的工作量。软件可移 植的设计方法与软件可重用的设计方法相似 （ Glass 1992）。可移植性对于工程的成功是不 重要的，对工程的结果也无关紧要。可以移植的 目标必须陈述产品中可以移植到其它环境的那一 部分，并确定相应的目标环境。于是，开发者就 部分 并确定相应的目标环境 于是 开发者就 能选择设计和编码方法以适当提高产品的可移植 性。

对开发者重要的属性(4-3)
可重用性
从软件开发的长远目标上看，可重用性表明了 个软件组 从软件开发的长远目标上看，可重用性表明了一个软件组 件除了在最初开发的系统中使用之外，还可以在其它应用 程序中使用的程度。比起创建一个你打算只在一个应用程 序中使用的组件，开发可重用软件的费用会更大些。可重 用软件必须标准化、资料齐全、不依赖于特定的应用程序 和运行环境，并具有一般性（ DeGrace and Stahl 1993）。 确定新系统中哪些元素需要用方便于代码重用的方法设计， 或者规定作为项目副产品的可重用性组件库。

对开发者重要的属性(4-4)
可测试性
可测试性指的是测试软件组件或集成产品时查找 缺陷的简易程度。如果产品中包含复杂的算法和 逻辑，或如果具有复杂的功能性的相互关系，那 么对于可测试性的设计就很重要。如果经常更改 产品，那么可测试性也是很重要的，因为将经常 对产品进行回归测试来判断更改是否破坏了现有 的功能性。 的功能性

属性的取舍
有时，不可避免地要对一些特定的属性对进行取舍。 用户和开发者必须确定哪些属性比其它属性更为重 要，并定出优先级。在他们作决策时，要始终遵照 那些优先级。图描述了来自表11 – 1的质量属性之间 一些典型的相互关系，当然你也可能会遇到一些例 外。一个单元格中的加号表明单元格所在行的属性 增加了对其所在列的属性的积极影响。例如，增强 软件可重用性的设计方法也可以使软件变得灵活、 更易于与其它软件组件相连接、更易于维护、更易 于移植并且更易于测试。

一个单元格中的减号表明单元格所在行的属性增加了对其所在 列的属性的不利影响。高效性对其它许多属性具有消极影响。 如果你编写最紧凑，最快的代码，并使用一种特殊的预编译器 和操作系统，那么这将不易移植到其它环境，而且还难于维护 和改进软件。类似地，一些优化操作者易用性的系统或企图具 有灵活性、可用性并且可以与其它软硬件相互操作的系统将付 出性能方面的代价。例如，比起使用具有完整的制定图形代码 的旧应用系统，使用外部的通用图形引擎工具生成图形规划将 大大降低性能。你必须在性能代价和你所提出的解决方案的预 期利益之间作出权衡，以确保作出合理的取舍。 期利益之间作出权衡 以确保作出合理的取舍

选择的质量属性之间的正负关系

引言
你的工程应该有个好的起点。一个小组要带领客户 进入需求启发阶段而且你要写软件需求说明书。这 份说明有些大，但客户会很重视，所以说明必须得 到赞同。 现在你正在设计其中的一个特性，已经发现了需求 的一些问题。你可以用多种不同的方式解释需求15； 需求9 的说明正好与需求21相反，你因该相信哪一 个？需求24非常含糊，你根本不明白它的意思；你 不得不花上 个小时与2位开发人员讨论需求30， 不得不花上一个小时与2位开发人员讨论需求30， 只因为你们对其各有各的理解；并且，唯一能够澄 清这些问题的客户没有给你们答复。你被迫破解众 多需求的含义，并且你能预料到，如果你错了，你 要做大量的重复工作。

问题
许多软件需求说明书（SRS）写得非常糟糕。任何 产品的质量需要其原始材料的质量保证，糟糕的软 件需求说明书不可能产出优秀的软件。不幸的是， 几乎没有开发人员受过与需求的抽象、分析、文档、 质检有关的教育。而且，没有非常多的好需求可以 借鉴学习，部分原因是很少有工程可以找到一个好 的借鉴，其他原因是公司不愿意将其产品说明书放 在公共区域。 不要期望能够编写出 份能体现需求应具备的所有 不要期望能够编写出一份能体现需求应具备的所有 特性的SRS。无论你怎么细化、分析、评论和优化 需求，都不可能达到完美。但是，如果你牢记这些 特性，你就会编写出更好的需求，生产出更好的产 品。

高质量需求叙述的特性
我们如何从一些有问题的需求中分辨出好的 软件需求？需求叙述应体现的6个特性，判 软件需求？需求叙述应体现的6个特性 判 断每个需求是否具备应有的特性的一种方式 是由持有不同观点的工程资金管理人所作的 正规检查。另一种有力的方法是在编写代码 前依据需求编写测试例子。测试例子能够明 确显现在需求中描述的产品行为（特性）， 能够显现缺陷、冗余和含糊之处。

高质量需求叙述的特性(6-1)
正确：每个需求必须精确描述要交付的功能。 正确性依据于需求的来源，如真实的客户或 高级别的系统需求说明书。一个软件需求与 其对应的系统需求说明书相抵触是不正确的 （当然，系统需求说明书本身可能不正确）。 只有用户的代表能够决定用户需求的正确性， 这就是为什么在检查需求时，要包括他们或 他们的代理的关键所在。不包括用户的需求 他们的代理的关键所在 不包括用户的需求 检查就会导致开发人员的：“这是没意义 的”，“这可能是他们的意思”等众所周知 的猜测。

高质量需求叙述的特性(6-2)
可行性：在已知的能力、有限的系统及 其环境中每个需求必须是可实现的。为了 其环境中每个需求必须是可实现的 为了 避免需求的不可行性，在需求分析阶段应 该有一个开发人员参与，在抽象阶段应该 有市场人员参与。这个开发人员应能检查 在技术上什么能做什么不能做，哪些需要 需要额外的付出或者和其他的权衡。 需要额外的付出或者和其他的权衡

高质量需求叙述的特性(6-3)
必要性：每个需求应载明什么是客户确实需 要的，什么要顺应于外部的需求，接口或标 准。每个需求源于你认可、具有权说明需求 的原始资料，这是考虑必需的另外情形，跟 踪每个需求回溯到出处，如用例，系统需求， 规章，或来自其他用户的意见。如果你不能 标识出处，可能需求只是个镀金的例子，没 有真正的必须。

高质量需求叙述的特性(6-4)
优先权：为了表明在一个详细的产品版本中应包含 哪些要点，需要为每个需求，特征，或用例分配实 现的优先权。客户或其代理都应有强烈的责任建立 优先权。如果所有的需求都被视为同等重要，那么 由于在开发中，预算削减，计划超时或组员的离开 导致新的需求时， 项目经理将不能起到作用。优先 权的作用是提供给客户的价值，实现的相关费用， 实现相关联的有关技术风险。 我是用3种级别的优先权：高优先权表明需求必须 体现在下一个产品版本中，中优先权表明需求是必 须的，但是如果需要可以推迟到晚一些的产品版本 中，低优先权表明有它很好，但我们必须认识到如 果没有充足的时间或资源，它可以被放弃掉。

高质量需求叙述的特性(6-5)
明确：需求叙述的读者应只能从其得到唯一 的解释说明 同样 的解释说明，同样，一个需求的多个读者也 个需求的多个读者也 应达成共识。自然语言极易导致含糊。要避 免使用一些对于SRS作者很清楚但对于读者 不清楚的主观词汇，如：用户友好性，容易， 简单，快速，有效，几个，艺术级，改善的， 最大，最小等等。每写一个需要都应简洁， 简单，直观的采用用户熟知的语言，不要采 用计算机术语。检查需求模糊的有效方式包 用计算机术语 检查需求模糊的有效方式包 括需求说明书的正规检查，根据需求写测试， 建立用户的假想来说明产品某个特定部分预 期的特性。

高质量需求叙述的特性(6-6)
可证实：看你是否能够做出测试计划或 其他验证方式，如检查和实证，来决定在 其他验证方式 如检查和实证 来决定在 产品中每个需求是否正确的实现。如果需 求是不可验证的，决定需求是不是正确的 实现就成了判断的事。需求之间不一致， 不可行，不明确也能导致不可证实。任何 需求如果说产品将要支持什么也是不可证 实的。

高质量需求说明的特征
一个完整的SRS不仅是包括长长的功能 性需求列表，还包括外部接口描述和一些 性需求列表 还包括外部接口描述和 些 诸如质量属性，期望性能的非功能性需求。 下面描述了高质量的SRS的一些特性。

高质量需求说明的特征(4-1)
完整：不应该遗漏要求和必需的信息。完整性也是 一个需求应具备的。发现缺少的信息很难，因为根 本不存在。在SRS中将需求以分层目录方式组织， 将帮助评审人员理解功能性描述的结构，使他们很 容易指出遗失的东西。 在需求抽象时，相对于系统功能，你过多的注意用 户的业务，将导致在需求的全局观和引进不是真正 必需的需求上显得不足。在需求抽象上，应用用例 方法会发挥很好的作用。能够从不同角度察看需求 的图形分析模型也可以检查出不完整性。 如果你知道已缺少一些信息，使用TBD（to be determined）标准标志可以突出这些缺陷，当你在 构建产品的相关部分时，就可以从一个给定的需求 集中解决所有的缺陷。

高质量需求说明的特征(4-2)
一致性：一致性需求就是不要于其他的 软件需求或高级别的系统（商业）需求发 生冲突。需求中的不一致必须在开发开始 前得到解决。只有经过调研才能确定哪些 是正确的。修改需求时一定要谨慎，如果 只审定修改的部分，没有审定于修改相关 的部分，就可能导致不一致性。 的部分 就可能导致不 致性

高质量需求说明的特征(4-3)
可修改性：当每个需求的要求修改了或 维护其历史更改时，你必须能够审定 维护其历史更改时 你必须能够审定 SRS。也就是说每个需求必须相对于其 他需求有其单独的标示和分开的说明，便 于清晰的查阅。通过良好的组织可以使需 求易于修改，如：将相关的需求分组，建 立目录表，索引，以及前后参考（照）。 立目录表 索引 以及前后参考（照）

高质量需求说明的特征(4-4)
可追踪：你应能将一个软件与其原始材 料相对应，如高级系统需求，用例，用户 料相对应 如高级系统需求 用例 用户 的提议等。也能够将软件需求与设计元素， 源代码，用于构造实现和验证需求的测试 相对应。可追踪的需求应该具有独立标示， 细密和结构化的编写，不应过大，不应是 叙述性的文字和公告式的列表。 叙述性的文字和公告式的列表

需求质量的评审
这些有关需求质量的特性的描述在理论上都 是非常好的，但 个好的需求到底是个什么 是非常好的，但一个好的需求到底是个什么 样子的呢？为了体现得更切合实际，我们做 个小练习。下面有几个从实际的工程选出的 需求，依据上面的质量标准，评估每个需求， 看看有什么问题，然后用更好的方式重写。 我将对每个例子都提出自己的分析和改进的 建议。也欢迎你提出不同的见解。我所占优 建议 也欢迎你提出不同的见解 我所占优 的只是我知道每个需求的出处。因为你我都 不是真正的客户，我们只能猜测每个需求的 意图。

需求质量的评审-案例（1）
例1．“产品应在不少于每60秒的正常周期内提供状态信息” 这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求 有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不 少于60秒？，甚者每10年显示一条新的状态信息也可以？也许它的 意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个 词导致了不确定性。问题的后果，就是需求的不可证实。弥补缺陷， 重写需求的一种方法：
1、状态信息 1.1后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面 的指定位置显示状态信息 1.2如果后台进程处理正常，那么应该显示任务已完成的百分数/比 1 2如果后台进程处理正常 那么应该显示任务已完成的百分数/比 1.3任务完成时，应显示相关的信息 1.4后台任务出错应该显示错误信息

为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接 在一节中，在构造和测试时就很容易漏掉一个。

需求质量的评审-案例（2）
例2．“产品应瞬间在显示和隐藏不可打印字符间切换” 计算机在瞬间不能做任何事 所以这个需求不切实可行 它的 计算机在瞬间不能做任何事，所以这个需求不切实可行。它的 不完整性表现在没有声明触发状态切换的条件。软件要在某些 条件下更改自己？或者用户为了模仿更改要做一些动作？而且， 在文档中改变显示的范围是多大：选中的文本，整个的文档， 或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一 样吗？或者是一些属性标志或一些控制字符？问题的后果，就 是需求的不可证实。 象这样编写需求也许更好一些：“用户能够在一个由特定触发 条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切 条件激活处于编辑的文档中在显 和隐藏所有 标记间切 换”。现在就很清楚，不可打印字符是HTML标记。由于没有 定义触发条件，需求对设计没有约束力。只有设计人员选定了 触发条件后，你才能编写测试验证触发的正确操作。

需求质量的评审-案例（3）
例3．“HTML分析器可以产生HTML标记错误报告， 帮助HTML入门者快速解决错误 。单词 快速 帮助HTML入门者快速解决错误”。单词“快速” 使其模糊，没有加进错误报告的定义也是其部完整。 我不知道，你怎么验证这个需求。找一个自称为 HTML的入门者，看看能不能根据错误报告快速解 决错误？ 试试这个：“HTML分析器可以产生一个错误报告， 错误报告包含有在被分析文件中出错的HTML文本 和行号以及错误的描述。如果没有错误，就不会产 生错误报告”。现在我们知道了，什么会被加到出 错报告中，但是出错报告是个什么样子，则留由设 计人员决定。我们还指定了一个例外：如果没有发 现错误，不产生错误报告。

需求质量的评审-案例（4）
例4．“如果可能，主管号码应通过联机校验，而不是通过主 全体主管号码列表校验”。真感到绝望，什么是“如果可能”： 如果技术上可行？如果主全体主管号码列表可以联机获得？要 避免象“应该”的这类不确切的词。客户是需要这个功能性还 是不需要。我曾看过一些需求说明书，采用诸如：应，将，应 该/将要等一些词描述优先级的细微差别。但我更喜欢用“应” 清楚的说明需求的意图，指明优先级。这是修改后的：系统应 校验输入的主管号码而不通过联机的主全体主官号码列表。如 果在列表中没有发现主管号码，将会显示一条错误信息，也不 接受指令。 接受指令 在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是： 开发人员与客户将会在审核需求，未达成共识前发生激烈的争 论。详细检查大的需求文档不是一件轻松的事情。我清楚有人 做过，而且他们花在检查上的每一分钟都是值得的。相对于开 发阶段和用户的抱怨电话，在这个阶段修补缺陷是便宜的，

编写质量需求的方针
编写优秀的需求是没有公式化的方法的。 这需要大量的经验，要从你在过去的文档 这需要大量的经验 要从你在过去的文档 中发现的问题学习。请在组织软件需求文 档时，严格遵从这些方针。

编写质量需求的方针(6-1)
句子和段落要短。采用主动语气。使用正确 的语法，拼写，标点。使用术语，要保持 的语法 拼写 标点 使用术语 要保持一 致性，并在术语表或数据字典中定义它们

编写质量需求的方针(6-2)
要看需求是否被有效的定义，可以以开发人 员的观点看看。在内心将 当你们做完了找 员的观点看看 在内心将“当你们做完了找 我”这句加到文档尾部，看看能不能是你紧 张起来。换句话说，你是否需要SRS的编写 者的额外解释帮助开发人员很好的理解需求， 以便于设计和实现？如果是的话，在继续工 作前，需求还需要细化。

编写质量需求的方针(6-3)
需求编写者还要努力正确地把握细化程度。 要避免包含多个需求的长的叙述段落。有帮 要避免包含多个需求的长的叙述段落 有帮 助的提示是编写独立的可测试的需求。如果 你认为一小部分测试可以验证一个需求的正 确，那么它已经正确的细化了。如果你预想 到多种不同类的测试，几个需求可能已挤到 了一起，需要拆分开。

编写质量需求的方针(6-4)
密切关注多个需求合成了单个需求。一个需 求中的连接词 和 / 或 建议几个需求合并。 求中的连接词“和”/“或”建议几个需求合并 不要在一个需求中使用“和”/“或”。

编写质量需求的方针(6-5)
通篇文档细节上要保持一致。我曾看见过多 个需求说明书前后不 致。如： 对于红色 个需求说明书前后不一致 如：“对于红色 合法的颜色代码应是R”及“对于绿色合法的 颜色代码应是G”就有可以以分散的需求分离 开，而“产品应能对来自语音编辑指示做出 反应”应作为一个子系统，不应作为单个的 功能性需求。

编写质量需求的方针(6-6)
避免在SRS中过多的申述需求。在多处包含 相同的需求可以使文档更易于阅读，但也会 相同的需求可以使文档更易于阅读 但也会 给文档的维护增加困难。文档的多份文本要 在同一时间内全部更新，避免不一致性。

编写质量需求的方针
如果你遵从了这些方针，你能够尽早地经 常正式或非正式的审查需求，这些需求对 常正式或非正式的审查需求 这些需求对 于产品的构造，系统测试以及最后的客户 满意，都会成为好的奠基石。并且要记住， 没有高质量的需求，软件就象一盒巧克力， 你永远不知道你会得到什么。

企业建模，是一种全新的企业经营管理模式， 它可为企业提供一个框架结构，以确保企业 它可为企业提供 个框架结构 以确保企业 的应用系统与企业经常改进的业务流程紧密 匹配。企业建模以分析方法和建模工具为主 体，其参考模型的建立以及建模工具的研制， 是当前帮助企业 不断缩短产品开发时间 ( (Time)、提高产品质量(Quality)、降低成本 ) 提高产品质量(Q y) 降低成本 (Cost)、提高服务层次(Service)的重要手段。

残酷的市场竞争是现在几乎所有企业面临的最大挑战，同时也 给善于运用科学手段完善经营管理体制的企业带来了机会。为 了在市场竞争中获得更高的回报，很多企业都在进行不断的内 部改造，由此产生了诸如JIT（Just In Time：准时生产制）、 TQM（Total Quality Management：全面质量管理）、TCM （Time Compress Management：时间压缩管理）、FCR （Fast Cycle Response：快速反应周期）等等经营管理体系， 为了实施这些理论，MRP、ERP、MRP II、CIMS被更多的企 业认知并运用，但是在添置计算机、架构自己的企业网络、采 购大型数据库系统和先进设备后，企业并没有获得预期的效益。 购大型数据库系统和先进设备后 企业并没有获得预期的效益

管理体制在不断的变化，管理思想体系在几轮冲刷后也得到升 华。现在，BPR （Business Process Re-Engineering：业务 流程再造）体系被越来越多的企业采用，于是，如何适应企业 在实施BPR时诱发的业务不断变化和持续发展，成为经营管 理方法是否科学有效的关键。 从企业组织形态上看，企业是由不同业务部门组成的，换一个 角度从企业业务环节上看，企业包括复杂的业务流转系统（由 供应链子系统、客户关系管理子系统等构成）、 设计系统、 生产制造系统，企业的业务环节中存在大量的信息作为其运行 基础，而不同的信息又在不同的业务环节中发挥不同的作用。 基础 而不同的信息又在不同的业务环节中发挥不同的作用 就目前而言，我们要分析这个复杂的系统，除了需要企业的经 营管理者和研究人员付出激情、勇气、智慧和耐心外，更需要 借助科学的手段、有效的数学工具和先进的计算技术，来构造 一个可以解释和反映企业外部行为表现及内在本质的模型。

模型是人们为了方便研究、理解和解决客观世界中存在的种种 问题而对客观现实经过反复思维抽象后的文字、图表、符号、 关系式以及实体模样的集合，以描述所认识到的客观事物的一 种直观表现形式。模型的构造以及构造模型的目的都是为了研 究问题的需要，它们都是为了满足研究者在某个研究问题上的 需要而建立的，是为了帮助人们对问题进行分析和研究。根据 模型理论的定义，模型主要有四种基本表示形式，它们分别是： 形象模型 数学模型 模拟模型 其他模型

在具体的一个问题分析过程中建立什么样的模型完全由研究者 根据研究的需要和是否方便来决定， 因此，我们不难看出， 模型不是客观事物的具体表现，它仅仅是客观事物经过抽象的 简化的表示，另外建立模型的目的是为了解决客观事物中存在 的问题，而不仅仅是为了描述客观事物。 企业建模，就是引入模型理论，以模型结构为依据，把企业的 业务划分为增值业务、衍生增值业务、增值业务伴生业务和非 增值业务四大类，以企业业务环节为核心，建立一个整体的参 考模型， 简化企业业务流程和降低生产成本，运用信息技术 实现企业信息（信息，不是数据）的共享，将企业生产流程中 实现企业信息（信息 不是数据）的共享 将企业生产流程中 定义的团队、组织、管理、技术及信息、物料、资金、价值等 因素高度抽象和集成优化，从而为企业带来更高的附加价 值。

企业建模分析方法
企业建模的第一大主体是分析方法，主要研究对象是企业信 息系统的参考模型。 分析是将复杂的企业信息合理的整理、加工、归纳、抽象，简 化内涵，分解成相对简单的元素（我们之所以要提取元素而不 提取要素，是因为业务要件在分析方法中所发挥的作用是未知 的），找出这些元素的根本属性和彼此之间的关联。从系统工 程理论中不难看出，一个企业之所以成为一个系统，是因为企 业是一个用诸多元素组成的整体，这些元素相互关联、相互制 约、相互影响、相互作用，有时又相互排斥，于是就导致了企 业系统无限复杂、无穷变化和来源于系统根源的不确定性。 业系统无限复杂 无穷变化和来源于系统根源的不确定性

数学模型分析法
数学模型分析法是最传统、最普遍和最常 见的分析方法，这个方法更容易被企业管 见的分析方法 这个方法更容易被企业管 理研究者实施和被企业经营管理者接受， 在运用这种方法的时候，通常要经历五个 阶段：

企业系统诊断：通过对企业现存管理体系的具体分析，发现问题并将问题追 溯到问题的起始阶 段，找到问题的根源，得到业务建模中所需要的目标元 素。 企业元素抽象：将元素进行分类、归纳处理，罗列这些处理后的结果并进行 抽象定义。 元素权重定义 ：抽象元素通常定性容易定量难，而数学模型中的元素是需要 量化的，元素的权 重在这种分析方法中变的十分重要。 通过对业务元素的 再理解和再认识，在分析体系的协同作用下，为每一元素评 分，合理定义 元素在整个业务中所占的比重，这些经过权重定义的元素，将决定业 务建 模中业务环节的作用绩效。 数学模型运算：建立N组数学模型集合，对每一组模型进行定义评价，找出一 组或几组适合业务 建模目标的模型 并通过再论证 将带有权重符号的业 建模目标的模型，并通过再论证。将带有权重符号的业 务元素导入数学模型中进行 运算，得出分析结果。 在很多的情况下，数学 运算会得到一组解，这时，我们选择的解不是最优解而 应该是满意解。 分析结果校正 ：一组满意解的集合，我们需要进行反复的结果校正，根据企 业系统的实际情况 修正其中的参数，使最终结果更接近目标值。

简单逻辑分析法
简单逻辑分析法是业务建模中比较直观的一种分析 方法，这种方法打破传统企业建模分析法的程序化， 是最快捷的企业建模分析方法。它采用最简单的手 段描述企业复杂系统中的构造逻辑。首先，它将业 务元素归纳为几种信息或几种流的集合，这个集合 在被定义为一个个相互独立又相互关联的业务环节 和功能环节后被完全逻辑化，用逻辑公式来表达集 合中元素间的关系，通过逻辑关系表来显现业务逻 辑，从而构造出结构清晰易于理解的业务模型。

相对参照分析法
任何客观事物都具有两面性，相对参照分析法就是运用来这个 理论，具体描述企业业务环节中两面性，对所有元素属性的排 列组合，构造出一个企业模型矩阵，矩阵中的每一个元素就是 一个企业模型，这些元素没有任何的关联，只有在对该矩阵进 行复杂的运算后，才可能得出一组符合企业现行管理体系的企 业模型。 矩阵中提取的结果是互为参照的，它们之间的关联程度较高且 具备一定的特质，此时，通过客观和主观的相对参数比较，不 难得出几个企业模型方案，而最终的企业模型，是在多方案中 难得出几个企业模型方案 而最终的企业模型 是在多方案中 选择出最优化的方案。

量子模型分析法
量子模型分析法，是目前最贴近现代计算工具设计理论的分析 方法，这个方法将企业描述为一个”黑洞”，以解决企业业务信 息”在黑洞中丢失”现象为主要目的，通过透视业务环节和业务 功能中微妙的信息化带来的巨大效应的同时，构造反常规的抽 象量子模型，并对预定义的量子模型进行执行评估和重复引用， 重现信息变化的效应，从而实现业务模型效用最大化。 量子模型分析法，之所以将企业描述为”黑洞”，不仅仅是因为 企业的能量无法估量，更主要是企业的功能效应无法量化，其 延续时间和衍射范围只能引入”单位时间”和”惯性质量”来进行 衡量，由此而产生宏观元素更不容易为传统企业管理方法所包 衡量 由此而产生宏观元素更不容易为传统企业管理方法所包 容，同时也说明了企业业务的无限复杂和持续变化，这才是保 证企业可持续发展的根本。

信息之所以”在黑洞中丢失”，是因为企业”黑洞”存在 巨大的能量，并且 黑洞 巨大的能量，并且”黑洞” 在状态系统上进行着频繁 的非一元变化，业务信息丢失的事实反映在企业所 发出辐射的”热特性”上，事实上任何热系统都可通 过吉普斯（Gibbs）规则dE=S dT被赋予一个熵值。 这就说明黑洞的熵与信息丢失有关，关于这一现象， 简单的事实就是它们是稍有区别的同一件事情。 为 了解决这个问题，设想使信息能够依照”黑洞”的非 一元变化而变换，尽管它并不保持概率性（非一元 变化后，一次试验的所有可能结果的可能值之和会 大于1），我们仍然认为其可能性是存在的。

传统企业建模原理
传统建模系统体系结构是由三个重要部分构成的三维立方体。体系结 构的每个侧面描述企业建模关心的不同阶段、不同视图和不同的建模 构件的通用性程度 生命周期维：建立企业需求分析、系统设计、系统实施和运行维护四 阶段的建模方法学，并确定各阶段的研究重点和不同建模阶段之间的 模型映射方法。包含需求分析、系统设计、系统实施和运行维护四个 重要部分。 视图模型维：研究集成化的企业建模视图结构，该系统以过程视图 （工作流模型）为核心，其它视图（功能视图、信息视图、组织视图、 资源视图）为辅助视图来统一集成建模，最终形成具有一定柔性的动 态企业模型。 态企业模型 通用性层次维：研究不同建模阶段、不同建模视图的基本构件形式， 从而建立基本构件模型库，并以不同的行业为背景建立企业参考模型， 并在企业中建立专用的企业特定模型。

传统企业建模方法是企业经营管理人员对企业的抽 象及企业本身元素的具体概括和归纳，是为了描述 企业的所有特征（特质、属性、功能、交互、关联 等）而采取的途径、步骤和手段。通常由此产生的 企业模型可以被定义为一个具有相关企业公共特质 的描述模板，它的构造遵循一定行业、一定经营方 式、一定建模分析方法，这种模板在同一类行业的 企业建模过程中保留一定的参考、指导乃至直接应 用的价值。

各类企业建模体系介绍
国外在企业建模方面的研究已经开展多年，也取得 了丰富的研究成果。其中已GRAI/GIM方法、ARIS 体系结构、IDEF方法、CIMOSA方法、BAAN/DEM 方法最为常见.

CIM-OSA方法
CIM-OSA（Computer Integrated Manufacturing – Openness System Architecture）是由欧共体的22家公司和大学组成的 ESPRIT-AMICE组织经过六年多的努力而开发出的一个CIM开 放体系结构。其目的是提供一个面向CIM系统生命周期的、开 放式的CIM参考体系结构，从多个层次和多个角度反映了CIM 企业的建模、设计、实施、运行和维护等各个阶段，提供了 CIM系统描述、实施方法和支持工具，并形成了一整套形式化 体系。与其他CIM体系结构相比，CIM-OSA具有全面性、完 整性、开放性、标准化和形式化等优点，因而受到国际上的好 评，并成为国际准化组织的 项预标准。 评 并成为国际准化组织的一项预标准

ARIS方法
ARIS（Architecture of Integrated Information System）整合 性信息系统架构是由德国萨尔大学（University of the Saarland, Saarbrucken, Germany）企业管理研究所所长及 IDS－Scheer公司执行长的August－Wilhelm Scheer 教授所 提出的。其设计理念，是希望提出一个整合性的概念，目的是 把描述企业程序的所有基本观念通通纳入。因此可想见，所描 述出的模型必是非常庞大与复杂，为减少其复杂性，就必须依 不同的观点来切割这个复杂的模型。在一种观点下无数的交互 关系将被先省略，只专注于观点内的事物。之后各观点的模型 会整合成完整的分析，而不会有任何的重复。 会整合成完整的分析 而不会有任何的重复

IDE方法
IDEF方法是由美国KBSI提出一系列建模、分析、仿真方法的 统称。它主要由3种模型组成：功能模型（IDEF0），信息模 型（IDEF1X），和动态模型（IDEF2）。IDEF0是一种基于 功能分解的单元建模技术。在IDEF0中，一个盒子表示一个整 体功能，该功能是相关功能的一个集合， 而不只是一个单独 的活动。IDEF1用于生成一个信息模型，描述在该环境（或系 统）中的信息的结构和语义。IDEF1模型的构件是实体、联系 和属性。IDEF2用于产生制造系统随时间变化的各种行为的一 个描述，分析IDEF2描述可以获得制造系统用计算机仿真的系 统执行情况。 统执行情况

GRAI/GIM方法
GRAI （Graph with Results and Activities Interrelated）方法 是由法国Bordeaux第一大学提出的，是专门为在生产系统制 定决策而开发的。GRAI由一个生产系统由一个物理系统和一 个生产控制系统组成，物理系统是一组制造单元，其功能是将 原材料或部件转变为完成的部件或一个完成的产品。生产控制 系统制定决策，它由一个信息系统和一个决策系统组成。它基 于诸如定货、资源和能源等方面的信息制定决策，以便物理系 统执行其功能。GRAI的概念模型描述在信息系统、决策系统 和物理系统间的联系。信息系统是其它系统间连接的链条。 GRAI模型有 个层次化结构，因此在每 层，决策和信息都 GRAI模型有一个层次化结构 因此在每一层 决策和信息都 取决于执行的任务和制定决策过程所处的时间段。因此，必须 构造信息以满足每一层决策的制定。

BAAN/DEM动态企业建模方法
BAAN是一个为项目型、流程型以及离散型 产业提供企业资源计划（ERP）应用系统和 咨询服务的公司。 它利用关键组件 Orgware来实现动态企业建模DEM （Dynamic Enterprise Modeling）策略，进 而实现较为灵活而有效的经营管理运作。

什么是业务建模
业务建模（Business Modeling）是以软件模型方式 描述企业管理和业务所涉及的对象和要素、以及它 们的属性、行为和彼此关系，业务建模强调以体系 的方式来理解、设计和构架企业信息系统。 业务建模（Business Modeling）是一种建模方法的 集合，目的是对业务进行建模。这方面的工作可能 包括了对业务流程建模，对业务组织建模，改进业 务流程，领域建模等方面。

为什么要业务建模
Brooks 大师说，三十多年来各式各样的应 用系统（Application Programs AP）历经多 次的修修改改，已经变得面目全非，如同一 群的怪兽，难以驯服。 Rogerson大师也说，The application is a rock in the river of change.（应用（系统） 成为改变之潮流中的顽石）。

对很多企业而言，有一个统合企业各部门的信息系 统的心愿似乎已经成了 种奢望。企业中或多或少 统的心愿似乎已经成了一种奢望。企业中或多或少 都会有一些应用系统在辅助企业的自动化运作，当 企业信息主管希望能够对目前的信息系统进行整合， 能够配合企业的发展的时候，他们失望了。大多数 的应用缺乏一个统一的接口，难以进行整合。 在我们进行项目开发的银行中，我们也同样发现了 这个问题，不同部门的系统之间无法进行互联，跨 部门的业务流程必须经过手工的处理。

基于部门的功能的应用
以前，应用程序的开发都是基于部门的功能的而建 的。单纯只是为了解决目的而建立应用系统。所以 这种方式建立的应用系统是针对特定的功能区域 （Function Area）而建立的。 至于如何使企业内的多个应用系统共同运作，就不 在设计者的考虑之列了。随着企业的发展，就会发 现企业需要变化以适应市场变化，业务发展的时候， 原有的 系列应用系统却成了企业发展的拦路虎， 原有的一系列应用系统却成了企业发展的拦路虎， 这使得企业不得不回到手工的时代。

用例建模分析技术
针对这种情况，有没有相应的解决之道呢？解决的 方法就是从业务建模入手，而不是从较低层次（部 门级或以下）入手。 通过用例分析技术，建立企业的业务模型，进行适 当的切割，选取稳定的软件架构，分析出企业的业 务实体（Business Entity 企业中微小不可分的事 物，抽象或具体的，如帐户，契约等，又被称为 Business Object），以此为基础，组装出组件 （Component），落实到相应的三层结构，建立针对 特定功能区域的应用系统。

以这样的流程做出来的企业应用系统，不论规模是 部门级的，还是企业级的，都有扩展的余地。以组 件为基础的软件三层构架，也能够较好的配合企业 的业务变化而变化（相应变化的代价较小）。而整 个流程的第一步，就是业务建模。

在前一段时间，中国很流行企业流程再造BPR(Business Process Re-engineering)这个名词。 BPR这一名词中的R(Re-engineering)一词是由Dr. Hammer提 出，说明企业必须推动四个层面的重新设计：
Re-position、 Re-organization、 Re-system、 Re-vitalizing之再造工程；

名称中的P(Process)，更是管理上由销售、采购到财务、生产 各层次，力求降低成本、提高产出，所必须精密设计的企业管 各层次 力求降低成本 提高产出 所必须精密设计的企业管 理流程或程序。这个词目前都是和ERP串联在一起，成了 ERP的前置工程，更成为保证ERP能建立企业完美管理体系， 以支持高绩效的最重要因素。实际上呢，这个BPR就是我们 所谈到的业务建模。

可以看出，业务建模在ERP工程中被着重强调，而且ERP中 的BPR已经成为一门独立的学科。不仅如此，即便是在普通 的信息系统中，业务建模也是非常重要的，所不同的，仅仅是 它们的规模而已。这一点上，可能大家会不理解，如果你只是 为企业的业务自动化建立应用，直接照搬企业模式不就行了吗。 这里有两点原因，一是企业原有的业务模式在以人为主的环境 中可能运行的很好，可是把这套模式原本不动的搬到计算机上 就未必会适合了。人的能力和计算机的能力有很大的出入，所 以流程必须经过调整以适应计算机；第二个原因是上面已经提 到过的避免产生部门级的，部分功能区域的应用系统。 到过的避免产生部门级的 部分功能区域的应用系统

在RUP中，业务建模被作为下游流程的输 入重点强调：业务模型是需求工作流程的一 入重点强调 业务模型是需求工作流程的 种重要输入，用来了解对系统的需求。业务 实体是分析设计工作流程的一种输入，用来 确定设计模型中的实体类。

业务建模的目的
了解目标组织（将要在其中部署系统的组织）的结构及机制。 了解目标组织中当前存在的问题并确定改进的可能性。 目 前存 并确 可能 确保客户、最终用户和开发人员就目标组织达成共识。 导出支持目标组织所需的系统需求。

为实现这些目标，业务建模工作流程说明了 如何拟定新目标组织的前景，并基于该前景 如何拟定新目标组织的前景 并基于该前景 来确定该组织在业务用例模型和业务对象模 型中的流程、角色以及职责。 作为对这些模型的补充，还开发了以下工件：
补充业务规约 词汇表 与其他工作流程的关系

业务建模工作流程与其他工作流程的关系如下：
业务模型是需求工作流程的 种重要输入，用来了解对系 业务模型是需求工作流程的一种重要输入，用来了解对系 统的需求。 业务实体是分析设计工作流程的一种输入，用来确定设计 模型中的实体类。 环境工作流程开发并维护支持工件，例如“业务建模指南”。

业务建模的规模
根据环境和需求的不同，业务建模工作可 能有不同的规模。以下列出了六种这样的 能有不同的规模 以下列出了六种这样的 场景。

场景 #1 – 组织图 您可能需要构建组织及其流程的简图， 您 能需要构建组织 其流程的简图 以便更好地了解对正在构建的应用程序的 需求。在这种情况下，业务建模就成了软 件工程项目中的一部分，它主要是在先启 阶段执行的。通常，这些工作在开始时仅 仅是画出组织图，其目的并不是对组织进 仅 出 其 的并 进 行变更。但实际上，构建和部署新的应用 程序时往往会进行一定程度的业务改进。

场景 #2 – 领域建模 如果您构建应用程序时的主要目的是 管理和提供信息（例如，订单管理系统或 银行系统），那么您可能选择在业务级别 上构建该信息的模型，而不考虑该业务的 工作流程。这就称为领域建模。请参见工 作流程明细：开发领域模型。通常，领域 作流程 发领域模 常 领域 建模是软件工程项目的一部分，它是在项 目的先启阶段和精化阶段中执行的。

场景 #3 – 单业务多系统 如果您正在构建一个大的系统（即一 如果您 在构建 个大的系统（ 系列的应用程序），那么一个业务建模工 作可能成为数个软件工程项目的输入。业 务模型帮助您找出功能性需求，并且也作 为构建应用程序系列构架的输入。详情请 参见概念：从业务模型到系统。在这种情 参 念 务模 系统 在这种情 况下，通常将业务建模工作本身当做一个 项目。

场景 #4 – 通用业务模型 如果您正在构建一个供多个组织使用的 应用程序（例如，销售支持应用程序或结账 应用程序）。一种有效的做法是：从头到尾 进行一次业务建模工作，从而按这些组织的 经营方式对它们进行调整，避免一些对于系 统来说过于复杂的需求（业务改进）。但如 果无法对组织进行调整，那么业务建模工作 果无法对组织进行调整 那么业务建模工作 能够帮助您了解并管理这些组织使用该应用 程序时存在的差别，并使您更容易确定应用 程序功能的优先级。

场景 #5 – 新业务 如果某个组织决定要启动一项全新的 如果某个组织决定要启动 项全新的 业务（业务创建），并将构建信息系统来 支持该业务，那么就需要进行业务建模工 作。在这种情况下，业务建模的目的就不 仅仅是要找出对系统的需求，而且还要确 定新业务是否可行。在这种情况下，通常 定新 务 行 在这种情 常 将业务建模工作本身当做一个项目。

场景 #6 – 修改 如果某个组织决定要对其经营方式进 行彻底修改（业务重建），那么业务建模 通常本身就是一个或多个项目。通常，业 务重建分数个阶段完成：新业务展望、对 现有业务实施逆向工程、对新业务实施正 向工程以及启动新业务。 向 程以 启动新业务

业务建模时期的主要任务(5-1)
项目涉众的共同愿景：要想项目成功，可离不开项目涉众的支 持。在项目一开始，不论是项目涉众还是开发人员，对项目的 任务、范围都是模糊不清的。但随着项目的深入，原来模糊的 景象会慢慢清晰、立体起来。但是为了不浪费时间，我们有必 要在项目射入之前，现在项目涉众中竖立一个共同的愿景。 共同愿景的竖立可没有想象中的那么简单，因为每位涉众都关 心自己的利益，都有自己的评判标准。你可以把大家的意见都 列在白板上，然后逐项集中讨论，做出修正，直到大家的意见 一致的时候为止。在共同远景的竖立过程中，其实有两件事情 也已经同时做了，项目范围（scope）和高阶（high-level）需 也已经同时做了 项目范围（scope）和高阶（high level）需 求。

业务建模时期的主要任务(5-2)
项目范围：项目该做什么，不该做什么，需要在一开始就有 明确的定义。对于项目范围内的需求，一个也不要放过，而项 目之外的，一个也不要去关心。虽然有的时候，范围的变化会 有利于项目本身，例如客户的合理要求或是市场目标客户的变 化，但是这种变化应该要在”资源能够支持”和”得到审批”的前 提下进行。 项目范围的描述可以通过陈述和图示来进行。我建议大家使用 图示。因为陈述语句比较含糊不清。例如常常听到有客户说。 “我要建立我公司的电子商务系统。”这句话就是含糊不清的， 你的电子商务系统是销售什么产品？面向什么客户？是否要支 持在线支付？根据这些疑问，这个陈述句可以做进一步的修改， “建立在线订货系统，针对当前的目标客户销售公司的目前产 品。”这样就清楚许多了。不过图示的方法会更好一些，在图 的选择上，你可以使用DFD图或是用例图。根据经验，DFD 图比较容易为客户所接受。

业务建模时期的主要任务(5-3)
高阶需求：这个部分我们在下面会详细讨论。既然 是高阶需求，就不能讨论过多的细节。在讨论高阶 需求的时候，尽量保证快速的讨论出系统的概貌， 建立需求模型，得到项目涉众的一致通过。

业务建模时期的主要任务(5-4)
取得支持：为了保证需求计划的顺利进行，取得项 目涉众的支持至关重要。你可以选择在这个时候告 诉项目涉众他们的权利和义务，以及开发人员的权 利和义务。在这个方面，具体的我不想多说，大家 可以参考『软件需求』的第二章。主要的就是”涉众 有改变需求的权利，同时要承担向开发人员讲解需 求的义务。”开发人员的权利和义务正好和涉众相反。

业务建模时期的主要任务(5-5)
业务建模会议：所有的这一切都通过业务建模会议 进行，和其它会议不同的是，这个会议需要所有的 项目涉众参加，如果不能获取所有项目涉众的意见， 那就不是完美的。会议中最重要的工具就是白板， 一位出色的速记员也是必须的。

需求和业务建模(3-1)
业务建模是需求工程中最初始的阶段，也是 整个项目的初始阶段。需要指出的是，业务 整个项目的初始阶段 需要指出的是 业务 建模时间的跨度在不同的项目中有很大的差 别的。 在有些项目中，例如大型ERP系统，可能需 要几个月的时间。而对于普通的项目，业务 建模的时间可能仅仅需要几天的时间。

需求和业务建模(3-2)
需求是技术无关（technology independent）的。 在需求阶段讨论技术是没有任何意义的。那只会让 你的注意力分散。技术的实现细节是在后面的分析、 设计阶段才需要考虑的事情。 而在业务建模阶段，不但要保证需求的技术无关性， 还要保证你的需求不要深入细节。因为在业务建模 阶段，最重要的事情就是要了解业务的全貌，深入 细节会浪费时间和精力。要知道，讨论 个企业里 细节会浪费时间和精力。要知道，讨论一个企业里 的业务细节，就算给你一个月的时间也没必能够结 束。

需求和业务建模(3-3)
在实际中，这两点都是很难做到的。例如企业原先 有 个系统，这就不得不由你讨论和新旧系统的兼 有一个系统，这就不得不由你讨论和新旧系统的兼 容问题。这时候就要注意，如果你是讨论就有系统 的架构的话，那还是属于技术无关的范畴，如果你 一旦进而讨论各具体模块/组件的细节，那就非但不 是技术无关，而且也深入细节了。 在不深入细节的问题上，往往你很难禁止项目涉众 （Stakeholder）不去讨论 些相关的业务细节。这 （Stakeholder）不去讨论一些相关的业务细节。这 个时候你可以将这些细节记录下来，然后再回到业 务建模上。

业务建模中的用例
我们讨论了很多用例的知识，可是落实到企业中的时候，我们 往往会感觉难以把握企业的用例，这一点我们在用例的误区中 也有提到。在实际的情况中，你可能会对角色的归类，用例的 划分，粒度的把握等很细节的方面都没有底，偏偏这些实际的 东西对你的项目有非常大的影响。 RUP中，有多种的概念来支持用例的实现：业务主角 （Business Actor）、业务实体（Business Entity）、业务用 例（Business Use Case）、业务角色（Business Wo

 

高级需求分析师培训总结(王楠)—文档资料库www.03964.com汇集和整理大量word文档,专业文献,应用文书,考试资料,教学教材,办公文档,教程攻略,文档搜索下载下载,拥有海量中文文档库,关注高价值的实用信息,我们一直在努力,争取提供更多下载资源。