|
我们都知道，需求开发到了最后是要进行需求确认。需求确认的目的是通过对开发出来的需求进行确认，确保需求已经得到开发方和需求方的认可，双方达成一致意见，经确认的需求将成为软件开发的基线，后续的软件开发以此为基础。 所以说，需求确认是非常重要的。做好需求确认，就会减少后续开发阶段中的需求变更。 需求确认的方法，通常都是通过评审进行的。有的组织的需求确认就是组织有软件开发方和需求方参加的任务书的评审，并且在评审通过后将任务书作为功能基线管理起来。可是，这种做法还存在不足。 首先，需求确认不仅对任务书进行确认，还需要对需求规格说明书进行确认。因为任务书是用户需求，是从用户的角度阐述的需求，对任务书进行了评审确认，就是对用户需求做了确认，开发方和需求方对用户想要什么达成一致理解；而需求规格说明是产品需求，是从开发人员的角度来阐述需求，对需求规格说明确认，就是用户对开发人员的需求理解进行确认。这两者一个是从用户角度来讲需求，一个是从开发人员的角度讲需求，只有二者相互印证，才能真正地做到“达成一致理解”。 其次，需求确认不是做了评审就好，还要看评审是否真的有效。需求评审并不是一件简单的事。评审任务书的时候，只是请来一帮事先也没有看过任务书的领导，短短的一两个小时，能把软件功能明白，提出一两个细枝末节的问题就不错了。有时候在3~4个小时内，一次打包评审通过10几个软件任务书，那更是走个过场而已。要做好需求评审，就不应该是一次性的，也不可能仅靠一次评审就能解决的。需求评审应当采取两种评审方式，非正式评审和正式评审。非正式评审要多次进行，可以是一个开发人员对一个用户，也可以是多个开发人员对一个用户或不同的用户，只要有需求不清楚的地方，都可以进行。当非正式评审进行的足够多之后，需求基本上已经清楚了，再进行一次正式评审，把非正式评审遗留的问题一次性解决，这样的评审方式比只开一次评审会要有效得多。另外，需求评审一定要建立以下的评审通过准则——描述的需求是否满足这些指标：正确性、清晰性、无二义性、一致性、必要性、完备性、可实现性、可验证性。通过评审的需求必须满足上述指标。 最后，需求确认完成后，要进行需求承诺。需求承诺是指开发方和客户方的责任人对通过了正式技术评审的需求文档做出承诺。比如这样的“八股文”：需求文档建立在双方对需求的共同理解的基础之上，我同意后续的开发工作根据该需求文档开展。如果需求发生变化，我们将按照“变更控制规程”执行。我明白需求的变更将导致双方重新协商成 、资源和进度等。这样的八股文，不仅仅是形式主义，它是让开发人员和用户都对这份通过评审的需求文档更加慎重，认真对待。 参考书目：《软件工程与项目管理解析》 微信赞赏专用通道 |
|
|
