用例和测试用例的需求图可能性
Requirements diagram possibilities with use cases and test cases
我想知道在 SysML 需求图中允许什么（或者至少什么是最佳实践）关于使用 satisfy/verify 用例、测试用例和需求之间的链接。
据我了解，一般来说，一个用例<<满足>>一个需求，一个测试用例<<验证>>它。
用例是否有可能<<验证>>需求？
我发现不同的来源对此事的说法相互矛盾。
对于经典的闹钟示例，使用：
Req1：在选定的时间被唤醒。
UseCase1：设置闹钟时间和收音机频率。
Test1 : 假设有一个电台在 101.5FM 并且时间设置正确，当我设置闹钟未来时间并将频率设置为 101.5FM 时，我将在给定时间收听该电台。
那么正确的 and/or 最佳图表是什么？
(UseCase1) -- 满足 --> [Req1] , [TestCase1] -- 验证 --> [Req1]
或
(UseCase1) -- 满足 --> [Req1] , [TestCase1] -- 验证 --> (UseCase1)
或
(UseCase1) -- 验证 --> [Req1] , [TestCase1] -- 验证 --> [Req1]
感谢任何澄清！
规范中没有正式的约束，不允许这样做。然而，元素的语义使这变得毫无意义。
用例如何验证需求？
SysML: A Verify relationship is a dependency between a requirement and a test
case or other model element that can determine whether a system
fulfills the requirement.
用例描述了系统可用于实现特定目标的所有方式。它描述了用户操作以及系统必须具有的有助于实现此目标的功能。它没有描述如何测试系统功能。但是，您可以从用例描述中导出测试用例。
用例如何满足需求？
SysML: A Satisfy relationship is a dependency between a requirement and a
model element that fulfills the requirement.
用例是一种分析工具，用于查找系统应支持的功能 - 换言之，功能需求。发现需求的分析工具如何满足需求？
关于你的例子
用例的目标是什么 "set an alarm time and radio frequency"？闹钟时间和收音机频率设置好了吗？好吧，请原谅我，但这并没有什么帮助。
用例细化涉众需求"Be waken at chosen time"并且同名。这个用例有很多替代流程，大多数钟表制造商在他们幸福的无知中忘记了：我很早就醒了，想过早地取消闹钟（不在第二天清除）。我按下了贪睡按钮，但现在，我醒了，还是决定起床（当我在淋浴时，闹钟响了）。我熬夜了，现在需要在最低睡眠要求和完整的待办事项列表之间取得平衡（并且想知道，在不计算深夜的情况下，还剩下多少时间）。所有这些替代流程都会导致额外的功能要求。
因此，在此用例中找到的完整功能需求列表为：
- 设置闹钟时间
- select 收音机或闹钟
- 设置无线电频率
- 报警控制时钟（主要功能）
- 在预定义的时间播放广播
- 在预定时间发出声音警报
- 暂停闹钟
- 取消今天的闹钟
- 清除闹钟时间
- 显示闹钟前的时间
令人惊讶的是，有多少闹钟不具备所有这些功能，因为用例分析会很快找到它们。
所以图表可以是：
«利益相关者要求» be waken at chosen time
<-«优化»- «用例» be waken at chosen time
<-«trace»- «功能需求» cancel Alarm for today
<-«满足»- «操作» cancel Alarm
«功能需求»cancel Alarm for today
<-«验证»- «测试用例» cancel Alarm after snooze
您可能会争辩说，利益相关者的需求，因此间接地可以通过测试用例来验证用例。但是，我认为利益相关者的要求会得到验证，而不是被验证。
我想知道在 SysML 需求图中允许什么（或者至少什么是最佳实践）关于使用 satisfy/verify 用例、测试用例和需求之间的链接。
据我了解，一般来说，一个用例<<满足>>一个需求，一个测试用例<<验证>>它。
用例是否有可能<<验证>>需求？
我发现不同的来源对此事的说法相互矛盾。
对于经典的闹钟示例，使用：
Req1：在选定的时间被唤醒。
UseCase1：设置闹钟时间和收音机频率。
Test1 : 假设有一个电台在 101.5FM 并且时间设置正确，当我设置闹钟未来时间并将频率设置为 101.5FM 时，我将在给定时间收听该电台。
那么正确的 and/or 最佳图表是什么？
(UseCase1) -- 满足 --> [Req1] , [TestCase1] -- 验证 --> [Req1]
或
(UseCase1) -- 满足 --> [Req1] , [TestCase1] -- 验证 --> (UseCase1)
或
(UseCase1) -- 验证 --> [Req1] , [TestCase1] -- 验证 --> [Req1]
感谢任何澄清！
规范中没有正式的约束，不允许这样做。然而，元素的语义使这变得毫无意义。
用例如何验证需求？
SysML: A Verify relationship is a dependency between a requirement and a test case or other model element that can determine whether a system fulfills the requirement.
用例描述了系统可用于实现特定目标的所有方式。它描述了用户操作以及系统必须具有的有助于实现此目标的功能。它没有描述如何测试系统功能。但是，您可以从用例描述中导出测试用例。
用例如何满足需求？
SysML: A Satisfy relationship is a dependency between a requirement and a model element that fulfills the requirement.
用例是一种分析工具，用于查找系统应支持的功能 - 换言之，功能需求。发现需求的分析工具如何满足需求？
关于你的例子
用例的目标是什么 "set an alarm time and radio frequency"？闹钟时间和收音机频率设置好了吗？好吧，请原谅我，但这并没有什么帮助。
用例细化涉众需求"Be waken at chosen time"并且同名。这个用例有很多替代流程，大多数钟表制造商在他们幸福的无知中忘记了：我很早就醒了，想过早地取消闹钟（不在第二天清除）。我按下了贪睡按钮，但现在，我醒了，还是决定起床（当我在淋浴时，闹钟响了）。我熬夜了，现在需要在最低睡眠要求和完整的待办事项列表之间取得平衡（并且想知道，在不计算深夜的情况下，还剩下多少时间）。所有这些替代流程都会导致额外的功能要求。
因此，在此用例中找到的完整功能需求列表为：
- 设置闹钟时间
- select 收音机或闹钟
- 设置无线电频率
- 报警控制时钟（主要功能）
- 在预定义的时间播放广播
- 在预定时间发出声音警报
- 暂停闹钟
- 取消今天的闹钟
- 清除闹钟时间
- 显示闹钟前的时间
令人惊讶的是，有多少闹钟不具备所有这些功能，因为用例分析会很快找到它们。
所以图表可以是：
«利益相关者要求» be waken at chosen time
<-«优化»- «用例» be waken at chosen time
<-«trace»- «功能需求» cancel Alarm for today
<-«满足»- «操作» cancel Alarm
«功能需求»cancel Alarm for today
<-«验证»- «测试用例» cancel Alarm after snooze
您可能会争辩说，利益相关者的需求，因此间接地可以通过测试用例来验证用例。但是，我认为利益相关者的要求会得到验证，而不是被验证。