需求开发与需求管理

 需求开发与需求管理概述

            在我看来， 项目管理的日常活动包括了： 需求管理、故障管理、版本管理、任务管理。

       需求管理贯穿了项目的大部分生命周期，故障管理则从第一个迭代版本出现直到产品维护阶段（包括内部故障与外部故障）结束。

              所以：需求驱动开发，需求是开发的上游。

            在Karl E.Wiegers写的“软件需求”第2版中，第一章中就描述了需求开发与需求管理的关系。

    广义的需求管理就是指需求工程，需求工程常分为需求开发（RD：requirement development）和需求管理（RM：requirement management）。

    简述之：

1，  需求开发=需求获取与分析+编写需求文档+评审并确认需求文档。

    解释：

          在需求文档得到下游（开发、测试）确认后，被传递给下游进入 代码开发与需求测试 活动。二者不属于 需求开发 范围。

　    由于目前的开发大多常用迭代版本(即：增量开发)，一个项目中包括了多个版本，在项目起始时制定第一个版本的需求基线，在后续每个版本开发前都会补充新的需求（也会删除、修改需求）。所以需求开发计划也包括了多个周期。

 

2，需求管理＝版本规划+需求变更控制+需求状态跟踪+需求追踪。（更全面的内容见下面）

    解释：

        版本规划 常称为制定需求基线，它应该制定本项目周期内，每个版本所包括的需求列表（有时版本内功能也包括了某些故障的解决，或把故障以需求的形式进行跟踪）。

        需求变更控制 针对上面提到的 需求开发的多个周期 进行控制，需求开发活动每个周期开始时都依靠 需求变更控制 活动来确认需求范围。

        需求状态跟踪与需求追踪 在我看来是 颗粒度粗与细 的关系，体现了 进度控制 的作用。

 

        需求管理计划 与 需求开发计划 是不同的项目管理计划、受不同的　项目进度计划　控制，但不同的活动又紧密联系在一起，交叉。

      在传统的、理想的开发模型中，需求开发活动（这个阶段中也受 需求管理 活动控制）完成后，需求不再变更，则之后只剩下需求管理活动直至本项目最终版本发布。但实际上，在版本发布之前、甚至版本维护阶段，仍有新的需求产生，则 需求开发活动 仍然不断持续中，这就是：需求开发多周期的意义。

 

需求开发

  包括以下各活动
1. 需求获取与需求分析：

          在定义了项目目标后，需求收集人员运用各种方法\工具，从不同的渠道，获取真实的需求。

          需求收集工具：市场调查、原型、需求专题讨论会、头脑风暴、同类/类似产品解剖、历史经验（如以前版本中遗留下来的未实现功能） 等。

          渠道包括： 如市场、客户/用户、竞争对手、研发等

          真实的需求： 原始需求可能只有一句话，但整理成的用户需求可能包括（但不限于）：市场必要性、功能（技术可行性分析、需求场景及主要过程、可验证性）、需求优先级及影响面分析、性能、质量、外部接口、应符合的业界标准、实现的限制（指某些不能满足的场景 需要明确列出）、国际化 等，并整理成 用户需求文档或 需求属性列表。

          需求分析工具：建模、图形化分析、创建原型、编写数据字典、Use Case、序列图、流程图。。。

          分析的结果( 用户需求文档)，应该得到 客户或需求提交人 的确认。

        有些教材将需求获取与需求分析分成两个活动，但在我看来，这两个活动是融合在一起的，获取的过程中需要明确一些细节，当然需求细节的颗粒度仍然较粗，这里也是考察需求收集人员业务能力的时候，有能力的需求收集人员应该尽可能获取或分析出 真实的需求，颗粒度适合研发需要为好。

    或者可以这样认为：需求最初获取的是 原始需求，需求分析时进行 细化、转换、显式化上层需求，得到用户需求（但分析过程中也会向客户确认细节）。

 

      注1：客户常见的困难在于：“我知道你已理解我所说的，但我不知道我所说的是否就是我真正想要的”，“只要一看到它，我就知道我要的正是它，但是我无法准确描述”
    注2：如果把活动与项目阶段作严格对应的话，整个需求开发阶段 还应该包括：

      1)，一些需求管理或需求状态跟踪的内容

                    用一个表格维护：需求提交人、需求来源（客户公司名称、项目 等）、需求名称、需求描述、提出时间、要求对外发布时间点或承诺时间点、要求决策时间点（即答复客户是否能满足要求的时间点）、需求分析人、需求状态（已拒绝、分析中、已批准。。。）、需求优先级、对外部项目的影响、用户需求文档归档路径 等。

      2)，需求决策：项目组内对于 用户需求 的评审及确认是否接受 的控制过程。接受后即为 已批准 状态。                                           

      3)，文档管理

                    原始需求文档、用户需求文档的归档及列表记录，

                    重点需求或经过反复讨论过的需求，应该将需求讨论记录、会议记要 归档或附到 用户需求文档中。

 

