问题：为什么系统/软件开发企业偏爱用例需求而不是声明系统需求？
比较：
系统的功能需求通常通过以下任一方式定义：
1-传统须说明系统要求
2个用例（文本或图表）
尝试使用这两种方法来提供系统要求，就像将系统视为“黑匣子”一样，即要求不应定义子系统详细信息。
我感到传统的遗嘱声明被遗弃了，但是我也认为它们对于系统是很好的定义。我并没有找到用例来编写SMART或良好需求的方式。它们不是原子的，不可测试的，定义或依赖于其他系统行为，超定义系统或定义子系统行为以定义系统交互。我认为，传统的声明声明需求在需求管理方面具有原子性，因此更好。但是，我看到它也被批评为难以完成，完成时很难适应变化。我反对。它们可能很难完成，但是您必须具有完整的要求。您可能没有完整的开始，但是可以随心所欲地完成。我也不认为他们很难适应变化。我认为，在用例中，单一更改更容易影响需求的其他部分。但是良好的声明书要求应该是原子的。借助可追溯的需求管理，例如接口的任何更改，都可以轻松地指出要更改/删除/添加的需求。您甚至可以通过在界面元素上使用符号来从界面详细信息中提取需求，以增强适应界面更改的能力。
示例：
我想用下面的例子进一步阐述。为了简单起见，功能定义将很小。
比方说，我有一个由4个子系统组成的系统。 System1控制system2。系统2控制系统3和系统4。 System2具有打开和关闭System3和System4的电源。系统1将消息1发送到系统2，以控制系统3。系统1将消息2发送到系统2，以控制系统4。我需要定义的系统是system2。
用例方法：
主要流量
替代流1（MF.2）： 1. system2收到“关闭system3的电源”。 2. system2关闭“ system3”的电源
替代流2（MF.4）： 1. system2收到“关闭system4的电源”。 2. system2关闭“ system4”的电源
应声明的要求：
REQ1：如果“ system1”通过消息“ message1”应用了“ system3上电”，则“ System2”应上电。
REQ2：如果“ system1”应用了消息“ message1”关闭系统3，则“ System2”应关闭“ system3”。
REQ3：如果“ system1”通过消息“ message2”应用了“ system4上电”，则“ System2”应上电。
REQ4：如果“ system1”应用了消息“ message2”关闭“ system4”，则“ System2”应关闭“ system4”。
注意：我什至将REQ1和REQ2作为一个需求，而REQ3和REQ4作为一个需求，因为它们是两组截然不同的需求，它们的并集定义了用户系统（“ system1”）应用的每个条件。 / p>
我认为需求应该是明确的，可实现的，可测试的，与其他需求不冲突，在必要时有时限，不定义子系统的行为，不过度定义，不定义其他交互系统的行为，定义在什么条件下满足。我认为该声明要求足够好。您可以简单地实现它们，只需编写简单的测试用例并验证系统。
我认为，对于用例语句，我们必须定义主流中的每个步骤是否是一个需求，或者整个场景是否是一个单独的需求。
如果每个步骤都是必需的，那么我认为第1,2步定义了其他系统行为（如果它以替代方式编写），并且它们不可测试，因为测试的唯一方法是询问系统是否收到了该行为消息。步骤3可能还可以，但是我们想要的是，如果步骤1和步骤2之前发生，则必须满足该要求。由于step3没有引用step1＆2，因此step3不能成为独立的要求。
我认为我们应该将所有这些都视为一个单独的要求。我认为这种观点更可行，但是我认为，这种观点也有缺陷。
步骤1仍在定义其他系统行为，或与其相关。您可能会说这是整个场景的前提，否则可能会反驳，但在这种情况下，步骤4还在定义其他系统行为。我认为需求不应该取决于其他系统应该做什么，而应该定义不依赖于其他系统的所有情况。
此外，由于用例是一个序列，因此我们现在还将“ power system3”操作定义为在“ power system4”操作之前。但是，以系统工程师的身份，我不想为system2定义它。 System2应该处理订单发出的顺序。对这些操作进行排序是对我的过度定义和子系统行为。
我试图简化示例。但是在现实生活中，用例通常很长，它们必须定义不必要的子系统行为才能定义系统交互，而不是原子的，不可测试的，或者生成测试用例并不自然。须声明要求，这是基本要求。由于用例很长，因此它们由多个原子的声明声明组成。如果将具有大量原子需求的用例的整个长期情况视为一个单一的需求，那么当相关的测试用例失败时，那么如何确定并记录问题。