CN113704135B - 一种需求覆盖验证方法及装置 - Google Patents

Abstract

本发明公开了一种需求覆盖验证方法及装置，主要技术方案包括：获取待验证的需求矩阵，需求矩阵中包括有至少一个需求项，需求项对应于城市轨道交通项目的合同文档中的需求；确定各需求项对应的覆盖项，覆盖项对应于城市轨道交通项目的技术文档中为对应的需求项设计的技术内容；将属于同一子系统的需求项分类至同一个子表中；验证各子表中存在对应关系的需求项和覆盖项；将未通过验证的目标需求项提供给其所在子表对应的子系统，目标需求项对应的覆盖项不能满足其需求；基于未通过验证的目标需求项生成新的需求矩阵，将新的需求矩阵作为待验证的需求矩阵，继续进行需求覆盖验证，直至不存在目标需求项为止。

Description

一种需求覆盖验证方法及装置

技术领域

本发明涉及城市轨道交通项目技术领域，特别是涉及一种需求覆盖验证方法及装置。

背景技术

随着城市轨道交通的快速发展，大量的城市轨道交通项目被部署到城市中，以解决城市中人们的出行需求。在城市轨道交通项目启动初期，通常在签署城市轨道交通项目合同的同时也会附带技术合同，该合同文档中会记录有需求，以这些需求限定城市轨道交通项目交付时需要达成的技术成果或实施效果。

为了保证城市轨道交通项目交付时能够与技术合同中的需求相应的技术成果或实施效果，需要对合同文档中的需求进行覆盖验证。目前，针对合同文档中的需求进行覆盖验证时，需求维护人员需要出具合同文档中的需求，并根据技术文档为各需求添加覆盖信息，然后验证人员根据覆盖信息验证需求是否被覆盖。一旦完成一轮验证后存在验证不通过的需求，需要人工识别出所有验证不通过需求，并将人工识别出的需求复制出来，更新其对应的覆盖信息，进行下一轮的验证。可见，整个需求覆盖验证过程中需要大量重复性的人工识别、复制、粘贴等维护工作，人工成本高，效率低，且由于人工可能存在疏漏，而出现一些需求追踪丢失和追踪错误，使得需求覆盖验证的正确性及完整性无法得到保证。

发明内容

有鉴于此，本发明提出了一种需求覆盖验证方法及装置，主要目的在于提高需求覆盖验证的完整性及效率。

第一方面，本发明提供了一种需求覆盖验证方法，该方法包括：

获取待验证的需求矩阵，其中，所述需求矩阵中包括有至少一个需求项，所述需求项对应于城市轨道交通项目的合同文档中的需求；

确定各所述需求项对应的覆盖项，其中，所述覆盖项对应于所述城市轨道交通项目的技术文档中为对应的需求项设计的技术内容；

将属于同一子系统的需求项分类至同一个子表中，其中，所述子系统为所述城市轨道交通项目中的子系统；

验证各所述子表中存在对应关系的需求项和覆盖项；

将未通过验证的目标需求项提供给其所在子表对应的子系统，以供所述子系统的业务人员修改所述技术文档中目标需求项的覆盖项对应的技术内容，其中，所述目标需求项对应的覆盖项不能满足其需求；

基于未通过验证的目标需求项生成新的需求矩阵，将新的需求矩阵作为待验证的需求矩阵，继续进行需求覆盖验证，直至不存在目标需求项为止。

第二方面，本发明提供了一种需求覆盖验证装置，该装置包括：

获取单元，用于获取待验证的需求矩阵，其中，所述需求矩阵中包括有至少一个需求项，所述需求项对应于城市轨道交通项目的合同文档中的需求；

确定单元，用于确定各所述需求项对应的覆盖项，其中，所述覆盖项对应于所述城市轨道交通项目的技术文档中为对应的需求项设计的技术内容；

分类单元，用于将属于同一子系统的需求项分类至同一个子表中，其中，所述子系统为所述城市轨道交通项目中的子系统；

验证单元，用于验证各所述子表中存在对应关系的需求项和覆盖项；

提供单元，用于将未通过验证的目标需求项提供给其所在子表对应的子系统，以供所述子系统的业务人员修改所述技术文档中目标需求项的覆盖项对应的技术内容，其中，所述目标需求项对应的覆盖项不能满足其需求；