2.  编写产品需求：

                对用户需求文档进行细化，将需求过程对应到具体的产品，有时也称为SRS（System Requirement Specifications）或XX需求说明书。

              7 + 4特征：

                                  单条需求：完整性/正确性/可行性/必要性/划分优先级/无二义性/可验证性；

                                  需求说明书：完整性/一致性/可修改性/可追踪性

                用户需求文档应视为与外部客户之间的“契约”，而产品需求文档则是软件公司内部的“契约”，后者是产品方案、产品详细设计（HLD，High Level Design)、系统测试  的基础与依据。

              它是 需求评审、需求管理 的对象（我认为：用户需求也在需求管理的范围之内）

3，评审并确认产品需求文档

            评审产品需求文档，它确定了项目交付时用于评判是否符合客户要求的验收准则（内部交付依据产品需求，对客户交付依据用户需求）

            有时也称为 需求验证、需求审核，它不是指验证代码，而是指审核需求文档。

            发现缺陷越多的评审，是越成功的评审。

            评审员越全面越好：客户、用户需求作者、产品需求作者、开发代表、测试代表、用服代表、市场代表、售后代表、质量代表。。。

            激励评审员的积极性，也是项目管理的一个难点之一。

 

4，测试用例、操作手册的开发

        在产品需求完成同时，应完成以下两个活动

                          以需求为依据编写测试用例、编写用户操作手册（侧重于功能方面）

  这两个活动依据产品需求进行，且可以在 产品方案 设计前完成。

 

 

需求管理

            需求管理作为整个项目计划的一部分，在项目立项后，项目经理应首先明确：需求管理的活动、方法和资源。

            需求管理目的：使顾客和项目队伍对系统建立一致并保持一致，保持一致意味着计划、活动、工作产品都要和需求保持一致，不能偏离。
            所以：需求管理不仅是项目目标的体现，也是 项目进度控制 的主要手段之一。(其它的手段如：开发计划、测试计划、项目里程碑。。。)
          任何活动都可分为三个阶段：
1，计划
2，执行与进度控制。
3，验收与收尾
                需求管理的每个子活动与上述三个阶段可以对应起来理解。

              比如需求跟踪是属于进度控制的范围，但也包括了已验收状态的记录。

            收尾时所有需求均进入了已发布状态，项目一般会进行 文档的配置管理的补充与审核工作，比如 功能清单、版本发布说明、产品规范。。。 应该提交。

               

          基于需求驱动开发的理念，以需求管理、需求变更控制为主线，将需求、设计、开发、测试和项目管理完全工具化管理。

