1. 验证需求列表是spec在验证角度的提取结果

2. 验证需求列表关注结果的检查方法

3. 验证需求列表不涉及具体怎么做验证（验证平台和验证细节），把过多的精力放在这些How的事情上，What层面的内容就会有遗漏。

4.验证需求列表提取的来源：总体设计，用户手册，详细设计（主要），设计代码（文档不清晰时参考），以及设计人员或者架构设计师的书面或口头的建议。

5.验证需求列表提取粒度（granularity):最小粒度，最小是指一条entry可以用“是否”句式来回答，如果回答是“是”则结束，如果回答“否”则需求对需求再细分。

6.验证需求列表提取考虑的维度：提取每条entry需要考虑三大维度（功能，实现，接口），其中功能为高层次的来源于需求的需要完成的功能（包括配置）；实现主要是在实现功能的同时使用到的逻辑设计元素，包括fifo,arbiter,fsm,ALU,bus,ram等具体实现；接口关注的是在顶层的信号时序特性和协议特性。

7.验证需求列表考虑：需要在提取验证需求的时候，考虑边界，异常，性能。

8.验证需求列表的提取顺序：按照设计spec的章节序提取需求，需求的前后顺序与章节序相对应。

9.验证需求列表的层次化：将需求分为三个层次，目的是有层次就有归类，有归类就有思考，从而保证需求提取的完备性。

10.验证需求列表中结果校验：默认是scoreboard，实际有coverage和SVA（SVA的coverage).

11.验证需求列表分为优先级：从时间和重要性上设置高低优先级，保证集中时间做完主要的事。

12.验证需求列表的case栏：对每个feature进行命名和编码。

13.验证需求列表的状态栏：随着验证的执行，可以追踪验证的进度。

14.验证需求列表需要建立与spec的对应关系（例如超链接方式）:没有对应关系就会产生功能点的遗漏，理论上将可以通过评审来把关这个，事实上1-2小时的评审并不能有效保证。

15.验证需求列表需要增加一栏：对验证过程详细描述（按照测试规程的格式）。