问将软件划分为需求层

EN

需求通常有层次，特别是当软件是复杂的，或者当指定一个系统同时包含硬件和软件元素时。根据系统的复杂性，您可以有任意多个层。

不过，我不同意你的定义。需求总是针对系统所做的事情(功能需求或行为需求)或用于评估系统的标准(非功能需求、非行为需求或质量属性)。它们有不同的源和不同级别的粒度，但都满足良好要求的特点。

需求的第一个来源是我所说的“客户需求”。这些都是来自为软件的设计和开发付费的客户或将使用该软件的人的需求。这些通常使用客户和用户的域语言来表示。通常，这些需要转化为可以设计和实施的更多的技术要求。

规则、法律和条例也提供了要求的来源。我通常听到这些被称为“监管要求”或“合规要求”。客户或用户可以明确或不明确地识别这些问题，也可以在高级别上加以识别(例如指必须遵守的法律或条例)。具体的法规要求将识别系统的特定行为或属性，这些行为或属性可以追溯到法规或法律，但不存在于客户需求中。

另一个需求来源是“业务需求”。这些都是发展中组织征收的要求。也许开发组织有一个实现产品路线图的总体策略。为了遵循这个路线图，必须在软件的设计上添加额外的约束。

在这些更高层次的需求之间可能存在冲突。需求工程过程的一个步骤是分析需求并围绕冲突进行协商，以实现一组可以设计和实现的需求。客户可能不完全了解开发组织所知道的一些规则。客户的愿望可能与开发组织的产品路线图发生冲突。这些问题必须由需求工程师来解决。

所有这些顶级需求可能都是用特定于领域的语言编写的，这些语言可能不适合于设计和测试。接下来的所有需求层在本质上都是技术性的。但是，有多少层取决于系统的复杂性。

在更简单的软件系统中，您可以将用户需求、法规需求和业务需求组合成一组软件需求。在本例中，您将只有两层需求。

在复杂的硬件/软件系统中，您可能有多个级别，包括描述整个硬件/软件系统的系统需求，然后对不同的组件分离需求。根据复杂性，如果您有多个组件，那么您可能对子系统和组件有一组需求。然而，任何分组都是为了管理需求和产品。

维基百科的一组要求类型也略有不同。但是，该列表是级别和类型之间的交叉。

我建议查阅一些关于需求工程的资源，以获得更多的细节。就我个人而言，我的首选是软件需求，它现在已经在第三版了。不过，我也听说过关于管理需求过程的一些积极的事情。