1) Verification方法
Verification方法包括测试类和非测试类（比如：评审、分析(FMEA, FTA)、仿真模拟等）。功能需求的验证方法多采用测试类方式；而非功能性需求可以采用非测试类的验证方法。
例如：
非功能安全需求：软件函数的圈复杂度小于10；
该需求的验证方法可以是采用静态代码分析工具的分析。
所有的需求都需要验证，不能通过测试方式验证的，需要采用其它验证方式来验证。
2) 验证准则是什么？
模型中对验证准则的解释为（参照SYS.2 Note 5/SWE.1 Note 6）：
Verification criteria demonstrate that a requirement can be verified within agreed constraints and is typically used as the input for the development of the system test cases or other verification measures that ensures compliance with the system requirements.
验证准则是表明可以在约定的约束条件下验证需求，通常被用作测试用例开发或其它验证措施的输入。
验证准则是用来回答“在什么条件下，才能判断需求有被满足呢？”
验证准则往往限定了验证的条件、范围、判定准则等。
例如：
软件需求：通过车机的USB口，给手机充电，不影响车机的正常功能。
那么从需求的可验证性角度就需要考虑：什么情况下才能认为车机的正常功能不被影响呢？
为了回答这个问题，就需要为该需求增加验证准则，如：分别在车机处于媒体播放、导航、收音机等状态下，通过USB连接手机，媒体播放、导航和收音机功能不受影响。
3) 每个需求都需要单独的验证准则吗？
在项目中，很多时候都是通过为需求增加一个单独的“验证准则”属性来做的。但是不是每个需求的“验证准则”属性都需要填写内容呢？
可以这么来考虑：
1）需求 + 验证准则是后续测试用例的输入
2）如果需求本身的描述足以支持测试用例的开发，则不需要单独定义验证准则
接下来我们看看Guideline中的规则
Verification Criteria/验证准则
a) Identification of the requirement to be verified / 识别待验证的需求
b) Verification method (e.g. tests, inspections, peer reviews, audits,walkthroughs or analysis) / 验证方法(如：测试、审查、同行评审、审计、走查或分析)
c) Verification environment / 验证环境
d) Preconditions and special conditions (e.g. with winter diesel) / 前提条件和特殊条件（例如：使用冬季的柴油）
e) Constraints / 限制
f) Success Criteria / 成功准则
[VEC.RL.1] If one of the aspects a), b) or f) is missing in the verification criteria, the indicator SYS.2 BP5 / SWE.1 BP5 must not be rated higher than P.
老杨解读：如果验证准则中缺失如上描述中的 a), b)或f)，则SYS.2 BP5/SWE.1 BP5的打分一定不能高于P
[VEC.RL.2] If the corresponding requirements or corresponding work products (e..g. test plan) contain all aspects above and there are no additional verification criteria defined, the indicator SYS.2 BP5 /SWE.1 BP5 must not be downrated.
老杨解读：如果在相关的需求或工作产品（例如：测试计划）中包括了如上描述中的所有内容，而没有单独定义验证准则，那么一定不能降低SYS.2 BP5/SWE.1 BP5的打分