艾伟也谈项目管理,需求管理成熟度的五个级别

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

 

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

目录
相关文章
|
监控
CMMI之项目监控管理
CMMI之项目监控管理
121 0
|
项目管理
艾伟也谈项目管理,项目管理 – 人员外购利弊谈
  昨天与同行进行案例讨论时得知,前2个月还被列为正面经典案例的项目到这次讨论时居然变成了反面典型,真可谓成也萧何败也萧何啊。   该项目是一个软件外包项目,发包方是非中国大陆的客户,项目规模在500人月左右,团队人数峰值为50人,实施周期为12个月。
1037 0
|
测试技术 项目管理
艾伟也谈项目管理,项目管理 – 人员外购利弊谈(续)
接上一篇文章“项目管理 – 人员外购利弊谈”。   以上方案只是初步分析,其缺点都是有相应解决办法的。  该公司对以上情况并没有使用DAR(决策分析解决方案)方法进行正式和认真的分析,仅仅从能快速启动和项目利润两个方面考虑来选择了最终的解决方案:项目经理由公司的技术和业务都掌握的人员担当;各小组的组长和测试组长采用人员外购的方式;项目组成员1/3由公司员工组成,1/3由实习人员组成,1/3采用外购方式。
1055 0
|
项目管理
艾伟也谈项目管理,话里话外:流程管理,其实可以做的更多
  在为企业做流程管理项目的时候,我们经常会反复的给企业流程经理灌输这样的一种思想:流程管理,并不仅仅是把流程图画出来,装订成册就结束了,流程管理其实可以做的更多。流程管理实际上是一种建立在流程基础上的管理体系,是从流程入手,借助流程这个平台将各种管理方法结合在一起的管理模式。
926 0
|
架构师 项目管理
艾伟也谈项目管理,架构组织管理
  架构组织管理的五大原则:构想、节奏、预见、协作和简化   架构组织的三在概念:准则、模式和反模式   准则:为了把原则运用到实践中,需要实施细节。准则把广泛的原则翻译成是否和如何执行原则的细节。   模式:描述了开发或者使用软件架构时可能遇到的常见问题的解决方案。
1286 0
|
程序员 项目管理
艾伟也谈项目管理,较大型项目的产品工作心得
  最近做的一个项目从需求分析到上线绵延了四个月之久,这也是目前接手过功能点最繁复,产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得,拿出来跟大家分享。   立项前   1、统一元素设计需考虑周全   也许是初创团队的缘故,我不得不感叹团队对产品经理要求之严格之缜密,项目全程只有一个人负责,所以大到产品线对接,小到一句提示的位置和展示形式都需要一一推敲。
1295 0
|
项目管理
艾伟也谈项目管理,项目管理有感之需求调研
  一个项目中需求调研的充分与否是项目日后成败的关键要素之一,这一点我想没有哪位项目经理不认同吧?不过咱说的需求调研可不只是拿张纸记记客户说什么就完了,调研顾名思义就是调查和研究客户的想法,我感觉应从以下几个步骤入手:   1、客户想要什么?   2、要这干什么?   3、为什么这么想?   4、会不会有别的想法?   这里也说一个最最最最基本的,只谈项目别谈钱,我们可以说,价钱嘛需要我们回去详细的分析过您的需求后再给您提供一个整体的解决方案,您放心价钱一 定合理,不会超出您的预算(真超了再说)。
1040 0
|
测试技术 项目管理
艾伟也谈项目管理,对项目管理的几点认识
自2007年参加工作以来,参与的项目也有好几个了,但都是以项目成员的角色参与,从来没有以项目经理的角色参与项目。中国有句古话叫“旁观者清”,同一个问题站的角度不同,可能会形成不同的结论。下面我就以一个普通项目成员的角度谈一下对项目管理的几个看法,希望大家给予指正。
946 0
|
监控 测试技术 项目管理
艾伟也谈项目管理,聊聊我们团队的绩效管理
  绩效管理对一个Team是比较重要的一项日常管理任务,如何做到团队内每个人的绩效得分公平公正,必须有一套行之有效的方法。下面我谈谈我们部门管理的一些方法,拿出来与大家分享,希望有相关经验的人参与讨论,说说你们的管理方法。
1069 0
|
项目管理 C#
艾伟也谈项目管理,切勿过早优化
  Donald Knuth说“过早优化是万恶之源”(premature optimization is the root of all evil)。这话也许有些夸张,但“过早优化”的危害我觉得不能忽视。
1228 0
下一篇
无影云桌面