需求管理流程.docx

需求管理流程.docx

《需求管理流程.docx》由会员分享，可在线阅读，更多相关《需求管理流程.docx（11页珍藏版）》请在冰豆网上搜索。

需求管理流程

千贺文化传播有限公司

公司文件

司发字【20年】第号签发人：

拟稿人：

机密等级：

秘密

千贺文化传播有限公司需求管理流程

一、背景介绍

1.通常遇到的需求问题

根据Rational公司的统计，在项目运作过程中通常出现的问题如下：

✓无法跟踪需求的变更

✓需求难以表达

✓业务功能的渐变

✓没有很好的组织

以上问题，时时困扰着项目的策划者、项目管理者、系统构架师、项目开发团队、测试团队、产品维护团队......。

因此，我们必须解决这些与需求相关问题。

2.为什么要管理需求

需求管理的唯一目的在于促使项目成功，降低失败的风险。

项目失败的大多数原因是与需求相关的问题。

——TheStandishGroup'sCHAOSReportsfrom1994and1997

对美国和英国500个IT经理调查，76%的人曾经历过失败，其中最多的原因就是“用户的需求总是在变化”。

——InDecember1997,ComputerIndustryDailyreported

如果没有好的需求管理就可能会导致需求失控、项目缺乏计划性、项目失控、延期甚至导致项目失败。

因此，如何管理需求，保证项目成功，是我们要解决的问题。

为此，我们制定需求管理流程，规范需求管理过程和活动。

3.适用范围

本规范适用于千贺文化传播有限公司所有的业务产品开发过程。

二、需求管理概念

1.需求管理目标

需求管理的目的是在客户和将处理客户需求的业务项目之间建立对客户需求的共同理解。

它有两个目标：

目标1：

分配给业务项目的需求是受控的，建立供业务项目工程和管理使用的基线

目标2：

业务项目计划、产品和活动与分配给业务项目的需求保持一致

2.需求管理过程

需求管理意味着：

1）需求的来源是受控的，不能随便纳入业务项目开发计划中或合入版本，要经过受影响各方评审和同意

2）业务项目计划、活动和工作产品都必须与需求保持一致

3）对需求的实施过程进行监控，确保需求正确实现；

4）在需求发生变化时，要对变化对项目造成的影响进行评估，并与受影响的各方协商，在取得一致意见后，再进行修改。

并要保持业务项目计划、活动和工作产品与需求保持一致。

没有需求管理的项目，看起来要满足几乎所有的地方的需求，例如，各级领导、客户代表、市场人员等等。

他们提供需求给希望实现它们的项目组，而不管它对产品的影响如何。

没有控制的需求将导致产品计划的推迟和低质量。

在业务项目开发过程中，需求改变是不可避免的。

但更重要的是，如何管理和监控这些需求的变更过程，并相应调整开发计划和开发活动，保证这些需求能够被正确实现，是需求管理过程的重要内容。

下图显示了需求管理的全过程：

1）需求开发阶段：

需求责任人组织进行需求调研，汇总、分析和整理需求。

2）需求评审：

项目组对员工创意或公司立项的项目进行评审，如评审通过，则转入下一步。

3）根据评审通过的项目（创意）评估报告书，建立技术需求说明书。

4）根据技术需求说明书制定开发计划，相关人员对开发计划进行承诺（下发工单）。

5）业务项目开发过程：

包括开发和测试，在开发阶段建立需求跟踪进度表

6）需求变更过程

7）开发完毕后，提交业务项目产品进行验收。

8）产品发布

三、需求开发阶段

工作内容

在此阶段，进行需求开发工作，通过市场调研，对新产品的需求进行提炼、归纳和汇总。

责任人：

产品部产品经理

工作职责：

产品部产品经理是需求开发阶段的第一责任人，负责组织与产品相关的各个接口部门共同进行需求调研、分析、讨论和编写工作。

业务项目需求

讨论业务项目需求之前，必须先确定如下要素：

1）业务项目的边界：

明确业务项目系统的边界在哪里，哪些是业务项目系统内部的，哪些是业务项目系统外部的。

2）Actor:

必须确定与业务项目系统进行交互的用户和其它系统，统称其为Actor.

讨论业务项目需求时，需要先把要开发的业务项目系统看成一个黑盒子，从Actor的角度来看这个黑盒子。

Actor对黑盒子内部的结构一无所知，Actor与业务项目系统的交互仅仅是在业务项目系统边界上进行的。

因此业务项目需求就是在业务项目系统的边界上，Actor所能进行的一切，包括看到的（界面）、听到的（提示语音）、输入（键盘/鼠标输入）、操作（查看日志文件）、感受到的（响应速度，吞吐能力）、扣费......。

归纳起来，业务项目需求包括如下方面：

1）功能需求：

包括界面，声音，输入输出、操作、计费等等

2）性能需求：

如容量、响应速度、吞吐能力等等