1，制订需求管理计划
              立项后完成。     

              包含：

                            有关人员的角色职责：

                                        产品\项目CCB(Configuration Control Board      配置控制委员会)(产品与项目并不等价，产品内可能包括多个项目，反之也可能)，CCB成员包括：主席、秘书、项目经理、开发经理、xx开发组负责人、测试代表、QA代表。。。

                                            各人在各子活动中的作用：牵头、组织、负责、参与、旁听、被通知、拍板或决策权。

 

                            工具与方法：

                                        原始需求收集的工具、需求跟踪工具、需求追踪工具、需求变更工具（各工具可使用如Excel表格、邮件、Word文档、软件工程软件、自己开发的OA系统。。。）、度量指标（如需求总数、已完成需求个数、测试中需求个数、已发布需求个数。。。）、项目需求例会机制、版本规划工具（如excel、microsoft的Project...)、版本规划例会、项目CCB会议机制。。。

                                    各工具、指标、会议机制的具体内容（如excel中应该包括哪些字段）、负责人、参与人。

 

                              需求追踪：需要追踪的工作产品类别及其追踪粒度：

                                        需求追踪的工作产品包括：市场需求文档、产品需求文档、系统测试用例、组件级需求、组件级方案、设计文档、代码模块\函数，前三者应该是最基本的跟踪粒度。有些非常敏捷的项目可能把 产品需求文档 也省掉了。

 

                                需求状态跟踪：跟踪的需求状态及其跟踪方法：

                                        用户需求、产品需求、产品组件需求 的各种状态（可能是不同的），如已提出、已批准或采纳、已删除、已拒绝、开发中、分析中、测试中、已实现、已验证、已发布、变更中、已变更、已延期。。。，项目需要为状态进行定义。

                                        部分项目可能跟踪的需求粒度更大或更小。由于有若干层次的需求，因此，需要明确需要跟踪的是哪个层次的需求(原始需求、用户需求、产品需求。。。）

 

                            接受用户需求、产品需求的准则，如项目可以定制自己的需求评审检查单。

                              定义审核频度：将项目组从技术角度对追踪关系的审核要求明确化

          注：需求管理活动可以酌情剪裁掉许多内容，视项目情况而定。

                        在数十、上百研发人员参与的大项目，需求繁多、变更频繁、质量要求高时，需要更多的管理成本投入到各种需求管理活动中。

                        也有些公司，虽然项目大且需求复杂，但参与项目的各方已经建立了一套约定俗成的规则，员工的职业成熟度较高，对于自己岗位的职责比较明确，较少发生扯皮事件，上下游之间配合较好，可以剪裁掉一部分需求管理活动，比如  需求评审、变更评审、需求追踪\跟踪 的简化、不再维护产品需求文档 等。

 

  注：需求管理工具 中还应该包括    沟通机制、文档访问控制，和设计方案、测试计划、配置工具的结合，跨项目追踪能力

            有些商业工具可以完成 需求管理 的全套或有关工作：提交用户需求、指派SE分析、提交分析结果、文档归档与基线化、决策记录与执行决策（拒绝或采纳、挂起、转交、拆分）、需求规划入版本、需求基线化、需求变更、需求状态跟踪（需求状态的变更）、需求单派生出文档单\代码单（与设计方案、代码开发计划的有效衔接）、导出需求追踪矩阵、提交版本、批准版本、生成roadmap、版本发布、计算需求度量指标、需求决策与变更通知有关人等、人员角色分组自定义。加上强大的统计、分析、图形功能。。。

          基于文档（比如Word、Excel)存储需求的方法有若干限制。例如： 

                                很难保持文档与现实的一致(即文档的变更没有进行正确跟踪，手工跟踪只能通过详细的修订记录表格来记录 变更详细情况与变更历史，很容易懈怠)、

                                通知受变更影响的设计人员是手工过程（一般是通过邮件通知 联系人分组，对方可能会忽视邮件）、

                              不太容易做到为每一个需求保存增补的信息(每次变更的修订必须手工记录、维护，很难保证全面，商业跟踪工具可以与SVN版本建立关联)、

                                很难在功能需求与相应的使用实例、设计、代码、测试和项目任务之间建立联系链（与第一条 文档与现实 的理由一样）

                              很难跟踪每个需求的状态( Excel做这个较好，但Word的表格功能则较差，行列长度个数受页面大小控制而不能让字段太多，没有筛选功能 )

            部分项目选择Excel、结合word进行需求管理的原因可能是：商业工具的性能较差（全公司数千个项目都在数据库内维护），公司定义的流程不符合项目需要、公司IT部门对项目需求的反应太慢。。

