ASPICE 追溯性实践分享

木心鱼儿

于 2024-04-19 20:36:26 发布

阅读量635

点赞数 30

文章标签：需求追溯 ASPICE 需求管理

本文链接：https://blog.csdn.net/weixin_43957681/article/details/137912753

版权

01前言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

其他工具推荐：

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

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

关注