软件需求工程-需求验证

需求验证（SRS）的主要内容
1、SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征
2、SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的
3、需求是完整的和高质量的
4、需求的表示在所有地方都是一致的
5、需求为继续进行系统设计、实现和测试提供了足够的基础

需求评审类型
1、评审。是一次正式的会议，在会议上向用户或其他项目干系人介绍一个或一组工作产品，已征求对方的意见和批准
2、检查。是一种正式的评估方法。检查成员是由非制作本人的个人和小组组成检查小组，主要是验证是否有错误、是否违反开发标准、是否存在其他问题
3、走查。走查的成员组成是由某个开发人员领导一个或多个开发团队成员对工作产品进行检查

评审的过程
1、计划，就是要确定评审的对象及原因、评审小组成员和人数、议程和进行评审所需的信息和资料。评审小组成员一般都是3到7人之间，并且要有一定的专业知识和项目经验，并把整理评审的材料发给评审小组成员从而让小组成员有时间查看资料
2、准备，评审人员应该在评审之前研究材料、构思和确定要讨论的问题
3、进行评审，就是把所有评审人员召集在一起进行评审会议讨论，记录评审过程中的问题
4、对评审结果采取行动，就是在评审结束后对整理的问题进行优先顺序的排列，并对问题进行跟踪和解决办法的整理

如何做好评审
1、分层评审，因为需求是分层的，所以根据不同的需求进行不同层次的评审和不同层次评审人员的组织
2、正式评审与非正式评审相结合，因为非正式评审更容易发现问题，所以在进行评审的时候要两个方式进行结合使用
3、分阶段评审，不要在需求最终阶段才进行，应该计划性的分阶段进行需求评审，从而降低需求的风险
4、精心挑选评审人员，因为评审是分阶段和目的性的，所以在进行评审的时候应该根据情况进行人员的组织
5、对评审人员进行培训，因为评审人员是领域专家而不是进行评审活动的专家，他们没有掌握评审的方法、技巧和过程等。因此，需要对他们进行培训，从而达到很好的效果
6、充分利用需求怕是检查单，因为检查单可以帮助评审人员系统而全面地发现问题，最主要的是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等
7、建立标准的评审流程
8、做好评审后的跟踪工作
9、充分准备评审

需求测试的过程
1、需求测试人员根据概念用例所描述的若干问题可能的过程，进行“概念上”的执行，期望发现遗漏的、错误的和不必要的需求
2、根据测试结果快速修改对应的需求文档，完成一轮完整的需求测试过程