3）安全性需求：

如加密，防攻击，防盗用等等

4）可维护性：

包括日志、告警、在线跟踪等等。

5）其它需求：

上述各个部分都不能涵盖的需求。

需求表述

一个需求的表述，必须满足如下要素：

1）清晰：

需求的表述是从Actor的角度来表达的，其必须清晰，不能模棱两可，含糊不清。

另外，其必须没有二意性。

2）正确：

需求必须真正代表了Actor的需求，表述必须正确无误，引用数据和表述细节必须绝对精确。

3）可验证性：

必须有明确的方法可以验证此需求是否被实现。

4）全面：

全面性有两层含义：

一是必须将每一个Actor的所有业务项目需求都表述，不能有遗漏；二是对单个需求的表述，除了要表述正常过程下的需求，也要表述异常情况下的业务项目需求（如号码无效，用户输入错误，当前状态无效......）

需求的标识：

每一个需求都必须被命名，并且用一个代码对其进行唯一标识。

此代码用于需求管理的全过程。

需求标识代码的命名为：

SR-XX-YYYY,说明如下：

SR为SoftwareRequirement的缩写

XX为需求分类码，固定2位，可以为字母或数字，根据实际需求来制定。

YYYY为需求序号，固定4位，从0001开始递增，不足四位前补0。

产品测试验收

产品测试验收是Actor验收业务项目系统是否满足了技术需求说明书的唯一依据。

验收是按照需求逐项进行验收的。

由于每一个需求都被标识，并且每一个需求都是可验证的，因此在需求阶段，产品测试表就必须提供，以明确业务项目系统的交付标准。

产品测试验收中阐述了对需求进行验收的所有测试用例，不仅要对正常情况下的业务项目需求进行验收，也要对异常情况下的业务项目需求进行验收。

四、评审流程

工作内容：

评审组织者组织相关评审者对立项（创意）需求表或立项、（创意）评估报告书进行评审。

评审者提出评审意见，组织者汇总所有的评审意见，并通过开会讨论的方式决定对立项（创意）需求表或立项、（创意）评估报告书的最终评审意见。

相关角色：

立项（创意）者：

被立项（创意）需求表或立项、（创意）评估报告书的立项（创意）者。

评审组织者：

公司领导、部门领导，特别是策划部的领导。

评审者：

公司领导、部门领导、立项（创意）者等其他人员。

适用范围：

对项目（创意）的评审。

评审过程活动：

评审过程活动，按照时间顺序依次为：

1、评审规矩按照《项目（创意）评估表》进行。

2、组织者要确认每一个评审者都收到立项（创意）需求表或立项、（创意）评估报告书，并且理解了评审要求。

组织者一般要保证下发立项（创意）需求表或立项、（创意）评估报告书与评审会议之间的时间间隔不小于1天。

3、各个评审者收到立项（创意）需求表或立项、（创意）评估报告书后，在指定的时间内对立项（创意）需求表或立项、（创意）评估报告书独立进行评审，将发现的问题自行列表。

评审期间，对于不理解的地方，可以请立项（创意）者进行局部讲解。

4、根据与会者评分，才能得到程序上的立项，或把创意立为项目来操作。

5、产品部经理至少要在评审会议前半小时将评审意见汇总，并给立项（创意）者看一下，使立项（创意）者能够先自行确认一些问题，避免全部问题都在会议上讨论，浪费时间。

6、产品部经理在既定的评审会议时间，召集立项（创意）者和所有评审者进行评审。

会上主要讨论评审者提出的意见，确认评审意见是否可以接受，将确认结果记录下来。

7、产品部经理组织者将评审结果汇总，发给立项（创意）者，由立项（创意）者进行修改。

组织者跟踪这些问题，保证都被正确修改。

备注：

如果评审过程发现严重缺陷或较多缺陷，产品部经理应该在立项（创意）者修改完毕后，重新组织评审。

8、产品部经理将评审全过程的所有文档都归档保存。

五、建立技术需求说明书

工作内容：

建立配置库，将通过评审的项目技术需求说明书和产品测试验收书纳入配置库进行管理，标注技术需求说明书标签。

角色：

配置管理员：

对业务项目配置进行管理的人员，其工作职能包括：

标注配置项、对配置项的变更进行授权和审核、版本管理等。

六、制定开发计划

工作内容：

根据业务项目技术需求说明书，估计业务项目规模和复杂度，并根据人力资源状况，制定业务项目开发计划，具体活动按时间先后顺序为：

1）业务项目估计：

2）制定开发计划

3）开发计划评审

4）相关人员进行任务承诺

下面分别阐述如下：

业务项目估计

业务项目估计活动的依据是技术需求说明书和组织生成力水平。

组织生成力水平的单位为代码行/人天。

