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

Question

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

据我所知，通常用例<>需求，而测试用例<< verify >>它。

虽然用例可以<>需求吗？

我在有关此事的陈述中发现了不同的消息来源。

对于经典的警报时钟示例，带有：

Req1：在选定时间唤醒。

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

[Test1：给定一个电台处于101.5FM，并且正确设置了时间，当我设置警报未来时间并将频率设置为101.5FM时，我将在给定时间收听该电台。

什么是正确和/或最佳的图？

（（UseCase1）-满足-> [Req1]，[TestCase1]-验证-> [Req1]

或

（（UseCase1）-满足-> [Req1]，[TestCase1]-验证->（UseCase1）

或

（（UseCase1）-验证-> [Req1]，[TestCase1]-验证-> [Req1]

感谢您的澄清！

Answer 1

用例将如何验证需求？

SysML：

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

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

用例将如何满足要求？

SysML：

满足关系是需求与需求之间的依赖关系 满足要求的模型元素。

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

关于您的示例

用例“设置警报时间和无线电频率”的目标是什么？警报时间和无线电频率设置？好吧，请原谅我，但这并没有真正的帮助。

用例完善了涉众需求“在选定的时间唤醒”，并且具有相同的名称。而且这个用例有很多替代流程，大多数钟表制造商一无所知，他们忘记了：我醒得很早，想过早取消警报（第二天不清除）。我按下了贪睡按钮，但是现在，我已经醒了，还是决定起床（在淋浴时，闹钟响了）。我熬夜了，现在需要在最低睡眠要求和完整待办事项列表之间取得平衡（并且想知道，如果不计算深夜，还剩下多少时间）。所有这些替代流程导致附加的功能要求。

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

设置闹钟时间

选择广播或警报
• 设置无线电频率
• 用于报警的控制时钟（主要功能）
• 在预定时间播放广播
预定义时间的声音警报
• 打no警报
• 取消今天的警报
• 清除警报时间
• 显示直到警报的时间

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

所以该图可能是：

«利益相关者要求»be waken at chosen timebe waken at chosen timecancel Alarm for todaycancel Alarm

«功能要求»cancel Alarm for todaycancel Alarm after snooze

您可能会争辩到，利益相关者的需求以及间接的用例都可以通过测试用例进行验证。但是，我认为利益相关者的需求将得到验证，而不是得到验证。