生成单元，用于基于未通过验证的目标需求项生成新的需求矩阵，将新的需求矩阵作为待验证的需求矩阵，继续进行需求覆盖验证，直至不存在目标需求项为止。

第三方面，本发明提供了一种计算机可读存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行第一方面所述的需求覆盖验证方法。

第四方面，本发明提供了一种存储管理设备，所述存储管理设备包括：

存储器，用于存储程序；

处理器，耦合至所述存储器，用于运行所述程序以执行第一方面所述的需求覆盖验证方法。

借由上述技术方案，本发明提供的需求覆盖验证方法及装置，当确定存在需求覆盖验证需求时，获取包括有需求项的待验证的需求矩阵，并确定各需求项对应的覆盖项。然后将属于同一子系统的需求项分类至同一个子表中，并验证各子表中存在对应关系的需求项和覆盖项。当存在未通过验证的目标需求项时，将未通过验证的目标需求项提供给其所在子表对应的子系统，以供子系统的业务人员修改技术文档中目标需求项的覆盖项对应的技术内容。最后基于未通过验证的目标需求项生成新的需求矩阵，将新的需求矩阵作为待验证的需求矩阵，继续进行需求覆盖验证，直至不存在目标需求项为止。可见，本发明提供的方案能够实现需求覆盖验证过程的自动化管理，实现需求覆盖验证的需求项和覆盖项的自动识别、提取、分类、验证，降低需求覆盖验证的复杂性。另外，实现验证未通过项的需求项的提取，并针对验证未通过需求项的再次需求覆盖验证，从而降低业务流转的复杂度，避免出现需求项遗漏验证的情况，进而提高需求覆盖追踪及验证的完整性和效率。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了本发明一个实施例提供的一种需求覆盖验证方法的流程图；

图2示出了本发明另一个实施例提供的一种需求覆盖验证方法的流程图；

图3示出了本发明一个实施例提供的一种需求覆盖验证装置的结构示意图；

图4示出了本发明另一个实施例提供的一种需求覆盖验证装置的结构示意图。

具体实施方式

下面将参照附图更加详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

随着城市轨道交通的快速发展，大量的城市轨道交通项目被部署到城市中，以解决城市中人们的出行需求。在城市轨道交通项目启动初期，通常在签署城市轨道交通项目合同的同时也会附带技术合同，该合同文档中会记录有需求，以这些需求限定城市轨道交通项目交付时需要达成的技术成果或实施效果。城市轨道交通项目启动后技术人员需要根据合同文档中的需求，进行技术设计，将对应于技术设计的技术内容作为需求的覆盖项配置到技术文档中，以供城市轨道交通项目在实施阶段可以根据技术文档实施。

为了保证城市轨道交通项目交付时能够满足与技术合同中的需求相应的技术成果或实施效果，需要对合同文档中的需求进行覆盖验证。目前，针对合同文档中的需求进行覆盖验证时，需求维护人员需要出具合同文档中的需求，并根据技术文档为各需求添加覆盖信息，然后验证人员根据覆盖信息验证需求是否被覆盖。一旦完成一轮验证后存在验证不通过的需求，需要人工识别出所有验证不通过需求，复制出来，更新其对应的覆盖信息，并对验证不通过的需求进行下一轮的验证。可见，整个需求覆盖验证过程中需要大量重复性的人工识别、复制、粘贴等维护工作，人工成本高，效率低，且由于人工可能存在疏漏，而出现一些需求追踪丢失和追踪错误，使得需求覆盖验证的正确性及完整性无法得到保证。

针对上述提及的现有技术中需求覆盖验证的缺陷，本发明实施例提供了一种需求覆盖验证方法及装置，下面进行具体说明。

如图1所示，本发明实施例提供了一种需求覆盖验证方法，该方法主要包括：

101、获取待验证的需求矩阵，其中，所述需求矩阵中包括有至少一个需求项，所述需求项对应于城市轨道交通项目的合同文档中的需求。

为了保证城市轨道交通项目的安全运行，城市轨道交通项目对应部署有城市轨道交通信号系统。城市轨道交通信号系统是列车行车管理的系统，其是轨道交通网络的大脑。因此，城市轨道交通项目的合同文档中的需求大部分都是针对的城市轨道交通信号系统的需求。

