业务、功能和系统需求之间的相互作用或关系是什么？

Question

我从最终用户社区引出业务需求，然后将这些业务需求带到功能团队以创建功能需求，然后将这些功能需求传递给系统工程师和架构师以创建系统需求，这是否有意义呢？

例如:业务需求是，用户应该能够在文本框中输入数据。功能需求是文本框可以接受长度为40个字符的用户数据，并且将数据传递给后端应用程序。系统需求是使用Java将数据接受并传递给后端Oracle DB。

那有用吗？

Answer 1

作为业务分析师，我甚至可以说，在您的示例中，业务需求可能更多地是一种功能需求，因为它与解决方案无关，而不是一种需求。对我来说，业务需求是从业务角度编写的，并且应该尽可能地与技术无关。根据业务的需要，可以通过文本框、下拉列表、组合框等来满足需求。

Answer 2

在我习惯的术语中，你对这些词的使用不对齐。但是，其他组织可能会使用其他定义。

在我的经验中，有多个资源将需求放在软件产品上。客户和用户都有需求，这就是我所说的“客户需求”。这些都是客户和用户认为必要的系统的特点。然而，需求也可以来自业务(生产软件的公司)，通常是因为领域经验和深入了解如何继续跨客户开发产品。要求也可能来自监管来源--政府、法律、行业标准。

客户的要求可能需要某种形式的修饰。很有可能，客户不会提交从技术角度完全可用的需求。可能有不一致、不明确或不完整的问题需要解决。然而，即使在梳理和购买之后，它们仍然是客户的需求。

工程团队从这些来源获取需求，以开发与特定产品相关的系统(和子系统/组件)需求。这些需求是对客户、业务和法规需求的细化。在最高的系统级别，它们仍然需要与客户进行讨论和协商，因为业务和法规需求可能与客户需求相冲突，这些冲突需要解决。

功能需求只是一种需求。一个需求通常可以被称为“功能需求”或“非功能性需求”。非功能性需求有时也被称为“质量属性”。任何需求(客户、业务或法规)可以是功能性的，也可以是非功能性的。

在需求规范中还可以包括其他一些内容。这些被称为设计约束--不是描述软件的功能或特性，而是影响您的设计。例如，如果您的客户只运行Windows环境，那么您的软件将部署在Windows上的事实是一个设计约束。设计约束也可能来自业务或法规需求，但通常是客户或业务需求驱动设计约束。

在您的具体示例中，我要说，用户能够以特定格式输入数据是用户的要求。为了维护产品线或安全需求，在数据验证、数据完整性、校验和或散列等方面可能存在业务或法规要求。您的系统需求将为设计和测试系统的人提供足够的信息。我称之为Java和Oracle DB设计约束的使用。