一种强化可追溯性的新低风险方法——在需求工程中构建面向未来的架构
采用一种有针对性且低风险的方法，在完全不打乱现有工具链的情况下，加强可追溯性并赋能您的工程师。
在本系列最后一篇——第7部分中，Iain Cunningham将带领我们从理解问题转向采取实际行动。
构建复杂系统是为了应对未来的挑战。当开发初衷逐渐淡忘、工具链断开连接时，在不打乱现有工作流程的前提下修复可追溯性似乎难以实现。我们坚信，工程需要清晰明确，而非凭空猜测。探索一种低风险、有针对性的方法，它能强化系统架构、使验证结果切实可用，并确保工作流程的连续性——从而证明，可追溯性应当是工程的自然组成部分，而非其负担。
如果能在不打乱现有工作流程的情况下解决可追溯性问题，那会是什么样子？
在本系列的前一篇文章中，我们探讨了为何即使需求显而易见，组织仍对改进可追溯性犹豫不决，以及这种犹豫往往源于与中断、复杂性和连续性丧失相关的实际风险。最后一步是从理解问题转向采取切实行动。实际上，这些挑战往往归结为本系列文章中反复提及的三个优先事项：
实现切实可行的可追溯性的三大重点
- 从源头加强结构：可追溯性始于需求如何定义。需求必须结构清晰、可测试且相互关联。如果结构薄弱，下游的所有工作都会变得被动，团队将花费时间去解读需求含义，而非直接依赖需求。
- 使覆盖率和验证证据可利用：可追溯性必须支持不同角色实际的工作方式。覆盖率必须可见，验证证据必须可获取，这样运行结果和缺陷才能追溯到源头需求，而无需手动重建。
- 确保跨版本和跨时间的连续性：可追溯性必须在真实的交付条件下成立。它应保持对版本的感知能力，从而始终明确正在验证的是哪个修订版本、哪些测试适用，以及哪些证据支持该状态。
当这三个优先事项得到统筹处理时，可追溯性便成为工程工作流中值得信赖的一部分。设计意图得以保留，覆盖范围清晰明确，各角色及各交付周期均可依赖验证证据。从更深层次来看，这正是可追溯性本应具备的本质。它应当减少不确定性，而非创建更多不确定性。
从实践角度来看，问题便在于如何应用这些原则，同时避免再次引入相同的风险。这正是我们Vector致力于解决的问题。
为了支持这一方法，Vector正在开发一款由PREEvision驱动的新版需求WebClient，直接解决我们在前几篇文章中探讨的风险。我们的目标不是引入干扰，而是最小化干扰；不是增加复杂性，而是在当前复杂性积聚的环节减少复杂性。
我们的目标并非一次性替换所有内容，也并非将所有角色强行纳入单一的工作体验。相反，我们的目标是提供针对性的可追溯性访问，使需求工程师能够充满信心地维护结构，同时下游角色可以直接处理覆盖率、影响及验证证据，而无需依赖转换或变通方案。
由于该解决方案基于PREEvision构建，因此从一开始就具备支持互联工程使用场景的相同底层模型。这使得组织在向更深入的MBSE或基于模型的电气/电子架构设计（MBEEA）扩展时，追溯性能够保持一致，同时仍能适应现有的工具链和工作方式。
这使本系列得出一个简单的结论：可追溯性只有在反映系统如何演进、验证如何进行，以及不同角色如何与同一“真相源”交互时，才能真正发挥作用。当这些条件都满足时，可追溯性就成为工程的一部分，而不是必须在工程之外单独维护的内容。
如果您希望关注该方法的发展动态，并了解其在实践中的应用，欢迎加入我们的邮件列表以获取最新更新。同时，我们也想了解您最希望解决的可追溯性难题是什么。
加入讨论，帮助塑造系统设计的未来。在LinkedIn上关注Iain Cunningham，并在其原文评论区分享您的经验。