我想知道关于在用例、测试用例和需求之间使用满足/验证链接的 SysML 需求图中允许什么（或者至少是最佳实践是什么）。
据我了解，一般来说，一个用例<<满足>>一个要求，一个测试用例<<验证>>它。
一个用例是否有可能<<验证>>一个需求？
我发现不同的消息来源对此事发表了相互矛盾的陈述。
对于经典的闹钟示例，使用：
Req1：在选定的时间被唤醒。
用例1：设置闹钟时间和无线电频率。
测试1：假设有一个 101.5FM 的电台并且时间设置正确，当我设置闹钟未来时间并将频率设置为 101.5FM 时，我将在给定时间收听电台。
那么正确和/或最好的图表是什么？
(UseCase1) -- 满足 --> [Req1] , [TestCase1] -- 验证 --> [Req1]
或者
(UseCase1) -- 满足 --> [Req1] , [TestCase1] -- 验证 --> (UseCase1)
或者
(UseCase1) -- 验证 --> [Req1] , [TestCase1] -- 验证 --> [Req1]
感谢您的任何澄清！
规范中没有正式的约束，这将不允许这样做。但是，元素的语义使这毫无意义。
用例如何验证需求？
SysML：验证关系是需求与测试用例或其他模型元素之间的依赖关系，可以确定系统是否满足需求。
用例描述了系统可用于实现特定目标的所有方式。它描述了用户操作以及系统必须有助于实现此目标的功能。它没有描述如何测试系统功能。但是，您可以从用例描述中导出测试用例。
用例如何满足需求？
SysML：满足关系是需求和满足需求的模型元素之间的依赖关系。
用例是一种分析工具，用于查找系统应支持的功能——换句话说，就是功能需求。找到需求的分析工具如何满足需求？
关于你的例子
用例“设置闹钟时间和无线电频率”的目标是什么？闹钟时间和收音机频率都设置好了吗？好吧，请原谅我，但这并没有真正的帮助。
该用例细化了涉众要求“在选定的时间被唤醒”并具有相同的名称。而且这个用例有很多可供选择的流程，大多数钟表制造商在他们的幸福无知中忘记了：我起得很早，想提前取消闹钟（第二天不清除）。我按下了贪睡按钮，但现在，我醒了，还是决定起床（当我在淋浴时，闹钟响了）。我熬夜了，现在需要在最低睡眠要求和完整的待办事项清单之间取得平衡（并且想知道，不计算深夜，还剩多少时间）。所有这些替代流程都会导致额外的功能需求。
因此，在此用例中找到的完整功能需求列表将是：
令人惊讶的是，有多少闹钟没有所有这些功能，因为用例分析会很快找到它们。
所以图表可能是：
«利益相关者要求» be waken at chosen time
<-«refine»- «用例» be waken at chosen time
<-«trace»- «功能要求» cancel Alarm for today
<-«满足»- «操作»cancel Alarm
«功能需求» cancel Alarm for today
<-«验证»- «测试用例»cancel Alarm after snooze
您可能会争辩说，利益相关者的要求，因此间接地用例可以通过测试用例得到验证。但是，我认为利益相关者的要求会得到验证，而不是验证。