为什么需求工程师对全面采用MBSE持观望态度——在需求工程中构建面向未来的架构
应对对系统中断和复杂性的合理担忧，并学习如何在全面推行基于模型的系统工程之前减少风险。
在本系列由Iain Cunningham撰写的第6部分中，我们将揭示团队之所以犹豫不决、未能全面采用基于模型的系统工程（MBSE）的合理原因。
构建复杂系统是为了应对未来的挑战。当初衷逐渐淡去时，全面采用MBSE的承诺似乎是完美的解决方案——然而，对混乱、复杂性以及覆盖缺失的担忧却让许多人止步不前。我们相信，工程需要清晰明确，而非凭空猜测。了解这种犹豫为何是基于以往经验的理性响应，并学习如何规避风险，构建一个经得起未来考验的架构。
当您考虑改进可追溯性时，最让您担心的是什么：业务中断、复杂性，还是失去控制？
在本系列的前一篇文章中，我们探讨了在结构、覆盖范围、验证证据以及时间连续性等方面，一套稳健的可追溯性方法在实践中究竟需要什么。接下来的自然步骤就是据此采取行动。然而，在实践中，许多组织和需求工程师却犹豫不决。
这并非无意为之，通常是基于经验的。
可追溯性同时涉及多个维度。需求必须保持结构化，覆盖率必须保持可见，且验证证据在不同版本和迭代中都必须值得信赖。与此同时，许多团队在多种工具之间切换工作，这使得将需求、设计、测试用例和执行结果连接起来变得更加困难。
这带来了改进潜力与可能增加复杂性的风险之间的矛盾，主要体现在以下三个方面：
仓促推行可追溯性带来的三大风险
- 破坏结构和所有权的风险：需求工程师是设计意图的守护者。他们深知，在组织尚未做好准备之前，大规模变更可以引入复杂性。原本旨在改进的举措，很快就会变成额外负担。
- 破坏覆盖率与验证清晰度的风险：在碎片化的环境中，过早引入新工具会使覆盖率的解读变得更加困难。当从需求到测试用例再到运行结果的链条不清晰时，信心会下降，团队只能退而求其次，依靠手动变通方案。
- 跨版本和工作流连续性丧失的风险：如果可追溯性在并行分支和不断演变的需求中表现不一致，团队将失去信任。届时，工作重心将转向在巨大的时间压力下重建已验证的内容。
如果这些风险未能及早得到解决，结果可想而知：采用进程放缓，利益相关方失去参与热情，可追溯性更多停留在理论层面而非实践层面。最终，需求工程师又不得不再次承担重担，维护结构并在各个系统间重建证据。
从更深层次来看，这种犹豫并非对变革的抵触，而是基于以往经验的理性响应。大多数组织都曾尝试过改进可追溯性，但结果往往是复杂性增加，而非清晰度提升。要取得成功，改进措施必须先减少风险，然后才能减少工作量。
如果您在当前环境中也面临类似的挑战，不妨退一步，审视一下这些风险目前最突出的领域。一项小而精准的调整，往往比大规模的转型更有效。
在本系列的最后一篇文章中，我们将从犹豫不决转向付诸行动。我们将探讨一种切实可行的方法，旨在强化架构、提高可见度并保持连续性，而无需从一开始就具有全面的转型需求。
回顾您的亲身经历，迄今为止，改善可追溯性面临的最大障碍是什么？原因又是什么？欢迎参与讨论，帮助塑造系统设计的未来。请在LinkedIn上关注Iain Cunningham，并在其原文评论区分享您的经验。