软件需求，即客户对于软件产品的要求,是软件项目开展的基础。在大多数情况下，对于需求，客户本身也并不十分清楚或客户认为需求和限制条件过于明显以至于并不将它们作为需求专门向软件开发团队提出。与此同时，软件产品的规模越来越大，实现的业务越来越复杂，因而促使人们采用一些工程化方法对软件产品需求进行研究，需求规格说明的正确性能获得准确、清晰和全面的需求，促进软件项目顺利进行。需求规格说明的正确性通常可以从如下方面得以体现：
1 是否有需求与其他需求相互冲突或者重复？
通常一份长达几百页的需求规格说明书都不会是一蹴而就的，它可能是系统分析师几个夜晚的心血之作。正是因为撰写过程的连续性，可能导致同一份文档中前后名词定义不一致，前后观点上有重叠或差异的情况出现，这需要我们在撰写报告前首先要在思想上形成统一概念, 可使术语列表贯穿整份文档以达提纲挈领之效。
2 是否清晰、简洁、无二义地表达了每个需求?
“清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果,是让大家对需求描述的理解能够达成一致 。需求评审的前提是用户读懂了需求说明,并且用户的理解内容就是分析师们所描述的内容。
3 是否每个需求都通过了演示、测试、评审，分析是否得到了验证?
需求应该是可以测试的,通常通过测试去验证它是不是正确。如果需求书未能经过原型测试通过,则需求评审是不能得到通过的。 面对相当复杂的业务需求,经过测试或演示是让用户信任的一个必要过程。试想一下, 如果连需求都不能很好地被确认，则开发实现阶段更是没有把握控制了。
4 是否每个需求都在项目的范围内?
划分项目范围和区分系统边界同样是需求说明书的一个任务，不要对需求书作出超范围的论述和延伸，要知道需求书不是分析师卖弄概念、展示时尚的场所，它是软件工程的一个重要环节。
5 是否每个需求都没有内容和语法上的错误?
按照传统的需求列表方式，需求像菜单一样被一条条列出来，构成需求项的主要栏位包括：需求ID、 需求描述、优先级、来源和状态等。 通常需求首先要经过“拼写检查”，保证没有拼写上的问题，然后通过逐行浏览修改那些在内容或行文上出现问题的需求。
6 在现有的资源内, 是否能实现所有的需求?
需求规格说明要考虑可行性的问题。事实上，分析师的关注层面是价值驱动和成本驱动方面。分析师应该明白不是所有的需求都要去实现，一些看上去很明显与涉及用户有冲突的、费力不讨好的需求应该果断地舍弃。国内有专家提出，搞需求也要讲“和谐”即是此中道理。
7 每一条特定的错误信息，是否都是唯一的和具有含义的?
不要忽视错误信息的定义, 它必须具有唯一性。如果过于笼统地定义错误信息则和没有定义的效果是一样的。