规则需求101

业务规则提供了系统所需的灵活性和敏捷性。根据定义,它们使业务分析师能够根据不断发展的业务方向调整系统的决策逻辑。由于竞争压力、商业规则或行政指导,业务规则需要不断适应调整提炼规则需求的能力决定了我们能否实现需要遵循的规则。


规则需求也是需求


作为一名产品经理,我很重视写好产品需求文档。许多文章提供了关于需求收集的指导,以及一些关于写好需求文档的黄金法则。我特别喜欢邓肯·豪伊Duncan Haughey对这个问题的简明看法。要的一点关注问题本身而不是简单的一个答案,这是再怎么强调都不为过的。从一开始就相关利益人主题专家参与是至关重要的。衷心感谢他把这点在他的文章中


此外,这简单的黄金法则会让你在工作中保持安全:“一个好的要满足聪明SMART原则

· 明确(Specific)

· 量的(Measurable)

· 一致同意的(Agreed-upon)

· 能够实现的(Realistic)

· 基于时间(Time-based)

总的来说,需求的收集,无论是对于规则还是对于系统,都没有太大的不同。然而,细微的差别使得这两实际操作起来大相径庭。我这里强调一些关键


源规则收集中的最佳实践


规则需求在我们行业中也被称为“规则”。

通常,源规则包含很多细节

系统的需求文档可能很长,但每个需求通常都相对较小。例如,考虑“打印这个功能。你需要描述它什么,怎么与其他功能交互,有什么限制…你可能会一整页此类需求,但仅此而已了要记得需必须是明确的。个功能点的需求不可能覆盖保单管理系统的全部“承保”部分。考虑到这一点,我们应该看到一个功能各个方面的简短描述。


与此相反,业务规则往往包含大量的细节。虽然在推理过程中,并所有的决策步骤都包含全部的变量,但我们经常看到一些步骤包含了成百上千的变。例如,利率可以按年龄、性别、州、风险水平进行细分。在某个时需求文档将无法覆盖所有的源规则。此时可以将源规则作为电子表格或外部文件在需求中引用

值得注意的是,这些表格必然会随着时间的推移而演变。将它们与需求文档分开,专家可以更容易地根据需要提供迭代。还可以通过原样导入来实现规则。这份在线视频展示了如何以本机方式导入电子表格。


与体系为


决策是复杂的,所以源规则在提炼时并不总是直接导入。业务分析员擅长边分析边构建体系但是如果不仔细的话很可能会被源规则难住不考虑源规则内在的逻辑,就其数量而言就能使任何人陷入困境

差不多是我最常遇到的一个难题。从一源规则开始,一个需求牵出另一个需求最后这条源规则变成了一个超级大的需求。举个例子你最初打算记录下投保资格的规则,然后发现年龄的限制因州而异,接下来你想深入了解一下各个州的规定,却发现有些州根本不符合该款产品的投保条件这时或许想到了交叉销售,并向申请人提议其他产品但是如果申请人多个不同产品的投保资格,如何定哪一个是最好的?


就这样,一个简单的关于投保年龄的需求变成了涉及投保资格和交叉销售逻辑的规则网。对于业务分析师来说,很重要的一点就是成体系地构建这些需求以随需应变。

其底层的方法论,DMN标准(Decision Model and Notation决策建模标记法可以指导完成复杂规则的分解。通过这个视频,你可以了解更多关于如何使用“慧笔创建决策模型的知识

如果不使用DMN工具,业务分析师必须要时刻意识到风险。最通过专注来避免混作一团源规则。


最后的总结


考虑采用不同的方法来收集源规则的需求

将在电子表格中维护的源规则与需求分开

体系体系体系即时组织你的规则

产品
解决方案
学习
上海杨浦区昆明路739号文通大厦9F
©2021 上海数泱信息科技有限公司 版权所有