2，评审需求（用户\产品\组件级需求）或理解需求

        这应该属于 需求开发 的功能，但实际上因为常与版本规划、需求承诺  同时进行，也纳入 需求管理活动中。

        主要是让 产品\项目CCB 了解需求，确认优先级与发布时间点的过程。

      可使用的工具：用户\产品\组件需求 同行评审检查单

      组件级需求中也包括了系统内的接口需求，网元间接口需求\对其它网元的影响 则在 产品需求说明书 中体现。

 

注：需求开发的活动负责人是 负责每个需求的系统工程师。但需求开发活动也有其它角色参与。评审过程必须得到所有或大部分评审员的同意。

          需求管理的活动负责人是：需求经理（可以兼版本经理，有时版本经理会独立出来，专门负责版本规划、版本制作等活动），需求管理活动的其它重要角色如项目经理、版本经理、其它CCB成员。它们一般应该参与 需求开发活动中的评审过程。

              所以：评审需求 这个过程属于 需求开发与需求管理 的交叉过程。

 

3，评价与承诺需求（requirement commitment）

      需求承诺：需求干系人之间对需求和需求变更的文档化约定，它包括:需求范围、完成日期、质量、优先级等的约定，确保需求干系人对当前的、批准的需求和因该需求引起的项目计划、活动和工作产品变更负责。

          需求评审时就评估需求影响：需求范围，工作量，工期，成本，资源，质量目标。并形成报告上交CCB。

        将潜在风险识别出来并录入风险管理库进行跟踪。
      CCB对需求进行承诺：批准或拒绝、挂起、延期，对内对外的发布时间点。。。

        配置管理：文档版本、代码版本、模块函数的编号或命名方法、归档目录、有关人的访问权限。。。

 

注1：评价需求过程 的输入是需求评审时确认的需求影响面分析报告，

                        承诺需求过程 包括了 需求规划入哪个版本 的过程。与 版本控制 过程交叉。
注2：需求承诺表包括：需求名称，实现版本，交付日期，承载质量 等信息，是对市场的一个承诺。

                      需求承诺表也可以与 需求跟踪表 合一。比如在每周需求例会中对上周新来的需求进行规划、承诺。

 

4，需求的基线化和版本控制（版本控制即版本规划）

        基线化包括

            每个版本指定一个时间点，之前所有规划入这个版本的需求应该已经编写评审完成。这是项目进度控制的一个重要时间点。

          将需求规划入各个版本，各版本指定做版本时间点、发布时间点、测试周期 等。

          基线化操作表示对这个版本的需求内容进行冻结，在 基线化时间点之后的需求变化走用户需求变更流程，可能修改版本计划（版本发布时间点不变）或补充版本计划（推迟版本发布时间点）
          公司可能把需求变更、文档变更、代码变更控制 下放到项目线管理，而只对版本变更进行控制。

       

          需求的基线化：在需求（用户需求、产品需求）经过评审后，需求的修改纳入 变更控制 范围。

          需求评审会议举行 那天的时间点为 基线化时间点。

     需求的变更 可能引起文档变更、版本规划变更、代码变更。

       

        文档的基线化：在某文档（需求文档、设计方案、测试方案、功能指导书。。。）通过评审后，文档的修改纳入 变更控制 范围。

        文档评审会议举行 那天的时间点为 基线化时间点。

        文档的变更 可能由需求变更、故障、代码变更 引起。文档变更常与 需求变更、版本变更、代码变更 同时受影响。

 

        代码的基线化：这里各项目的控制力度可能不同，因为基线化之后的变更控制由项目线、开发经理进行，而开发任务下达到 代码基线化 之间的代码修改 可属于开发人员自己的行为。所以：

                有些管理较细化项目要求在代码入库（版本发布库、或测试库，视开发经理管理粒度而定）之后不能轻易修改。必须提交代码变更申请，并经CCB（可能是开发CCB、或项目CCB）批准通过。代码入了测试库之后，经测试人员测试通过后才允许入发布库（经过CCB批准后才可入）。

                有些管理较粗的项目要求将 版本对外发布 的时间点作为本版本有关代码的基线化时间点，之后对代码的优化修改、发现故障触发修改，都走变更控制流程。即代码的基线化等价于 版本发布。版本在发布之后，代码进入严格受控状态。

              完全没有控制的项目，在版本对外发布后，仍允许开发人员随时修改代码。外场故障一发生，开发人员随意修改代码解决后制作版本发布给现场。

