ASPICE 追溯性实践分享

01前言

接着之前的分享，遗留的追溯性ASPICE 认证实践及个人理解分享-CSDN博客文章浏览阅读961次，点赞22次，收藏17次。ASPICE是Automotive 和SPICE的组合，全英文为（Automotive Software ProcessImprovement and Determination）中文为汽车软件过程能力提升和能力评定。https://blog.csdn.net/weixin_43957681/article/details/137726102?spm=1001.2014.3001.5501我们在实践中应该如何实现各环节的追溯性呢？ 本篇文章将做简单的分享，如有不足之处，欢迎批评指正。

如上图所示，追溯性主要体现在：

• 需求拆分追溯（利益相关方需求拆解，系统需求拆解，软件需求拆解等），
• 需求和设计的追溯（系统需求和系统架构设计，软件需求和软件架构设计）
• 需求和测试用例的追溯（系统需求和系统测试，软件需求和软件功能测试）
• 测试用例和测试结果（Bug）的追溯
• 设计和测试规范的追溯
• 需求和变更的追溯

通过解决追溯性问题，ASPICE能够确保软件开发过程中各个阶段和活动之间的关联性和一致性，从而提高软件开发的质量和可靠性。追溯性也有助于提高开发过程的可管理性和可追踪性，减少因开发活动之间的不一致性而导致的风险和问题。

02追溯微观结果示例及介绍

“微观”追溯指的是针对具体的某个需求，下图举例的是SYS.2的一个需求（需求的内容是汽车BCM部件对应的一个简单需求示例，大家无需关注需求内容）。

当建立好完整的需求追溯以后，针对特定的某个需求，直观的效果应该能够达到，需求来源于哪里，需求被拆分成了多少个更详细的需求，需求的设计是怎样的，需求的实现进度如何，需求的测试用例有哪些，需求对应用例的测试结果如何（是否产生了bug）？ 

如下将对具体各个部分进行介绍：

1. 需求的属性内容。如上图第一部分，里面描述了需求的基本内容，所属产品，描述，等属性。 实践中，该环节主要以表格的方式呈现，不同的列定义了需求的不同属性，如优先级、实现团队、时间要求等等。
2. 需求的拆解追溯。 如上图第二部分，可以看到一个SYS-R1的需求被拆解成为了SR1.1,SR1.2,SR1.3三个软件需求。 用Child 标识了。 其实还应展示需求的上层需求 ，及需求的Parent，但实践中，有时系统需求可能会直接复用利益相关方的需求，需要根据实际情况调整。
3. 需求的设计追溯。 如上图第三部分，此处展示的的是该需求在具体的设计文档中，被如何设计的，点击链接即进入对应设计文档或其他有引用的文档内，以查看依赖关联关系。
4. 需求的实现过程追溯。如上图第四部分，该需求共有2个执行的任务，分别是系统需求设计，编码实现，测试用例执行。 并可以看到每一个任务当前都还是TODO的状态，即说明该需求当前还未实现。
5. 需求的测试用例追溯。如上图第五部分，需求对应六个测试用例，其中3个用例当前未执行（no result）,2个执行通过，1个执行失败。
6. 需求的测试结果追溯。如上图第6部分，需求测试产生了一个bug【BDP-1】，且该bug和第五部分执行失败的用例是有对应关系的。

如上就是特定需求下能清晰的展现该需求的各类依赖关系。

03追溯宏观介绍

如前面的介绍，我们知道各个部分之间都存在依赖，那针对一个产品或系统，的完整需求的追溯应也要能整体追溯并呈现。如下是一个简单的示例，在实际运用中，各个阶段，拆分，产出之间是可以按需进行追溯的。（如系统需求，软件需求 ，任务执行，测试用例，测试结果）

示例一

如下显示了系统需求<--->软件需求<----->需求执行<----->测试产生的bug的关联关系。

我们可以看到SYS被拆分成了3个软件需求，并被分为三个阶段实现，并在测试过程中产生了1个bug.  而SYS-R2,SYS-R3,SYS-R4则为产生bug。 

示例二

展示了各个层级需求之间的依赖关系。

示例三

展示需求和测试结果，测试用例的追溯关系。 可以看到各需求对应的测试用例的执行情况，及产生bug的情况。

04需求基线及变更追溯

需求基线

它指的是在软件项目中确定和记录需求阶段的基准状态。需求基线通常包括了对软件系统功能、性能、界面、安全性等方面的详细描述，以及与利益相关者达成的一致意见。在需求基线确定之后，任何后续的变更都需要经过严格的变更控制流程来管理，以确保变更的有效性和对项目的影响可控。

需求基线的确定具有以下几个重要的作用：

1. 提供清晰的目标和方向：需求基线为整个团队提供了明确的需求规范和目标，帮助所有利益相关者理解项目的范围和期望。

2. 作为变更的参考点：一旦需求基线确定，任何后续的变更都需要与基线进行比较，确保变更的合理性和对项目的影响可控。

3. 降低变更成本：通过严格的变更控制流程，需求基线可以帮助团队避免不必要的变更，从而降低变更引入的成本和风险。

4. 提高沟通和协作效率：需求基线作为团队间沟通和协作的基础，帮助各个团队成员和利益相关者在项目需求上保持一致，减少误解和偏差。

需求变更对比

需求变更对比，将软件项目中的需求基线与后续发生的需求变更进行比较，以评估变更对项目的影响和可行性。Requirements Yogi提供了这个基线对比的功能。

05需求管理工具

此次使用的工具是Requirement Yogi ，该工具是基于Confluence平台为主的，详细可参考官方文档。Requirement Yogi - Requirements Management for Confluence | Atlassian Marketplace

其他工具推荐：

在Jira平台上的还有：R4J和RTM等,都是比较优秀的工具。 这个主要取决于团队人员的使用习惯，Confluence更适合文档化管理，而Jira则更容易实现条目化，但对需求人员的使用有一定要求。 

R4J : R4J - Requirements Management for Jira | Atlassian Marketplace

RTM：Requirements & Test Management for Jira | Atlassian Marketplace

市面上肯定也有一些比较优秀的其他工具，选择合适自己团队的即可。