74 6 accntNum );
75 6 ratio = balance / avgBalance ;
76 6 if
77 6 (
78 6 ratio < .2
(M) STATIC VIOLATION : 96 S : Use of mixed mode arithmetic: float double ratio < .2
79 6 )
以航空电子显示系统为例。 一个用于实现捕获需求"维持账户" 的示例性源4、码文件"CheckAvionicsDisplay. c"可能包含下列代码 段：
int CheckAvionicsDisplay ()
//试图启动各模块，如果一个模块和它的备份失败
〃返回一个负数，表明该模块发生故障。
〃
if ( IBITestModulel () ) { if ( ! BackupModulel ( ) ) return -l;)
if ( !BITestModule2 () ) { if ( ! BackupModule2 () ) return -2; }
if (!BITestModule3() ) { if ( ! BackupModule3 () ) return -3; }
//所有模块均已启动。返回1表明成功。 return l(
在此例子中，静态分析&代码覆盖工具120可能识别下列源代码基 本块（块1-7):
37 1 int
38 1 CheckAvionicsDisplay ()
39 1 {
40 1 //试图启动各模块。如果一个模块和它的备份失败41 1 //返回一个负数，表明该模块发生故障
42 1
43 1 if
44 1 (
45 1 !
46 1 BITestModulel ()
47 1 )
48 2
49 2 if
50 2
51 2 j
52 2 BackupModulel ()
53 2
54 3
55 3 rsturn
56 3 一 1 ;
57 4
58
59 6 if
60 6 (
61 6
62 6 BITestModule2 ()
63 6
64 7
65 7 if
66 767 7 !
68 7 BackupModule2 ()
69 7 )
在分析源代码和项目编码规则的一致性之后，静态分析&代码覆盖 工具120可能鉴定下列代码为不一致性（M)命令：
37 1 int
38 1 CheckAvionicsDisplay ()
(M) STATIC VIOLATION: 63 S Empty parameter list to procedure/ funct .
39 1
40 1 〃 试图启动各模块。如果一个模块&它的备份失败
41 1 // 返回一个负数，表明该才莫块发生故障
42 1 〃
43 1 if
44 1 (
45 1
46 1 BITestModulel ()
(M) STATIC VIOLATION : 114 S : Expression is not Boolean.
47 1 )
48 2
49 2 if
50 2 (
51 2 j
52 2 BackupModulel ()
(M) STATIC VIOLATION : 114 S : Expression is not Boolean.
53 2 )
54 3
(M) STATIC VIOLATION : No brackets to then/else (added by analys is)
55 3 return56 3 - 1 ;
57 4 }
58 5 }
59 6 if
60 6 (
61 6 J
62 6 BITestModule2 ()
(M) STATIC VIOLATION : 114 S : Expression is not Boolean.
63 6 )
67 7 J
68 7 BackupModule2 ()
(M) STATIC VIOLATION : 114 S : MISRA-C: 2004 12.6 13.2: Expression is not Boolean.
69 7 )
此外，静态分析&代码覆盖工具120也可以用于测试和度量外部运行 检验中的代码覆盖。静态分析&代码覆盖工具120对静态分析和代码 覆盖（也称为动态分析）能力的集成为测试验证的三角测量和软件抽 象的结构化覆盖提供了关键保障。
[0032]单元/集成测试工具125可以用于测试源代码是否符合需 求。在一个实施方案中，单元/集成测试工具125可以运行测试用例， 所述测试用例定义源代码各部分的输入和期望的输出，并且产生描述 代码覆盖的结果。例如，源代码可以实现为多个函数。如果在单元/ 集成测试期间某个函数被调用并且执行，那么该函数可以描述为"被 覆盖，，。这样，通常希望被覆盖的源代码所占百分比比较高。另外， 在单元/集成测试期间，可以对各种级别的覆盖进行测试，比如路径 覆盖、语句覆盖、分支覆盖和变更的条件/判定覆盖（MC/DC)。可以 采用各种自动化和集成测试软件产品来实现单元/集成测试工具125， 比如LDRA TB簡tm; Parasoft (网址parasof t.国）的C++ Test, C++Test for Embedded Systems, Code Wizard and Jest with Test Case Sniffer; Vector Software (网址vectorcast. com)的 VectorCAST/Ada， VectorCAST/C， VectorCAST RSP for Rea卜time Embedded Testing和VectorCAST/Cover; IBM Rational (网址 www-306. ibm. com/software/rational/) 的Test RealTime; IPL (网 址ipl.com)的Adatest 95和Cantata++', Free Sof tware Foundation (网址gnu.org)的Cunit， CPPimit和Junitj 以及，Testwell (网 址testwell.fi)的CTA++, C++ Test Aider, CTC++, Test Coverage Analyzer for C/C++。
[0033]以在线杂货店为例。 一个示例性测试用例可能测试映射到 需求"维持账户"的过程（比如浮点MaintainAccountFuncUon()) 是否符合该需求。在该例子中，测试用例可能规定：如果 GetAccountBalance(accntNum) #皮调用时输入值-3201，则测试用例将 返回值-1。在该例子中单元测试的覆盖结果可能表示如下：一覆盖一
-语句-
期望的覆盖率（%): 80 V: 映射过程的通过率（％): 89 -分支判定-期望的覆盖率OO: 60 被映射过程的通过率OO: 63 -路径-
期望的覆盖率（%): 70 被映射过程的通过率（°/。）： 72
[0034]以航空电子显示系统为例， 一个示例性测试用例可能测试 映射到需求"隔离故障"的过程（比如int CheckAvionicsDisplay()) 是否符合该需求。在该例子中，测试用例可能规定如果函数 BITestModule3 ()被设置为1并且BackupModule返回1。在该例子 中的单元测试的覆盖结果可能表示如下：—覆盖一
-语句-
期望覆盖率（W: 80被映射过程的通过率（％): 61 -分支判定-期望覆盖率（%): 60 被映射过程的通过率（％): 51 -路径-
期望覆盖率（%): 50 被映射过程的通过率（％): 48
[0035]对需求是否已经在源代码中实现的跟踪和对所实现的源代 码是否按期望方式运作的验证可以人工方式进行，但是对大型软件开 发项目来说可能有数以千计的需求，对需求的人工跟踪和验证很快便 会变得不切实际并且无法管理。因此，如图1A所示，自动化的需求 验证工具115可以实现，以缩短需求捕获工具110和静态分析和单元 /集成测试工具120和125之间的差距。图1B示意了自动化需求验 证工具115的一种示例性实现，它包括需求才莫块140、项目模块145、 映射&分析模块150、验证模块155和网络接口模块160。本文中结合 图4A-4J描述的LDRA TBmanagerTM工具可以用来实现自动化需求验证 工具115。
[0036]需求模块140可以配置为基于需求捕获工具IIO从需求信 息源105捕获的需求信息定义用于该软件开发项目的需求。被捕获的 需求信息可以表示用户定义的，项目级的软件开发项目需求，这里称 之为"高级"需求。在线杂货店的例子中，被捕获的需求"维持账户" 是示例性高级需求。但是，高级需求并不描述实际实现该软件所需要 的代码级设计需求。如此，需求模块140可以被配置为提供定义未被 需求捕获工具110所捕获的其它需求的选项。
[0037]例如，需求模块140可以用于定义满足某高级需求的一部 分的需求，本文称为"低级，，需求。低级需求可以定义成规定软件的 一部分应当如何实现。例如， 一个低级需求可能集中在特定函数、目 标或目的。以在线杂货店为例，可以为高级需求"维持账户，，定义一 种被称为"账户名，，的低级需求，以便为该账户建立一个名字。在另 一个例子，即航空电子显示系统中，为高级需求"隔离故障，，定义一 个低级需求"启动被命名的冗余系统"，以确保只有被识别为Built In Test的冗余模块^皮启用。22[0038]需求模块140也可以用于定义从高级需求或低级需求推断 或衍生而来的需求，这里称之为"衍生，，需求。因此，衍生需求可能 不会由需求捕获工具110捕获，但是可以后续由自动化需求验证工具 115创建并且管理。以在线杂货店为例，可以为高级需求"维持账户，， 定义一个被称为"取消账户"的衍生需求，以取消一个被维持的账户。 在另一个例子即航空电子显示系统中，可以为高级需求"隔离故障，， 定义一个称之为"损失评估"的衍生需求，以帮助恢复过程通知。
[0039]需求模块140还可以用于定义作为高级、低级或衍生需求 的副本的需求，这里称之为"同级，，需求。同级需求可以是出于需求 多样化和任务管理（比如，用户135之一可能写源代码来实现某个低 级需求，而用户135中的另一个可能验证所实现的源代码）的目的而 创建的。如这里所述，同级需求可以由唯一标识符区别，尽管它在其 它方面和作为它母体的基础的高级、低价或衍生需求并无不同。这样， 需求模块140可以用于给RTM填充（populate)来自需求信息源105 的被捕获的高级需求、以及其它的低级、衍生和同级需求，以便允许 自动化需求验证工具115提供向下到源代码级的自动化需求跟踪工 作。
[0040]同级需求可以被称为验证任务。 一种额外的同级类型， 或者验证任务，被称为目标（objective)。目标被定义为确保同处 理目标或诸如需求验证或恰当计划和归档之类的量化评估的一致性。
[0041]另一种同级需求类型和缺陷报告生成及解决方案有关。 作为需求的对立面，缺陷报告可以由用户使用静态分析&代码覆盖工 具120或单元/集成测试工具125的自动产生。缺陷报告的分配导致 产生一个同级或验证任务，该任务的唯一目的便是跟踪缺陷报告到其 关闭为止。
[0042]项 目模块145可以配置用于建立项目。如这里所述，项目 模块145所建立的"项目"描述了真实世界软件开发项目的电子实现， 其中被建立的项目可以提供一种电子机制使得现实世界的许多方面 有机化和自动化，其中一些方面包括定义用于项目的需求，分配用户 参加项目的工作、跟踪各需求的实现、分析和验证所开发用于实现所 述需求的源代码文件、跟踪缺陷。所建立的项目可以包括相关的需求 信息和为实现这些需求由开发者编写的源代码文件。在一个实施方案中，先前针对某需求开发的源代码可以和所述项目关联起来。如果该需求不存在已开发好的源代码，那么项目模块145可以推进基于需求的开发，其中在源代码开发之前将该需求分配给用户。
[0043]项目模块145可以配置为对已建立的项目的相关需求和源代码文件进行的分层显示，并且可以提供某需求的状态信息（比如，该需求是否已验证或未获验证，被分配参加该需求工作的用户，等等）。例如，图4C (这里结合一种示例性用户接口描述）示意了一种在线杂货店例子下的项目树412，图中给出了需求和源代码文件的分层体系。通过将高级需求和其低级实现进行关联，项目模块145可以允许项目管理者看到逐个需求的分解图示，了解哪些需求的实现符合编码约定（convention)、代码覆盖水平和函数测试准则。如此，项目模块145可以提供集成的需求跟踪和验证矩阵。在一个实施方案中，项目模块145可以产生状态报告，总结用于某个用户的需求信息，该状态报告可以随着项目的进展加以更新，以纳入诸如单元测试之后的代码覆盖结果之类的其它信息。
[0044]项目才莫块145可以配置为添加用户135到项目之中。用户135可以包括参加项目工作的任何人，比如项目经理、软件开发者、测试工程师等。在一个实施方案中，项目模块145可以基于被指定完成类似行为的用户135组为项目创建角色"，并且将所创建的角色分配给用户135。例如，可以创建开发者角色、测试工程师角色、独立验证和确认（validation) ( IVV )角色和质量保证（QA )角色，以及其它角色。在一个实施方案中，项目管理者角色可以被创建，使得被分配项目管理者角色的用户可以对需求验证处理的几乎所有方面实施控制，并且可以创建其它角色，并且向用户135分配角色和需求。
[0045]在一个实施方案中，可以给角色分配各种权限，以定义被分配该角色的用户可以执行的动作。权限的例子包括创建低级需求权限、创建衍生需求权限、生成子项目权限（例如，当一个用户被分配了某个需求的时候可以建立一个子项目）、编辑线程属性权限（例如，可以给每个需求创建XML线程）、人工验证权限（比如，允许用户访问验证模块155,以审视本文所述的单元测试、代码覆盖和静态分析结果。）以及其它权限。
[0046]项目模块145也可以配置为允许用户具有必要的权限去向用户135分配需求模块140所定义的各种需求（即高级、低级、衍生和同级需求）。在一个实施方案中，向用户分配需求可以建立相应的子项目。这里所提到的"子项目，，描述了一个用户可以访问执行和他们被分配角色有关的指定任务（例如，写源代码、分析源代码文件、测试源代码文件等等）的工作区。
[0047]在一个实施方案中，项目模块145可以调整子项目的操作状态，要求用户在对某子项目执行任何任务之前从项目模块145 "签出，，该子项目，并且在完成所述任务之后将子项目"签入"项目模块145。换句话说，为了签出某个子项目，用户可以出于远程完成任务的目的制作它们的子项目文件的副本，并且为了将子项目签入，用户可以将他们子项目文件的修改后内容复制回已立项项目的目录树中。如此，项目模块145可以通过在每次用户签入和签出它们的子项目的时候将子项目和RTM的当前状态进行同步，保持RTM的完整性。另夕卜，如这里所述，可以分配一种创建子项目的;fr又限，以允i午用户通过项目模块145更 新子项目。例如，受影响的子项目应当在它们相应的需求被更改（例如由于添加或删除用户的缘故）的时候加以更新。
[0048]如图1B所示的网络接口模块160可以配置为允许项目的全球（globally )分布，并且提供基于通信网络130 (例如LAN、 WAN、互联网等等）的集成处理。在一个实施方案中，网络接口模块160可以允许用户135从远方将它们的子项目签入和签出。可以实施一些安全措施，比如建立安全连接以及要求用户135登录并且提供密码。此外，验证状态才艮告可以做到全球可用。通过这些方式，网络接口模块160可以用于执行同步或异步操作并且实现基于全球动态更新的需求矩阵（跟踪和验证矩阵）。
[0049]图1B所示的映射&分析模块150可以配置用来调用静态分析&代码覆盖工具120。如本文所述，映射&分析模块150可以调用静态分析&代码覆盖工具120，将源代码中指明的过程映射到用于项目的各个被定义的需求。以在线杂货店为例，在示例性源代码文件"MaintainAccount. c"中指明的过程floatMaintainAccountFunction()， long GetSessionAccountNumber()，float GetAverageAccountBalance (long accntNum), floatGetAccountBalance (long accntNum)， void FatalError (const char* msg)， void UserMessage (const char * msg) 可以被映射到高级需求"维持账户，，。以航空电子显示系统为例，过程有intCheckAvionicsDisplayO; int BITestModulel05 intBITestModule2 (); int BITestModule3 0 ; int BackupModulel (); intBackupModule2(); int BackupModule3 0 。图4G示意了一种将过禾呈映射到需求的示例性图形用户接口 。
[0050]此外，映射&分析模块150可以允许用户通过指明分析需求验证方法和/或测试需求验证方法，来验证某个需求。例如，在一个实施方案中，映射&分析模块150可以用于调用静态分析&代码覆盖工具120来提供集成分析能力，包括分析被映射的过程是否符合项目编码规则和质量度量。此外，在另一个实施方案中，映射&分析模块150可以用于调用单元/集成测试工具125来测试被映射的过程是否符合需求，办法是运行测试用例并且产生描述代码覆盖的结果。在又一个实施方案中，映射&分析模块150可以用来装备代码，这些代码将被在外部执行，并且其执行结果（即代码覆盖结果）可以后续返回给映射&分析模块15G以便进行事后代码覆盖分析。
[0051]如图18所示的验证模块155可以配置为基于由静态分析&代码覆盖工具120对被映射过程分析的结果以及由单元/集成测试工具12 5对被映射过程进行单元测试的结果，来验证所述被定义的需求。例如，在 一 个实施方案中，具有必要权限的用户可以利用验证模块15 5来选择需求并且观看该选定需求的期望代码覆盖率和所获得的代码覆盖率（例如，获得期望覆盖率的被映射过程所占百分比）。如果用户对选定需求所取得的覆盖率满意，用户可以将选定需求的当前状态维持为已验证。但是，如果用户对选定需求所取得的覆盖率不满意，那么用户可以改变选定需求的当前状态为未经验证。由于未对某需求做验证即更改了该需求线程（如同本文结合示例性XML实现进行描述的那样），用户应当后续更新和该需求有关的任何子项目。
[0052]验证模块155也可以配置为在一个用户下创建多组，并且将需求和相应组管理起来。各组分别分配有验证规则，使得当一个需求被分配给某组时，为该（基本）需求产生用于每个验证规则的一个同级需求。对于测试验证规则，为每个和基本需求相关的测试用例创建一个同级或验证任务。所有需求可以在初始时是未编组的需求。然后，需求可以和一个或多个组关联起来。
[0053]在该示例性实施方案中，验证规则规定哪些验证任务必须在该需求可以认定为已验证之前完成。某个需求必须满足的内容由该需求所处的验证组决定。验证规则不仅规定什么验证任务必须完成，也规定谁应当去做。^S正规则可以确定该需求是否通过代码审查(review),也可以进一步^见定代码审查由特定用户或者特定角色（例如，"测试者，，或"QA")的用户来完成。各规则可以排序，排序将促使各规则按照验证组中列出的顺序完成。
[0054]当验证规则被定义的时候，可以应用一个或多个质量模型。 一种质量模型可以设立一种标准，通过该标准用于某给定项目的软件的质量可以测量并且可视化。质量模型由代码审查和质量审查验证任务强制执行。
[0055]代码审查标准可以定义在一对文件中，报告文件(report. dat)和处罚文件(pen. dat)。报告文件包含完整的一组预先定义的编码规则。该组规则可以扩展，以便包容某个项目。该组规则的各个子组由公布的编码标准定义，它们是预先定义的，使得用户可以使用这些标准，而不必精通该标准的各个细节。通过报告文件，人们可以看到这些标准到规则的映射及其实施。处罚文件可以是代码审查配置的遗留（legacy)机制。
[0056]质量审查标准可以定义在'metpen. dat'中。该文件包含一系列的分析测量，这些分析测量是和容限（tolerance)阈值配对的。例如，秩（cyclomatic)复杂度测量、代码复杂度测量、不可达代码行测量、注释比例测量。如果复杂度超过某个预设的阔值，则质量审查^^告将相应地给予标记。如同用于代码审查的'report, dat'文件那样，'metpen. dat'可以;故定制以满足某个项目的需要。
[0057]对不同质量模型的选择可以通过对分配给各组的验证规则的组合实现。当调用同级需求进行代码或质量审查时，采用适当的质量模型进行测试。
[0058]如上文所提及，对于基本需求必须满足的每个验证规则可以产生某个验证任务的某个同级需求。例如，如果某需求的验证规则明确要求它需要通过代码审查，那么产生一个同级，并且如果该同级通过了代码审查，那么该需求被认为通过了代码审查。[0059]相应地，可以在某个软件开发项目中采用自动化需求验 证工具115,以便允许基于需求的开发和验证进程的自动化集成，并 且为项目团队的所有成员（包括管理在内）提供对动态更新的跟踪和 验证需求矩阵的全球访问。如本文所述，在一个实施方案中，自动化 需求验证工具115可以利用可扩展标记语言（XML)实现。
[0060]为了使需求跟踪可重复处理自动化，必须支持一种对测 试-验证处理的三角测量（triangulation)。这种三角测量包4舌三个 矢量：被映射的需求（包括某过程的静态关联、各过程的聚集体、类 或者任何执行工件）、结构性覆盖（代码覆盖的动态度量和测试用例 执行）以及测试用例（待执行的功能性）。需求跟踪的实现由于软件 编禾呈抽象(software programming abstractions) ( t匕:i口重载、多 重继承，通用参数化(generic parameterizations )， 和动态调度 表）而极大地复杂化。本发明实现这一跟踪的办法是集成所需要的功 能性规定的静态和动态矢量。本发明所实现的跟踪，包括对静态分析 &代码覆盖工具120的利用，扩展到软件及其运行时间工件的各个用 例。除了被映射的需求之外，测试用例（或使用例）必须明确映射为 供任何待执行的基于测试的验证任务之用的谓词（predicate)。处理回顾
[0061]图2示意了以电子方式管理软件开发需求的处理200示例 性步骤。并不是图2的所有步骤都必须按照图示顺序出现，本领域的 普通技术人员在阅读了本文的教导之后对这一点应当是一 目了然的。 结合下文的讨论，其它的操作性和结构性实施方案对本领域的普通技 术人员来说也是一目了然的。这些步骤将在下文详细讨论。
[0062]在步骤205，建立软件开发项目。例如，结合图1B描述 的项目模块145可以用来实现步骤205。在一个实施方案中，步骤205 包括为项目识别各用户。在另一个实施方案中，步骤205包括基于被 指定执行类似动作的用户组创建该项目的多个角色。例如，项目管理 者角色可以创建为具有对处理200实施控制的权限，可以产生至少一 个额外的角色，比如开发者角色、测试工程师角色、独立验证和确认 (validation)角色、和质量保证角色。在该实施方案中，步骤205 可以包括向各角色分配4又限，以定义用户可以完成的各项动作，比如创建低价需求权限、创建衍生需求权限、生成子项目权限、编辑线程属性权限和人工验证权限，步骤205也可以包括为用户选择各角色。[0063]在步骤210，基于从需求源捕获的需求信息来定义用于项目的各个需求。例如，结合图1B描述的需求模块140可以用来实现步骤210。在一个实施方案中，步骤210包括基于需求信息捕获用于该项目的高级需求，基于需求信息来定义该项目至少一个额外需求。所述的额外需求可以定义完成用于该项目的;^皮捕获和分配的高级需求中一部分的低级需求、从用于该项目的被定义高级需求或者低价需求推断而得到的衍生需求，和/或作为用于该项目的被定义高级、低级或衍生需求的副本的同级需求。额外需求信息可以包括任何给定需求相关的测试用例。在被定义为原始需求信息的一部分测试用例不存在的情况下，在执行基于测试的验证任务之前用户必须输入一个测试用例。
[0064]在步骤212,对于每个需求，将已经针对该需求开发的源代码和该项目关联起来。例如，结合图1B描述的项目模块145可以用于实现步骤212。此外，如果还没有为某个需求开发源代码，则步骤212可以促进基于该需求的开发工作，其中需求分配在源代码实现之前完成。在该实施方案中，将源代码和项目的关联直到步骤215才会出现。在步骤212,相应的子项目可以在项目被定义的需求分配给用户的时候建立。
[0065]可选地，处理200可以包括为用户产生状态净艮告，该用户概括被分配给用户的被定义需求，并且在项目期间更新状态报告，以纳入分析、代码覆盖和单元测试相应结果的各个额外步骤。
[0066]在步骤215，源代码中指明的过程被映射到用于该项目的被定义需求。例如，结合图1B描述的映射&分析模块可以用于实现步骤215。在一个实施方案中，步骤215包括调用静态分析工具，比如结合图1A描述的静态分析&代码覆盖工具120，以分析源代码来识别源代码中的各个过程。在该实施方案中，静态分析工具也可以被调用来对源代码进行分析，包括对相关的源代码文件应用项目编码规则和质量度量。此外，该静态分析&代码覆盖工具120可以用于测试和度量外部运行检验中的代码覆盖。在另一个实施方案中，步骤215包括调用单位测试工具，比如结合图1A描述的单元/集成测试工具125,以便对被映射过程进行用例测试。
[0067]在步骤220,基于对被映射过程执行的分析、代码覆盖测量和单元测试中的一个或多个结果，来验证该项目的各被定义需求。例如，可以采用结合图1B描述的验证模块155来实现步骤220。在一个实施方案中，步骤220包括：如果分析的结果表明源代码和项目编码规则和质量度量一致的话，则验证该项目的被定义的需求。在该实施方案中，可以基于分析结果对未一致情况进行追踪，并且可以就未一致的情况提出报告，包括提供有关不一致的分布信息。在另一个实施方案中，步骤220包括如果测试用例产生所需的结果，则验证该项目的被定义需求。
[0068]在另一个实施方案中，步骤220包括下列额外步骤：提供用于该项目的被定义需求的状态，指明每个被定义需求是否被验证或未获验证；并且产生集成的需求跟踪和验证矩阵，以便动态跟踪被定义需求的实现情况和被定义需求的状态。在该实施方案中，项目的子项目可以通过将项目的被定义需求分配给参加项目工作的用户而建立，并且子项目可以与集成的需求跟踪和验证矩阵同步。
[0069]可选地，处理200进一步包括允许用户通过通信网络访问项目的步骤。例如，结合图1B描述的网络接口模块160可以用于实现该联网步骤。在一个实施方案中，需求跟踪和验证矩阵的完整性可以通过监视用户何时经通信网络签出和签入其相应的子项目的方式而保持。换言之，处理200可以支持一种单元测试工作流场景，该场景包括通过高级、低级和衍生需求而进行的需求跟踪和测试验证并且有助于将这些需求和源代码过程或方法映射在一起。映射后的需求可以后续提供给开发者或测试者进行测试规范（specif ication)创建和测试-验证。处理200也可有助于从这些测试*见范创建测试用例。处理200可以自动跟踪该单元测试场景的结果而追溯到需求源，以确保其调度中的需求跟踪矩阵UTM)完整性和用户工作区（例如，项目/子项目）安全性和灵活性。在一个实施方案中，用户可以就"签入，，的子项目展开工作，其中用户所执行的所有任务可以被动态跟踪并且与RTM的更新同步，或者用户可以就"签出"的子项目展开工作，其中可以在任何地点执行验证任务，并且可以后续在用户返回工作（签入的子项目时）将结果和当前RTM同步。示例性XML实现的详细描述
[0070]正如本文所述，自动化需求验证工具115和自动化需求管 理处理200可以用在软件开发项目中，以缩短高级需求跟踪工具和低 级代码测试工具之间的差距，并且在一个实施方案中，它们可以利用 XML结构实现。
[0071]例如，需求管理数据可以按被称为"线程"的XML构造方 式维持，使得每个被跟踪的需求具有一个相应的XML线程。按照此种 方式，如本文所指，术语"线程"和"需求"实质上是可以互换的， 只是线程更准确地描述了基于需求的任务。例如，如图3A所示，线 程305可以包括描述该需求以及和其它需求310之间关系的元数据， 以及源代码文件中被映射到需求315的过程的有关原型信息和与该需 求验证有关的分析与测试结果信息320。所有原型信息可以保持在线 程自身中，包括利用〈Prototypex/Prototype〉 XML块的代码覆盖信息。
[0072]除分层信息（即，线程关系数据可以放置在线程自身中， 但是所有的线程一起构成有结合力的层次结构）外， 一个线程的所有 相关信息均可以放置在线程自身中。如此， 一个线程可以在很大程度 上成为一个自包含的对象，允许程序能够明智（sensibly)地使用线 程信息，而无需关于线程所属项目的任何知识，包括用户、角色和权 限信息。例如，图3C示意了一种项目机制340,并且可以看到线程 XML文件345可以独立于项目XML文件350、 355和360，而项目XML 文件350、 355和360可以用于创建有结合力项目并且将线程信息以 有益和直观的方式呈现给用户。
[0073]线程的定义可以规定数据聚合称为"线程"适量（proper) 和必须存在的字段（在XML特定范畴下也称为"元素"）最小数量及 其排列。放入到这些字段中的信息是否和真实世界数据有任何相关性 超出了线程定义的范围。线程的定义仅和唯一参考识别符（例如 ref-""元数据）有关，而和线程可读所采用的实际字符串无关。
[0074]图3B示意了线程XML文件335可以由调用应用/程序325 通过被称为CXML Wrapper的XML包装器类加以操控的情形。尽管可 以直接从/往线程中读出/写入，CXML Wrapper可以用于强制执行 ref=，， " XML惯例（convention)，由此确保线程按一致的符合标准的方式写和重写。
[0075]图3D示意了线程在存储器中的示例性表示。CXML Wrapper 类是基于CGenericXMLWrapper XML包装器类的，后者可以实现用于 将XML文件转4灸为^皮称为ReqDataContainer365的分层对象树。相X念 上来看，ReqDataContainer 365可以维持关于其自身的分层信息（例 如，其父母和子女是谁）以及关于自己数据的分层信息（例如，名字、 唯一参考识别符和数据）。CGenericXMLWrapper类可以为读取XML文 件时遭遇到的每个元素创建一个ReqDataContainer。该元素的名字和 唯一参考号可以存储，有别于任何数据。分层信息可以基于相关因子 (其中一个因子比如是，是否该元素具有数据和父元素）从上下文方 面力口以石角定。^口jt匕，在ReqDataContainer的树中，每个 ReqDataContainer都可以类似于一个具有指向树上同级的指针的节 点。
[0076]在遭遇到不具有参考号的元素的情况下，可以给该元素 分配一个参考号，以一个合理高的"未知界限"作为起点。如此，希 望检索该元素的数据的程序必须提前了解未知界限的值（该值可以定 义在XMLWrapper. h类中），以及有关多少未设参考号的元素正被读 取以及已经被读取的其它因素。实际上，可以更有效地定义线程树， 为线程的每个元素使用唯一参考号（或其它唯一识别符），而不是依 赖于自动分配参考号。但是，自动分配参考号可以有助于避免由于程 序的故障部分不向其新的元素分配参考号而导致整个线程（或 _trace, xml文件）不能被访问的情形。
[0077] —旦CGenericXMLWrapper类创建了一个 ReqDataContainer树，如图3D所示，调用程序可以完全自由地》务改 ReqDataContainer。例如，调用程序可以添加或去除 ReqDataContainer,并且修改已有ReqDataContainer中的数据。在 调用程序完成对ReqDataContainer树的修改之后，它可以调用该包 装器类的一种被称为WriteAsXMLQ的XML方法，将wrapper class转 换ReqDataContainer树返回XML文件，并且将XML文件写入存储设 备。
[0078] ReqDataContainer365在设计时可以尽可能多地模仿XML。 ReqDataContainer并不必需基于它们是否有数据、子容器、同级或任何其它上下文属性（property)而加以分类。但是，在实际中， ReqDataContainer之间应当有所区别，4吏得数据可以相应地加以组 么口S/、 o
[0079] ReqDataContainer树实现方案的灵活特性可以允许不同 的程序将其自身的数据添加到线程中，而不会彼此干扰。例如，在一 个实施方案中，缺陷跟踪信息和函数原型XML块可以添加到线程"范 围"，而不会混淆其主要的载荷、个体需求。这些是随着个体跟踪需 要增加（在此情况下，验证向下延伸到个别函数）而添加到线程中的 数据的例子，并且在此方式下，将和需求有关的所有数据及其跟踪信 息装入单个线程中的做法可以实现用户程序的灵活性和自由度。 ReqDataContainer树实现也可以定义对凄丈据编码的标准途径。如此， 希望利用其它程序提供的特征程序仅需要理解所使用的XML块协定 (convention),以便围绕它建立其自身功能性。
[0080]在一个实施方案中，可以采用被称为RDCPtr， iRDCPtr，和 CwrapperLibrary的类，（1 )将重复的XML块组织成"垂直数据"的 "堆，，，以避免和父节点接触的需要，（2)允许有顺序地访问同级， 而不必和父节点通信，（3)提供ReqDataContainer和所存储的XML 文件的单个元素之间的一对一关联。
[0081]避免依靠父节点获得子层次关系信息的做法可以改善代 码的完整性。例如，程序通常需要访问某个XML块的所有实例，比如 从某个线程中获得原型信息。不使用RDCPtr类便能从线程获得原型 信息的函数的伪代码表示可以表达如下： ReqDataContainer prototype—parent =current-thread. GetElement(REF-TEST一SPECIFICATION); ReqDataContainer prototype =
prototype—parent.GetElement (REF-PR0T0TYPE); while (prototype != NULL) {
PrintPrototypelnfo (prototype) 5
prototype = prototype—parent . NextElement (prototype);
使用RDCPtr类从线程获得原型信息的函数的伪代码表示可以表达 如下：RDCPtr prototype = current—thread
.GetElement (REF_TEST_SPECIFICATION)
.GetElement (REF一PROTOTYPE); while (prototype != NULL) {
PrintPrototypelnfo (prototype) 5
prototype = prototype. GetNext 05
[0082]两个实J见之间无代^马变动（cleanliness)方面的改进可以 是显著的，如果考虑到仅需传递一个线程所具有的原型"列表"中的 第一原型的RDCPtr，则可以将这一列表作为一个整体到处传递，这是 因为该列表中的第一原型知道其它原型的位置。如此，不再需要由一 个函数将两个ReqDataContainer指针（一个用于该元素， 一个用于 它的父元素）到处传递，相反仅需要将一个RDCPtr对象到处传递， 便可以使每个函数访问所有的原型。此外，wrapper类仅需要服务 (servie) —个应用调用（即得到第一原型的调用），而不必服务其 它调用来获得任何额外的原型信息。如此，重复的XML数据块可以表 示为"垂直"数据，如图3D和3E所示。第一原型可以和任何其它的 XML块一样对待，而后续读取的原型块可以"堆，，在第一原型的上面。 RDCPtr类体现了 ReqDataContainer堆这一理念。[0083〗如此，调用程序不必和ReqDataContainer直才妄接触。所 有的数据访问可以由RDCPtr完成，后者可以实现如图3D和3E所示 的唯一的"垂直数据"堆机制。由于它们可以充作智能指针，RDCPtr 可以提供专有的访问ReqDataContainer的手段。即使某个元素没有 垂直数据（即，只有该元素的一次迭代），它仍然可以采用RDCPtr的 形式返回。这样，函数不必净皮重写来接受ReqDataContainer和 RDCPtr,所有的函数可以简单地接受一个RDCPtr。通过传递一个较小 的RDCPtr，整个调用程序可以随才几或顺序地访问整个垂直it据堆。该 特征可以促成更容易、较无变动（cleaner)且更准确的代码实现。 此外，通过采用RDCPtr，调用程序不必向/从存储器创建或删除 ReqDataContainer,如本文所述该过程可以完全自动地进行。
[0084] iRDCPtr类可以提供将ReqDataContainer "左和右"编排 进列表的机制。iRDCPtr类不是由调用程序使用，但是可由后端（例如，用于和XML文件接口的包装器）使用来实现通过同级和写递归算 法的顺序搜索法4臾索ReqDataContainer树（ReqDataContainer不在 ReqDataContainer树^己录其同级）。调用禾呈序可以通过索引（即通过 唯一参考识别符）访问ReqDataContainer的子容器，但不能顺序地 遍历ReqDataContainer的子容器以搜索找到它所需要的子容器，但 是对于内部进程来说，CGenericXMLWrapper可以使用iRDCPtr来顺序 地遍历ReqDataContainer的子容器。
[0085]调用程序应当使用CWrapperLibrary类来得到用于XML 文件的包装器。出于存储器管理的目的，自动化需求验证工具115及 其后端可以-使用一个类来管理资源的分配和删除。例如，CXMLWrapper 类可以用于创建所需要的ReqDataContainers、RDCPtrs和iRDCPtrs。 调用程序可以基于请求获得RDCPtrs,并且由CXMLWrapper表示的整 个XML文件可以由CXMLWrapper创建和删除。继而，CXMLWrapper可 以注册利用GlobalRDCPool对象创建的所有对象（比如 ReqDataContainers ) ， GlobalRDCPool对象可以由调用程序在退出的 时候清空。
[0086]此外，自动化需求验证工具115及其后端可以利用被称作 CWrapperLibrary的类来管理CXMLWrappers,管理方式和 GlobalRDCPool类管理RDCPtrs的方式相同。由于CWrapperLibrary 的存在，调用程序根本不必创建包装器。相反，调用程序可以向 ReqDataContainer树请求获得XML文件。如果还未为该请求的XML 文件建立ReqDataConta iner树,贝'J可以使用CWrapperLibrary类来 创建包装器，让包装器建立ReqDataContainer树，并且向调用程序 返回一个指向所创建的包装器的指针。如此，CWrapperLibrary可以 组织调用程序正在^f吏用的所有CGenericXMLWrappers。例如，如果调 用程序请求和"f ilel一trace. xml"对应的包装器，CXMLWrapper可以 搜索已经建立的包装器库来查找filel-trace. xml的CXMLWrapper对 象。如果用于filel-trace. xml的CXML Wrapper对象已经被创建， 则CXMLWrapper可以简单地将指向已经生成的CXMLWrapper的指针返 回给调用禾呈序，否贝'J CWrapperLibrary可以为f ilel一trace. xml产生 一个新的CXMLWrapper对象，并且将指向新对象的指针返回给调用程 序。[0087]象RDCPtrs—样，CXMLWrapper对调用程序隐藏存储器的 分配，使得调用程序不负责释放CWrapperLibrary传递回来的对象。 同样，当调用程序使用CWrapperLibrary的时候，该程序的所有部分是XML文件中的单个元素，故此ReqDataContainer的树表示整个XML 文件），并且调用程序并不必要遍历该程序实行同步。
[0088]通常，调用程序将调用GetFile()方法来^r索RDCPtr中 的文件根元素，并且将不会再对包装器作任何进一步的调用。调用程 序不删除被创建的包装器。相反，EmptyWrappers()方法（它也将所 有已被开启的包装器写入存储设备）可以用替代方式删除包装器。如 此，CWrapperLibrary类可以用于确保自动化需求管理程序的所有工 作都在相同的ReqDataContainer树上并且有助于存储器管理。
[0089]各个存储器管理类在一起使用的时候可以得到一个不间 断存在的RDCPtrs (即，调用程序在会话开始时接收的RDCPtr与调用 程序在会话期间后续时间接收的RDCPtr相同），以此允许调用程序 使用的相同GlobalRDCPool和CWrapperLibrary各个部分将RDCPtrs 到处传递。因此，调用程序决定要求存储器管理类清空它们自己的时 间是一个重要的决策点。出于充分利用存储器的原因，在某些情况下， 强制清空包装器和RDCPtrs甚至可以是可取的。这种存储器管理技术 可以导致在程序的生命周期中存储器利用率的提高。 一旦存储器利用 率达到一定的水平，它不太可能进一步增加，但是对于在其生命周期 中可能打开数十个或甚至数以百计XML文件的程序来说，强制清空存 储器管理类可以是有益的。但是应当注意对存储器管理类所管理的资 源的引用在对这些资源清空后将不再需要。
[0090]在一个实施方案中，线程可以转换为SQL格式，以便全局 网络存储和访问。该进程可以由接受来自自动化需求验证工具115的 上载请求的网络（web)服务支持。同一个网络服务可以基于来自网 络用户的请求产生跟踪和验证报告。另外，该网络服务可以向自动化 需求验证工具115提供下载请求。这些网络服务的结果是，可以促进 全局项目同步。示例性图形用户接口实现[0091]图4A-4J示意了用于由LDRATM开发的软件需求管理工具 TBmanagerTM的图形用户接口 （GUI)的示例性实J见。TBmanagerTM可 以用于促进软件需求的管理和分配，以便开发、测试和验证。本领域 的普通技术人员将理解到，GUI设计不必受限于图4A-4J中示意的设 计，其它的GUI设计也可以采用。在该实施方案中，可以利用需求捕 获工具（比如GeensysTM开发的TBreqTM)首先创建一个项目文件（例
如，具有".tbp"扩展），需求捕获工具可以从诸如Telelogic DOORS® 或IBM Rational RequisitePro®, MS Excel®, MS Word⑧的需求信 息源和其它需求信息源捕获用于软件开发项目的需求信息。 定义角色和用户 [0092]图4A示意了在初始设置期间定义项目的角色的示例性 GUI401。角色可以用于将执行类似或有关任务的用户编组在一起；例 如，可以对项目的所有开发者创建并应用一个角色。每个用户可以分 配一个角色。 一个用户可以采用项目管理者的角色。项目管理者角色 可以对需求管理进程的每个方面进行控制，可以负责创建角色和用户
以及委托需求。例如，项目管理者可以创建和分配角色，授权其他用 户创建角色和委托需求的能力。
[0093]如图4A所示，GUI401的新角色字段402可以用于输入新 角色的名字，并且可以按压Add按钮添加该新角色。示例性角色403 可以包括开发者角色、GUI设计者角色、独立验证和确认（IVV)角色、 质量保证（QA)角色和测试工程师角色以及其它角色。如图4A所示， 可以利用Remove Selected (去除选定）按钮来去除某个已添加角色， 并且可以选择Import Roles From File (从文件引入角色）按钮来引 进已经定义在文本文件或另一个项目中的角色。
[0094]可以给各角色分配权限，为相应的用户赋予不同级别的 功能，比如定义用户可以访问的需求信息和他们可以完成的动作。如 图4A所示，可以利用Assign Permission (分配权限）按钮将权限分 配给角色403。示例性权限404可以包括"Create Low Level (LL) Reqs"(创建低级需求），它可以被分配给某角色来允许相应的用户创建低 级需求；"Create Derived (DV) Reqs"(创建衍生需求），它可以被 分配给某角色来允许相应的用户创建衍生需求；"Make SubProjects
(生成子项目）"，它可以允许相应用户为项目需求分配用户；"EditThread Properties"(编辑线程属性），它可以分配给某角色以允i午 相应的用户通过本文描述的Requirements View (需求-f见图）编辑可 用的需求属性；以及，"Manual Verification"(人工驺ri正），它 可以被分配给某角色以便使相应用户访问本文描述的Verification View (验证视图）。
[0095]角色可以用于使用户之间的分配需求多样化。如此，相 同的需求（通过同级需求）可以被分配给两或多个不同角色的用户， 而同时保持对开发和验证任务的跟踪。例如，相同的需求可以分配给 开发者进行编码，给QA进行测试，给IVV进行独立的验证和确认。
[0096]类似地，图4B示意了为项目定义用户的示意性GUI405。 如图4B所示，新的用户字段406可以用于为新用户输入名字，为该 新用户选择相应的角色，并且可以通过按压Add按钮添加新用户。添 加的用户可以显示在用户字,殳407。可以利用Remove Selected (去 除选定）按钮从项目中去除所添加的用户，可以选择Import Roles From File (从文件引进角色）按钮来引进此前在另 一文件定义的用 户。
[0097]当跟随有本文描述的子项目更新时，在设立之后添加新用 户和角色可以安全进行。但是一旦如本文所述为用户分配了需求，则 用户和角色将不能删除。例如，删除一个角色将导致某用户丢失在项 目工作的必要权限，删除用户将导致需求未被分配。因此，在删除角色和用户时应当留意。 基于类型视图进行解析 [0098]可以引进需求文档并且对之解析。解析工作可以基于类 型进行。解析提要必须描述在类型文件中。如图7所示，许多类型文 件可以预先定义，涵盖通常使用的工具，比如图表软件（Visio 702 ); 需求管理工具（DOORS 704和706,以及Rational Requisite Pro 708 ); 字处理程序（比如MS Word 710);电子表格程序（Excel 712);以 及创作和出版软件（比如Framefflaker 714)。类型文件可以是一个转 换器，使得它可以理解需求如何描述在参考文件中。
[0099]图8示意了 MSWord文件中的需求例子。如图8所示，必 须给需求ID 802和需求文本804采用合适的样式（style),使得文 件可以按作者希望的方式解析。[0100]图9和图10示意了类型编辑器的例子。文档中采用的MS Word样式，包括需求ID 802和需求正文804在内，必须描述在类型 编辑器字段902和1002中，以便MS字文件可以^皮正确解析。 组视图
[0101]项目的各马全证组可以创建在一个用户下。图5示意了在 "Verification Groups" ^H舌才匡500下选择、创建、重新命名或删 除组视图的例子。如图5所示，点击"NewGroup"(新组）按钮502 创建验证组。当点击"New Group"按4丑502的时候，对话框"Enter Group Information"(输入组信息）518出现。可以在名字文本字段 514输入验证组的名字。在此例子中，在名字文本字段514中输入组 名字"High Priority (高优先级）"。此外，在描述文本字段516 输入描述"Must be implemented in the current spiral"(必须 在当前螺旋中实现）。当点击"OK"按钮的时候， 一个验证组得以创 建。
[0102] —旦创建了验证组，用户可以突显该组并且点击"Rules >，，（规则）按钮508，为某个给定组编辑验证规则。图6示意了在"Edit Rules"(编辑规则）对话框600中为给定组编辑规则的例子。参看 图6，当点击"New"(新）按钮610时，"NewRule"(新规则）对 话框616出现。在"New Rule"对话框下，规则分别在文本字段602 和604规定需求必须满足"Unit Testing"(单元测试），并且必须 由"The Requirement's Assignee"(需求受指派人）完成。可供选 择的验证规则可以包括：代码审查、质量审查、系统测试、单元测试、 子系统测试和集成测试。也可以判断被分配给该需求的用户是否被允 许执行该测试，或者是否必须由另一用户执行该测试。当点击"OK" 按钮606时，新规则便被创建在"High Priority"(高优先级）组 下。"< Group"(组）608按钮可以用于返回"Verificat ion Groups"(验证组）对话框500。 "Save and Use"(保存和4吏用）按钮612 可以用于保存这些规则，供将来之用。"Use Existing"(使用现有 的）按钮614可以用于为给定组选择所保存的规则。
[0103]返回图5， "Rename Group"(重新命名组）按钮504可 以用于对该组重新命名，如果它已经;故创建的话。"Delete Group"(删除組）按钮506可以用于删除某个组。"Save and Use"(保存和使用）按钮可以用于保存组信息设置，供将来之用。"Use Existing" (使用现有的）按钮512可以用于为给定组选择所保存的组信息设置。 [0104]在按照上文对组定义之后，需求可以和该组关联起来。图 11示意了未编组需求和编组需求的例子。在图11中，REQ 1 1102 和REQ 2 1104是未编组需求。REQ 3 1106和REQ 4 1108净皮包含在命 名为"Static Testing"(,争态测试）的组别中。 同级需求视图
[0105]图12示意了同级需求视图的例子。在图12中，两个同级 需求1202和1204对应于需求1206。同级需求1202供代码审查用， 同级需求1204供质量审查用。
[0106]验证可以由该组同级需求驱动，并且每个同级需求都要 求一个单独的测试运行被执行。需求只有在所有和该需求对应的同级 需求被验证之后才算验证通过。
[0107]图13示意了同级需求视图的另一个例子。在图13中，同 级需求1306位于与命名为"Sam Brown"的开发者有关的命名为"Static Testing"(静态测试）1304的组别之下。同级需求1306 表明验证任务是代码审查。在该例子中，同级需求的验证状态1308 是"Passed"。它也表明分别命名为CashRegister. cpp和 Backbeat.cpp 1310和1312源文件和同级需求1306有关。 项目视图
[0108]如图4C所示，GUI可以有选项卡式的格式，为用户提供可 供选择的不同视图（例如，项目、验证、定义需求、需求信息、分配 用户、映射过程、以及过程）和可以基于其被分配角色而执行的动作。 图4C示意了在选择Project View (项目#见图）标签的时候可以显示 的GUI 408。项目GUI 408可以显示被分配给用户和被用户分配的所 有需求（例如，粗体的需求可以表示被分配给用户的需求，非粗体的 需求可以表示为用户已经分配的需求）。
[0109]项目GUI 408包括当前需求下拉菜单409,该菜单可以用 于选择和显示项目的特定需求。GUI 408也包括一些按4丑，比如可以 用于选择供上载的项目或子项目文件的Open Project (打开项目）按 钮410a,可以选择用于利用对项目需求所做的近期修改来更新/同步 所有当前签入的子项目的Update Sub-Projects (更新子项目）按钮410b，可以选择来基于项目的当前需求显示状态4艮告的Status Report (状态报告）按钮410c，可以选择用来对当前项目添加/上载代码源 文件的Add Source (增加源）按4丑410d,可以选择用来从当前项目 去除当前选定的源代码文件的Remove Source (去除源）按钮410e, 可以选择用来发布单元测试用的外部工具（比如LDRA TestbedTM和 TBrun™)的Unit Test (单元测试）按钮410f,以及如果当前用户 有必要的4又限的话可以选择来设立角色和用户的Setup Wizard (i殳置 能手）按钮410g。项目GUI的其它元素分别包括可以选择用来显示用 户指引的User Gu ide按钮411,以及可以选择用来分别退出工具和保 存当前项目的Exit and Save (退出和保存）按4丑413和414。
[0110]项目GUI 408也可以显示项目树412，列明^皮分配给用户 的各个需求和添加到项目的任何源代码文件。需求树412可以按号码、 名字、参考标识符和类型显示每个需求，这里可以采用不同的图标表 示不同类型的需求。此外，"X"号可以覆盖在需求图标上，以表明 相应的需求是未被验证的。为了观看某个需求的更多信息，用户可以 选择本文描述的Requirement Information (需求信息）标签。
[0111]对子项目的更新可以进行，将对项目的各项需求的修改 分发给受影响的子项目。为了更新子项目，用户应当首先签入他们的 子项目。然后，在修改需求（例如重新分配需求，未验证需求等等） 之后，可以选择Update Sub-Projects (更新子项目）按4丑410b来散 发该修改给所有受影响的签入子项目，使得当用户后来签出他们的子 项目的时候，他们可以访问该修改。尽管只有工作在受需求修改影响 的子项目的用户需要在更新子项目之前签入他们的子项目，但是所有 用户应当签入它们的子项目以便完成对用户的修改（例如，当从/往 项目去除/添加用户的时候）。
[0112]在一个实施方案中，用户可以通过4会压Status Report (状态报告）按钮410c产生状态报告，以显示所有和用户相关的需 求的当前状态。状态报告可以提供被分配给用户或由用户分配的需求 的汇总，可以显示详细的需求属性，比如需求名称、需求号、需求文 件、需求体、分配给需求的用户和被分配用户的角色。随着项目的进 行以及过程被映射到需求，如本文所述，状态报告可以被更新，以便 纳入每个需求的被映射过程表。该表可以显示被映射过程的详细属性，比如过程名字、源代码文件的名字和位置、所取得的路径覆盖、所取得的分支判决覆盖、所取得的MC/DC覆盖和所取得的语句覆盖。 表中的取得覆盖字段可以保持为空，直至对被映射过程的测试已经完 成，如本文所述。在单元测试完成之后，这些字萃殳可以更新以显示所 取得的覆盖。另外，在单元测试完成之后，状态报告可以指明取得所 需覆盖的被测试映射过程的百分比。状态报告也可以配置为区分获验 证和未获验证的需求被显示的方式，例如采用不同颜色的文本来加以 显示。
[0113]在对需求定义并且将用户分配给所被定义需求（如本文所 述）之后，可以通过选择Add Source (增加源）按4丑410d,将已经 由用户开放的源代码添加到项目中。 一旦添加之后，源代码可以显示 在项目树412中。值得注意，源代码文件可以添加到项目而不是需求 自身，这是因为源代码文件中的过程，而不是源代码文件自身，可以 4皮映射到需求中，如本文所述。也可以通过选择拟在Project Tree (项目树）412中去除的源代码文件并且按压Remove Source (去除 源）按钮410e，将源代码文件从项目中去除。 需求信息视图
[0114]图4D示意了在Requirement Information (需求信息） 标签被选择时可以显示的GUI 415。需求信息GUI 415可以显示有关 当前选定需求的信息。具体地说，需求信息GUI 415可以将当前选定 的需求的有关信息编组为三个关注区域：test configurat ion (观寸试 酉己置)、test management (观'H式管理)和requirement nomenclature (需求命名）。Test Configuration下拉菜单416可以用于观看和编 辑当前选定需求的测试配置特性的有关信息，Test Management下拉 菜单418可以用于观看和编辑当前选定需求的测试管理特性，而 Requirement Nomenclature下拉菜单417可以用于观看和编辑当前选 定需求的需求命名的有关信息。需求信息GUI 415包括View/Edit(观 看/编辑）区419,其中可以显示和/或编辑选定需求。当不允许用户 编辑和被选定需求信息有关的数值或描述时，View/Edit区419可以 变灰。定义需求视图
[0115]在项目的寿命周期期间，可能需要引入新的需求或改进现42有需求。为了定义某个需求，可以选择Define Requirement (定义需 求）标签。图4E示意了在选定Define Requirement标签的时候可以 显示的GUI 420。利用定义需求GUI 420，用户可以根据被分配给用 户的相应角色的权限，创建并且添加低级或衍生需求到项目中去。如 本文所述，高级需求包括被需求捕获工具所捕获并且引入项目中的 需求。低级需求包括和高级需求有关的需求。衍生需求包括未被需求 捕获工具捕获但在TBmanagerTM中定义并且由高级或低级需求推知或
衍生得到的需求。
[0116]如图4E所示，定义需求GUI 420包括可以用于输入被定 义需求的名字的Requirement Name (需求名字）字革更421,可以用来 选择被定义需求是否是衍生（DV )或低级（LL )需求的Requirement Type (需求类型）单选按钮422，可以在定义低级需求时使用来选择和该 低级需求相关联的高级需求（否则可以选择NONE (DV需求））的 Reference Requirement (参考需求）下拉菜单423。定义需求GUI 420 也包括可以用来输入被定义需求的号码的Requirement Number (需求 号）字段424。在一个实施方案中，项目的每个需求要求有唯一的识 别号，它可以由TBmanagerTM自动填写。定义需求GUI 420也包括可以用来输入到详细描述被定义需求的文件的路径的Requi rement Document Path (需求文件路径）字段425 ( Browse按钮可以用于找 到该文件），可以用来输入纟皮定义需求的简短描述的Requirement Body
(需求体）字段426，可以用来清除定义需求GUI 420的所有字段的 Clear (清除）按钮427，和可以在按压后创建新需求的Create LL/DV
(创建）需求按钮428。在一个实施方案中，在向项目引入需求的时 候，TBmanagerTM可以自动使用规定在才莫板中的数值作为该新需求的
期望代码覆盖的数值。新定义的低级或衍生需求可以显示在项目树 412中。
[0117]在项目的寿命周期期间，可能有必要摒弃或忽略某个需 求，以便它不再被考虑用于验证。用户可以通过项目GUI 408选择拟 在项目树412中解除分配的需求，并且通过定义需求GUI 420利用 De—allocate/Re— allocate Current Requirement (解除/重#斤分酉己 当前需求）按钮429解除对选定需求的分配。De-allocate/Re-allocate Current Requirement按钮429可以配置为相对于选定需求的上下文相关的按钮，使得它根据需要在"De-Allocate Current Requirement"(解除当前需求）和"Re-allocate Current Requirement"(重新分配当前需求）之间切换。如jt匕，用户可以通 过项目GUI 408选择项目树412中的被解除分配的需求，按相似方式 重新分配该;陂解除分配的需求，并且可以通过定义需求GUI 420利用 De—allocate/Re—allocate Current Requirement按4丑429重#斤分酉己 被选定需求。 分配用户^L图
[0118]已经建立项目的角色和用户之后，可以通过选择Assign Users标签，为用户分配要工作的需求。图4F示意了在Assign Users 标签被选定的时候可以显示的GUI 430。利用该分配用户GUI 430， 具有必要权限的用户可以分配各用户给各个需求，并且创建同级需 求。如本文所述，可以出于需求多样化和任务管理的需要，在 TBmanagerTM中创建同级需求，并且代表项目的高级、低级或衍生需求的副本。拟分配的需求可以通过项目GUI 408从项目树412中选出， 或者通过分配用户GUI 430从Current Requirement (当前需求）下 拉菜单中选出。
[0119]分配用户GUI 430包括"Assigned to this Requirement" (分配给该需求）字段，它有一个可以显示被分配给当前需求的用户 名字的User字#爻431和可以显示^皮分配给该用户的角色的Role字賴: 432。分配用户GUI 430也包4舌"Assign User"(分配用户）字l爻， 它有一个可以用于基于项目的用户435的相应角色434识别哪些用户 可供选择的Filter by Role (按角色过滤）下拉菜单433。可以选择 Assign to Requirement (分配给需求）按钮436来将识别出用户435 中的一个选定用户分配给当前需求。
[0120]为了完成该分配并且为该用户创建一个子项目，可以通 过项目GUI 408然后由Update Sub- Projects (更新子项目）按4丑 410b选择Save (保存）按钮414。在一个实施方案中，可以在项目目 录中建立命名为"Sub-Projects (子项目），，的目录，以容纳所有该 用户的子项目。每个用户可以具有单独的子项目目录，它可以在首次 分配一个需求的时候自动创建。然后用户可以打开他们各自的子项目 来就被分配的需求开展工作。用户可以将他们的子项目目录复制到不同的机器（例如他们自己的安装有TBmanagerTM的工作站或笔记本） 来开展所分配需求的工作。用户然后可以在其机器上启动 TBmanagerTM,通过项目GUI 408选择Open Project (打开项目）按 钮410,导航到子项目目录，并且选择适当的子目录来开展工作。用 户可以净皮要求在登陆时输入名字。然后，项目GUI 408可以刷新自身， 以显示用户项目和所分配的需求。
[0121]分配用户GUI 430也可以用来创建同级需求，它是已有高 级、低级或衍生需求的副本。同级需求可以，在除了:l皮分配给该同级 需求的唯一识别符以外，和相应的高级、低级或衍生基本需求相同。同级需求可以在被创建的时候复制基本需求线程。如此，同级需求可 以允许用户将相同的需求分配给具有不同角色的多个用户（一个同级 不能被分配给具有相同角色的两个用户）
[0122]为了创建同级需求，通过选择Create Sibling Req + Assign (创建同级需求+分配）按钮437，经分配用户GUI 430显示的 用户435之一可以被选定并且分配给同级需求。在一个实施方案中， 被分配给同级需求的用户应当具有不同于被分配给基本需求的用户 的角色。新创建的同级需求可以通过项目GUI 408观看，并且在项目 树412中将其显示为基本需求的子需求。仅仅有制作子项目权限的用 户应当被允许创建同级需求。
[0123]由于同级需求可以被看成相应基本需求的严格副本，如 果基本需求发生变化，则其所有的相关同级需求应当被解除分配，如 本文所述。然后，修改后的基本需求的新同级需求可以被创建并且分 配给适当的用户。如果基本需求有新过程分配给它，有它的需求体发 生改变，或者任何其它的可能影响据以验证基本需求的条件的变化发 生，那么应当创建新的同级需求。 映射过程视图
[0124]图4G示意了在选择Map Procedures (映射过程）标签的 时候可以显示的GUI 438。在向项目添加用户开发的源代码文件之后， 如本文所述，映射过程GUI 438可以用于选择一个添加的源代码文件， 为可用的过程分析该选定源代码文件，并且将选定的过程映射到一个 当前选定需求。可以利用Project Source Files (项目源文件）下拉 菜单439，来选择已经被添加到当前项目的源代码文件并且返回在选定源代码文件中找到的过程列表442 。例如，可用调用LDRA Tes tbedTM 工具来分析选定源代码文件并且将识别出的过程列表442返回给 TBmanagerTM。
[0125]可以通过分别选择Analyze Procedures (分析过程）按钮 440和Analyze Interactively (交互分析）按钮441 ，以静态和/或 交互方式分析选定源代码文件与项目编码规则和质量度量之间的一 致性。也可以调用LDRA TestbedTM来对选定源代码文件进行静态和/或交互的分析。如果希望采用交互分析，那么用户可以进行代码审查、 质量审查和设计审查分析。完成分析之后，映射过程GUI 438可以显 示在选定源代码文件中找到的识别过程442。利用Map to Current Requirement (映射到当前需求）4安4丑444，用户可以将某个识别出的 过程442映射到当前需求，后者可以通过项目GUI 408利用Current Requirement (当前需求）下拉菜单或Project Tree (项目树）412 选择。类似地，可以选择Unmap Selected (解除选定的映射关系）4安 钮443来解除某个识别出的过程442和当前需求的映射关系。在将过 程映射到需求之后，用户可以选择Procedures (过程）标签来观看被_ 映射到当前需求的过程的列表。 过程视图
[0126]用户可以选择当前需求的映射过程并且通过过程GUI 445 观看其相应的输入和输出（1/0)，如图4H所示。过程GUI 445包括 一个Select Procedure下拉菜单446,它可以用于从映射到当前需求 的各过程中选择一个过程。可以从Current Requirement (当前需求） 下拉菜单或通过项目GUI 408从Project Tree (项目树）412选择当 前需求。作为选择映射后过程的结果，过程GUI 445可以被更新，以 显示1/0变量字段447中的选定被映射过程的1/0变量。另外，过程 GUI 445包括可以用来为当前需求修改期望代码覆盖值（例如，语句、 分支、MC/DC、和路径覆盖值）的Desired Coverage (所需覆盖）字 段449，和可以用来在单元测试之后观看所取得覆盖的Coverage Achieved at Verification (验证所取得的覆盖）字,殳450。可以选 择Unmap This Procedure (解除该过程的映射关系）448来解除选 定被映射过程和当前需求之间的映射关系。
[0127] —旦各过程被映射给需求，就可以启动单元测试。首先，可以从Project Tree (项目树）412或通过项目GUI 408从Current Requirement (当前需求）下拉菜单409选择有待测试的被映射过程 的需求。接下来，为了启动单元测试，在按压Unit Test (单元测试） 按钮410f后，包含被映射到选定需求的过程的源代码文件可以被选 择。然后，可以调用外部单元测试工具来完成单元测试。例如，LDRA TBrunTM是可以经LDRA TestbedTM工具调用的单元测试工具。利用该 外部测试工具，可以创建用于被映射过程的测试用例。然后，可以选 择待测试的被映射过程，可以输入测试用例的各个输入和期望输出， 并且运行测试用例。
[0128]如果测试用例的结果是令人满意的并且取得了期望的代 码覆盖，那么应当确认需求验证结束。在确认需求验证的完成之前， 对某个需求的每个被映射过程应当采用至少 一个测试用例来进行测 试。在关闭外部单元测试工具之后，TBmanagerTM可以刷新Project Tree (项目树）412来显示该需求为通过验证的（例如，相应的需求 图标在显示时可以不带"X"符号）。项目管理者现在可以审查项目 的单元测试信息，评估用户的工作。 验证视图
[0129] —旦用户对某需求的各被映射过程进行了单元测试，就 可以在Project Tree 412将该需求显示为"已获验证"，如项目GUI 408所示。但是，由于对映射过程的单元测试可能没有取得期望的覆 盖，项目管理者或具有必要权限的其它用户应当审查单元测试的结 果，并且判断是否该需求实际上应当被视为已获验证。
[0130]取决于^皮分配给用户的权限，用户可以通过选择 Verification标签来访问验证GUI 451,验证某需求是否已经达到期 望的代码覆盖，如图4I所示。为了验证某个需求，用户可以经项目 GUI408或经验证GUI 451从Current Requirement下拉菜单，从 Project Tree 412中选择拟验证的需求。验证GUI 451包括显示^皮选 需求452的当前状态的Details (细节）字段453。 Details字段453 指明被分配给选定需求452的用户及其角色、期望的代码覆盖、和取 得的代码覆盖，后者可以根据取得期望覆盖的被映射过程的百分比加 以显示。如果用户对所选定需求取得的覆盖满意，那么用户可以按压 Verify (验证）按钮454将选定需求的当前状态维持为已获验证。但是，如果用户对选定需求所取得的覆盖不满意，那么用户可以按压Un-ver if y (未—睑证）按4丑455，将选定需求的当前状态改为未获验证。 由于将需求标记为未获验证的做法改变了该需求，那么用户应当更新 任何和该需求相关的子项目。
[0131]对于同级需求的验证，同级需求在相当程度上象低级需 求。换言之，为了让基本需求被看作为已获验证，它的所有同级需求 必须先获验证。例如，如果开发者用户已经分配了一个低级需求，它 具有两个同级需求， 一个用于IVV用户而另一个用于QA用户，开发 者不能指明该低级需求是获验证的，直到IVV和QA用户将相应的同 级需求标记为获-睑证。
[0132] —个TBmanagerTM的示例性用途场景如下文所述。首先， 项目管理者可以基于捕获的高级需求建立一个项目、创建低级、衍生 和同级需求（如果恰当的话），将各需求分配给各个用户。用户可以 签出它们各自的子项目，所述子项目是在项目管理者将需求分配给用 户时建立的。换言之，用户可以出于在远程展开子项目工作的考虑制 作他们的子项目的副本。用户可以通过映射过程、测试和分析源代码 等操作，修改子项目。然后，用户可以签入它们的修改的子项目。换 言之，用户可以将子项目的更新内容复制回项目的目录树。项目管理 者可以在后续登录，并且获得项目所有方面的完整的当前视图。 缺陷视图
[0133]图4J示意了当缺陷标签净皮选定时可以显示的GUI 456。 在一个实施方案中，用户可以通过缺陷GUI 456跟踪项目源代码中的 缺陷。例如，缺陷GUI 456可以用于基于静态分析工具所进行分析的 结果，跟踪源代码中的缺陷（即不一致性）。如图4J所示，用户可 以通过选择"Add Defect"(增加缺陷）4姿4丑457,添加拟多艮踪的缺 陷。添加的缺陷458与该缺陷的有关信息以及缺陷处置信息一起显示， 该有关信息包括例如缺陷号、创建日期、状态、和被分配给缺陷的用 户。添加缺陷458也可以被选择用于编辑。 结论
[0134]上文结合多个示例性实施方案对本发明进行了描述，但 是相关领域的普通技术人员易于理解的是有可能采用不同于前文描 述的示例性实施方案的方式来实施本发明。这在不偏离本发明范畴的情况下是可行的。这些示例性的实施方案仅仅是示意性的，无论如何 不应当看作为限制性的。本发明的范围由后附的权利要求书而不是前 文的说明书限制，并且所有落入权利要求书范围之内的所有变化和等 价物均被^f见为包含在内。
