需求管理体系中小企业.docx
- 文档编号:10992577
- 上传时间:2023-02-24
- 格式:DOCX
- 页数:14
- 大小:157.76KB
需求管理体系中小企业.docx
《需求管理体系中小企业.docx》由会员分享,可在线阅读,更多相关《需求管理体系中小企业.docx(14页珍藏版)》请在冰豆网上搜索。
需求管理体系中小企业
中小企业需求管理体系
目录
1前言2
2需求管理复杂性分析2
3需求管理策略3
4某企业需求管理过程规范4
4.1有关的角色及职责4
4.2软件需求管理过程的概貌5
4.3Discover阶段6
4.4Define阶段7
4.5需求维护10
1前言
在软件项目的开发过程中,需求变更贯穿了软件项目的整个生命周期,从软件的项目立项,研发,维护,用户的经验在增加,对使用软件的感受有变化,以及整个行业的新动态,都为软件带来不断完善功能,优化性能,提高用户友好性的要求。
在软件项目管理过程中,项目经理经常面对用户的需求变更。
如果不能有效处理这些需求变更,项目计划会一再调整,软件交付日期一再拖延,项目研发人员的士气将越来越低落,将直接导致项目成本增加、质量下降及项目交付日期推后。
这决定了项目组必须拥有需求管理策略。
2需求管理复杂性分析
软件需求是整个软件开发项目的最关键的一个输入,和传统的生产企业相比较,软件的需求具有模糊性、不确定性、变化性和主观性的特点,他不像生产汽车、电脑等硬件的需求,是有形的、客观的、可描述的、可检测的,软件需求是软件项目最难把握的问题,他的复杂性体现在以下方面:
1、需求的描述问题。
缺少正式的完整的需求文档浪费了大量的人力物力,但是有了需求文档又出现了新的问题。
在用户方进行的需求评审会完全是走形式,因为用户根本不去听他读那上百页的需求文档。
不同层次的客户(用户)关心的问题是不一样的,想要每个客户都成为需求专家是不现实的。
2、需求的完备程度问题。
需求如何做到没有遗漏?
如何准确划定系统的范围?
这确实是一个两难问题,稍微大一点的系统要想穷举需求几乎是不可能的,每次开需求评审会时,总会冒出新的需求,以至于系统没有一个准确的范围界定。
即使是这样,系统还是要开发,没办法,系统的范围还要硬性的划定一个,从而建立一个基线。
3、需求开发的工期问题。
在需求上花费了大量的时间,客户、软件公司是否能够忍受?
为了确保需求的正确性,完备性,项目经理往往坚持要在需求阶段花费大量的时间,但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已!
他们往往会逼迫项目组尽快往前推进,而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽,他们也希望尽快结束此阶段。
4、需求的细致程度问题。
需求到底描述到多细,才算可以结束了?
仁者见仁,智者见智,并没有定论,如果时间允许,要想细总可以细下去的。
但是,需求的周期越长,可能的变化越多,对设计的限制越严格,对需求的共性提取要求越高,所以只要大家(客户、用户、需求分析人员、设计人员、测试人员)认为描述清楚了,就可以进入设计阶段了。
5、需求的变化问题。
在软件开发过程中如果只有一条真理的话,那一定是:
需求的变化是永恒的,需求不可能是完备的。
软件开发的过程实际上是同变化做斗争的过程,需求的变更不一定是坏事,也有可能是好事,是商业机会,对市场敏感的人可以从需求的变化中发现市场机会。
需求变化的原因很多,如:
·一开始没有识别全,需要增加需求;
·业务发生了变化,需求必须变化;
·需求错误;
·需求不清楚。
需求的变化问题是每个开发人员、每个项目经理都遇到的问题,也是最头痛的问题,一旦发生了需求变化,你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等,需求的变化好比是万恶之源,为项目的正常的进展带来不尽的麻烦,怎么办?
管理它!
使需求在受控的状态下发生变化,而不是随意变化,需求管理就是要按照标准的流程来控制需求的变化。
难题随之而来,需求中的变化一般不是突发的革命性的变化,最常见的是项目需求的渐变问题,这种渐变很可能是客户与开发方都没有意识到的,当达到一定层度时,双方才蓦然回首,发现已经物是人非,换了一番天地。
3需求管理策略
需求管理需要遵守以下策略:
1、需求一定要与投入有必然的联系。
需求一定要与投入有必然的联系,否则如果需求变更的成本由开发方来承担,则项目需求的变更就成为必然了。
人们常说世上没有免费的午餐,同样也不应该有免费的需求变更。
但是,接受需求变更目前却是软件开发商不得不咽下的苦果。
所以,在项目的开始无论是开发方还是出资方都要明确这一条:
需求变,软件开发的投入也要变。
2、需求的变更要经过出资者的认可。
需求的变更引起投入的变化,所以要通过出资者的认可,这样才会对需求的变更有成本的概念,能够慎重地对待需求的变更。
笔者曾经经历过一个项目,为了避免项目的风险,我们请了用户代表全程参与了开发过程,结果此用户代表在开发过程提出了大量“小的需求变更,当开发人员按此需求变更修改了软件时,在项目进入现场实施阶段时,却有大量的这些变更需要改回去,问题就是出在我们的项目组成员视该用户代表的需求为圣旨,却忽略了需求是否经过了客户方真正有决策权的人员的认可。
3、小的需求变更也要经过正规的需求管理流程。
小的需求变更也要经过正规的需求管理流程,否则会积少成多。
在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低了开发效率,浪费了时间。
正式由于这种观念才使需求的渐变不可控,最终导致项目的失败。
4、精确的需求与范围定义并不会阻止需求的变更。
并非对需求定义的越细,越能避免需求的渐变,这是2个层面的问题。
太细的需求定义对需求渐变没有任何效果。
因为需求的变化是永恒的,并非由于需求写细了,它就不会变化了。
注意沟通的技巧。
实际情况是用户、开发者都认识了到了上面的几点问题,但是由于需求的变更可能来自客户方、也可能来自开发方,作为客户他们可能不愿意为需求的变更付出更多的投资,开发方有可能是主动的变更了需求,他们的目的可能是使软件做的更精致,于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。
4某企业需求管理过程规范
4.1有关的角色及职责
角色职责描述
市场人员负责discover阶段所有工作,并帮助开发项目经理和设计师在define阶段初期很快地了解业务和客户
开发项目经理协调discover阶段的所有活动;与设计师共同完成需求文档;维护scopematrix。
设计师与开发项目经理共同完成需求文档
行业专家提供行业咨询
高层团队指导discover和define阶段的工作
SEPG负责过程的培训,提供过程支持,负责过程的跟进和改进
4.2软件需求管理过程的概貌
需求可定义为“(正在构建的)系统必须符合的条件或具备的功能”,也有人定义为“用户解决某一问题或达到某一目标所需的软件功能”。
而需求管理是一种获取、组织并记录系统需求的系统化方案,以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。
需求管理的目的是在顾客和将处理顾客需求的软件项目组之间建立对顾客需求的共同理解。
需求管理的目标是:
1)使软件需求受控,并建立供软件工程和管理使用的基线。
2)使软件计划、产品和活动与软件需求保持一致。
4.2.1过程图
4.2.2注解
(1)Discover阶段
本阶段的目的是了解客户的问题,分析并确定公司是否开展此行业的项目。
这里的客户不一定针对一个企业,有可能是一个行业。
在进行具体的调研时,目标是本行业的一个或几个典型用户。
市场人员主要对客户的问题,客户的现状,和客户的业务模式三方面进行了解,然后对照公司的业务发展方向和实际现状进行可行性分析,并负责编写可行性分析报告。
然后发起可行性分析会议,邀请公司高层,行业专家和利益相关者一起来商议公司是否开展此项目。
一旦决定做此项目,下来将寻找有意向的用户。
找到合适的用户后,就可以正式开始创建开发团队进行开发系统的定义,设计,编码等工作。
(2)Define阶段
目的是得到一套客户认可的详细的需求说明文档,用来指导后期的软件开发工作。
开发项目经理和设计师通过与客户沟通交流,分析项目目标和成功因素,识别项目风险和假设,以及系统的功能需求和技术需求,最终整理出一套详细的需求说明文档,包括总体系统的需求信息,每个子系统的需求信息,数据字典,等。
为了指导后期的开发和跟踪需求实现的状态和范围,项目经理需要根据需求来建立本项目的ScopeMatrix。
在ScopeMatrix中随时跟踪每项功能的In或Out,以及现在处于开发的什么阶段。
所有需求文档完成之后,由项目经理和设计师发起并组织阶段审核会议,并邀请客户和行业专家参加。
审核的内容包括所有需求文档和ScopeMatrix。
一旦审核通过,则开始制定下阶段的计划,准备进入概念阶段。
(3)需求维护阶段
目的是管理需求的变更。
在软件开发过程中,需求不可避免会有大或小的更改。
为了更有效地管理需求的变更,这里规范了需求变更,需求跟踪,和需求配置管理的要求。
对每项内容的详细内容,将在后面的章节中介绍。
4.3Discover阶段
4.3.1过程图
可行
不可行
4.3.2活动
1、理解客户的需求
●活动:
与客户沟通交流,了解他们的原始需求。
并分析公司开发此项目的业务机遇,业务目标,客户和市场的需求,以及业务风险等问题。
●职责:
由公司高层负责,市场人员具体执行。
2、了解客户的现状
●活动:
评估客户的现状,如信息化程度,人员的计算机技能水平,业务模式等。
●职责:
由公司高层负责,市场人员具体执行。
3、了解客户的业务模式
●活动:
了解客户当前的业务模式,包括业务角色及其关系。
●职责:
由公司高层负责,市场人员具体执行。
4、编写可行性分析报告
●活动:
根据前面三项内容,对本项目做评估,分析是否开展此项目
●职责:
由公司高层负责,市场人员具体执行
●模板:
依据提供的“可行性分析报告的模板”整理。
根据实际内容,允许对模板进行裁剪。
5、可行性问题的决策
●活动:
审核可行性分析报告的内容;决定是否开展此项目
●参与人:
市场人员(发起者和组织者),行业专家,公司高层决策人员。
●主要沟通内容:
可行性分析报告
●输出:
作出结论的可行性分析报告
●职责:
市场人员发起,组织,和主持会议,做会议记录。
负责可行性分析报告的修订和决策记录。
●说明:
决定开展此项目后,方可进入define阶段。
在进入Define阶段之前,需要由项目经理和设计师确定项目的整体计划和define阶段的详细计划。
4.4Define阶段
4.4.1过程图
通过
4.4.2活动
1、准备
●活动:
了解discover阶段的输出文档,安排交流的客户代表
●职责:
市场人员帮助开发项目经理和设计师了解可行性分析报告中的内容,并共同联系客户代表;开发项目经理和设计师理解可行性报告中的相关内容,为后面工作的开展作好准备。
2、分析项目目标和成功因素
●活动:
通过与客户的沟通,定义项目目标和成功的关键因素
●职责:
开发项目经理和设计师共同完成,市场人员可协助。
3、识别项目的风险和假设
●活动:
通过与客户的沟通,识别项目的风险和假定,并分析他们对项目的影响,给出风险的减缓方法。
●职责:
开发项目经理和设计师共同完成,市场人员可协助。
4、获取功能需求和技术需求
●活动:
通过与客户的沟通,获取功能需求和技术需求,即明确系统的功能需求和使用什么样的技术
●职责:
开发项目经理和设计师共同完成,市场人员可协助。
5、编写需求说明文档
●活动:
根据前面几个步骤的沟通结果,整理项目的需求文档。
需求文档不一定是一个,可以是几个文档。
但必须包括内容:
总体系统的需求信息,每个子系统的需求信息,数据字典。
公司建议将总体系统的需求信息与每个子系统的需求信息分开写成文档。
在总体系统的需求中,从系统整体出发来阐述,而每个子系统的需求只针对子系统本身来阐述。
●职责:
开发项目经理和设计市共同完成。
●模板:
依据提供的“总体系统的需求说明模板”“子系统的需求说明模板”“数据字典的模板”整理。
根据实际内容,允许对模板进行裁剪。
●高质量的需求说明文档的关键特点:
●完整:
不应该遗漏要求和必需的信息。
发现缺少的信息很难,因为根本不存在。
如果你知道已缺少一些信息,使用TBD(tobedetermined)标准标志可以突出这些缺陷,当你在构建产品的相关部分时,就可以从一个给定的需求集中解决所有的缺陷。
●一致性:
一致性需求就是不要于其他的软件需求或高级别的系统(商业)需求发生冲突。
●可修改性:
每个需求必须相对于其他需求有其单独的标示和分开的说明,便于清晰的查阅。
通过良好的组织可以使需求易于修改,如:
将相关的需求分组,建立目录表,索引,以及前后参考(照)。
6、建立ScopeMatrix
●活动:
根据系统的需求建立ScopeMatrix,以指导后期的开发。
ScopeMatrix的所有内容必须忠实于整理出来的需求文档。
如果需求文档的内容不足以得到完整细致的ScopeMatrix,可以回过头来完善需求文档;如果实在确定不下来的内容,可以在ScopeMatrix中标注出来,待以后确定。
●职责:
开发项目经理和设计市共同完成。
●模板:
依据提供的“Scopematrix的模板”整理。
根据实际内容。
●如何在Scopematrix中描述功能域:
7、Define阶段的审核
●活动:
以会议的形式沟通需求的内容,对需求进行Qualityreview.
●参与人:
项目经理(发起者和组织者),设计师,行业专家,和客户
●审核内容:
数据字典,总体系统的需求说明,各子系统的需求说明,Scopematrix
●输出:
Reviewnotes。
Reviewnotes要求填写在公司规定的Qualityreviewnotes的模板中。
●职责:
●设计师发起,组织,并主持审核会议,做会议记录。
会后总结reviewnotes.
●开发项目经理。
与设计师共同完成审核工作。
●说明:
Define阶段审核通过后,方可进入设计阶段。
4.5需求维护
需求维护的关键内容是需求变更管理。
需求的变更是不可避免的,如何以可控的方式管理软件的需求,对于项目的顺利进行有着重要的意义。
对于需求变更的管理,我们主要使用需求变更控制流程,需求跟踪矩阵,和需求配置的管理方式。
4.5.1变更控制
1、变更控制流程
2、变更审核小组
●成员组成:
项目经理,设计师,和客户代表
●职责:
处理每一份需求更改申请单
3、变更申请单
变更申请单的模板请参见“需求更改单模板”文件。
本模板包含两部分内容,第一部分是更改申请的信息,第二部分是审核小组的分析和决策信息(包括他们的签字)。
需求更改的提出者可以是客户,也可以是开发团队的任何人。
4.5.2需求跟踪
●活动:
使用scopematrix来跟踪每项需求是否要求实现,以及需求实现的状态
●职责:
由开发项目经理负责维护scopematrix。
4.5.3需求配置管理
●活动:
保存需求方面的所有文档的所有版本
●职责:
每个有关需求的文档以及升级文档均要求保存到CVS。
●要求:
所有资料均放入CVS。
按照规定的目录存放资料。
现有两个:
Client和Requirement目录。
文件的每个修改版本都要求保存。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 管理体系 中小企业