需求管理流程

《需求管理流程》由会员分享，可在线阅读，更多相关《需求管理流程（11页珍藏版）》请在金锄头文库上搜索。

1、目录一、背景介绍 21. 通常遇到的需求问题 22. 为什么要管理需求 23. 适用范围 3二、需求管理概念 31.需求管理目标 32.需求管理过程 3三、需求开发阶段 5四、评审流程 6五、建立技术需求说明书 7六、制定开发计划 8七、业务项目开发过程： 10八、需求变更过程 10九、业务项目验收流程 10十、产品发布 11XXXX 文化传播有限公司公司文件司发字【20 年】第 号 签发人：拟稿人：机密等级：秘密xxxx传播有限公司需求管理流程一、背景介绍1. 通常遇到的需求问题根据 Rational 公司的统计，在项目运作过程中通常出现的问题如下：/无法跟踪需求的变更/需求难以表达/业务功

2、能的渐变/没有很好的组织 以上问题，时时困扰着项目的策划者、项目管理者、系统构架师、项目开发团队、测试团 队、产品维护团队。因此，我们必须解决这些与需求相关问题。2. 为什么要管理需求需求管理的唯一目的在于促使项目成功，降低失败的风险。 项目失败的大多数原因是与需求相关的问题。The Standish Groups CHAOS Reports from 1994 and 1997 对美国和英国 500 个 IT 经理调查，76%的人曾经历过失败，其中最多的原因就是“用户的 需求总是在变化”。In December 1997, Computer Industry Daily reported 如

3、果没有好的需求管理就可能会导致需求失控、项目缺乏计划性、项目失控、延期甚至导 致项目失败。因此，如何管理需求，保证项目成功，是我们要解决的问题。为此，我们制定需 求管理流程，规范需求管理过程和活动。3. 适用范围本规范适用于 XXXX 文化传播有限公司所有的业务产品开发过程。二、 需求管理概念1. 需求管理目标需求管理的目的是在客户和将处理客户需求的业务项目之间建立对客户需求的共同理解。 它有两个目标：目标 1：分配给业务项目的需求是受控的，建立供业务项目工程和管理使用的基线目标 2：业务项目计划、产品和活动与分配给业务项目的需求保持一致2. 需求管理过程需求管理意味着：1) 需求的来源是受控

4、的，不能随便纳入业务项目开发计划中或合入版本，要经过受影响 各方评审和同意2) 业务项目计划、活动和工作产品都必须与需求保持一致3) 对需求的实施过程进行监控，确保需求正确实现；4) 在需求发生变化时，要对变化对项目造成的影响进行评估，并与受影响的各方协商， 在取得一致意见后，再进行修改。并要保持业务项目计划、活动和工作产品与需求保持一致。没有需求管理的项目，看起来要满足几乎所有的地方的需求，例如，各级领导、客户代表、 市场人员等等。他们提供需求给希望实现它们的项目组，而不管它对产品的影响如何。没有控 制的需求将导致产品计划的推迟和低质量。在业务项目开发过程中，需求改变是不可避免的。但更重要的

5、是，如何管理和监控这些需 求的变更过程，并相应调整开发计划和开发活动，保证这些需求能够被正确实现，是需求管理 过程的重要内容。目标1:控制业务项目需求并建立基线目标2:计划、产品、活动与业务项目需求保持一致需求责任人活动1：在纳入业务项目之前要 经过项目组的评审业务项目需求活动2：使用需求是计划、产品、活动的基础需求基线文档化业务项目研发计划变更请求活动3：对需求的变化经过项目组 评审通过才纳入业务项目下图显示了需求管理的全过程：责任人影响评估对承诺的重新评估1) 需求开发阶段：需求责任人组织进行需求调研，汇总、分析和整理需求。2) 需求评审：项目组对员工创意或公司立项的项目进行评审，如评审通