以合同文档中记录的需求限定城市轨道交通项目交付时需要达成的技术成果或实施效果，因此为了保证城市轨道交通项目交付时能够达成满足与需求相应的技术成果或实施效果，需要对合同文档中所有的需求进行覆盖验证。

在进行需求覆盖验证时，需要获取待验证的需求矩阵，该待验证的需求矩阵与执行验证的次数有关，下面进行具体说明：

第一，首次针对合同文档中的需求进行需求覆盖验证，待验证的需求矩阵中包括的需求项为合同文档中的所有的需求项。

第二，非首次针对合同文档中的需求进行需求覆盖验证，待验证的需求矩阵中包括的需求项为上一轮需求覆盖验证后合同文档中未通过验证的需求项。

上述的需求项对应于城市轨道交通项目的合同文档中的需求，也就是说，合同文档中的一个需求对应一个需求项。合同文档中的需求可以基于业务需求确定，本实施例不做具体限定，示例性的，合同文档中包括有诸如无人驾驶需求、运营的互联互通需求等需求，需求矩阵中就包括有对应于无人驾驶需求的需求项和对应于运营的互联互通需求的需求项。

需求矩阵的存在形式可以基于业务要求确定，本实施例不做具体限定，可选的，需求矩阵是一个EXCEL文档内容，它包含了从合同文档中摘取的需求项。

进一步的，为了保证需求维护和需求覆盖验证之间的独立性，需要对需求维护人员和需求覆盖验证人员之间的权限进行隔离。权限隔离从以下两个方面执行：

第一方面，待验证的需求矩阵在具有需求矩阵生成权限的需求维护人员输入的生成指令下生成，也就是说，只有具有需求矩阵生成权限的需求维护人员才有对需求矩阵的维护权限，其他的人员仅能使用需求矩阵，而对需求矩阵无修改权限。

第二方面，仅有在接收到具有需求覆盖验证权限的验证人员下发的验证指令时，才获取待验证的需求矩阵，对需求矩阵中的需求项进行需求覆盖验证，其他的人员不能发起验证。

可见，对于需求维护人员、需求覆盖验证人员两种不同的角色进行了业务范畴的权限划分，确保了人员的独立性，符合欧标EN50126的规范要求。

102、确定各所述需求项对应的覆盖项，其中，所述覆盖项对应于所述城市轨道交通项目的技术文档中为对应的需求项设计的技术内容。

为了保证城市轨道交通项目交付时能够达成与合同文档的需求相应的技术成果或实施效果，技术人员需要对合同文档中所有的需求设计相应的技术内容，这些技术内容被记录到城市轨道交通项目的技术文档中。在验证需求矩阵的需求时，将对应于需求项的技术内容作为需求项的覆盖项提取出来，以验证覆盖项是否能够满足对应的需求项的需求。

103、将属于同一子系统的需求项分类至同一个子表中，其中，所述子系统为所述城市轨道交通项目中的子系统。

城市轨道交通项目的合同文档中的需求大部分都是针对的城市轨道交通信号系统的需求。城市轨道交通信号系统由诸如ATS（Automatic Traffic Supervision ，自动列车监控）系统、CI（Computer Interlocking，计算机联锁）系统等子系统组成，因此，需求矩阵中的需求项均有其对应的子系统。

为了降低需求覆盖验证的复杂度，提升验证效率，将属于同一子系统的需求项分类至同一子表中，以便在进行需求覆盖验证时，以子系统为单位进行验证。一个子表对应一个子系统，子表中包括有对应于该子系统的需求项，以及各需求项对应的覆盖项。

示例性的，需求矩阵中对应于ATS系统的需求项分类至ATS系统的子表，对应于CI系统的需求项分类至CI系统的子表。

104、验证各所述子表中存在对应关系的需求项和覆盖项。

验证各子表存在对应关系的需求项和覆盖项，实际上就是验证覆盖项是否能够满足其对应的需求项的需求。由于各子表的验证方法均相同，下面以一个子表为例，对验证过程进行说明，该验证过程包括如下步骤一至步骤三：

步骤一，展示所述子表中存在对应关系的需求项和覆盖项，以供验证人员读取所述子表中存在对应关系的需求项和覆盖项。

为了便于验证人员验证，将子表中存在对应关系的需求项和覆盖项中展示在验证人员对应的验证终端中，以供验证人员验证覆盖项是否满足对应的需求项的需求。

步骤二，获取所述验证人员针对各所述需求项的验证信息。

