质量关是每项需求正式进入需求说明书地方。我们在分析需求的时候，通常是把想到的各种各样的想法都记录下来，需求可能出现在任何地方，我们捕获了需求之后，并不会直接分析需求，有必要存在，也不考虑需求的完整性和一致性。而有了质量关之后，我们就要完整的看某一项需求了，考虑这个需求是否完整，是否合适放入到需求说明书中，如果这个需求不够完整，没有存在的必要，那就会把它排除在外，或者直接放弃这个需求。之所以这样做，是为了在后期软件开发时，避免出现无用需求，如果到那时再改的话，将花费大量的人力物力。
有了需求之后，就要经过质量关的检查了，就像食品检查一样，只有检验合格的产品，才能出了产品线进入我们的销售渠道。首先应该先检查它的完整性，需求的描述，需求存在的理由，需求的来源，从各个方面对需求进行检查，即需求是否还存在遗漏的地方。有了需求，就一定要承担相应的风险责任，那么我们就要衡量，我们所要承担的风险，是否与我们的需求相匹配，简单的说就是值不值得，值得就做，不值得就pass。和目标的相关性也要检查，就是我们做的这个需求，是不是真的是用户需要的，和我们的业务目标是否相关。总的来说就是，你这个需求，首先要完整，其次，你要对我们这个软件有用，让用户满意，没有用的需求，或者用户觉得不喜欢不满意，那也就没必要存在了。
原型的建立也很重要，它能让用户更加明白我们要做的东西，简单易懂。我们写出一种情况，就好像书上说的，我有一个电吹风，做电吹风这个东西，功能性需求那当然就是能吹热风，非功能性需求那就多了，就需要和用户进行交流了。
比如说，我想自己调节吹凉风或是热风，我希望电吹风可以有多个档位而不是只有快和慢两档，或者说我想让电吹风有时间计时功能，到了之间就自动停止等等。通过对场景的模拟，来看用户想要什么。因为有的时候你问他，你想要什么功能，可能他也说不出来个一二三，或者他只会说，我想要一个可以吹头发的电吹风。所以这个时候我们就需要模拟一些场景，来引导用户说出他们真实的想法，真实的需求。遇到这种情况，你想怎么办，会比直接问，你想要什么功能要好的多。
我们的需求规格说明书也是需要检查的，主要就是检查需求是否有遗漏，是否有冲突的和是否有二义性的。比如涉及到个人隐私信息的东西，是否考虑到信息安全方面的东西了。用户用这个软件，个人信息不被泄露这是最基础的。需求中用字一定要精准，避免存在二义性，像“应该”、“大概”这些词都不应该出现在需求说明书上。
需求分析说明书是我们需求分析的最终结果，一定要再三检验之后，才能进入到真正的开发阶段，需求分析和软件开发的重要性是同等的，并不存在孰轻孰重的问题，如果连需求分析这个基础的做不好，就像盖楼一样，地基不行，盖出来的楼也一定不合格。