6、过，则转入下一步3) 根据评审通过的项目(创意)评估报告书，建立技术需求说明书。4) 根据技术需求说明书制定开发计划，相关人员对开发计划进行承诺(下发工单)。5) 业务项目开发过程：包括开发和测试，在开发阶段建立需求跟踪进度表6) 需求变更过程7) 开发完毕后，提交业务项目产品进行验收。8) 产品发布三、 需求开发阶段工作内容在此阶段，进行需求开发工作，通过市场调研，对新产品的需求进行提炼、归纳和汇总。 责任人：产品部产品经理工作职责： 产品部产品经理是需求开发阶段的第一责任人，负责组织与产品相关的各个接口 部门共同进行需求调研、分析、讨论和编写工作。业务项目需求讨论业务项目需求之前，必须先确

7、定如下要素：1）业务项目的边界：明确业务项目系统的边界在哪里，哪些是业务项目系统内部的， 哪些是业务项目系统外部的。2）Actor: 必须确定与业务项目系统进行交互的用户和其它系统，统称其为 Actor. 讨论业务项目需求时，需要先把要开发的业务项目系统看成一个黑盒子，从 Actor 的角度 来看这个黑盒子。Ac tor对黑盒子内部的结构一无所知，Actor与业务项目系统的交互仅仅是 在业务项目系统边界上进行的。因此业务项目需求就是在业务项目系统的边界上，Ac tor所能 进行的一切，包括看到的（界面）、听到的（提示语音）、输入（键盘/鼠标输入）、操作（查看 日志文件）、感受到的（响应速度，吞

8、吐能力）、扣费。归纳起来，业务项目需求包括如下方面：1）功能需求：包括界面，声音，输入输出、操作、计费等等2）性能需求：如容量、响应速度、吞吐能力等等3）安全性需求：如加密，防攻击，防盗用等等4）可维护性：包括日志、告警、在线跟踪等等。5）其它需求：上述各个部分都不能涵盖的需求。需求表述一个需求的表述，必须满足如下要素：1）清晰：需求的表述是从 Actor 的角度来表达的，其必须清晰，不能模棱两可，含 糊不清。另外，其必须没有二意性。2）正确：需求必须真正代表了 Actor 的需求，表述必须正确无误，引用数据和表述 细节必须绝对精确。3）可验证性：必须有明确的方法可以验证此需求是否被实现。4）

9、全面：全面性有两层含义：一是必须将每一个 Actor 的所有业务项目需求都表述， 不能有遗漏；二是对单个需求的表述，除了要表述正常过程下的需求，也要表述异 常情况下的业务项目需求（如号码无效，用户输入错误，当前状态无效）需求的标识：每一个需求都必须被命名，并且用一个代码对其进行唯一标识。此代码用于需求管理的全 过程。需求标识代码的命名为：SR-XX-YYYY，说明如下：SR 为 Software Requirement 的缩写XX为需求分类码，固定2位，可以为字母或数字，根据实际需求来制定。YYYY为需求序号，固定4位，从0001开始递增，不足四位前补0。产品测试验收产品测试验收是 Actor

10、 验收业务项目系统是否满足了技术需求说明书的唯一依据。 验收 是按照需求逐项进行验收的。由于每一个需求都被标识，并且每一个需求都是可验证的，因此 在需求阶段，产品测试表就必须提供，以明确业务项目系统的交付标准。 产品测试验收中阐 述了对需求进行验收的所有测试用例，不仅要对正常情况下的业务项目需求进行验收，也要对 异常情况下的业务项目需求进行验收。评审流程工作内容：评审组织者组织相关评审者对立项（创意）需求表或立项、（创意）评估报告 书进行评审。评审者提出评审意见，组织者汇总所有的评审意见，并通过开会讨论的方式决定 对立项（创意）需求表或立项、（创意）评估报告书的最终评审意见。相关角色：立项（创

