如何记录业务规则

我想知道记录业务规则的正式和最常用的方法是什么？还有如何记录开发工件的UI规范（例如，记录表单字段以及按钮在表单，信息文本上的行为方式等）

对于业务规则，我认为@Joppe指出了我们所有人都在考虑的UML。

用例图很好地概述了Actor / Roles如何与系统交互以及系统做什么。为了配合物的使用情况，其他信息以文本解释将有很大的帮助（前置条件，后置条件，以往UC执行依赖，等等）

有些图表还可以很好地概述不同级别的业务：

• 状态机图，如果有任何状态要记录。
• 活动图。对于复杂的用例，您可能需要深入细节。详细程度取决于您，具体取决于谁将阅读文档。这份文件看起来似乎不像企业文件，但是如果具备适当的详细程度，它可能会变成这样。

只是一个建议，为每个用例分配一个代码（即UC-1，UC-n）。这些将在以后的UI文档编制中有用。

对于UI文档，通常的做法（这些天）是制作线框。比屏幕截图要好得多，因为它看起来更干净，更简单。例如，看一下WireframeSketcher

线框可能还不够用，因此，对每个屏幕进行简要介绍并描述每个按钮。另外，请参考屏幕中涉及的UC（请参阅为什么UC代码有用）。这将使您的文档连贯。

诸如Wireframesketcher之类的工具的重点在于它们可以进行交互式模型化。在您仍在设计或开发时，为客户提供交互性内容的完美之选。

不要忘记记录导航计划。导航 计划没有UML图，但可以使用状态机图代替。它不是为了制造它，而是为了。

最后，请记住要与谁联系。

• 技术人员：您可以深入细节并使用技术知识。

• 不是技术人员：避免技术性（与languaje或代码均无关）。尝试变得清晰和简单，并使用与客户使用的相同术语/单词。想起来就好像您不懂编程一样。

文档通常以用例和其他散文形式进行。此外，拥有UML图和其他图形形式可以为您提供更高层次的概述，并且比阅读页面和页面更容易在较短的时间内理解，因此非常有用。

最后但并非最不重要的一点是，最佳文档是执行业务规则的测试用例。这样，您可以更改代码并发现您违反了业务规则。否则，文档始终处于过时和过时的危险中。

可能最常见的形式是用例。您可以使用屏幕模型和说明来补充它们。

我推荐的书是Alistair Cockburn撰写的“编写有效的用例”。它描述了如何在各个细节级别上编写用例，如何避免陷入“模板”驱动的方法，以及仅坚持记录必要和相关的内容。

无论使用哪种方法，请确保可以对其进行积极维护。他们应该是居住文件。将文档保存在版本控制系统或某种文档管理系统（例如Sharepoint）中，对于保持文档的维护有很大帮助。通过附加在电子邮件中的Word文档来跟踪业务规则是解决该问题的一种可怕方法，因为它会导致出现多个版本。

我强烈建议仅通过引用用例和UI设计中的业务规则来严格将业务规则与系统规范分开。我最喜欢的技术是：-在电子表格中列出已识别的业务规则。-在系统设计，用例规格说明，用户案例或其他内容中，只需指定“用户输入业务规则BR012中指定的信息”，“系统将计算业务规则BR510中指定的总金额”即可。我推荐这篇文章http://www.allaboutrequirements.com/business-rules/

尝试使用Visual Studio代码和Plant UML插件生成UML图