作者：安德鲁 ·马丁，牛津创意出版社

现在，我们将依次尝试每个分离原则，确定它是否适用于我们的问题，然后使

用它来确定希望需求既固定又可变化的困境的可能解决方案。 通过时间分离得到的解决方案。

我们问自己一个问题：“我们是否要求要求同时是固定和可变的？”

如果这个问题的答案是“否”，那么就不能使用时间分离。然而，如果我们觉

得答案可能是“是肯定的”，那么我们可以考虑使用这个原则，将时间划分为允

许需求变化的时间和不允许需求变化的时间。有三种可能性：

1）需求最初是可变的，但在某个时候，它们被冻结了。这表明了一个“传统

的”需求捕获阶段，在此期间，利益相关者在修复它们之前细化需求集（

可能通过某种需求审查过程）。

2)需求最初是固定的，但在某一点之后，他们被允许改变。这表明，允许项

目针对一组固定的（但可能是不正确的或不完整的）需求快速进行，然后

使用经验丰富的(e。g.通过原型化)来支持以后引入新的或不同的需求。

3)固定要求和可变要求的时期在某种程度上是交错的。这建议了某种

混合方法，具有托管的实现周期和需求捕获。

显然，这里有很多不同的可能性，但一些可以从中得到的技术是：

l 迭代式需求的定义

l 迭代开发期

l 分阶段的需求评审（可能与设计评审相结合）

l ‘Gates的需求定义和实现

将某些需求的定义推迟到项目生命周期的后期

通过空间分离得到的解决方案

我们问自己：“我们是否要求在整个需求集中是固定和可变的？””

这个问题表明，可以将需求划分为那些我们允许更改的需求（或者我们认为更有

可能更改的需求）和那些我们认为是固定的需求（或者不太可能更改的需求）。这样，我们就可以把准备工作和努力集中在管理那些构成最大威胁和/或机会的需求变化上。

这可以通过多种方式加以利用，例如：“•‘环-栅栏”的某些要求：

将某种“稳定性”属性与每个需求关联起来，并将其作为我们对各种派生需

求的“变化敏感性”的分析的一部分。这反过来可以告知我们发展的分阶段：推迟系统中更容易受影响的部分。

根据对每个要求的稳定性的评估，选择性地应用本文中讨论的一些分离原理。

条件下分离的解

这一原则表明，在我们处理需求的过程、系统的设计或系统本身中存在某种适应性。

让我们来考虑一下这三个问题。

适应性适应过程的概念既令人兴奋又令人不安。这是一个固定和严格的做事方

式和一个更务实的“现实世界”方法之间的紧张关系的进一步例子——还有另一个物理矛盾！但这是有道理的：大多数实际的过程都需要一定程度的适应性才能有效，而流程需要运行的环境越复杂，就越能合理地接受流程的适应性或裁剪

有必要将此应用于手头的问题，分离的条件原则建议，我们应该考虑使用定制的或可适应的流程来管理需求（以及通过推理来实现）。这里有一个广泛的可能性，但脱离我们的过程必须被固定的假设是实现它们的第一步。

关于该原理的第二个应用，适应性设计的概念看起来很有前途。它建议我们以某

种方式创建一个可以随时修改的设计，以满足不断变化的需求需求（注意，目前，

我们讨论的是设计信息，而不是正在设计的系统）。这个建议使用以下技术：

自动化的需求管理系统，以跟踪需求和设计之间的依赖关系。在设计过程中使用自动化，特别是允许系统在一些更高的抽象级别上被定义的系统，留下一个自动化的系统来填写细节。创建一个中间系统，为我们构建最终系统，而不是为我们自己直接构建最终系统。将柔性组件纳入系统设计，如“可编程”组件或人。最后，让我们考虑一个本身具有适应性的系统或产品。也就是说，我们创建了一个能够适应以满足新的或不断变化的需求的系统。可编程的计算机就是一个明显的例子。集装箱运输解决方案是另一种方式——容器包含一个固有的灵活空间，可以放置各种货物，而不影响集装箱处理基础设施的功能。

通过过渡到超级系统或子系统的解决方案

最后，我们考虑了基于过渡到超级系统或子系统的解决方案。

这表明，可以尝试设计我们的系统，如需求变化对系统实现的影响受到限制和

包含的实际方式。许多好的系统工程和软件工程实践都是基于这一原则：最小化子系统之间的相互依赖以及需求和实现之间的依赖。我们已经注意到，大多数需求变更源都超出了我们的控制范围，但是我们确实对我们设计和实现系统本身的方式有更大的控制。我们可以在设计中使用这种灵活性来创建子系统，其需求使它们能够适应或扩展，以满足更高级别的需求中可能发生的变化。这表明如下：

•是一种面向对象的“设计技术”

u 子系统之间的耦合关系松散

u 最小化子系统之间的依赖关系

u 使用子系统之间的中介体来减轻接口更改的影响

u 过度指定子系统（公差分层或拉伸目标）

u 指定对子系统的可伸缩性和/或适应性

u 可以重新配置的灵活的设计或体系结构

u 增加系统粒度，以促进可伸缩性或适应性

u 指定子系统中指定冗余

u 仔细使用现成的设计元素或子系统

我们还可以使用这一原则，在系统实现的所有层次上最小化相互依赖的依赖，而不仅仅是工程。它应该应用于项目组织、合作伙伴关系、分包、市场营销等。

总结

通过使用一些TRIZ工具，我们已经能够（简单地）考虑变量需求来源的范围。从那时起，我们继续确定问题核心的物理矛盾：

我们希望需求是固定的，并且我们希望它们是变量（未固定的）。

然后，我们使用了一些TRIZ分离原则来探索一些可能的解决方案来解决这个明显的困境。我们已经看到，通过这种方法，可以“发现”多少在需求变化的环境中生存所必需的系统工程技术。

TRIZ技术的“九盒”和分离原则的解决

物理矛盾是一种简单而强大的工具，可以用来解决范围广泛的问题——包括技术问题和非技术问题。需求管理示例演示了如何以系统的方式分析和解决明显的困境，从而产生一系列可能的解决方案。

参考文献

加德，K.J。（2005）矛盾指南。马耳他：进步出版社。

萨夫兰斯基。D.（2000）创意工程。纽约： CRC出版社。