软件需求最佳实践——SERU过程框架原理与应用(典藏版)

《软件需求最佳实践——SERU过程框架原理与应用(典藏版)》基本信息作者： 徐锋出版社：电子工业出版社ISBN：9787121200526上架时间：2013-5-5出版日期：2013 年5月开本：16开页码：424版次：1-1所属分类：计算机

更多关于 》》》《 软件需求最佳实践——SERU过程框架原理与应用(典藏版)》内容简介计算机书籍　　“用户说不清需求”、“需求变更频繁”……都是在软件需求实践中频繁遇到的问题。《软件需求最佳实践——seru过程框架原理与应用(典藏版)》首先直面这些问题，从心理学、社会学的角度剖析其背后的深层原因，使大家从中获得突破的方法。　　 然后沿着需求开发的几大关键过程，逐一说明了需求定义、需求捕获、需求分析与建模、编写规约、需求验证等需求开发活动的任务、要点和具体手段，并提出了一个可操作性强、易于上手的seru过程框架，能够帮助读者清晰地了解整个过程，理解各阶段的关键产物和产物之间的关系，迅速应用于实际工作中。本书还对包括需求基线、变更管理、需求跟踪在内的需求管理活动的操作要点进行了阐述，给出了具有很强实践性的具体建议。　　 纵观全书，语言浅显、文字生动，蕴含了许多人文、心理、交流方面的知识，即使是非技术背景的读者也能够轻松读懂大部分内容，从中受益。　　 《软件需求最佳实践——seru过程框架原理与应用(典藏版)》可作为计算机软件专业本科生、研究生和软件工程硕士的软件需求分析教材，也可以作为软件工程、软件开发管理培训的教材，更是一线项目经理、需求分析人员、资深开发人员、信息系统运行管理人员、研发企业管理人员的必备参考书。目录《软件需求最佳实践——seru过程框架原理与应用(典藏版)》第1部分 原理、模型与误区第1章 需求实践现状分析2在信息化高速发展的今天，构建与时俱进的信息化系统已成为所有政府、企事业单位的重点课题之一。然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，甚至有许多项目根本无法达到预期的目标，更谈不上为业主创造真正的效益。归根结底，软件需求实践这一共同的软肋是问题的根源。1.1 软件项目失败的根源21.1.1 chaos report 199421.1.2 chaos report后续版本31.1.3 需求相关败因简要分析41.1.4 一幅漫画带来的思考81.2 透过表象，分析本质131.2.1 需求变更频繁131.2.2 上线阻力大141.2.3 运行效果差151.2.4 完全崩溃161.3 方法论与需求工作171.3.1 计算模式171.3.2 软件工程方法论181.3.3 开发思想191.4 小结20第2章 不同软件项目的需求视图21随着信息化应用的逐渐深入，软件项目在企业、政府等各类组织中所担负的角色也越来越多，应用层面也在逐渐地深入，同时也意味着不同的软件项目具有不同的特点，这也就对需求工作产生了诸多影响。 在本章中，我们就将针对信息系统、嵌入式系统、软件产品等不同角度来说明如何进行相应的需求工作，为需求分析师提供一个切实有效的视图。2.1 信息系统的需求视图212.1.1 信息系统的本质与分类212.1.2 联机事务处理系统——流程电子化232.1.3 管理信息系统——数据信息化262.1.4 其他信息系统302.1.5 信息系统的多维视图322.2 嵌入式系统的需求视图342.2.1 面向直接用户的嵌入式系统352.2.2 面向特定设备的嵌入式系统362.3 软件产品的需求视图372.4 小结41第3章 软件需求与需求工程42笔者在做需求分析师的培训时，经常会问学员这样的一个问题：什么是软件需求个看似简单的问题却并不好回答，也许很多人会简单地认为软件需求就是用户需要实现的功能加上一些非功能方面的要求。但这样的理解却并不完整，如果对用户所处的业务场景没有建立正确认识，经常会给工作带来麻烦。因此本章将对一些与需求、需求工程相关的关键概念进行阐释。3.1 什么是软件需求423.1.1 需求的三个层次423.1.2 需求的三种类型443.1.3 优秀需求的标准473.2 需求工程解析513.2.1 需求工程的范畴523.2.2 需求开发工作要点523.2.3 需求管理工作要点573.2.4 需求分析人员的技能组成603.2.5 seru模型概述613.3 小结62第2部分 需求开发第4章 需求定义最佳实践64需求定义活动准确来说是不属于需求工程范畴的，它实际上是立项管理需要做的工作。但需求定义阶段的产物对于需求捕获、分析与建模活动都有着直接的影响，如果这个阶段的工作做得不理想，就会出现“上梁不正下梁歪”的结果。因此本书还是将这个活动纳入进来，并将给大家提供一个能够与后续活动结合紧密的方法。4.1 需求定义任务概述644.1.1 需求定义的时机644.1.2 需求定义的理念与策略654.2 问题分析的五步法674.2.1 在问题定义上达成共识674.2.2 分析问题背后的问题734.2.3 确定相关人员和用户774.2.4 定义解决方案的界限784.2.5 确定加在解决方案上的约束814.2.6 小结814.3 需求定义的产物与要素824.3.1 需求定义的产物824.3.2 需求定义的要素834.4 定义需求范围884.4.1 案例说明884.4.2 划分主题域894.4.3 确定主题域范围984.4.4 标识业务事件与报表1024.4.5 生成需求大纲1054.5 小结108第5章 需求捕获最佳实践109需求捕获是需求开发中的第一个活动，可以说任何一个需求团队对它都不陌生，但如何提高需求捕获的有效性却一直以来是困扰大家的问题。需求捕获的要点在于计划性和科学性，计划性体现在对捕获对象、问题、时间的计划，科学性则表现在如何有效地选择合适的捕获方法。本章的目的就在于帮助大家更好地达到这两个目标，从而提高需求捕获活动的质量。5.1 需求捕获的策略1095.1.1 需求捕获应该是主动的1095.1.2 需求捕获应该是聚焦的1105.1.3 破解需求的冰山模型1115.1.4 破解阻碍需求捕获的心理现象1135.1.5 不要忽视对变更可能的捕获1175.1.6 需求协商1185.2 需求捕获的主要方法1265.2.1 用户访谈1265.2.2 用户调查1385.2.3 文档考古1435.2.4 情节串联板1455.2.5 现场观摩1475.2.6 联合开发1495.3 需求捕获的记录工具1525.3.1 工具的选择与定义1525.3.2 任务卡片1525.3.3 场景说明1545.3.4 其他工具1555.4 小结156第6章 需求分析与建模最佳实践157需求分析是需求工程中最为核心的工作，而需求建模则是需求分析的主要手段。但由于分析这个词比较抽象，很多时候让人感到无从入手，甚至导致被轻易地滑过了，直接将需求捕获的结果整理到软件需求规格说明书中。而需求建模也有很多工具，到底怎么有效地应用到需求分析过程中也是令人感到难以掌握的东西。因此本章的目标就是为读者勾勒出需求分析的阶段与任务，指出如何选择适合的建模工具，以及在什么时机、如何应用这些建模工具。6.1 需求分析与建模的要点与误区分析1576.1.1 需求分析到底做什么1576.1.2 建模的目标与要点1606.1.3 选择建模工具的要点1626.2 周期一：理清框架与脉络1656.2.1 业务流程分析1666.2.2 业务实体分析1926.2.3 角色与使用场景分析2186.2.4 周期一的产物2366.3 周期二：确定需求细节2526.3.1 确定行为需求的细节2536.3.2 确定结构需求的细节2746.3.3 周期二的产物2836.4 其他需求分析2966.4.1 接口需求2966.4.2 非功能需求的追踪2996.4.3 设计约束3026.5 小结306第7章 需求描述最佳实践307需求描述就是将需求捕获、分析的结果进行文档化的过程。在软件开发时，将分析的结果文档化是不可或缺的任务，也称为编写规约活动；而在某个项目中，可能还会由用户代表或需求捕获人员对捕获的内容进行整理，形成用户需求说明书。具体要干什么，想必大家并不陌生，而且在前一章中也看到了一些实例的片段。因此本章将重点从需求描述的风格与格式、写作策略与技巧两个方面做些强调和补充。7.1 需求描述的风格与格式3077.1.1 常见的描述风格与选用标准3077.1.2 典型软件需求规格说明书模板解析3087.1.3 定义模板的技巧3237.1.4 用户需求说明与软件需求规格说明3317.2 写作策略与技巧3337.2.1 文字表达的先天不足3337.2.2 需求描述的两大原则3357.2.3 不要忽视陈述需求理由的重要性3387.2.4 注意措辞3397.3 小结340第8章 需求验证最佳实践342需求验证是需求开发的最后一个环节，它是一个质量关。也就是说，其目标是发现尽可能多的错误，减少因为需求的错误而带来的工作量浪费。而需求验证的主要手段就是review（复查，也常译为评审）。但是许多需求团队都觉得需求验证比较容易变得“务虚”，收效很少，本章的目标就是帮助大家缓解这个问题。8.1 需求验证的主要手段3428.1.1 不同正式化程度的评审3428.1.2 审查过程概述3448.2 需求验证的主要误区与解决方案3468.2.1 需求验证的5大要点3478.2.2 需求验证常见的5大问题3508.3 小结353第3部分 需求管理第9章 需求基线操作实务356需求基线是需求管理活动中最为基础的一个，通常也是在项目中首先应该引入的管理活动。但许多相关书籍中对需求基线的介绍相对比较理论化，很少给出具体的操作方法，往往使得许多软件开发团队无从入手。为了帮助大家更好地引入需求基线，本章的重点将是结合具体的实例来说明需求基线的划分方法。9.1 需求基线的理念与策略3569.1.1 基线思想的起源3569.1.2 基线的策略3589.2 基线划定的基础：优先级评价3599.2.1 组织需求项3599.2.2 业务优先级评价3609.2.3 根据技术依赖性和项目风险调整优先级3649.3 基线划定的要素：工作量估算3649.3.1 估算的意义与要点3649.3.2 定义阶段的估算示例3669.3.3 分析一阶段的估算示例3699.4 基线划定与管理3709.4.1 划定基线3709.4.2 管理基线3719.5 小结372第10章 变更管理操作实务373需求变更频繁恐怕是困扰无数软件开发团队的恶魔之首，而且在美国权威的第三方机构standish group的chaos报告中，也将其列为困扰软件开发团队、导致项目失败的5大原因之一，其中原因实际上也充分暴露了整个产业的不成熟。需求变更在chaos报告中是排名第四的问题，而在中国软件开发团队中却是排名第一的问题，这里面就意味着存在距离，本章的目的就是希望帮助大家找到其中的差距。10.1 变更管理的理念37310.2 变更管理要点一：统一渠道37410.2.1 ccb背后的道理37410.2.2 变更处理过程37710.3 变更管理要点二：统一平台38110.3.1 变更管理平台的选择38110.3.2 变更管理平台的应用要点38210.4 小结383第11章 需求跟踪操作实务384需求跟踪是一个高阶的管理活动，它的目标是为了更好地管理需求的状态、更好地分析需求变更产生的影响。虽然执行需求跟踪会带来不错的效益，但其所需付出的工作量也是巨大的。本章我们就对跟踪的一些要点做一简要的说明。11.1 需求跟踪的基本概念38411.1.1 用户需求到软件需求的跟踪38511.1.2 软件需求到软件需求的跟踪38511.1.3 软件需求到下游工作产品的跟踪38511.2 需求跟踪的操作方法38611.2.1 表格法38611.2.2 链表法38711.3 小结389第4部分 总结第12章 seru过程框架总结392经常说一个观点：“我们并不缺乏软件工程、需求工程的理论、技术，缺乏的是将这些理论与技术有效地应用到实践中去的具体方法”。而贯穿全书的seru过程框架（也称为seru模型）正是笔者基于多年不同领域、不同规模的软件项目实践的基础上，通过对许多重型方法的剪裁而得到的一个清晰、实用的软件需求过程框架。12.1 seru过程框架要点概述39212.1.1 seru过程框架的理论基础39212.1.2 seru过程框架全景图39312.1.3 seru过程框架导入建议39612.2 需求实作要点概述39712.3 结语399参考文献400seru诫语目录第1章 需求实践现状分析2seru诫语1-1：需求规格说明书应该采用业务导向的树型层次结构来组织。6seru诫语1-2：对于需求分析员而言，真正的专业主义是基于业务利益（解决问题、创造机会、提高管控力等）的沟通。6seru诫语1-3：缓解沟通失真最有效的方法是及时复述。10seru诫语1-4：需求分析的本质在于业务分析，而非技术分析。12seru诫语1-5：业务场景是需求之魂。12seru诫语1-6：需求分析人员对于技术方法论的评价重在适用性。17seru诫语1-7：对预设计的需求是评判敏捷方法论是否适用的关键。18第2章 不同软件项目的需求视图21seru诫语2-1：流程分析（业务事件）是oltp系统的关键线索和主要视图。24seru诫语2-2：报表分析是mis系统的关键线索和主要视图。27seru诫语2-3：决策场景是dss系统的关键线索和主要视图。31seru诫语2-4：工作场景是专家系统的关键线索和主要视图。31seru诫语2-5：并行工作流是oa系统的关键线索和主要视图。32seru诫语2-6：高层管理人员的关注点往往在问题和机会。34seru诫语2-7：对于面向用户的嵌入式系统，行为分析是要点。36seru诫语2-8：面向特定设备的嵌入式系统，外部接口和事件分析是要点。37seru诫语2-9：信息系统类软件产品的需求重点在于针对不同目标客户群体的不同商业模式分离变化点；经常需要减出通用性，再通过插接解决扩展性。40seru诫语2-10：基于使用场景的困难点分析是工具软件的需求要点。41第3章 软件需求与需求工程42seru诫语3-1：业务需求是需求定义的产物，用户需求是需求捕获的产物，软件需求是需求分析与建模的产物。44seru诫语3-2：功能需求的要点在于如何组织。45seru诫语3-3：非功能需求的要点在于保证信息的有效传递和注意其局部性。45seru诫语3-4：设计约束包括非技术因素的技术选型、预期的软硬件环境和预期的使用环境三大类型。47seru诫语3-5：业务导向的层次结构是保障完整性的关键。47seru诫语3-6：需求有时会戴上“高优先级”的面具，实际上就是担心你不去实现它。49seru诫语3-7：满意/不满意度模型是需求必要性评价的有效手段。50seru诫语3-8：在需求捕获活动中，化被动为主动是关键。53seru诫语3-9：需求分析就是向下分解+向上提炼，外加一些规格化。54seru诫语3-10：需求分析是目标，需求建模是手段。55seru诫语3-11：在编写需求规格说明书时，应确保一类信息只在一处描述。57seru诫语3-12：划分出大小合适、粒度均匀的需求项是需求管理的前提。58seru诫语3-13：需求优先级与工作量估算是基线管理的关键。59seru诫语3-14：seru模型是需求分析的工作指南。61第4章 需求定义最佳实践64seru诫语4-1：清晰的项目目标和范围定义，能够引导需求工作顺利进行。65seru诫语4-2：对混沌不清的目标，可以通过内部寻根或外部溯源来破解。65seru诫语4-3：对问题进行了正确的定义，意味着成功解决了一半。而在问题定义时应该善于使用转换和本源两个技巧。68seru诫语4-4：需求定义阶段要善于将未知解问题转换成已知解问题。69seru诫语4-5：在确定某问题的解决方案时，一定要思考是否会引发新问题。70seru诫语4-6：直接修改错误，不要用其他方案来弥补错误。71seru诫语4-7：鱼骨图为解决问题找到了靶子，帕累托图则标上了环数。77seru诫语4-8：范围是涉及的事、物，边界是人与系统的职责边界。80seru诫语4-9：用户永远会希望花同样的钱，获得尽可能多的功能。80seru诫语4-10：需求阶段描述的是用户的能力特点，旨在提高可用性。86seru诫语4-11：你可以不做一件事，但一定不能不知道为什么需要做这件事。86seru诫语4-12：在分解系统时，应该按业务的脉络来划分成不同的主题域。90seru诫语4-13：各个主题域之间的服务接口是需求变更的防火墙。91seru诫语4-14：确保能做的事和知道的事相匹配是职责驱动设计的要点。94seru诫语4-15：目标决定范围。97seru诫语4-16：绘制上下文关系图，先考虑customer再考虑worker是要点。99seru诫语4-17：业务事件应该是主动触发的，并且将会产生一系列后续行为。103seru诫语4-18：业务事件是直接作用于系统的，也就是将触发系统行为。104第5章 需求捕获最佳实践109seru诫语5-1：需求捕获是撒网打鱼，不是休闲钓鱼。109seru诫语5-2：善于聚焦访谈话题是需求捕获人员成功的关键。111seru诫语5-3：尝试理解业务场景是合格需求分析人员的良好习惯。112seru诫语5-4：善于利用技术为用户创造全新体验是优秀需求人员的特质。113seru诫语5-5：通过比较用户代表的表述来识别言过其实，利用差异展现、瓶颈分析法来缓解影响。114seru诫语5-6：针对越俎代庖心理现象最有效的方法是识别正确的被访谈者。114seru诫语5-7：离开办公室、对访谈进行计划是避免非正事现象的主要手段。116seru诫语5-8：化敌为友是缓解抗拒心态的主要方向。116seru诫语5-9：倾听对方的抱怨是化敌为友的有效手段之一。116seru诫语5-10：突破推卸责任心理的简单手段是让被访谈者介绍工作场景。117seru诫语5-11：需求捕获时不要忽视对变更可能的了解。118seru诫语5-12：在需求捕获时要善于使用“之箭，找到真正的需求。121seru诫语5-13：“拨开立场，寻找利益诉求”是需求协商的要点。123seru诫语5-14：不要孤立地看待需求项，应该将所有需求视为一个整体。123seru诫语5-15：“环境”将改变结果，切换不同的视角会得到不同的认识。125seru诫语5-16：善于打比方是提高跨专业沟通效果的好方法。126seru诫语5-17：占用时间长和信息的片面性是用户访谈的两大敌人。127seru诫语5-18：访谈的线索是因“人”（用户类型）而异的。127seru诫语5-19：尽量将访谈问题事先发给被访谈者，让他打一场有准备之战。129seru诫语5-20：在需求捕获时别忘了“一图抵千言”这句经典提示。133seru诫语5-21：用户访谈是一个有计划的、科学的过程。136seru诫语5-22：用户调查能够有效克服用户访谈中存在的片面性。138seru诫语5-23：在需求捕获过程中，先访谈再调查是更合理的方式。138seru诫语5-24：大样本用户、跨地域用户的存在就是使用用户调查的时机。139seru诫语5-25：分析文档资料时应该思考新流程对其的影响。144seru诫语5-26：收集文档时，应该尽可能让用户提供带有真实数据的样本。145seru诫语5-27：需求捕获人员要善于根据流程分析的结果主动收集相关文档。145seru诫语5-28：情节串联板是消除用户盲区的有效技术。146seru诫语5-29：情节串联板应该以业务场景作为展示的主线索。147seru诫语5-30：交互才是情节串联板的本质，不要只关注于界面的静态效果。147seru诫语5-31：现场观摩技术是消除开发团队认识盲区的有效手段。147seru诫语5-32：现场观摩技术能够使开发团队实现对业务场景“感同身受”。147seru诫语5-33：联合开发是突破双方需求盲区的有效手段。149seru诫语5-34：出现“上面开大会，下面开小会”现象，一半责任在组织者。150seru诫语5-35：沟通决定内容，内容决定格式。152第6章 需求分析与建模最佳实践157seru诫语6-1：需求分析就是先分解，再提炼，在这个过程中消除矛盾。157seru诫语6-2：需求建模的过程远比建模的结果更重要。160seru诫语6-3：模型是用来沟通的，因此仅当需要时才构建它。161seru诫语6-4：建模的要点是根据要完成的任务选择合适的建模工具。162seru诫语6-5：uml本身不是方法论。164seru诫语6-6：业务流程是对信息系统进行“庖丁解牛”的核心线索。166seru诫语6-7：流程有组织级、部门级、岗位级三个层次，其中部门级是需求分析的主线索，岗位级是需求细节填充时的工作内容，组织级是对部门级流程的抽象概括。171seru诫语6-8：应该根据项目的特点和团队的技能情况选择合适的模型。173seru诫语6-9：模型最有效的方式是在交流中演化出来的。177seru诫语6-10：流程图绘制完成之后，花些时间进行瓶颈和利益分析会有意想不到的收获。186seru诫语6-11：在需求建模时，应该大胆地用中文命名类和类的属性。195seru诫语6-12：需求阶段的类建模应该尽可能保持简单，引入过多的辅助建模元素反而会降低图的可读性。200seru诫语6-13：领域模型是自底向上合并出来的。206seru诫语6-14：领域模型的要点是拒绝实现、保持简单、忠于问题域。209seru诫语6-15：领域建模时应遵循“拒绝实现细节、大类不分拆、子类不合并、同类不抽象”的原则。209seru诫语6-16：团队的分工不明确往往是导致视图交叠的原因，了解不同视图的关注点，是理解不同模型的关键。216seru诫语6-17：仅在需求规格中出现用例图并不意味着应用了用例技术。219seru诫语6-18：千万不要为了使用扩展、包含关系而使用它们。扩展用例建模的通常是优先级较低的扩展事件流，包含关系建模的通常是多个用例所包含的公共子事件流。225seru诫语6-19：在访谈现场，就流程图讨论出用例图是高效的建模方法。230seru诫语6-20：如果说用例有粒度，那么它取决于业务流程和任务分工。233seru诫语6-21：系统动作（诸如新增、删除之类）和业务名词在用例名称中相遇时，就是一个十分危险的信号。234seru诫语6-22：对不影响泳道间协作的判断、活动均属于细节信息。237seru诫语6-23：对于报表而言，并不一定非得按用例模板来组织需求描述。241seru诫语6-24：诸如rose之类的建模工具，对模型抽象的支撑是最重要的。252seru诫语6-25：前、后置条件出现的频度并不高，不要画蛇添足。257seru诫语6-26：避免在用例事件流描述中出现实现细节、分支结构、循环结构；特别是不应该出现多路分支结构，如果出现要反思用例抽象是否正确。265seru诫语6-27：界面原型部分是约束、是建议，目的是支持有效的ui设计。269seru诫语6-28：建议使用不同的字体风格约定，以表达出数据的结构特点。280seru诫语6-29：历史记录的标准也是数据需求的一部分。280seru诫语6-30：哪里有分解，哪里就有接口。297第7章 需求描述最佳实践307seru诫语7-1：需求规格的格式取决于开发团队的特点及所选的开发方法论。329seru诫语7-2：用户需求说明书是为生成软件需求规格说明书服务的。333seru诫语7-3：文字的歧义可能与其长度成正比。335seru诫语7-4：要使需求描述更加清晰，就应该转用“结构化文本”式描述。338seru诫语7-5：在你被逼在需求描述中增加how的信息之前，先确认自己已经尝试过为需求添加了why。339seru诫语7-6：对于非功能需求而言，应该抛弃定性，改用场景化描述；并通过选取指标、积累经验值的方法过渡到定量描述。340第8章 需求验证最佳实践342seru诫语8-1：需求验证的目标是尽可能暴露问题，而不是证明无错。347seru诫语8-2：在企业中推行即时评审、同级桌查等正式化程度不高的评审手段，是创建企业评审文化的有效手段。348seru诫语8-3：在评审会中，不要用“评价者”的口气谈论你的观点。349seru诫语8-4：参加需求评审的人不是越多越好，一定要保证同级、适合。349seru诫语8-5：评审时要确保评审内容、缺陷检查表的规模适合，内容应该按每小时30～40页的速度来准备，缺陷检查表尽量在9条之内。350第9章 需求基线操作实务356seru诫语9-1：优先级是相对的，要在同一级中进行比较。363seru诫语9-2：评价具体功能点的优先级时，应将其放到业务场景甚至是业务流程环境中考虑。364seru诫语9-3：软件估算是随着工作任务的细化不断提高精确度的。365seru诫语9-4：不同阶段进行软件估算时，应该采用不同的计数单元。365seru诫语9-5：悲观估计、乐观估计应和“风险”理由对应起来。370第10章 变更管理操作实务373seru诫语10-1：需求变更管理的目标是控制变更，而非避免变更。373seru诫语10-2：控制变更的目标是减少变更对开发工作的影响。373seru诫语10-3：需求团队的贡献在于“尽早标识变更”，设计团队的贡献在于“尽可能以弹性的设计来减少变更的影响”。374seru诫语10-4：建立统一的渠道让客户意识到变更的成本，减少“来路不正”的变更，记录“变更的工作”。374seru诫语10-5：ccb的核心人员只有两个，分别代表用户团队和开发团队，其他组成人员都是协作者和决策者。375seru诫语10-6：基于业务驱动的需求项（树型）列表，是对变更进行业务影响分析的有效方法。380seru诫语10-7：对变更进行分类、再分类，是管理变更的重中之重。383第11章 需求跟踪操作实务384seru诫语11-1：需求跟踪是高阶管理活动，所需的工作量很大，特别是软件需求到设计元素的跟踪，因此一定要考虑投入与产出是否成正比。385 本 图书信息来源： 中国互动出版网 相关资源：淘金币抵钱怎么用|淘金币自动领取工具v1.3绿色版.zip_淘金币自动…

来源：iteye_11916