⑤ 是否每个需求都没有内容和语法上的错误？
⑥ 在现有的资源内，是否能实现所有的需求？
⑦ 每一条特定的错误信息，是否都是唯一的和具有含义的？
（2）注意对软件需求说明书的实践性进行评审。所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度，而非源于分析师们经验主义的臆测。实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。
（3）注意对需求规格说明书的完整性进行评审。可由下面的问题清单来评审需求说明书是否“完整”：
① 编写的所有需求，其详细程度是否一致和合适？
② 需求是否能为设计提供足够的基础？
③ 所有对其他需求的内部引用是否正确？
④ 是否包含了每个需求的实现优先级？
⑤ 是否定义了功能说明的内在算法？
⑥ 是否包含了所有已知的客户需求或系统需求？
⑦ 是否遗漏了必要的信息？⑧是否对所有预期的错误条件所产生的系统行为都编制了文档？
需求说明的完整性主要体现在需求说明的详细程度上，怎样判断该需求的描述是否详细呢？笔者认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应等。
（4）注意对需求方案的可行性和成本预算进行评审。
（5）注意对需求的质量属性进行评审。评审需求规格需要说明是否合理地确定了所有的性能目标，是否合理地确定了安全性方面要考虑到的问题。
（6）注意对需求的可实施性进行评审：
① 是否对每个需求都设置了唯一性并且可以正确地识别它？
② 是否每个功能需求都可以跟踪到高层需求？
需求必须可以测试，每个需求在特定的输入条件下应当能给出已知的输出结果，同时，需求应当层次分明，需要把单个需求下面的相关需求综合在一起形成一组需求功能。需求的可实施性除了可跟踪性还包括可测试性，事实上，分析人员和测试人员在编写代码以前把需求模型，分析模型和测试用例综合起来通盘考虑，检查出遗漏的、错误的和不必要的需求，软件需求在概念上的测试是一种很必要的技术，它可以在项目早期阶段发现需求的歧义和错误。
