Model-Based Test is an interest of mine and a domain in which I have some practical experience as a technical leader.
Not speaking critically, but your expressed thoughts leave quite a bit of undefined space to your Test Engineering practice, so I'll make some assumptions. I tend to shy away from the idea of "Best Practice" when discussing MBSE, as most practitioners lack craftsman level competency in the practice and I'm not convinced of the existence of 'Universal Best Practice'. Engineering strategy, driven principally by risk tolerance, schedule, and cost, for a particular project is more likely the decision driver of the right practice for the project.
First: I'm assuming you are using MagicDraw or Cameo because you refer to «extendedRequirement», which is a non-normative stereotype presented in the OMG SysML specification, but it is NOT in the OMG's SysML XMI. The «extendedRequirement» stereotype is NON-NORMATIVE and therefore, in my opinion, "custom" in the context of MD/CSM. The MD/CSM implementation does not specify Multiplicity for the "verifyMethod" tag definition and the default "<undefined>" multiplicity behavior of MD/CSM is only a single value specification is supported. You should closely evaluate the implementation of the properties of the «extendedRequirement» stereotype and take note of its variance from the implementation of the OMG standard stereotype «abstractRequirement» properties for multiplicity and visibility. Your organization should also consider the justification of using the «extendedRequirement» stereotype to denote the requirement taxonomy semantic of "verification requirement". I suggest this creates ambiguity in your requirement taxonomy and should be avoided.
Secondly, If your organization intends to model a "Verification Requirement" for each system requirement, then your organization should strongly consider adding a configuration-managed custom profile to support the practice. Elaboration of the verification method is also essential. Merely stating the verifyMethodKind is insufficient. I subscribe to the thinking of A. Wayne Wymore in this regard (see: A System Theoretic Framework for V&V). I paraphrase: How can it be proven that the as-built system meets stakeholder expectations? What is the set of objective evidence that provides proof?
That said, I also suggest that there are many of us in the Test Engineering community that question "multiple verification methods" for a properly written black-box functional or non-functional requirement. I'm aware that many organizations misuse the "verification method: analysis" (as defined in ISO-29148). As stated in ISO-29148 "analysis" does NOT mean to process collected data from stimulating and observing the realized system. This is a discussion for a different medium. The OMG SysML specification implies an expansive scope of verification method = analysis.
I have many more thoughts on this topic, but I'll stop here.