注：代码可能分为几个库：开发库（供开发人员自己平时测试之用）、测试库（代码入测试库之后，测试人员发生故障后可以要求开发人员修改）、发布库（最终代码，版本制作基于发布库）。最差的情况是三个库合一。中间的控制粒度是 开发库与测试库合一。

 

        视项目内各成员权限让有关人等了解到各元素的最新修订。

          没建基线前、或者两个基线时间点之间，改动控制就可以比较宽松。

版本计划、需求、文档、代码的基线化，意味着： “版本”的意义扩展了

                        上述各管理元素应跟踪 其历史修订 情况，

                      常规所指的版本计划，是指代码的版本，每个版本内含若干需求、文档、代码文档的某个版本。   

                        但需求、文档也可以有自己的版本计划。三种版本计划之间存在对齐关系。比如每个文档都有自己的版本，从V0.1开始，每次小修订都让小版本号增加一位，大修订则增加大版。可能还涉及各文档的版本号对齐控制。  从文档对象出发，能跟踪到每个文档版本所属的代码版本、需求版本。

                      版本控制的最简单方法是根据标准约定手工标记软件需求说明书的每一次修改。  更高级别的使用版本控制工具

                    每个版本->需求->文档->代码块 的追踪、关系关系，能支持正向、反向追溯、同级关联关系确定。

 

5，需求变更（requirement change）管理      

                需求变更，是指增加、修改和删除已经基线化的版本需求。

                重点是变更影响分析（Change Impact Analysis，CIA）：通过广泛的确认，对变更进行分析，以确定：变更的必要性、可行性（技术、成本等）；可能的工作量及对进度的影响；可能的受影响的工作产品（利用需求追踪矩阵RTM）或其它事项
                CIA的目的：为“CCB决策是否要做”提供经过广泛确认的、基于经验的依据

 

        需求变更过程控制 的目标：控制项目范围的扩展
                            扩展需求指在软件需求基线已经确定后又要增添新的功能或进行较大改动
                            管理范围扩展的第一步就是把新系统的 视图、范围、限制 文档化并作为业务需求的一部分
                            控制范围扩展的方法是要敢于说“不”

            需求变更管理的流程是：

                          需求提交-分析-重承诺需求-实施变更（指对基线的变更）
  1），当版本规划中的用户需求已经冻结，用户需求变化后 需要提交申请。
                      产品\产品组件需求 已经基线化，存在 产品\产品组件需求 变更的申请
  2），分析内容包括但不限于：规模，工作量，进度，风险，质量，成本，需要变更的产品需求，危害分析等等，
                            提交《变更影响分析报告》
  3），重新确认新的承诺:
                3.1，如果双方没有改变承诺（即不接受变更请求），那么应当将由此产生的风险纳入项目的风险管理库中进行管理。
                  3.2，需求被决策后的状态有以下几种状态：拒绝、接受、提交上级CCB、挂起、延期等。

                      如果接受需求变更请求，可能要修改需求\设计\测试文档\用户随机资料与代码，要通知受影响的所有人员。
  4），实施变更，
    修改工作产品（系统方案、设计文档、代码、测试用例。。。）的活动，且产品都要评审和验证，纳入 需求追踪和状态跟踪 管理。

    现有版本可能重新制定，会影响开发计划，开发任务的进度需要重新制定。

 