在验证人员验证完成后，对于子表中每一对存在关系的需求项和覆盖项均会反馈相应的验证信息，该验证信息表征需求项是通过了验证还是未通过验证。

步骤三，根据所述验证信息标记各所述需求项。

验证信息为需求项的覆盖项不满足其需求时，说明需求项验证未通过，其对应的覆盖项不能达到其期望的技术成果或实施效果，因此标记需求项为目标需求项，以使业务人员根据该标记对需求项对应的覆盖项进行修改。

验证信息为需求项的覆盖项不满足其需求时，说明需求项验证通过，其对应的覆盖项能达到其期望的技术成果或实施效果，因此标记需求项为正常需求项。

在针对该子表的需求项验证结束后，可自动汇总该子表中各需求项的验证情况。还可以在汇总验证情况的基础上，自动汇总该子表中验证未通过的需求项，以便及时对这些需求项进行需求覆盖。

105、将未通过验证的目标需求项提供给其所在子表对应的子系统，以供所述子系统的业务人员修改所述技术文档中目标需求项的覆盖项对应的技术内容，其中，所述目标需求项对应的覆盖项不能满足其需求。

若验证之后存在未通过验证的目标需求项，则说明目标需求项的覆盖项不能满足其需求，为了保证城市轨道交通项目交付时能够达成目标需求项对应的技术成果或实施效果，因此将未通过验证的目标需求项提供给其所在子表对应的子系统，以供子系统的业务人员修改技术文档中目标需求项的覆盖项对应的技术内容。当再次对目标需求项进行需求覆盖验证时，修改后的技术内容的覆盖项，将作为与目标需求项对应的覆盖项。

106、基于未通过验证的目标需求项生成新的需求矩阵，将新的需求矩阵作为待验证的需求矩阵，继续进行需求覆盖验证，直至不存在目标需求项为止。

在城市轨道交通项目交付之前，需要保证所有的需求项都需要验证通过，这样才能保证城市轨道交通项目交付时能够达成与合同文档中所有需求项对应的技术成果或实施效果。因此，需要整合未通过验证的目标需求项生成新的需求矩阵，也就是说，新的需求矩阵中仅包括有未通过验证的需求项。在生成新的需求矩阵之后，将新的需求矩阵作为待验证矩阵，重新执行步骤101至步骤106，直至需求矩阵中不存在目标需求项为止。

本发明提供的需求覆盖验证方法，当确定存在需求覆盖验证需求时，获取包括有需求项的待验证的需求矩阵，并确定各需求项对应的覆盖项。然后将属于同一子系统的需求项分类至同一个子表中，并验证各子表中存在对应关系的需求项和覆盖项。当存在未通过验证的目标需求项时，将未通过验证的目标需求项提供给其所在子表对应的子系统，以供子系统的业务人员修改技术文档中目标需求项的覆盖项对应的技术内容。最后基于未通过验证的目标需求项生成新的需求矩阵，将新的需求矩阵作为待验证的需求矩阵，继续进行需求覆盖验证，直至不存在目标需求项为止。可见，本发明实施例提供的方案能够实现需求覆盖验证过程的自动化管理，实现需求覆盖验证的需求项和覆盖项的自动识别、提取、分类、验证，降低需求覆盖验证的复杂性。另外，实现验证未通过项的需求项的提取，并针对验证未通过需求项的再次需求覆盖验证，从而降低业务流转的复杂度，避免出现需求项遗漏验证的情况，进而提高需求覆盖追踪及验证的完整性和效率。

进一步的，根据图1所示的方法，本发明的另一个实施例还提供了一种需求覆盖验证方法，如图2所示，该方法主要包括：

201、获取待验证的需求矩阵。

所述需求矩阵中包括有至少一个需求项，所述需求项对应于城市轨道交通项目的合同文档中的需求。

202、确定各所述需求项对应的覆盖项。

所述覆盖项对应于所述城市轨道交通项目的技术文档中为对应的需求项设计的技术内容。

203、采用覆盖验证模板整合所述需求矩阵中的各所述需求项以及各所述需求项对应的覆盖项，形成覆盖验证报告，其中，所述覆盖验证报告为分类需求项时依据的文档。

