功能要求、非行为规范、验收标准和差距

Question

我绞尽脑汁想知道什么是正确的答案，以及需求收集过程中的差距在这个团队中的位置。

• 非技术BA --他们的角色是以用户故事的形式编写业务和用户需求。但是，当有令人信服的业务理由定义一般的系统行为时，他们会用系统参与者编写用户故事。他们定义了这些故事的接受标准。
• 业务系统分析师和SE公司--我们的职责是接受业务和用户需求，并从中派生功能需求。我们通常会定义系统参与者，并使用可追溯性定义可追溯到业务需求和用户故事的系统行为。

我感到困惑的是，业务需求和用户故事通常没有定义描述功能组件所需的必要细节，而且我也不确定它们是否应该。非技术BA不会理解如何做到这一点的复杂之处，即使我们要求他们这么做，因此似乎他们属于功能需求，但是根据功能需求的正式定义，他们要定义系统的行为：

函数被描述为一组输入、行为和输出(也请参阅软件)。功能需求可能是计算、技术细节、数据操作和处理，以及定义系统应该完成的任务的其他特定功能。功能需求(维基百科)

团队中的每个人现在都在以不同的方式处理这件事。我们为捕获FR而批准的文档是有限的，它迫使我们定义组件的功能，而不是组件本身的细节。一些BSA和SE使用空条件和接受标准定义函数，并使用Input字段来定义组件的属性。其他人甚至还没有捕捉到这些信息，或者把它们分散在附加于函数的笔记中。

其他人仍然与非技术BA争论，声称他们的需求不够具体，Scrum大师的回答是鼓励我们把事情分割成完全模糊的遗忘，希望事情变得更有价值。

在此，我对功能需求定义的理解是否受到限制？

澄清:我觉得我应该澄清，当我说到业务需求时，我指的是来自管理层的非常高级别的愿景声明。他们几乎与这个项目无关，只不过是水冷的空谈。实际使用的需求是用户故事。

Answer 1

其他人仍然与非技术BA争论，声称他们的需求不够具体，Scrum大师的回答是鼓励我们把事情分割成完全模糊的遗忘，希望事情变得更有价值。

他们可能是正确的，虽然不是关于混淆。

需求应该足够具体，以便您可以为需求编写一个测试，并让客户同意，如果测试通过，需求就满足了，并且您可以声明成功。

如果您仍然需要更多的专用性来允许更好的估计并为程序员提供更好的细节，那么编写一个软件设计规范。这包括类图和方法描述(输入、输出、目的等)。顾客不会卷入这件事..。这些只是给开发人员的说明。然而，这些指令确实可以直接映射到可测试的需求。