需求变更控制策略 包括：
                制订的过程必须用于所有需求变更请求。（某些项目会为紧急需求制定绿色通道，即省略一些控制过程直接跳到开发。但应严格受控并记录，活动主体为项目经理）

            需求变更请求，必须由CCB决定是否采纳或拒绝。

            必须提交变更影响分析（并纳入 变更数据库 归档），供CCB决策。       

              当需求变更请求被拒绝后，只记录其拒绝状态，其它状态不再进行跟踪。

                未获批准的变更，除可行性论证之外，不应再做其它设计和实现工作。               
                  决不能删除或修改变更请求的原始文档，即需求的变更部分必须重新提交 产品需求文档，对现有文档的影响也应记录。（因项目而异，某些项目允许修改原来已经基线化的文档，但对原始文档的修订必须进行记录)

                需求变更 需要跟踪，特点是关联到 原需求的追踪矩阵与跟踪状态。
                需求变更 必须有专门的跟踪工具。

 

典型的失控变更
顾客直接对程序员提需求
出于对领导意见的尊重，错误被交付给用户，
竞争对手的功能直接被加入本产品。
程序员添加的“对顾客有宝贵好处”的产品行为
程序员为调试、提高技艺或者解闷而加入的功能

管理需求变更
识别不可避免的变更，为之制定计划
建立需求基线
建立唯一的变更控制流程
利用变更控制系统捕捉变更
管理变更的结构

注：需求变更的流程 与2、3、4、6、7、8步需求管理活动一致。也应包括 需求开发 的全部过程。

            在迭代版本管理方式下，经常放弃需求变更过程，新需求、旧需求的修改\删除 统一作为新需求提交->分析->评审->承诺->基线化->开发->测试->  发布。

              版本迭代的周期应该与项目一般的需求变更规律一致。

            对于需求变化非常频繁的行业、公司（比如项目进行中，每周都会有新需求过来并要求紧急开发），版本迭代的周期很短，可能一个月就需要出一个对外发布的版本。  每周的CCB上都会对新需求进行承诺并规划到下个月、或下下月版本中。

                那些需求变更较少（销售人员总是倾向于过分承诺、很多需求都要求紧急开发，如研发能顶住市场压力，推迟承诺时间点或决策时间点相当于需求变更较少），版本迭代的周期可以放长。

注： 需求变更 中很重要的地方是：要把变更通知到所有涉及人员，项目人员以及时准确的获取到需求与变更资料。

              尤其是对于旧需求有变化时，更要如此。

                这可能由 需求变更控制工具 自动实现（比如关联到原需求后，可以自动发送变更给 原需求的有关人员）

注：需求变更可能会对当前版本进度、计划构成影响。

 

6，需求追踪（requirements trace）
              需求追踪在需求、设计、实现、测试间建立追踪关系，以保证需求被正确、完整地传递到下游（即不存在“需求遗漏”），且不存在“实现镀金”（具体问题具体分析）
            需求追踪是衡量下游工作产品完成程度的重要工具；是实现工作产品彼此间保持一致的重要手段；是变更影响分析中确定波及范围的重要依据；需要由项目系统工程组保证追踪关系的完整性、正确性
                管理单个需求和其它项目可交付工作产品之间的依赖关系

 

    需求追踪矩阵（requirements traceability matrix）分纵向与横向