这个数据是指从技术需求说明书建立的时间开始，直到项目完成，项目实际产出的代码行与投入的人力相除而得到，其代表了公司当前的业务项目开发能力水平，要从各个项目的开发实践中逐渐积累而成。

每个项目完成后，都要统计业务项目开发能力的数据。

整个公司的业务项目开发能力水平，可以用各个项目的数据加权平均而计算。

同时，也要考虑当前开发组成员的实际能力水平状况。

初期进行业务项目估计时，没有可参考的经验数据，因此都是凭个人主观来估计。

后期积累了一些数据后，可以参照这些数据，进行估计。

业务项目估计的过程如下：

i.需求介绍

开发经理确定业务项目估计活动的组织者。

组织者确定要参加业务项目估计的小组人员，主要包括：

开发经理、设计人员、主要开发人员、专家。

在估计之前，所有成员必须对需求的理解达成一致的认识。

因此，要召开会议，对基线化的需求进行详细介绍，使估计小组的成员充分理解各项需求。

ii.匿名估计

组织者将估计表格发给估计小组的成员，小组成员采用匿名的方式，对需求逐个进行业务项目规模的估计，估计的单位是代码行。

iii.数据汇总

组织者将估计数据进行汇总，确定与每个需求对应的最大估计值，最小估计值，平均估计值，最大偏差度。

最大偏差度＝Max（（最大估计值-平均估计值），（平均估计值－最小估计值））/平均估计值*100%

iv.讨论，修订

组织者召集估计小组开会，对估计的数据进行讨论分析。

对其中最大偏差度比较大的数据进行讨论，分析出导致估计偏差比较大的原因，使大家对其的理解达成共识。

如果会上能够形成统一的意见，则可现场修改估计结果数据。

如果偏差度比较大的数据比较多，这需要重新进行匿名估计活动。

一般，在初期进行业务项目估计的时候，偏差度会比较大，这时应重复进行估计活动。

v.汇总

当大家对需求的估计结果达成一致后，将所有需求的估计结果累加，得出整个业务项目系统的规模，然后除以开发组的生成力水平，得出整个开发过程所需要的人力资源，单位为人天。

开发组的生成力水平，参照组织生成力水平，并考虑实际开发组成员的能力水平情况，酌情进行修正。

制定开发计划：

开发经理根据估计的结果，确定项目的完成时间。

然后根据业务项目开发过程模型，安排相关的开发活动，确定工作任务、任务开始时间、任务结束时间、输出成果，合理设置监控点。

这里面，要安排对文档的评审活动和对代码的检视活动。

开发计划评审：

开发经理组织评审活动，对开发计划进行评审。

具体参见评审流程。

参加人员：

开发部经理、各任务的执行人员。

如果评审不通过，则开发经理要重新修订开发计划，再组织评审。

如果评审通过，则将开发计划纳入配置库，相关人员对任务进行承诺。

七、业务项目开发过程：

业务项目开发过程主要是在研发部进行的，包括设计、开发、测试等环节。

在业务项目的设计阶段中，需要确定业务项目的配置项清单。

需求、设计、测试的文档都作为配置项，同时根据业务项目设计的体系结构，确定代码级的配置项。

同时建立需求跟踪矩阵，标识出需求与实现需求的配置项之间的对应关系。

在开发过程中的任何环节，如果开发组发现技术需求说明书中有不全面、遗漏甚至表述错误的需求，必须填写《需求缺陷单》，递交给相关的Actor。

Actor收到《需求缺陷单》后，应组织人员进行分析，明确需求，启动《需求更改流程》。

八、需求变更过程

业务项目开发过程中，需求的变更是不可避免的。

但要对需求的变更过程进行控制，保证业务项目开发过程与需求一致。

具体过程如下：

1）需求接口人以书面方式提出需求变更申请，阐述需求变更的原因、具体的变更内容、验收标准；

2）需求接口人组织相关人员对需求变更进行评审，对变更所带来的影响进行评估。

评审人员必须包括：

开发经理、相关开发人员、产品经理、需求的其它相关接口人。

如评审通过，则转入下一步；

3）开发经理将需求变更以文档方式记录下来，合并到技术需求说明书中；

4）需求接口人更新验收手册；

5）开发经理调整开发计划和开发活动，对承诺进行修订；

6）开发经理更新设计文档；

7）开发经理更新需求跟踪矩阵；

九、业务项目验收流程

业务项目开发完成后，由开发经理准备好如下材料，准备验收：

✓项目需求说明书

✓产品测试验收

✓业务流程

✓产品工单

✓业务项目程序

✓业务项目安装包

由Actor根据产品测试验收逐项进行验收，将验收结果填写在验收手册上。

如果各项都验收合格，则双方签字，确认业务项目产品正式通过验收。

十、产品发布

业务项目产品通过各个Actor的验收后，由市场部进行产品发布活动，研发部协助。

产品发布活动包括：

公司内部发布，业务项目产品培训，对外发布，宣传广告等活动。