需求是一种实践型的工作,在项目中永远不能说我能写好需求,通过不断练习,不断向编写好的需求靠近。有一些需求编写的技巧如下:采用较短的句子,易于编写,容易阅读理解。采用一致性的术语。采用主动语气,例如“系统应……”。如果句子中出现了“和”或者“或”,则分开成为两个句子。总之,需求是否容易被理解,看系统设计人员是否经常来找你询问,此外,好的需求描述加上一些具体的实例,就是功能测试的用例,是为系统测试人员提供便捷的。编写需求规格说明书也有一些误区。需求不是设计,即需求不是如何去实现这个系统,不是流程,而是对系统业务功能的详细解释。需求说明不是来自于软件实现,例如系统原型不是需求,系统原型是用来引导需求的,此外需求中避免使用软件的功能名称。需求也不是解决方案,不包括技术的细节,尤其在网站系统的需求编写过程中。
需求是一条一条编写出来的,用例图是一幅一幅画出来的,当完成部分需求或整个需求文档以后,要对组织会议对需求文档进行验证和评审,利用需求检查表保证需求的若干特性最大程度的实现。评审还有一个重要的原因是合规性检查,看需求是否和项目外部的法律、法规、业务规则等存在冲突。这是对客户、公司的项目干系人提供一种保障。但有的时候,因为进度的要求,需求评审流于形式,或者是根据系统开发的功能后补的需求,但实际上害的还是自己。完成内部需求评审,还要给项目干系人进行审批,让客户、用户共同评审需求规格说明书,因为需求用的是业务语言,所以客户也易于理解,从而确保需求的理解,如果评审通过,可以采用个人签字,专家评审签字的会议纪要方式等对需求规格说明书进行确认。
经过验证、评审和审批后的需求为项目范围基线,如果以后再出现需求变更情况,则可以对需求进行有效的控制。需求变更在软件项目中是非常常见的,控制不是避免变更,而是控制变更,减少对后续的设计、开发工作有更大的影响。关于变更的控制,要利用项目计划中的变更控制来进行,完成团队对变更进行评估,上级领导和客户进行审批等工作。
完成需求规格说明书以后,将需求放在需求跟踪矩阵中,采用需求跟踪矩阵的意义是,保证需求、设计、开发、测试过程的一致性,容易对过程数据进行度量。需求跟踪矩阵还确保需求是可以修改的,维护需求变更的历史。再者就是需求是可以被跟踪的,可以在系统的生命周期中看到需求被实现的状态。最后放置在需求跟踪矩阵中的需求是需求的简要描述,是按照优先级和功能类别分类的,可以通过需求的编号和需求规格说明书中的需求进行对应。管理需求跟踪矩阵是一项工作量大,技术要求高的工作。
网友评论