建模高度特定的业务需求

Question

如何对系统中没有先例的高度特定的业务需求进行建模？例如，以下要求：When a purchase order contains N lines, is over X value in total and is being recorded against project Y, an email needs to be sent to persons A and B with the details

此需求补充了围绕采购订单的其他需求，但由于业务其他方面的一些持续问题，该需求在较晚的时间出现。

人员A和B不是系统中任何角色或组的一部分，也不承担任何具体的责任；他们只是企业在这个非常具体的情况下指定接收这些电子邮件的两个人。项目也是数据驱动的，因此项目Y没有特殊的属性来区别于任何其他项目。识别它的唯一方法是将它的标识符与幻数进行比较。

如何在不引入太多额外复杂性的情况下对这种情况进行建模？我现在能想到的，有几个选择。

1. 按照现有代码执行检查和操作。在这里，我们在代码中找到正确的位置，检查需求中的条件，并将电子邮件发送到硬编码地址。当然，这是充满问题的。至少，如果其中一个人离开或更改他们的电子邮件地址，它就会停止工作。在最坏的情况下，您必须确保任何测试和测试数据都知道对特定的一组标准采取了额外的操作。
2. 介绍一些形式的事件系统。在这里，我们引入了一个事件处理系统，这样我们就可以对某些事件做出反应，并满足通常执行路径之外的需求。这听起来比选项1更干净，但对于这一小需求，所涉及的工作最终可能有点过分。也就是说，有了它，系统就可以在将来始终如一地、轻松地处理这些特定的需求。

是否有其他(好的/更好的)方法来处理高度具体的需求？我的意思是，除了告诉生意的其他部分不！

Answer 1

如果您在系统的某个位置提供某种配置设置，以便可以更改电子邮件地址，则选项一似乎很好。

选项二似乎对一个相对简单的业务需求来说是过分的。只有当它看起来能解决比这个特定需求更多的问题时，才能实现它。

Answer 2

此需求补充了围绕采购订单的其他需求，但由于业务其他方面的一些持续问题，该需求在较晚的时间出现。

你似乎认为，一旦这个问题解决了，你的客户就不会在其他商业领域有更多的问题了。经验表明他们会这样做。

您应该相应地规划一些可扩展的系统。事实上，IM(ns)HO从一开始就应该这么做；认为购买的验证规则可能会随着时间的推移而改变并不是件好事，而且会有助于执行您事先知道的规则(通过使它们更加模块化)。

无论如何，对我来说，这不是一个编程问题，而是一个项目管理问题。由于在最初的项目中没有考虑到这一点，因为没有人问到这种可能性，所以现在是打电话给利益攸关方并让他们作出决定的时候:一个快速、肮脏的解决方案，需要对代码进行每次修改，或者一个更灵活的解决方案，稍后才会交付(可能还需要一些额外的费用)。

真正知道平衡的是哪些是利益相关者(这些更改中有多少可能发生，这是延迟部署项目的成本，即使这种检查非常重要，以至于不能让人在报告中检查数据)。

你可以对这些变化的重要性做一个有教养的猜测，但真的不能确定。此外，通过让涉众参与并让他们做出决定，您可以希望教育他们认识到不完整/迟来的规格说明的成本，以便在下一个项目中他们在这方面做得更好。