用例和测试用例的需求图可能性

Question

我想知道关于在用例、测试用例和需求之间使用满足/验证链接的 SysML 需求图中允许什么（或者至少是最佳实践是什么）。

据我了解，一般来说，一个用例>一个要求，一个测试用例>它。

一个用例是否有可能>一个需求？

我发现了不同的来源，关于此事的陈述相互矛盾。

对于经典的闹钟示例，使用：

Req1：在选定的时间被唤醒。

UseCase1 : 设置闹钟时间和无线电频率。

Test1 : 假设有一个 101.5FM 的电台并且时间设置正确，当我设置闹钟未来时间并将频率设置为 101.5FM 时，我将在给定时间收听电台。

那么正确和/或最好的图表是什么？

(UseCase1) -- 满足 --> [Req1] , [TestCase1] -- 验证 --> [Req1]

或

(UseCase1) -- 满足 --> [Req1] , [TestCase1] -- 验证 --> (UseCase1)

或

(UseCase1) -- 验证 --> [Req1] , [TestCase1] -- 验证 --> [Req1]

感谢您的澄清！

Answer 1

规范中没有正式的约束，这将不允许这样做。但是，元素的语义使这毫无意义。

用例如何验证需求？

SysML：验证关系是需求和测试之间的依赖关系 案例或其他模型元素，可以确定一个系统是否 满足要求。

用例描述了系统可用于实现特定目标的所有方式。它描述了用户操作以及系统必须有助于实现此目标的功能。它没有描述如何测试系统功能。但是，您可以从用例描述中导出测试用例。

用例如何满足需求？

SysML： 满足关系是需求和 满足要求的模型元素。

用例是一种分析工具，用于查找系统应支持的功能——换句话说，就是功能需求。找到需求的分析工具如何满足需求？

关于你的例子

用例“设置闹钟时间和无线电频率”的目标是什么？闹钟时间和收音机频率都设置好了吗？好吧，请原谅我，但这并没有真正的帮助。

用例细化了利益相关者的要求“在选定的时间被唤醒”并且具有相同的名称。而且这个用例有很多可供选择的流程，大多数钟表制造商在他们的幸福无知中忘记了：我起得很早，想提前取消闹钟（第二天不清除）。我按下了贪睡按钮，但现在，我醒了，还是决定起床（当我在淋浴时，闹钟响了）。我熬夜了，现在需要在最低睡眠要求和完整的待办事项清单之间取得平衡（并且想知道，不计算深夜，还剩多少时间）。所有这些替代流程都会导致额外的功能需求。

因此，在此用例中找到的完整功能需求列表将是：

• 设置闹钟时间
• 选择收音机或闹钟
• 设置射频
• 报警控制时钟（主要功能）
  • 在预定时间播放广播
  • 在预定时间发出声音警报
  • 打盹闹钟
  • 取消今天的闹钟
  • 清除闹钟时间
  • 显示距离闹钟响起的时间

令人惊讶的是，有多少闹钟没有具备所有这些功能，因为用例分析会很快找到它们。

所以图表可能是：

«利益相关者要求»be waken at chosen time
be waken at chosen time
cancel Alarm for today
cancel Alarm

«功能需求»cancel Alarm for today
cancel Alarm after snooze

您可以争辩说，利益相关者的要求，因此间接地用例可以通过测试用例得到验证。但是，我认为利益相关者的要求会得到验证，而不是验证。