为了避免验证操作扰乱需求维护人员维护的需求矩阵，在进行验证时不直接对需求矩阵进行操作，而是采用覆盖验证模板整合需求矩阵中的各需求项以及各需求项对应的覆盖项，形成覆盖验证报告。

覆盖验证报告中包括有需求矩阵中所有的需求项以及各需求项对应的覆盖项。另外，为了便于分类各需求项覆盖验证报告中还可以包括有需求项对应的子系统。

需要说明的是，覆盖验证报告的存在形式本实施例不做具体限定，可选的，覆盖验证报告可以为表格形式的文档。

204、将属于同一子系统的需求项分类至同一个子表中。

所述子系统为所述城市轨道交通项目中的子系统。在将属于同一子系统的需求项分类至同一个子表中时，是按照子系统的标记进行的，也就是说，对应于同一子系统的子表和需求项具有相应的标记。

205、验证各所述子表中存在对应关系的需求项和覆盖项。

206、汇总验证后的各子表形成总表，其中，所述总表中包括有对应存在的需求项、覆盖项和验证项，其中，所述验证项用于标识对应的需求项的验证信息。

为了便于验证人员整体了解针对需求矩阵中所有需求项的验证情况，则将验证后的各子表汇总形成总表。总表包括有对应存在的需求项、覆盖项和验证项。比如，总表中的一个需求项存对应的覆盖项和对应的验证项，该验证项可以包括如下内容：验证结论、级别以及关联问题记录编号。验证结论包括OK、NOK、NOTcovered，其中，OK表征需求项验证通过、NOK表征需求项未验证通过、NOTcovered表征需求项未被覆盖项覆盖。级别表征需求项的重要程度。关联问题记录编号表征需求项所关联的问题对应的编号。

总表为汇总文档，其存在的目的存在如下几点：一是，得到针对合同文档中各需求项的总体验证结论，便于给出验证报告结论信息，比如，需求项总数、验证通过的需求项数量、验证未通过的需求项数量以及各需求项分别对应的子系统。二是，便于对外提交呈现完整合同追踪情况。三是，将未通过的需求项、覆盖及验证信息分配进入到对应子系统子表中，便于子系统的业务人员修改需求项的技术内容。

207、确定是否存在未通过验证的目标需求项，若存在，执行208；否则，结束当前流程。

在形成总表后，验证人员就能清楚了解到是否存在未通过验证的需求项。若不存在未通过验证的需求项，则说明各覆盖项都能满足其对应的需求项的需求。若存在需求项验证未通过，这些验证未通过的需求项被定义为目标需求项，需要进行下一轮的验证。

208、清空各子表。

为了避免验证出现混乱，需要清空子表，以便在下一轮验证的子表中仅存在此轮中需要验证的需求项。

209、将未通过验证的目标需求项提供给其所在子表对应的子系统，以供所述子系统的业务人员修改所述技术文档中目标需求项的覆盖项对应的技术内容，其中，所述目标需求项对应的覆盖项不能满足其需求。

210、判断是否停止验证，若是，执行212；否则，执行211。

为了避免验证进行入死循环，需要设定停止验证的条件，以该停止验证的条件终止验证。下面对判断是否停止验证的方法进行说明，该方法可以包括如下几种：

第一种，确定累计验证次数是否达到次数阈值；若达到，发出停止验证的提示；若未达到，基于未通过验证的目标需求项生成新的需求矩阵。

若累计验证次数达到次数阈值，说明验证次数过多，未通过验证的目标需求项已经进行了多轮验证，仍然未通过验证，其可能存在难以解决的技术问题，需要进行异常处理，此时再次验证意义不大。因此需要发出停止验证的提示，以使业务人员根据该提示停止验证。

若累计验证次数未达到次数阈值，说明未通过验证的目标需求项，技术人员还可以通过修改其对应的覆盖项的技术内容的方式，使其通过验证。因此，基于未通过验证的目标需求项生成新的需求矩阵，进行下一轮的需求覆盖验证即可。

第二种，确定验证的累计时长是否达到时长阈值；若达到，发出停止验证的提示；若未达到，基于未通过验证的目标需求项生成新的需求矩阵。

若累计时长达到时长阈值，说明验证次数过多，未通过验证的目标需求项已经进行了多轮验证，仍然未通过验证，其可能存在难以解决的技术问题，需要进行异常处理，此时再次验证意义不大。因此需要发出停止验证的提示，以使业务人员根据该提示停止验证。

