真实需求与业务需求

Question

假设我有一个帐户创建表单，它填充了一个用户数据库。假设这个数据库表有6列: UserID、UserLogin、Password、Email、Demographic1、Demographic2。

该程序确实需要UserID、UserLogin和密码。没有它就不能工作。剩下的是“业务需求”，公司想知道这些事情。它们是“必需的”。

将我的应用程序和数据库构建为实际需要它们，还是在业务逻辑中强制执行此约束会更好？

我的直觉告诉我是第二种选择，但在我见过的几乎所有的产品代码中，第一种通常都是这样的。

这是不是缺乏计划，或者给业务/项目经理的程序员留下了某种印记(他们告诉我这是必需的，我会让它成为必需的)。或者，有什么令人信服的理由吗？

Answer 1

对于我们来说，真正的需求通常指的是技术需求，这是程序运行所真正需要的。我们通常在结构设计中强制执行它们，例如在您的案例中作为DB约束。

业务需求处理业务感知的内容，以使应用程序可接受。在大多数情况下，但不是所有情况下，这通常涉及如何从我们开发的程序中生成ROI。在我们的项目中，人口统计信息通常与某种营销活动联系在一起，这些数据稍后可以用来向用户推广东西，或者类似的东西。

我发现业务人员通常没有充分地向我们解释业务需求的必要性，并简单地将它们描述为“必需的”。只是在没有让我们理解上下文的情况下说明这一点，这使得我们很难确定它应该如何实现。如果我们知道业务需求是业务的核心，如果我们不正确地实现它，公司可能会损失很多，那么显然我们会选择一种更安全的方式来实现它。在您的例子中，这可能会通过将其嵌入到结构约束本身中来实现。

为了回答您的问题，重要的是要了解业务/pm提出的业务需求的上下文和需求。由于你们在同一个团队中，您应该知道这一点，以便做出最佳的技术决策。作为我个人的信念，当我有疑问的时候，我总是去进行更强有力的检查和验证(尽管这并不是必须的，总是导致最好的决定)。

希望这能有所帮助

Answer 2

你应该同时做这两件事。对数据库进行约束以要求这样做，如果有必要，还会使异常冒泡。这就是说，当您执行sql插入/更新时，该规则将存在。

然而，在业务方面，这是根据表单上的要求以可视方式表示的，并且是弹出更好的错误消息的验证逻辑。

Answer 3

选择您认为最好的方法；您是程序员-->一个具有UserID、UserLogin和密码的数据库，并将其他数据库连接到该数据库。

问题是，就像生活中的许多事情一样，最终你将对自己的选择负责，你可以通过做出比客户更好的选择来脱颖而出。客户就像一个孩子，而你就是父母。你想让孩子快乐，所以有时你不得不做出选择，从长远来看，更有可能让孩子快乐。即使你的孩子(客户)和婆婆(老板)把你往另一个方向吸。