从需求到测试的 纵向追踪关系(指两个工作产品间的关系、工作产品的归档目录、工作产品的当前状态）    包括：

1.用户需求与产品需求
2.用户需求与外部接口
3.产品需求与内部接口
4.产品需求与产品组件需求
5.产品需求与系统设计
6.系统设计与子系统设计
7.子系统设计与详细设计
8.详细设计与代码
9.代码与单元测试
10.产品需求与系统测试
11.内部接口与集成测试

          需求追踪从用户需求开始进行追踪，包括对用户需求相互之间关系的标识和建立用户需求同下游工作产品元素（如产品需求、系统设计、产品组件件需求说明书、子系统设计、详细设计、接口说明书、源代码块、测试用例、用户手册等）之间的相关联系。

            比如项目可以 建立市场需求—产品/平台需求—系统测试用例之间的可视追踪关系，其它工作产品则不纳入需求追踪。

      对所有追踪对象建立 横向追踪关系：例如同级设计文档的某两个相关功能之间的追踪      同级追踪对象之间是否建立了横向的追踪关系       
      检查有关联关系的系统方案之间是否有追踪、接口说明之间是否有追踪、详细设计之间是否有追踪、代码等之间是否有追踪

      需求追踪结果对项目成员发布的方案，发布给哪些人，定期发布还是不定期发布。

      项目的需求追踪粒度：条目、工作产品等等，应该能满足现有的项目现状。比如：需求变更发生时是否能通过需求追踪表定位到关联的工作产品和责任人，是否需要进行 横向追踪。。。

          需求追踪的频次，应根据项目周期长度、历史需求稳定度来确定，即这个活动的触发时机，比如某工作产品评审完成后应在追踪表中建立与上游工作产品间的追踪关系。          比如每周检查并更新一次各追踪对象的当前状态、随时补充新的追踪对象（比如进行紧急需求开发时，应及时根据工作产品的输出情况进行需求追踪活动)。

          需求追踪 应该评审并纠正不一致性。比如每个版本基线建立时，CCB应审核追踪矩阵的建立，确认所有需求分析、评审、承诺活动已经完成。      比如每周项目例会上向项目CCB进行汇总，可供CCB了解当前项目进度与资源分配情况。      QA在每个里程碑评审之前进行检查。

            研发人员利用需求追踪维护需求和工作产品的一致性，当发现不一致时应进行相应的记录，并采取相应的纠正措施。

 

注：需求追踪信息是项目管理的重要依据，是 需求变更 的重要参考。

（很多项目中执行了需求状态跟踪，但没有严格执行 需求追踪，是因为这些项目管理的颗粒度针对只针对一条用户需求，他们对需求的几个关键点作了管理，确保了：需求进行了代码开发、测试验证通过、发布给某用户的版本中包括了用户要求的需求项。中间过程不在项目级别进行管理。

    这些项目在CMMI中不会视为 高可靠过程。）

 

注：需求追踪 要求需求得到有效管理，

                如各来源发来的需求均有统一的渠道、统一的接口人、统一归档、是否接受电话、邮件提交需求，

                哪些故障可以走需求流程，

                没有经过CCB承诺的需求不应下发给开发部，开发部只接受CCB下达的任务，

 

        问题举例：
                忘记实现子需求
                变更时不清楚要变动的地方
                搞不清改动的影响面有多大
                取消需求，设计仍然在进行

追踪注意事项
显式追踪和隐式追踪
                父子关系
                间接追踪关系
                冲突关系
尽量使用专用工具
信息访问权限
注意审核
及时维护

尺度把握
追踪范围
                从产品重要、关键的部分追踪起
                从需求信息追踪起
追踪频度
                每个里程碑？
                每个基线？
                每周/日？
追踪人员
                项目经理？
                项目经理+各组长？
                每个人？

思想顾忌
“需求追踪思想虽好，不适合我们”
                我们的直觉经常不可靠，尝试一下
                习惯了就好了
“系统这么大，不现实”
                正因为系统这么大，才需要追踪
“变更这么多，维护追踪信息是巨大的负担”
                变更越多，追踪信息越有价值
“时间紧迫，人手不够”
                向返工要时间
                向救火要人手

在下列情况下维护负担过重：
                追踪面广
                关联复杂
                变更频繁
常见困境
        拒绝更新追踪关系的改变
        难以承受，放弃追踪矩阵

 

