For investors
股价:
5.36 美元 %For investors
股价:
5.36 美元 %认真做教育 专心促就业
需求的一致理解,在需求开发和管理实践域中非常重要。如果开发人员没有和需求提供者对软件需求达成一致理解,就可能开发出一个和需求提供者原本想要的南辕北辙的软件来。
所以,我们的GJB5000标准中对此有专门的实践要求,目的就是要确保开发出来的软件满足用户的需求。
我们在实施这一实践的时候,通常是在项目早期通过与需求提供者的沟通和交流,确保双方对需求达成一致理解,并且这个一致理解会以任务书以及需求规格说明的评审作为“获得需求一致理解”实践的终极实践。
而很多GJB5000评价员也会以任务书交流和评审作为项目实施该实践的有力证据。
然而,这种“约定俗成”的做法是存在重大问题的。
我们这种“约定俗成”的做法是有一个假设性的前提条件的,即我们假设用户的需求在项目早期就已经确定,在项目中后期不会发生变化。
只有这个假设成立的时候,我们仅在项目早期与需求提供者进行交流,并完成任务书的评审就能确保需求理解是一致的。
而实际上,这个假设很有可能是不成立的。
一方面,即使在项目早期已经与用户进行了需求的确认,用户自己也以为他所期望的软件需求就是如此,可是随着时间的推移,项目的进展,用户也很有可能会发现新的需求,或者更好的需求。
况且,现实之中很多项目的软件需求一开始都有很多不确定的需求项,这些需求项在将来确定的时候可能会影响原本已经确认过的需求项。
这两种情况都会使得原本的一致理解发生偏差。
所以,“获得需求的一致理解”实践不能只在项目早期做,而是应当在软件开发的全生命周期都要进行。只有在软件开发的全生命周期,开发人员一直和需求提供者保持不间断的沟通和交流,跟踪用户的期望目标是否发生偏离,才能真正与用户保持对需求的一致理解。
这正是:
需求理解要一致,重要程度都已知
不能只在早期做,全程跟踪才保持
参考书目:成功软件开发方法——由外到内开发实践指南,作者:(美) Carl Kessler John Sweitzer著,出版社:机械工业出版社
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请添加3216764521学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。