若累计时长未达到时长阈值，说明未通过验证的目标需求项，技术人员还可以通过修改其对应的覆盖项的技术内容的方式，使其通过验证。因此，基于未通过验证的目标需求项生成新的需求矩阵，进行下一轮的需求覆盖验证即可。

第三种，结合上述的两种方法，同时考虑累计时长和累计验证次数。

211、基于未通过验证的目标需求项生成新的需求矩阵，将新的需求矩阵作为待验证的需求矩阵，继续执行步骤201。

待验证的需求矩阵中包括的需求项为上一轮需求覆盖验证后合同文档中未通过验证的需求项，因此这种生成新的需求矩阵的方式能够实现验证不通过需求项的自动提取、降低业务流转的复杂度，避免出现需求项遗漏验证的情况，从而进一步提高需求覆盖追踪及验证的质量和效率。

212、发出停止验证的提示。

停止验证的提示用于告知验证人员验证过程中存在异常，需要人工排除异常。

进一步的，依据上述方法实施例，本发明的另一个实施例还提供了一种需求覆盖验证装置，如图3所示，所述装置包括：

获取单元31，用于获取待验证的需求矩阵，其中，所述需求矩阵中包括有至少一个需求项，所述需求项对应于城市轨道交通项目的合同文档中的需求；

确定单元32，用于确定各所述需求项对应的覆盖项，其中，所述覆盖项对应于所述城市轨道交通项目的技术文档中为对应的需求项设计的技术内容；

分类单元33，用于将属于同一子系统的需求项分类至同一个子表中，其中，所述子系统为所述城市轨道交通项目中的子系统；

验证单元34，用于验证各所述子表中存在对应关系的需求项和覆盖项；

提供单元35，用于将未通过验证的目标需求项提供给其所在子表对应的子系统，以供所述子系统的业务人员修改所述技术文档中目标需求项的覆盖项对应的技术内容，其中，所述目标需求项对应的覆盖项不能满足其需求；

生成单元36，用于基于未通过验证的目标需求项生成新的需求矩阵，将新的需求矩阵作为待验证的需求矩阵，继续进行需求覆盖验证，直至不存在目标需求项为止。

本发明实施例提供的需求覆盖验证装置，当确定存在需求覆盖验证需求时，获取包括有需求项的待验证的需求矩阵，并确定各需求项对应的覆盖项。然后将属于同一子系统的需求项分类至同一个子表中，并验证各子表中存在对应关系的需求项和覆盖项。当存在未通过验证的目标需求项时，将未通过验证的目标需求项提供给其所在子表对应的子系统，以供子系统的业务人员修改技术文档中目标需求项的覆盖项对应的技术内容。最后基于未通过验证的目标需求项生成新的需求矩阵，将新的需求矩阵作为待验证的需求矩阵，继续进行需求覆盖验证，直至不存在目标需求项为止。可见，本发明实施例提供的方案能够实现需求覆盖验证过程的自动化管理，实现需求覆盖验证的需求项和覆盖项的自动识别、提取、分类、验证，降低需求覆盖验证的复杂性。另外，实现验证未通过项的需求项的提取，并针对验证未通过需求项的再次需求覆盖验证，从而降低业务流转的复杂度，避免出现需求项遗漏验证的情况，进而提高需求覆盖追踪及验证的完整性和效率。

可选的，如图4所示，所述验证单元34，具体用于针对每一个所述子表分别执行：展示所述子表中存在对应关系的需求项和覆盖项，以供验证人员读取所述子表中存在对应关系的需求项和覆盖项；获取所述验证人员针对各所述需求项的验证信息；根据所述验证信息标记各所述需求项，其中，所述验证信息为需求项的覆盖项不满足其需求时，标记需求项为目标需求项，所述验证信息为需求项的覆盖项满足其需求时，标记需求项为正常需求项。

可选的，如图4所示，所述装置还包括：

汇总单元37，用于在验证各所述子表中存在对应关系的需求项和覆盖项之后，汇总验证后的各子表形成总表，其中，所述总表中包括有对应存在的需求项、覆盖项和验证项，其中，所述验证项用于标识对应的需求项的验证信息。

可选的，如图4所示，所述装置还包括：

清空单元38，用于在汇总单元37汇总验证后的各子表形成总表之后，清空所确定的子表。

可选的，如图4所示，所述装置还包括：

