议题
需求跟踪 变更需求代价：影响分析 变更需求代价 影响分析
需求跟踪包括编制每个需求同系统元素之间的联系 文档。这些元素包括别的需求、体系结构、其他设 计部件、源代码模块、测试、帮助文件、文档等。 跟踪能力信息使变更影响分析十分便利，有利于确 认和评估实现某个建议的需求变更所必须的工作。
需求跟踪
跟踪能力（联系）链（ 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）
