需求确认的方法和内容，了解一下

需求开发不是那么好做的，有时候花费了不少时间和精力，也不一定理解了客户的需求。所以，把需求开发的结果写成需求规格说明，并不是需求开发的终点，最后也是最关键的是对需求的确认！

这也是在GJB5000A中把需求确认放在需求开发最后一个专用实践的原因吧！

那么需求确认就应该怎样做呢？

在GJB5000A标准当中，给出了需求确认的方法：分析、仿真、演示。

• 分析

通过对需求规格说明的分析来确认软件需求的方式，通常就是审查或评审。虽然全凭想像，但是有客户和开发人员一起分析，应该可以实现确认的目的。

• 仿真

通过使用一种低保真的模型模拟软件的方式来确认需求。由于有了可感知的东西，需求的确认更加可信。

• 演示

当具备了初步的软件原型的时候，就可以通过软件原型的演示对需求进行确认。这这种需求确认的方式可信度最高，因为他和将来软件的使用场景非常接近。

除此以外，GJB5000A标准对于需求确认的内容并没有给出详细说明。但是，我们可以从软件需求描述的一般特征来考虑需求确认的内容。包括以下特征/内容：

1. 正确性

需求描述必须是正确的。否则，实现的软件就是错误的。而需求的正确性只能由客户来确定。但是客户的思维方式和开发人员完全不同，所以，要让客户做好需求正确性的确认，应当尽可能地使用客户的语言描述或解释需求，最好让客户感知到软件的使用场景。

2. 一致性

需求描述的一致性有几个层次。首先是需求规格说明上下文的一致性。比如，对同一术语，上下文要保持一致。其次是与其他软件需求或高层需求一致性。比如，与用户需求的一致性；与非功能需求的一致性。

3. 完整性

完整性也有两个方面的含义。一是需求描述元素的完整性，包括状态，状态变化，转入，产品和约束等。二是需求与客户的期望相比是否有遗漏。这个层次的完整性在确认客户需求的时候就应由客户来做确认，在对需求规格说明进行确认时，也可以再次确认需求的完整性。

4. 可行性

需求必须是可实现的。要综合考虑技术水平、资源保障等多方面的因素。

5. 必要性

客户提出的需求不一定都是必要的。软件开发人员应当从软件帮助客户解决的问题的终极目标出发，考虑技术和环境的限制，分析软件的需求，确定哪些需求是必要的，哪些需求是冗余的。

6. 可测试性

软件的需求一定是可测试的，否则就无法进行验证和确认。需求的可测试性要求需求应当尽量采用量化的描述方式。

总结一下，需求确认就是通过分析、仿真或演示的技术手段，对需求规格说明中描述的需求的正确性、一致性、完整性、可行性、必要性、可测试性进行确认。