需求管理成熟度的五个级别_项目管理_非技术区_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 非技术区 > 项目管理 > 需求管理成熟度的五个级别

需求管理成熟度的五个级别

 2011/7/6 14:12:58  周 金根  程序员俱乐部  我要评论(0)
  • 摘要:需求管理是软件开发全生命周期重要的一个环节,我们每个人都知道它的重要性,但是要真做做好并不简单,我也写了一本在线电子书业务分析与需求.pdf来讲解需求相关内容。对于每种技术和方法,就像以前我写过的企业架构成熟度模型(EAMM)的一样,我们都不可能一下子就精通,而是按照一种学习的曲线进展,本篇本篇主要介绍一下需求管理成熟度的六个级别。级别0:没有需求(norequirements)没有任何明确的需求被记录下来,他们假定知道要构建什么,希望节省需求的时间来做开发,但这势必会给开发工作带来混乱
  • 标签:需求管理 管理成熟度

  需求管理是软件开发全生命周期重要的一个环节,我们每个人都知道它的重要性,但是要真做做好并不简单,我也写了一本在线电子书业务分析与需求.pdf来讲解需求相关内容。对于每种技术和方法,就像以前我写过的企业架构成熟度模型(EAMM)的一样,我们都不可能一下子就精通,而是按照一种学习的曲线进展,本篇本篇主要介绍一下需求管理成熟度的六个级别。

  级别0:没有需求(no requirements)

  没有任何明确的需求被记录下来,他们假定知道要构建什么,希望节省需求的时间来做开发,但这势必会给开发工作带来混乱,因为需求是一项比较复杂的工程,并不能通过假定就可以明确软件功能,这样做很可能会导致所做的产品并不是用户所需要的。 

  级别一:被记录的需求(Written Requirements)

   从混乱的没有需求级别上升一步的就是简单的写出需求。虽然只是简单书写需求,但是相对于没有需求级别来说已经可以感受到很多好处了:

  1. 与客户有一个基本的约定。如果写的好,需求能够清晰地描述你对客户需要的理解,他们可以通过阅读需求来检查是否与他们想的一致
  2. 开发团队的每个成员通过需求可以很好的支持他们的工作。架构师和设计师可以开始考虑如何架构系统来支持客户期望,也可以支持测试人员及早开始测试案例的编写,当然更能支持开发人员理解软件要求来编写代码
  3. 需求可以让新来的成员更快速的了解系统是什么

  要得到这些好处,我们也需要付出一些成本:

  1. 需要有人花时间来写需求
  2. 为了保证需求的及时性,需要不断地维护需求

  级别二:被组织的需求(Organized)


  需求的目的是为了清晰地与用户、客户和其他涉众(例如开发团队)等人就问题的解决方案进行沟通。级别二关注需求质量、格式化、安全和存储,以及版本管理。

  • 质量:好的需求容易让大家明白,架构师、开发人员和测试人员也都能很好的使用它,不好的需求会导致大家比较模糊、认识存在差异等问题。
  • 格式化:需求必须以统一的方式来描述,例如序号、标题、字体、表格等,可以使得文档更容易阅读、理解和使用,文档模板可以帮助我们以统一格式来编制
  • 可访问性、安全性和版本管理:当存在很多需求时,我们会经常遇到不知道在哪里可以找到需要的需求,这时我们就需要有一个统一管理需求地方

级别三:结构化需求(Structured)

  级别三开始对需求进行归类,它们是功能性需求还是非功能性需求?是业务需求还是系统需求?是特性还是软件需求?客户、市场和用户需求是什么?区分这些可以帮助我们更好的理解和管理需求。之前级别都是用一些文字类语言来描述,而级别三是一种结构化需求,例如给需求添加一些属性。

  级别四:可跟踪性需求(Traced)

  需求本身就是层级的,由业务需求到用户需求再到系统需求;而需求又与开发和测试有所关联,通过可跟踪性管理,我们可以知道在更改一个需求时,会影响到哪些子需求以及相关的同级需求,还能够分析出影响哪些开发和测试内容。

  级别五:集成化需求(Integrated)

  通常我们做了很多需求,但是并没有一种集成化的方法把需求直接引入开发中,可能导致实现出来的是另一回事。集成化需求管理流程可以直接由需求导入软件设计、变更管理、测试和项目管理。团队将需求作为主要输入,如果将需求模型化,我们则可以通过模型化需求来开发应用程序,OpenExpressApp就是通过建模来结构化需求,它的目标就是要做成能够让业务工程师来开发应用程序。

 

欢迎转载,转载请注明:转载自周金根 [ http://zhoujg.cnblogs.com/ ]

发表评论
用户名: 匿名