无论使用传统的分析方法或敏捷方法，都可以学习如何使用需求的模式，从而为成功的软件开发编写一致的、有效的需求。在这一篇教程里面，小编主要和大家简单的介绍一下：软件工程师知识点之业务规则和需求模式。
第一个知识点：业务规则
想必不需要小编多说，大家都应该知道业务规则指的就是，业务究竟怎样运营的某一个方面的定义。换一句话来说，业务规则是指对业务定义和约束的描述，用于维持业务结构或控制和影响业务的行为。就比如说：业务规则定义在一定情况下面。业务究竟怎样应对（就比如说：当客户的信用卡支付被拒绝的时候）又或者是一个限制（就比如说：不可以卖给不到16岁的任何人）。
另外一个方面，开发系统的业务规则方法承认业务规则的重要性，主要目的就是更容易理解以及变更业务运营的方式。在理想的情况下面，一旦业务规则发生一定程度上面的变化，所有被影响的系统能够立刻修改并且投入使用。大家可以看到，这是一个非常吸引人的场景。有非常多的业务规则产品能够直接帮助做到这一些。就像有一个大师透彻的了解大家的业务，大家能够直接向他询问相关的问题，当然拉不仅仅是这一些。在这里大家都需要注意一点，那就是小编不是说一定要有一个比较特别的产品才能够直接采用业务规则方法哦。事实上，业务规则技术改变了传统的、以过程形式处理业务逻辑的方式。
第二个知识点：需求模式
大家可以看到，相当多的需求类型反应了业务规则，包括在这一篇教程里面的一些需求模式。但是为什么大家不确定哪一个是呢？其中的一个麻烦就是没有一套普遍同意的业务规则类型。
有非常多种业务规则分类方案，假如说随便挑选一个那么就会有一些武断。（当描述一个需求究竟怎样映射到业务规则的时候，也会有同样的问题。）能够直接为一个业务规则方案建立一个需求模式分类，指示每一个模式与业务规则的关系。在这一篇教程里面没有这么做的原因，主要就是不希望冒犯任何一种方案。
在这里小编有必要指出的是采用一个特定的业务规则分类方案可能仅仅只可以等到需求编写完成之后才可以真正的做出决定。考虑到这一种情况，大家可以尝试这邀请三个人来投标，他们有可能来自三个供应商。第一个可能使用了一种业务规则方案。那么第二个可能使用了另外一种。又或者是第三个可能根本没有考虑业务规则哦。
然而，一旦大家的组织已经决定了使用一种特定的业务规则方案，编写需求的时候要考虑到方案（而且假如说大家愿意的话，在一个合适的地方列出每一个需求反映的业务规则的类型）。假如说大家决定使用业务规则产品的话，能够直接把它看作是系统必须依赖的基础架构。因此，就像是任何其他的基础架构，一定要定义需要它提供的需求，使用这一些需求作为选择合适产品的基础才可以哦。
小编结语：
业务规则由业务人员创建、实时更新和调试，业务规则之间的复杂逻辑关系由规则引擎处理。如果你也有这样的需要，那就赶快来学习一下吧。
