的描述，为设计阶段划定范围，不应该包含不确性因素在里面，要么做，要么不做，不能遗留任何待解决的问题，而且还要保证需求的完整性。
4、 对优先级的排列，任何需求在整理过程中都要分优先级，即问题的重要程度，解决时的优先顺序，需求收集过程中会汇总大量的客户需求，在这些需求当中，有些是客户急需解决的，有些是起锦上添花作用的，这时就需要分析人员结合软件的现状，根据问题的急缓，来划分一下将来处理问题的优先顺序，也是为设计和开发阶段的相关人员提供可参照的依据。
三、 需求的评审
在我们看来需求的评审是软件需求分析的最后一步，将整理好的需求规格进行评审，最终决定下一步如何执行，需求的评审一般由专业人士来完成，主要包括公司的内部专家及外部专家，公司内部一般包括分析设计人员、各部门开发经理、维护经理、项目经理及资深开发人员；外部专家包括典型客户代表、实施人员代表等，评审的目的主要就软件需求规格中定义的各事项做进一步讨论，根据评审过程中各专家提出的问题再作整理、修改，最终确定需求的状态。评审过程中常见的问题有以下几方面：
1、 需求的评审流于形式，需求的评审是最后的把关阶段，有时会遇到这种情况：需求规格编写完成后，在评审的过程中只是简单的走一遍，或者评审过程中讨论激烈，评审后该干么干么，没有事后监督与执行，感觉这一点是导致后续软件不急定的主要原因。
2、 对评审人员的要求要严格，不是任何人都可以参与评审的，人多了反而效果不好，参与人员应主要是与需求密切相关的，能对需求能提出改进建议的专家，而不是随便找几个人完事。
3、 没有典型客户参与，需求的整个过程最好让具有代表性的客户参与进来，哪怕客户不明白自己真正的想要实现的东西是什么，但在整个过程中客户自始至终起到指导作用，软件是个比较抽象的东西，客户不会多过的关注开发的过程，举个例子：如果你跟客户讨论的是在建工程或大型设备的安装，那么客户肯定会重点关注很多细节，提出很多建议，因为客户明白项目完工后再改造带来的影响，但对于软件，作为客户他考虑不到软件开发完成后，后期变更所带来的麻烦，所以在讨论需求时比较马虎，描述不清楚需求，导致开发者开发出的软件与客户的期望存在巨大差异。
4、 用户需求不断的增加，这也是最常见的问题之一，在需求评审的过程中，往往评审人员根据讨论的结果会提出新的需求，会导致不断的更改，所以在编写需求规格的时候要把握一个度，不是任何需求都要列入。
5、 对需求做全面的检查，从需求的几个特性去综合考虑，如：需求的完整性、正确性、无二义性、可验证性等。
作为客户如果得到的最终软件产品不能满足某项功能，就会让开发人员修改，虽然开发人员后期不管费多大力气最终能修改完客户的需求，客户感觉是理所当然的事情，但作为开发人员来讲，如果程序开发完成后再去修改，也是一件很头疼的事，因为要放下手头的工作，优先去处理客户的问题。这一切的问题都是由于在需求的收集或验证的过程的疏忽造成的。
需求验证的最终结果是得到一个完整、正确、可执并且无二义性的需求规格，这样才可为后续工作提供保障，在整个软件生命周期中，一个错误发现的越晚，修复错误的费用越高，软件需求分析阶段可以说是发现错误的阶段，可见其重要性，需求分析阶段看似没有明确的目标，实则不然，这期间对任何问题的疏忽，都会导致系统问题呈扇形扩张，估计做过需求分析的同行都能认识其重要性。任何形式的需求规格说明书都不能保证完全没有错误和缺陷，我们在编写的过程中只能尽量按照软件工程的规范去执行，尽量避免问题的发生。