I am wondering what is allowed (or at least what is the best practice) in a SysML Requirements diagram regarding the use of satisfy/verify links between use-cases, test-cases and requirements.
As I understand it, generally, a use-case << satisfy >> a requirement, and a test-case << verify >> it.
Is-it possible though for a use-case to << verify >> a requirement?
I found different sources with contradictory statements on the matter.
For the classical Alarm-Clock example, with :
Req1 : To be waken at chosen time.
UseCase1 : Set an alarm time & a radio frequency.
Test1 : Given there is a station at 101.5FM and the time is correctly set, when i set an alarm future time and set the freq to 101.5FM, then I will listen to the station at the given time.
What is then the correct and/or best diagram ?
(UseCase1) -- satisfy --> [Req1] , [TestCase1] -- verify --> [Req1]
or
(UseCase1) -- satisfy --> [Req1] , [TestCase1] -- verify --> (UseCase1)
or
(UseCase1) -- verify --> [Req1] , [TestCase1] -- verify --> [Req1]
Thanks for any clarifications!
There is no formal constraint in the specification, that would disallow this. However, the semantics of the elements makes this meaningless.
How would a use case verify a requirement?
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.
A use case describes all the ways a system can be used to achieve a certain goal. It describes user actions as well as functions the system must have to be helpful for achieving this goal. It doesn't describe how to test the system functions. You can however derive test cases from a use case description.
How would a use case satisfy a requirement?
SysML: A Satisfy relationship is a dependency between a requirement and a model element that fulfills the requirement.
A use case is an analysis tool to find the functions, that the system shall support - in other words, the functional requirements. How can an analysis tool that finds requirements satisfy a requirement?
About your example
What is the goal of the use case "set an alarm time and radio frequency"? The alarm time and the radio frequency are set? Well, forgive me, but this is not really helpful.
The use case refines the stakeholder requirement "Be waken at chosen time" and has the same name. And this use case has a lot of alternative flows, that most clock makers in their blissfull ignorance forget: I awake early and want to prematurly cancel the alarm (without clearing it for the next day). I pressed the snooze button, but now, that I'm awake, decide to get up anyway (and while I'm under the shower, the alarm goes off). I stayed up late, and now need to strike a balance between a minimum sleep requirement and a full to do list (and would like to know, without calculating late at night, how much time would be left). All these alternative flows lead to additional functional requirements.
So the complete list of functional requirements found in this use case would be:
It is amazing how many alarm clocks fail to have all these functions, given that a use case analysis would find them quickly.
So the diagram could be:
«stakeholder requirement» be waken at chosen time
<-«refine»- «use case» be waken at chosen time
<-«trace»- «functional requirement» cancel Alarm for today
<-«satisfy»- «operation» cancel Alarm
«functional requirement» cancel Alarm for today
<-«verify»- «testcase» cancel Alarm after snooze
You could argue, that the stakeholder requirement, and, thus indirectly the use case could get verified by a test case. However, I think that a stakeholder requirement would get validated, not verified.