软件开发项目中的需求变更分析和解决之道[3]

发表于:2008-08-29来源:作者:点击数: 标签:软件开发需求项目解决
对于项目中的需求,可以实行分级管理,以达到对需求变更的控制和管理。 一级需求(或变更)是关键性的需求,这种需求如果不满足,意味着整个项目不能正常交付使用,前期工作也会被全部否定。这个级别的需求是必须满足的,否则就意味着否定自已的项目成员和成
对于项目中的需求,可以实行分级管理,以达到对需求变更的控制和管理。 

    •一级需求(或变更)是关键性的需求,这种需求如果不满足,意味着整个项目不能正常交付使用,前期工作也会被全部否定。这个级别的需求是必须满足的,否则就意味着否定自已的项目成员和成员的所有努力,所以定为“Urgent”。 这通常是属于补救性的debug类型,要救火。 

    • 二级需求(或变更)是后续关键性需求,它不影响前面工作内容的交付,但不加以满足,新的项目内容无法提交或继续,所以是“Necessary”。一般新模块关键性的基础组件,属于这个级别。 

    •三级需求是后续重要的需求,如果不被满足会令整体项目工作的价值下降,为了体现项目价值,也是开发人员自已的技术价值的证明,所以定为“Needed”。一般性的重大的有价值的全新模块开发,属于这个级别。 

    以上三个等级是应该实施的,但时间性上可以作优先级的排列。 

    •四级需求是改良性需求,没有满足这类需求并不影响已有功能的使用,但如果实现了则会更好,定级为“Better”。界面和使用方式的需求,一般在这个档次。 

    •五级需求是可选性需求,更多的是偶是一种设想,以及一种可能,通常只是客户的的一种个人喜好而已,定级为“Maybe”。 

  对于四级需求,如果时间和资源条件都允许的话,不妨做下去。对于五级需求,正如对它的描述一样,做与不做是“Maybe”。 

    2、全生命周期的需求变更管理 

    各种规模和类型的软件项目的生命周期大致可以分为三个阶段,即项目启动、项目实施、项目收尾。不要以为需求变更的管理和控制只是发生在项目实施阶段,而是要贯穿在整个项目生命周期的全过程中。 

    站在全局角度的需求变更管理,需要采用综合变更控制的方法。 

    (1) 项目启动阶段的变更预防 

    正如前面强调的,对于任何软件项目,需求变更都无可避免,也无从逃避,无论是项目经理还是开发人员只能积极应对,而这个应对应该是从项目启动的需求分析阶段就开始了。 
    对一个需求分析做得很好的项目来说,基准文件定义的范围越详细清晰,用户跟项目经理提出需求变更的几率就越小。如果需求没做好,基准文件里的范围含糊不清,被客户发现还有很大的“新需求空间”,这时候项目组往往要付出许多无谓的牺牲。 

原文转自:http://www.ltesting.net

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)