规则，即业务活动能够完成、业务过程能够运转满足的条件要素

 掌握和理解需求核心组件——规则（Rule）

规则，即业务活动能够完成、业务过程能够运转满足的条件要素。

规则有时候是简略就能表示，有时候需要涉及复杂算法的计算并最终校验，才能够决策活动是否完成或者流程是否流转。

准确来说，规则是一个需求中的关系组件，它常常会也关联到其他需求和对象，需求与需求之间也通过规则进行联结在一起，共同进行协作。

举个例子：“某某地区凡是有超过15m的水位线的湖泊都记录到风险点管理”。

我们提炼一下，对象（某地区的湖泊）、数据（水位线）、其他对象（风险点）、规则（水位线超过15m），这样通过规则的定义，就把一个整个需求和不同对象进行关联起来。

有些产品经理可能会把规则误认为是需求，其实这样不能完全说是错的，只是大家在结合分析的时候要分清主次关系，重要的是在需求分析中提炼系统需要的规则，使需求和对象进行逻辑性的联结、沟通、通信。

描述规则时，我们在同一个项目中，相同的规则一定要采用相同的术语，避免测试和研发人员的误解和概念的混淆。这一点在开发过程中会造成很大的歧义，甚至影响后台整个的规则架构，引发不必要的开发工程量。所以在定义和描述规则时，动词的使用和名词的使用，最好保持一致性的原则。

如何从需求中找出我们的规则呢？

1）通过业务需求的干系人获取规则和定义规则。

需求讨论会中，不同的需求的干系人，也有可能对同一规则的描述产生用词差异。产品经理一定要询问并确认其是否指的是同一过程的同一规则、规则使用的场景是什么，这样才能对规则的把控和后续的功能描述更加到位。

2）通过数据需求的分析来暴露规则。

通常我们需要的规则往往是从对象之间数据需求的分析中暴露出来的，规则还可称为“数据传递相关规则”。

软件开发中也转化为表达式和校验判断的规则来约束数据在对象之间的传递，记录在数据的模型中，大多数的规则至少依赖于两个对象之间的数据。当然自己和自己进行内部的处理也是可以的，但我们作为分析，应该以对象之间的数据传递为中心去挖掘规则。