3、 要完整表达所描述的需求,完整性是需求规格的重要特征之一,一个好的需求规格应该说明什么需求做,什么需求不做,而不需要说明怎么去做,需求规格只是宏观的描述,为设计阶段划定范围,不应该包含不确性因素在里面,要么做,要么不做,不能遗留任何待解决的问题,而且还要保证需求的完整性。
4、 对优先级的排列,任何需求在整理过程中都要分优先级,即问题的重要程度,解决时的优先顺序,需求收集过程中会汇总大量的客户需求,在这些需求当中,有些是客户急需解决的,有些是起锦上添花作用的,这时就需要分析人员结合软件的现状,根据问题的急缓,来划分一下将来处理问题的优先顺序,也是为设计和开发阶段的相关人员提供可参照的依据。
三、 需求的评审
在我们看来需求的评审是软件需求分析的最后一步,将整理好的需求规格进行评审,最终决定下一步如何执行,需求的评审一般由专业人士来完成,主要包括公司的内部专家及外部专家,公司内部一般包括分析设计人员、各部门开发经理、维护经理、项目经理及资深开发人员;外部专家包括典型客户代表、实施人员代表等,评审的目的主要就软件需求规格中定义的各事项做进一步讨论,根据评审过程中各专家提出的问题再作整理、修改,最终确定需求的状态。评审过程中常见的问题有以下几方面:
1、 需求的评审流于形式,需求的评审是最后的把关阶段,有时会遇到这种情况:需求规格编写完成后,在评审的过程中只是简单的走一遍,或者评审过程中讨论激烈,评审后该干么干么,没有事后监督与执行,感觉这一点是导致后续软件不急定的主要原因。
2、 对评审人员的要求要严格,不是任何人都可以参与评审的,人多了反而效果不好,参与人员应主要是与需求密切相关的,能对需求能提出改进建议的专家,而不是随便找几个人完事。
3、 没有典型客户参与,需求的整个过程最好让具有代表性的客户参与进来,哪怕客户不明白自己真正的想要实现的东西是什么,但在整个过程中客户自始至终起到指导作用,软件是个比较抽象的东西,客户不会多过的关注开发的过程,举个例子:如果你跟客户讨论的是在建工程或大型设备的安装,那么客户肯定会重点关注很多细节,提出很多建议,因为客户明白项目完工后再改造带来的影响,但对于软件,作为客户他考虑不到软件开发完成后,后期变更所带来的麻烦,所以在讨论需求时比较马虎,描述不清楚需求,导致开发者开发出的软件与客户的期望存在巨大差异。
4、 用户需求不断的增加,这也是最常见的问题之一,在需求评审的过程中,往往评审人员根据讨论的结果会提出新的需求,会导致不断的更改,所以在编写需求规格的时候要把握一个度,不是任何需求都要列入。
5、 对需求做全面的检查,从需求的几个特性去综合考虑,如:需求的完整性、正确性、无二义性、可验证性等。
作为客户如果得到的最终软件产品不能满足某项功能,就会让开发人员修改,虽然开发人员后期不管费多大力气最终能修改完客户的需求,客户感觉是理所当然的事情,但作为开发人员来讲,如果程序开发完成后再去修改,也是一件很头疼的事,因为要放下手头的工作,优先去处理客户的问题。这一切的问题都是由于在需求的收集或验证的过程的疏忽造成的。
需求验证的最终结果是得到一个完整、正确、可执并且无二义性的需求规格,这样才可为后续工作提供保障,在整个软件生命周期中,一个错误发现的越晚,修复错误的费用越高,软件需求分析阶段可以说是发现错误的阶段,可见其重要性,需求分析阶段看似没有明确的目标,实则不然,这期间对任何问题的疏忽,都会导致系统问题呈扇形扩张,估计做过需求分析的同行都能认识其重要性。任何形式的需求规格说明书都不能保证完全没有错误和缺陷,我们在编写的过程中只能尽量按照软件工程的规范去执行,尽量避免问题的发生。
文章来源于领测软件测试网 https://www.ltesting.net/