整合单元39，用于在将属于同一子系统的需求项分类至同一个子表中之前，采用覆盖验证模板整合所述需求矩阵中的各所述需求项以及各所述需求项对应的覆盖项，形成覆盖验证报告，其中，所述覆盖验证报告为分类需求项时依据的文档。

可选的，如图4所示，所述装置还包括：

第一判断单元40，用于确定累计验证次数是否达到次数阈值；若达到，发出停止验证的提示；若未达到，触发生成单元36基于未通过验证的目标需求项生成新的需求矩阵；

和/或，

第二判断单元41，用于确定验证的累计时长是否达到时长阈值；若达到，发出停止验证的提示；若未达到，触发生成单元36基于未通过验证的目标需求项生成新的需求矩阵。

可选的，如图4所示，获取单元31所涉及的待验证的需求矩阵在具有需求矩阵生成权限的需求维护人员输入的生成指令下生成；

和/或，

获取单元31当接收到具有需求覆盖验证权限的验证人员下发的验证指令时，获取待验证的需求矩阵。

本发明实施例提供的需求覆盖验证装置中，各个功能模块运行过程中所采用的方法详解可以参见图1-图2方法实施例的对应方法详解，在此不再赘述。

进一步的，依据上述实施例，本发明的另一个实施例还提供了一种计算机可读存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行图1或图2所述的需求覆盖验证方法。

进一步的，依据上述实施例，本发明的另一个实施例还提供了一种存储管理设备，所述存储管理设备包括：

存储器，用于存储程序；

处理器，耦合至所述存储器，用于运行所述程序以执行图1或图2所述的需求覆盖验证方法。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

