一致的需求理解在需求开发和管理实践领域非常重要。

如果开发人员不与需求提供者一致理解软件需求，他们可能会开发出与需求提供者原本想要的软件。

所以，我们的GJB5000标准对此有特殊的实践要求，目的是确保开发的软件满足用户的需求。

我们在实施这一实践的时候，通常是在项目早期通过与需求提供者的沟通和交流，确保双方对需求达成一致理解，并且这个一致理解会以任务书以及需求规格说明的评审作为“获得需求一致理解”实践的终极实践。

而很多GJB5000名评估师还将使用任务书交流和评估作为项目实施实践的有力证据。

但是，这种约定俗成的做法存在着重大问题。

我们的约定俗成做法有一个假设性的前提，就是我们假设用户的需求在项目前期已经确定，项目中后期不会改变。

只有当这个假设成立时，我们才能在项目的早期与需求提供商沟通，完成任务书的评估，以确保需求理解是一致的。

其实这个假设很可能是不成立的。

一方面，即使在项目初期已经确认了用户的需求，用户自己也认为期望的软件需求是这样的，但是随着时间的推移和项目的进展，用户很可能会发现新的需求或者更好的需求。

另外，现实中很多项目的软件需求一开始都有很多不确定的需求，这些需求可能会影响以后确定的需求。

这两种情况都会导致来的一致理解产生偏差。

因此，获得对需求的一致理解的实践不仅要在项目的早期进行，还要在软件开发的整个生命周期进行。只有在软件开发的整个生命周期中，开发者始终与需求提供者保持不间断的沟通，跟踪用户的预期目标是否偏离，才能真正与用户保持对需求的一致理解。

这正是：

需求理解必须一致，重要性已知

不能只在早期做，全程跟踪才能保持

参考书目:成功的软件开发方法——外到内开发实践指南，作者:(美)CarlKesslerJohnSweitzer出版社:机械工业出版社

作者简介:王小双，长期从事GJB5000推广、实施、评价、改进工作，创建软件工程之思微信公众号，共享软件工程之思GJB5000、CMMI软件工程的知识与感悟。现在致力于GJB5000咨询和软件流程改进和软件工程能力提高的研究工作。