7，需求状态跟踪（requirements status track）
                需求状态跟踪：    维护用户需求在产品研发过程中的状态变迁，定义项目生命周期中反映需求完成程度的状态；确定“需求”与“状态对应的工作产品”间的对应关系；收集证据；根据状态定义及证据，定期或事件驱动地刷新每条需求的状态
                需求状态跟踪结果是判断项目进展的很客观的依据；需求追踪关系是状态跟踪的基础。

 

          对产品的需求状态进行统计分析可以查明对应项目的进度状况，需求跟踪就是对需求状态的收集分析。需求的状态定义如下： 
                  需求已提交，需求已删除，需求已拒绝，需求已批准，已重复，已挂起，已下达开发任务，代码已实现，测试已验证，版本已发布。。。

      对于每一条用户需求，相关人员对它进行状态跟踪，直至关闭；
              需要跟踪的对象包括：市场需求，产品需求，软件需求，硬件需求。当不区分软硬件、每条市场需求对应一条产品需求，则每个用户需求只有一个条目。

  活动：

    1），通过 需求追踪矩阵，识别与用户需求关联的所有工作产品元素 是否实现。这是检查 用户需求是否实现的方法。

    2），定期统计并报告需求状态分布
      3），审核需求状态表，识别需求与产品或项目工作的不一致，采取纠正措施。
    要有一个合适的需求状态发布方式，维护与评审时机。

注：需求状态跟踪一般可视为项目进度控制的手段，它比需求追踪的颗粒度要大，因为它关心的重点是： 需求 是否得到代码开发、测试并发布。

          需求追踪主要是为了维护上下游产品的一致性，并作为需求状态跟踪的输入。

          部分管理粒度粗的项目(比如敏捷项目)只要求需求状态跟踪，而不要求需求追踪，因为对需求（story)到代码之间的工作产品不进行管理。如果要在 需求跟踪与需求追踪 之间作个折衷的话，可以在需求状态跟踪表 中记录到 需求子功能点分解 级别。

 

注：  父子关联：  部分需求会与其它项目协同开发，如果不通过需求追踪来做，则应在 需求跟踪 表中对需求的下达其它产品、对方代码完成、对方测试完成情况进行跟踪。

          冲突关联：某些需求之间有交叉重复关系。比如需求A与需求B中均有重合的功能点，也有不重合的功能点。此时应指定同一个需求SE分析、下达同一个开发任务，新的需求任务应包括需求A与需求B的所有功能。需求跟踪表 此时只跟踪一条需求，另一条置为 已重复 状态。

          需要哪些需求状态：根据项目特点（哪些研发阶段特别长，哪些研发阶段特别关键）可以定制，比如敏捷项目中可能只记录采纳的需求，即不跟踪：需求已删除，需求已拒绝，需求已批准，已挂起。。。 等状态。当开发与测试人员合一时，代码已实现，测试已验证 两个状态也会合一。

 

注：  充分利用工具的自动工作特性，将 需求跟踪、版本规划、度量、需求变更、开发测试任务的下达\完成、文档修订或变更 等过程集成。

8，度量方式

1，需求状态统计，是观察项目进度的重要手段

    已实现需求个数

    已验证需求个数

    开发中需求个数

    未分析需求个数

   

2，需求变更的度量方法，是观察项目立项后需求变更的手段

        需求稳定度：变更的需求个数/基线化时的需求个数

  变更控制状态报告：  用报告、图表来总结变更控制数据库的内容和按状态分类的变更请求数量
比如：项目周期内，变更的产品需求数目

      接收、未作决定、结束处理的变更请求的数量
      已实现需求变更（包括增、删、改）的合计数量
      每个需求源发出的变更请求的数量
        每一个已应用的需求建议变更和实现变更的数量
        投入处理变更的人力、物力

 

一个具体的需求跟踪流程图

 

 

注：CMMI主要有5种成熟度级别，从低到高分别是初始级、已管理级、已定义级、定量管理级和持续优化级。