本领域内的技术人员应明白，本公开的实施例可提供为方法、系统、或计算机程序产品。因此，本公开的实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开的实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本申请是参照本公开的实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器 (CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存 (PRAM)、静态随机存取存储器 (SRAM)、动态随机存取存储器 (DRAM)、其他类型的随机存取存储器 (RAM)、只读存储器 (ROM)、电可擦除可编程只读存储器 (EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘 (DVD) 或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体 (transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本公开的实施例可提供为方法、系统或计算机程序产品。因此，本公开的实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本公开的实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (6)

1.一种需求覆盖验证方法，其特征在于，所述方法包括：

获取待验证的需求矩阵，其中，所述需求矩阵中包括有至少一个需求项，所述需求项对应于城市轨道交通项目的合同文档中的需求；首次针对合同文档中的需求进行需求覆盖验证，待验证的需求矩阵中包括的需求项为合同文档中的所有的需求项；非首次针对合同文档中的需求进行需求覆盖验证，待验证的需求矩阵中包括的需求项为上一轮需求覆盖验证后合同文档中未通过验证的需求项；

确定各所述需求项对应的覆盖项，其中，所述覆盖项对应于所述城市轨道交通项目的技术文档中为对应的需求项设计的技术内容；

将属于同一子系统的需求项分类至同一个子表中，其中，所述子系统为所述城市轨道交通项目中的子系统；

验证各所述子表中存在对应关系的需求项和覆盖项；

将未通过验证的目标需求项提供给其所在子表对应的子系统，以供所述子系统的业务人员修改所述技术文档中目标需求项的覆盖项对应的技术内容，其中，所述目标需求项对应的覆盖项不能满足其需求；

基于未通过验证的目标需求项生成新的需求矩阵，将新的需求矩阵作为待验证的需求矩阵，继续进行需求覆盖验证，直至不存在目标需求项为止；

验证各所述子表中存在对应关系的需求项和覆盖项，包括：

针对每一个所述子表分别执行：展示所述子表中存在对应关系的需求项和覆盖项，以供验证人员读取所述子表中存在对应关系的需求项和覆盖项；获取所述验证人员针对各所述需求项的验证信息；根据所述验证信息标记各所述需求项，其中，所述验证信息为需求项的覆盖项不满足其需求时，标记需求项为目标需求项，所述验证信息为需求项的覆盖项满足其需求时，标记需求项为正常需求项；

验证各所述子表中存在对应关系的需求项和覆盖项之后，所述方法还包括：

汇总验证后的各子表形成总表，其中，所述总表中包括有对应存在的需求项、覆盖项和验证项，其中，所述验证项用于标识对应的需求项的验证信息；

在汇总验证后的各子表形成总表之后，所述方法还包括：

清空各所述子表；

在基于未通过验证的目标需求项生成新的需求矩阵之前，所述方法还包括：

确定累计验证次数是否达到次数阈值；

若达到，发出停止验证的提示；

若未达到，基于未通过验证的目标需求项生成新的需求矩阵；

和/或，

在基于未通过验证的目标需求项生成新的需求矩阵之前，所述方法还包括：

确定验证的累计时长是否达到时长阈值；

若达到，发出停止验证的提示；

若未达到，基于未通过验证的目标需求项生成新的需求矩阵。

2.根据权利要求1所述的方法，其特征在于，在将属于同一子系统的需求项分类至同一个子表中之前，包括：

采用覆盖验证模板整合所述需求矩阵中的各所述需求项以及各所述需求项对应的覆盖项，形成覆盖验证报告，其中，所述覆盖验证报告为分类需求项时依据的文档。

3.根据权利要求1-2中任一所述的方法，其特征在于，待验证的需求矩阵在具有需求矩阵生成权限的需求维护人员输入的生成指令下生成；

和/或，

当接收到具有需求覆盖验证权限的验证人员下发的验证指令时，获取待验证的需求矩阵。

4.一种需求覆盖验证装置，其特征在于，所述装置包括：

获取单元，用于获取待验证的需求矩阵，其中，所述需求矩阵中包括有至少一个需求项，所述需求项对应于城市轨道交通项目的合同文档中的需求；首次针对合同文档中的需求进行需求覆盖验证，待验证的需求矩阵中包括的需求项为合同文档中的所有的需求项；非首次针对合同文档中的需求进行需求覆盖验证，待验证的需求矩阵中包括的需求项为上一轮需求覆盖验证后合同文档中未通过验证的需求项；

确定单元，用于确定各所述需求项对应的覆盖项，其中，所述覆盖项对应于所述城市轨道交通项目的技术文档中为对应的需求项设计的技术内容；

分类单元，用于将属于同一子系统的需求项分类至同一个子表中，其中，所述子系统为所述城市轨道交通项目中的子系统；

验证单元，用于验证各所述子表中存在对应关系的需求项和覆盖项；

提供单元，用于将未通过验证的目标需求项提供给其所在子表对应的子系统，以供所述子系统的业务人员修改所述技术文档中目标需求项的覆盖项对应的技术内容，其中，所述目标需求项对应的覆盖项不能满足其需求；

生成单元，用于基于未通过验证的目标需求项生成新的需求矩阵，将新的需求矩阵作为待验证的需求矩阵，继续进行需求覆盖验证，直至不存在目标需求项为止；

所述验证单元，具体用于针对每一个所述子表分别执行：展示所述子表中存在对应关系的需求项和覆盖项，以供验证人员读取所述子表中存在对应关系的需求项和覆盖项；获取所述验证人员针对各所述需求项的验证信息；根据所述验证信息标记各所述需求项，其中，所述验证信息为需求项的覆盖项不满足其需求时，标记需求项为目标需求项，所述验证信息为需求项的覆盖项满足其需求时，标记需求项为正常需求项；

所述装置还包括：

汇总单元，用于在验证各所述子表中存在对应关系的需求项和覆盖项之后，汇总验证后的各子表形成总表，其中，所述总表中包括有对应存在的需求项、覆盖项和验证项，其中，所述验证项用于标识对应的需求项的验证信息；

所述装置还包括：

清空单元，用于在汇总单元汇总验证后的各子表形成总表之后，清空所确定的子表；

所述装置还包括：

第一判断单元，用于确定累计验证次数是否达到次数阈值；若达到，发出停止验证的提示；若未达到，触发生成单元基于未通过验证的目标需求项生成新的需求矩阵；

和/或，

第二判断单元，用于确定验证的累计时长是否达到时长阈值；若达到，发出停止验证的提示；若未达到，触发生成单元基于未通过验证的目标需求项生成新的需求矩阵。

5.一种计算机可读存储介质，其特征在于，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行权利要求1至权利要求3中任意一项所述的需求覆盖验证方法。

6.一种存储管理设备，其特征在于，所述存储管理设备包括：

存储器，用于存储程序；

处理器，耦合至所述存储器，用于运行所述程序以执行权利要求1至权利要求3中任意一项所述的需求覆盖验证方法。

Images