（文章来宾与北美红帽公司高级中间件顾问约翰·赫洛克 （ John Hurlocker）合着）
在这篇技巧文章中，我们介绍了一些在使用规则项目时遇到的设计周期的背景和准则。
本文不是每个规则和事件项目如何随着时间演变的唯一标准或全部包含的来源。
它要做的是为您提供一些基础知识，就像我们在现实生活中的组织中的许多项目中遇到的一样。 当您在JBoss BRMS世界中着手进行自己的规则和事件冒险时，它们的作用是使您充满信心。
我们将讨论围绕规则制定的一些需求阶段，涉及将要遇到的一些设计选择，并详细说明可用于在项目中包括需求可追溯性的选项。
1.要求
规则作者将分析项目需求，以确定需要创建的规则数量，并与需求团队合作，以便他们可以为可能出现的任何问题提供答案。
分析规则需求是阶段，其中涉及以下问题：
- 在查看需求时，是否存在不清楚的“何时”或“当时”条件？
- 其中有一些规则数据验证吗？
- 可以将多个需求合并为一个规则吗？
通过花一些开发前的时间来检查和验证项目需求，您将能够缩小开发周期中要完成的工作范围。
这些问题已在前面的技巧和窍门中处理过。
2.设计
在设计阶段，企业规则管理员将需要与组织合作，并提出以下一些问题：
- 组织将需要托管一个中央规则存储库，还是没有好处？
- 谁拥有这些规则，并负责更新和发布新版本？
- 是否存在可以在组之间重用的通用规则？
集中的JBoss BRMS存储库。
中央存储库是一个JBoss BRMS服务器，整个组织都可以使用它来编写，存储和构建规则。
它促进规则重用，比在组织中部署多个存储库更容易管理和维护。
如果要与其他组共享一组规则，则其中一个组将需要拥有所有权，并将负责更新和发布新版本。
规则作者将需要与应用程序团队合作，以确定将使用哪种规则格式以及将使用哪种工具来编写规则。 需要解决的一些问题是：
- 应该在BRMS仪表板中还是通过JBoss Developer Studio（JBDS）开发规则？
- 您的规则作者更喜欢什么？
- 谁将在将来维护规则？
- Java开发人员，业务分析师
- 要求在一种格式下是否比另一种格式更好？
- 例如基于Web的数据表，业务指导规则，DSL
- 需要什么类型的测试？
- JUnit和BRMS测试方案？
这些主题已在以前的文章中列出，请参考它们以进行更深入的讨论。
3.可追溯性
元数据中的选项，用于需求可追溯性。
一旦实施了规则和事件，将某种需求可追溯性附加到规则以将它们链接到原始需求就变得至关重要。
使用JBoss BRMS规则，作者可以在规则上设置元数据以实现对需求的可追溯性，例如：
- 可以在描述部分的规则上设置相关需求。
- 也可以将关联的需求设置为规则元数据上的外部链接。
- 可以通过从存储库中提取元数据信息来生成报告。
在以后的文章中，我们将更深入地研究如何在规则实现中使用元数据字段来跟踪需求，并提取这些信息以生成有关这些需求的文档。
翻译自: https://www.javacodegeeks.com/2014/10/3-simple-guidelines-to-rule-development-design-and-traceability.html