11、意）者：被立项（创意）需求表或立项、（创意）评估报告书的立项（创意） 者。评审组织者：公司领导、部门领导，特别是策划部的领导。评审者：公司领导、部门领导、立项（创意）者等其他人员。适用范围：对项目（创意）的评审。评审过程活动：评审过程活动，按照时间顺序依次为1、评审规矩按照项目（创意）评估表进行。2、组织者要确认每一个评审者都收到立项（创意）需求表或立项、（创意）评估报告 书，并且理解了评审要求。组织者一般要保证下发立项（创意）需求表或立项、（创意） 评估报告书与评审会议之间的时间间隔不小于 1 天。3、各个评审者收到立项（创意）需求表或立项、（创意）评估报告书后，在指定的时 间内对立项（创意

12、）需求表或立项、（创意）评估报告书独立进行评审，将发现的问题 自行列表。评审期间，对于不理解的地方，可以请立项（创意）者进行局部讲解。4、根据与会者评分，才能得到程序上的立项，或把创意立为项目来操作。5、产品部经理至少要在评审会议前半小时将评审意见汇总，并给立项（创意）者看一 下，使立项（创意）者能够先自行确认一些问题，避免全部问题都在会议上讨论，浪 费时间。6、产品部经理在既定的评审会议时间，召集立项（创意）者和所有评审者进行评审。 会上主要讨论评审者提出的意见，确认评审意见是否可以接受，将确认结果记录下 来。7、产品部经理组织者将评审结果汇总，发给立项（创意）者，由立项（创意）者进行 修改

13、。组织者跟踪这些问题，保证都被正确修改。备注：如果评审过程发现严重缺陷或较多缺陷，产品部经理应该在立项（创意）者修 改完毕后，重新组织评审。8、产品部经理将评审全过程的所有文档都归档保存。五、建立技术需求说明书工作内容：建立配置库，将通过评审的项目技术需求说明书和产品测试验收书纳入配 置库进行管理，标注技术需求说明书标签。角色：配置管理员：对业务项目配置进行管理的人员，其工作职能包括：标注配置项、对配置项的变更进行授权和审核、版本管理等。六、制定开发计划工作内容：根据业务项目技术需求说明书，估计业务项目规模和复杂度，并根据人力资源 状况，制定业务项目开发计划，具体活动按时间先后顺序为：1) 业

14、务项目估计：2) 制定开发计划3) 开发计划评审4) 相关人员进行任务承诺下面分别阐述如下：业务项目估计 业务项目估计活动的依据是技术需求说明书和组织生成力水平。组织生成力水平的单位为 代码行/人天。这个数据是指从技术需求说明书建立的时间开始，直到项目完成，项目实 际产出的代码行与投入的人力相除而得到，其代表了公司当前的业务项目开发能力水平， 要从各个项目的开发实践中逐渐积累而成。每个项目完成后，都要统计业务项目开发能力 的数据。整个公司的业务项目开发能力水平，可以用各个项目的数据加权平均而计算。同 时，也要考虑当前开发组成员的实际能力水平状况。初期进行业务项目估计时，没有可参 考的经验数据，

15、因此都是凭个人主观来估计。后期积累了一些数据后，可以参照这些数据， 进行估计。业务项目估计的过程如下：i. 需求介绍 开发经理确定业务项目估计活动的组织者。组织者确定要参加业务项目估计的 小组人员，主要包括：开发经理、设计人员、主要开发人员、专家。在估计之 前，所有成员必须对需求的理解达成一致的认识。因此，要召开会议，对基线 化的需求进行详细介绍，使估计小组的成员充分理解各项需求。ii. 匿名估计组织者将估计表格发给估计小组的成员，小组成员采用匿名的方式，对需求逐 个进行业务项目规模的估计，估计的单位是代码行。iii. 数据汇总 组织者将估计数据进行汇总，确定与每个需求对应的最大估计值，最小估计值， 平均估计值，最大偏差度。最大偏差度=Max（最大估计值-平均估计值），（平均估计值一最小估计 值） ） / 平均估计值 * 100%iv. 讨论，修订 组织者召集估计小组开会，对估计的数据进行讨论分析。对其中最大偏差度比 较大的数据进行讨论，分析出导致估计偏差比较大的