精华内容
下载资源
问答
  • 需求管理

    千次阅读 2017-01-07 14:57:03
    需求指由项目接受的或项目生产的产品...需求工程的活动可以分为两类:需求开发、需求管理。需求开发是通过调查和分析,获取用户需求并定义产品的需求。需求开发产生的输出:项目视图、范围文档、用例文档、软件需求规

    需求指由项目接受的或项目生产的产品和产品构建的需求,包括由组织征集的对项目的需求。需求管理是确保各方对需求的理解一致,管理和控制需求变更,从需求到最终产品的双向跟踪。


    需求管理概述

    把所有与需求直接相关的活动称为需求工程。需求工程的活动可以分为两类:需求开发、需求管理。需求开发是通过调查和分析,获取用户需求并定义产品的需求。需求开发产生的输出有:项目视图、范围文档、用例文档、软件需求规格说明、相关分析模型。需求开发过程有四个主要活动:需求获取、需求分析、需求定义、需求验证。

    需求开发把项目干系人的需求转换成产品需求和决定如何在各个产品构建之间安排或分配需求。需求管理是收集需求变更和变更的原因,维持对原有需求和所有产品及产品构件需求的双向跟踪。

    需求管理的流程:

    1.制定需求管理计划。内容包括确定软硬件资源、需求跟踪矩阵、需求变更请求表等,由项目经理审批该计划

    2.求得对需求的理解。对需求的解读达成一致

    3.求得对需求的承诺。先对需求达成共识承诺,然后实施需求达成一致的承诺

    4.管理需求变更

    5.维护队需求的双向跟踪

    6.识别项目工作与需求之间的不一致

    需求属性是进行管理需求的一些指标,例如:创建时间、版本号、状态、稳定性等,一般情况下,最值得关注的是需求的状态,状态的取值有:已建议、已批准、已实现、已验证、已删除。


    指定需求管理计划的主要步骤

    1.建立并维护需求管理的组织方针

    2.确定需求管理使用的资源

    3.分配责任

    4.培训计划

    5.确定需管理的项目干系人,并确定其计入时机

    6.制定判断项目工作与需求不一致的准则和纠正措施

    7.制定需求跟踪性矩阵

    8.制定需求变更审批规程

    9.制定审批规程


    需求规格说明的版本控制

    版本控制是需求管理的一个必要方面。版本控制最简单的方法是根据标准约定手动标记软件需求规格说明的每一次修改。使用版本控制工具更佳。


    需求变更管理

    为了使开发组织能够严格控制软件项目应用,需要保证以下事项:

    1.仔细评估已建议的变更

    2.挑选合适的人选对变更做出决定

    3.变更应及时通知所有涉及人员

    4,项目要按一定的流程进行需求变更

    当进行变更时,按从高到低级别顺序对受影响的文档进行变更。

    扩展需求指在软件需求基线已经确定后添加新的功能或进行大范围改动,这种修改影响非常大。为了控制这种需求扩展,可以采用两种方法:第一种是预留需求改动的余地;第二种使用原型法为客户提供基于原型上的可能扩展,帮助客户了解真实需求

    变更控制策略描述了如何处理需求变更。下列需求变更策略是有用的:

    1.所有需求变更都必须遵循过程

    2.未获批准的变更只能做可行性论证

    3.变更请求不能保证变更实现,有变更控制委员会决定实现那些变更

    4.项目风险承担者应了解变更数据库内容

    5.不能从数据库中删除或修改变更请求的原始文档

    6.每一个集成的需求变更必须能跟踪到一个批准的变更请求

    变更控制中的组件:

    1.开始条件,执行变更控制之前应满足的条件

    2.过程或步骤中包含的不同任务及项目中负责完成他们的角色

    3.验证任务正确完成的步骤

    4.结束条件,指出过程或步骤完成的条件

    变更控制过程描述:

    1.绪论。说明此步骤或过程的目的,确定步骤或过程应用的范围

    2.角色和责任。列出参与变更控制活动的项目组成员并描绘他们的责任

    3.变更请求的状态。每个变更请求都有生命周期,用状态表示周期中的变化

    4.开始条件。基本开始条件:从何时渠道接受一个合法的变更请求

    5.任务。变更控制任务,包括评估可行性、批准或拒绝、传达变更决定

    6.验证。验证变更情况

    7.结束条件

    变更控制状态报告,用报告、图表总结变更控制数据库的内容和按状态分类的变更请求。

    变更控制工具,辅助变更控制过程,挑选时注意以下内容:

    1.可自定义变更请求的数据项

    2.可自定义变更请求生命周期的状态转换图

    3.可加强状态转化图使被授权用户做出可允许的修改

    4.可记录每种状态变更数据,确认做出变更的人员

    5.可在请求提出或请求状态修改后通知相关人员

    6.可根据需要生成标准或定制的报告或图表

    变更控制委员会(CCB)是控制需求变更的优良策略之一。

    软件度量是深入项目、产品、处理过程的调查研究,以面临的问题和要达成的目标为依据的评估活动。测量变更活动是衡量需求变更的一项重要活动。


    需求跟踪

    需求跟踪包括编制每个需求同系统元素间的联系文档。

    需求跟踪目的是保证需求跟实际开发任务的关联性,这会提高开发费用,降低运维费用。

    表示需求和别的系统元素联系链的最普遍方式是使用需求跟踪能力矩阵。

    变更需求的代价需要作出影响分析,例如成本、进度、收益、风险等。


    需求管理好不好看需求变更控制。


    选择性考察、客观性考察、论述性考察

    展开全文
  • 需求开发与需求管理

    千次阅读 2013-08-31 22:05:54
    在我看来, 项目管理的日常活动包括了:需求管理、故障管理、版本管理、任务管理。   需求管理贯穿了项目的大部分生命周期,故障管理则从第一个迭代版本出现直到产品维护阶段(包括内部故障与外部故障)结束。  ...
     需求开发与需求管理概述
                在我看来, 项目管理的日常活动包括了: 需求管理、故障管理、版本管理、任务管理。
           需求管理贯穿了项目的大部分生命周期,故障管理则从第一个迭代版本出现直到产品维护阶段(包括内部故障与外部故障)结束。
                  所以:需求驱动开发,需求是开发的上游。
                在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:需求承诺表包括:需求名称,实现版本,交付日期,承载质量 等信息,是对市场的一个承诺。
                          需求承诺表也可以与 需求跟踪表 合一。比如在每周需求例会中对上周新来的需求进行规划、承诺。
     
    注3:项目经常会从各种源头收到需求:各局点服务人员、某地销售处、市场应标人员、上级领导、其它产品或项目、内部开发人员、内部测试人员的邮件、会议记要、用户需求说明书。
                比如许多需求通过邮件收到,项目经理随意指定一个SE进行分析、随意给开发经理指定一个版本号与完成时间点,难以进行后期的监控。
                项目的需求收集应该有一个 统一入口,需求提交人应该提交需求的具体描述、要求时间点、有关市场项目、简单影响面 等信息,然后需求经理定期收集后指定需求SE分析。需求经理通过需求跟踪表记录 已分析状态 及要求完成分析工作的时间点,并对分析工作的完成状态进行监控。
              上述工作也属于需求管理活动范围。
     
    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,需求变更的度量方法,是观察项目立项后需求变更的手段
            需求稳定度:变更的需求个数/基线化时的需求个数
      变更控制状态报告:  用报告、图表来总结变更控制数据库的内容和按状态分类的变更请求数量
    比如:项目周期内,变更的产品需求数目
          接收、未作决定、结束处理的变更请求的数量
          已实现需求变更(包括增、删、改)的合计数量
          每个需求源发出的变更请求的数量
            每一个已应用的需求建议变更和实现变更的数量
            投入处理变更的人力、物力
     
    一个具体的需求跟踪流程图
    需求开发与需求管理
    需求开发与需求管理
                  图中每个矩形框表示一个需求活动,在许多活动完成后,都会触发需求经理填写用户需求跟踪表、产品需求跟踪表的信息,这就要求各个活动都要有输出信息,所以项目上要建立有效的信息通报机制。
                  在已挂起状态之后,用户需求可能后续被重新批准(图中略去这部分过程)。
                  在用户需求状态上有“部分实现”状态,表示某条需求因故分为多个阶段或版本提供。“已批准”表示项目经理决定接受这个需求,此后会触发产品需求的编写过程,所以为了跟踪产品需求文档的提交与评审状态,另外用“需求文档状态”信息项进行记录。
                  因为项目经理在评估用户需求分析报告时,可能会拒绝或挂起用户需求。所以在用户需求批准之后,需求作者才会开始编写产品需求说明书。使得产品需求没有 已提议、已批准、已拒绝、已挂起 状态。
                  在规划版本活动之后,可能产生需求变更活动,并可能删除用户需求或产品需求。
                  在制作版本完成后,产品需求跟踪表中本版本有关的产品需求被置为已实现状态,并记录了版本号。测试经理按版本号导出本版本已实现的产品需求,建立测试用例并组织验证版本。

    常见问题:
    1,跨项目协同
        各项目的开发流程经常需要纳入整体管理,至少要一致。
        某任务在各项目的进度必须一致、之间的任务交互如何可控、如何提交需求给其它项目、进度如何反馈?
                  如何监控其它项目的任务进度、质量?
                  问题发生如何追溯原因?
                  需求分析在各项目的理解要一致,在评审上如何协作?
                  发现问题如何反馈给其它项目?
                  项目间接口文档的形式、内容、如何归档、文档配置项的管理?
     
    2,通过需求管理对研发过程进行质量监控
                许多公司号称全面、全员的质量控制。
                  实际操作时,在各方资源总是不足的情况下,全面的质量控制会降低当前项目进度。以下列出一些可选用的措施。
    注:无论是从理论上,还是从实践上分析,有效的、全面的需求管理如得到执行,从长期看,会降低产品的故障率,产品开发、故障响应速率可以稳定的评估出来,从而达到可控的项目管理。
                  但受 结果导向 绩效体系影响,项目经理一般只关注短期目标的实现。
          下面针对的软件企业是:CMMI1、CMMI2,或者企业已经有部分过程达到CMMI3(至少各种标准、流程在文字上作了定义,执行上则因人而异)
      一、较粗的管理层面。
          1)需求评审与需求承诺的加强。
                  文字上明确各需求的评审员角色并要求必须参加,抄送人角色。。
                  各产品提供需求评审通过检查单,可列出产品常见的需求模糊问题、各方面的产品指标受影响程度、业务流程细化到什么程度等。
                  需求承诺必须有哪几级领导参与,介绍市场背景,任务具体执行部门(开发、测试)是否能当场承诺任务进度,他们对上游有何要求。
          2)需求状态跟踪
                          各条需求当前是否已提交开发、是否已提交测试,是否已发布。
          3)需求周报、项目周报及例会制度。
                          需求周报可列出本周需求变更情况,已经规划到版本的需求清单和未规划的需求清单等。抄送人员要全面。
                          重点需求重点跟踪。
                          需求例会对 未规划需求 进行规划,现有需求规划的变更,需求分析中面对的困难 等。
                          项目周报列出本周项目进度、已发现故障情况、未解决事宜与负责人、风险跟踪情况。。。,
                          项目例会是供各方面项目成员交流问题的一个平台。
        4)故障管理
                                  当前未解决故障列表,故障复盘,
            5)质量管理
                                  任务预警(故障、需求任务的进度是否拖延),未完成任务跟踪,度量指标统计,质量周报,改进措施跟踪。
     
          二、细化管理
    在上述活动的基础上,增加以下活动。
      1)需求追踪采用某工具进行管理。
          需求、设计、测试、代码各级产品的完成日期,负责人,归档路径,评审会议记要路径,受影响的其它项目的状态。
          各研发阶段执行情况可一目了然,监控哪些产品的提交、评审状态,定期检查与通报,及时发现识别风险。
      2)需求变更控制
                  变更历史追踪。。。
     
    注:CMMI主要有5种成熟度级别,从低到高分别是初始级、已管理级、已定义级、定量管理级和持续优化级。
    初始级(1级):过程的执行往往是即兴管理,对人的依赖性很高,结果很难预测,管理层实践可能会无效。
    已管理级(2级):项目管理规范化了,组织方针、项目计划和过程描述都被建立,并文档化,有适当的资源,责任指派和授权,小项目可以根据过去的经验进行预测。规范化有助于现有实践在压力下仍能进行,同时对管理人员来讲,过程活动和工作产品的状态在预定义的点上是可见的。
                  在本成熟度级别中主要有7个工作域,需求管理、项目计划、项目监督和控制、测量和分析、配置管理、供应商协议管理、过程和产品质量保证。
    已定义级(3级):在已管理级的基础上,整个组织有标准的过程,项目可以根据需要进行裁剪,工程过程可以更有效的设施,组织的活动是可预测的,培训也是有计划的。在整个活动过程中,角色和职责分明,过程和产品的状态在整个研发过程都是可见的。
                  在这个级别主要有14个工作域,需求开发、技术解决方案、产品集成、验证、确认、组织过程聚焦、组织过程定义、组织级培训、集成项目管理、集成供应商管理、风险管理、决策分析和解决、集成的组织环境、集成团队。
                  和2级相比,在过程描述上,3级更详细、严格,并且在实施管理是更强调了解过程活动之间关系、过程的详细度量值以及过程的工作产品和服务。
     
     
     
     
     
     
     
     
     
    展开全文
  • 软件需求管理

    千次阅读 2008-06-06 14:05:00
    软件需求管理 这篇文章的目录结构是我拟定的,内容大部分是参考网上和书上资料,也一部分是我自己总结的前言 需求和需求管理问题第1节 需求和需求问题 需求是项目的基础,只有准确了解客户的需求,以之为基础,...

    软件需求管理

     这篇文章的目录结构是我拟定的,内容大部分是参考网上和书上资料,也有一部分是我自己总结的

    前言 需求和需求管理问题

    1 需求和需求问题

           需求是项目的基础,只有准确了解客户的需求,以之为基础,我们才能顺利地完成项目,在预算内按时提交高质量的对客户有用的产品。然而,有头无尾的半截子工 程,用户不满意的工程,难以投入实际环境使用的工程,经费严重超支和进度被拖延的工程,并不是个别现象,而造成这种项目失败的原因非常多,其中最糟糕的莫 过于在需求阶段产生的重大缺陷,缺少来自用户的信息,需求不够完整及需求发生了变化。统计资料显示,返工的成本占总开发成本的30% - 50%,而70%-80%的返工是需求错误引起的。

    2 需求管理和需求管理问题

    需求管理是对需求开发的管理,伴随需求开发全过程、软件生命周期全过程。如果不能采取有效手段来实施需求管理活动,由此导致的结果是用户和开发团队对产品需求的理解相去甚远。项目需求获取也许是最困难,最关键,最容易出错和最需要沟通的一个环节,它的模糊性、不 确定性、变化性和主观性的特点,使项目需求管理更具复杂性。如果不能有效处理需求变更这个特殊和困难的挑战,项目计划将会一再调整,交付日期一再拖延,项 目团队人员的士气必将越来越低落,这将直接导致项目成本增加、质量下降及项目交付日期延迟。因此项目组必须拥有需求管理策略和需求过程。

    1 需求管理目标

    需求管理的目的就是要控制和维持需求事先约定,保证项目开发过程的一致性,使用户

    得到他们最终想要得产品

    Ø         确保需求调研的成功,即需求调研中要从人员、方法、工具方面组织好调研活动

    Ø         确保需求文档中描述的需求是用户需要的需求,即要和用户反复确认和商讨需求

    Ø         确保需求文档中描述的需求是最新的需求,即不断跟新需求文档版本

    Ø         确保需求文档中的需求是可以度量的,即对需求进行详细标识

    Ø         确保需求文档中的需求是可跟踪的,即可控制和可管理

    2 需求管理任务

           从需求管理目标看,确保得到一份正确的需求,然后对需求进行详细分解,达到度量需求的目的,对需求的每个小项进行跟踪,可以从用户需求追踪到设计、编码、测试、验收;反过来也可以由后面的过程追踪到前面的过程,所以需求管理要包括下面的任务

    Ø         需求调研计划:包括客户人员、自己人员、需要的资料、设备、规范、进度

    Ø         组织双方对需求进行评审:确保需求的正确、一致

    Ø         度量需求文档中的需求,标识需求项(作为需求跟踪的唯一标识)、重要等级。

    Ø         对需求变更进行评审,然后对需求变更进行版本维护

    Ø         对需求状态跟踪

     

     

    3 需求管理组织

           从需求管理任务看,需求管理的职责可以分成:

    Ø         需求调研计划制定

    Ø         需求分解,标识

    Ø         需求跟踪

    Ø         组织需求变更审核

    Ø         客户审核需求变更

    Ø         评估需求变更影响

    Ø         维护需求文档

    Ø          

      根据上述职责、根据项目情况设置适当岗位

    4 需求管理周期以及和其他活动关系

    Ø         必须与需求工程的其它活动紧密整合

    谈需求管理一定不能脱离需求工程。从完整意义上讲,需求工程包括了需求获取、需求分析、需求描述、需求验证、需求管理。狭义上,需求管理关心的是需求管理过程的建立,在企业或项目组中需要有一套规范的需求管理过程。而实际上从项目经理的角度上看,可能还有50%甚至更多的精力是用于关注结果的,所以对需求内容的管理与对需求形式的管理是密不可分的。

    Ø         与需求开发的关系

    组织需求调研活动;组织需求评审活动;分解需求项,标识重要级;对需求变更结果进行维护

     

    Ø         与设计的关系

    建立设计和需求关系,使之能追踪

     

    Ø         与编码的关系

    建立编码和设计、需求关系,使之能追踪

     

    Ø         与测试的关系

    建立测试和编码、设计、需求关系,使之能追踪

     

     

     

    5 需求管理内容

    第1节           需求质量管理

    5.1.1 需求质量属性

           功能属性

           功能正确性:需求定义的功能是否可以正确执行,并且产生理想的数据

           非功能属性:对用户重要属性

           有效性:系统故障概率

           效率:处理器、磁盘、通信带宽资源占用

           灵活性:可扩展性

           安全性:防止非法访问和数据丢失

           互操作性:和其他系统交互数据的难易程度

           可靠性:软件不发生故障的概率

           健壮性 :系统遭到非法输入、相关软件和硬件缺陷或异常操作时,能继续正

    确运行功能的程度

           可用性:系统使用的方便性

           对开发者重要的属性

           可维护性:做一次纠错或者更改的难易程度

           可移植性:把软件从一个运行环境移到另一运行环境的难易程度

           可重用性:复用

           可测试性:查找错误的难易程度

           软件度量属性需要根据客户要求进行取舍

    5.1.2 需求质量验证

           需求验证过程见,W验证模型,模型中验收测试和系统测试属于需求质量验证,集成测试和单元测试属于设计质量验证和编码质量验证

    2 需求风险管理

    5.2.1 风险管理

           风险管理中先要识别风险,然后分析风险发生条件、可能性、危害、避免方法,最后对系统中所有分析进行计划管理,有效控制风险,降低风险的危害

          

    风险条目跟踪

    序号

     

    确定日期:

     

    撤销日期:

     

    描述:描述风险

     

    可能性:发生概率

     

    影响:造成损失

     

    危害值:可能性*影响

     

    降低风险计划:

     

    负责人:解决风险的责任人

     

    截至日期(完成降低风险措施的截止日期)

     

     

     

    5.2.2 与需求相关风险

    Ø         需求获取:

    ü         产品试图与范围:如果开发方和客户没有就项目范围达成一致,适当的意见,会导致

                                       开发范围逐渐扩大

    ü         需求开发时间:时间安排不合理,隐藏的工作没有规划出来,开发支持工作配合不及时

    ü         需求规格说明书的完整性和正确性:需求说明描述出现问题

    ü         明确非功能要求:需要确定肺功能性需求

    ü         需求决定权:确保在需求决定权上有正确的人选

    ü         未加说明的需求 :识别用户隐含的期望要求

    ü         从解决方案中找到问题本质:用户推荐的解决方案掩盖了用户实际需求,分析人员要从客户叙说的解决方案中提炼其本质

    ü         用户不能正确表达自身的需求:在实际开发过程中,常常碰到用户对自己真正的需求并不是十分明确的情况,他们认为计算机是万能的,只要简单的 说说自己想干什么就是把需求说明白了,而对业务的规则、工作流程却不愿多谈,也讲不清楚。这种情况往往会增加需求分析工作难度,分析人员需要花费更多的时 间和精力与用户交流,帮助他们梳理思路,搞清用户的真实需求

    ü         业务人员配合力度不够:有的用户日常工作繁忙,他们不愿意付出更多的时间和精力向分析人员讲解业务,这样会加大分析人员的工作难度和工作量,也可能导致因业务需求不足而使系统无法使用

    ü         忽略了用户的特点分析:分析人员往往容易忽略了系统用户的特点,系统是由不同的人使用其不同的特性,使用频繁程度有所差异,使用者受教育程度和经验水平不尽相同。如果忽略这些的话,将会导致有的用户对产品感到失望

    ü         客户业务变动:客户业务根据实际情况发生变化

    Ø         需求分析

    ü         划分需求优先级:

    ü         带来技术困难得特性:分析每项需求的可行性以确定是否能按计划实现。

    ü         不熟悉的技术、方法、语言、工具和硬件平台:不要低估学习难度

     

    Ø         需求规格说明

    ü         需求理解:开发人员和客户对需求不同理解会带来彼此间期望的差异,将导致最终产品

                                产品无法满足客户要求

    ü         时间压力对TBD的影响:如果TBD并未解决对项目后续进行将带来很大影响

    ü         具有二义性的术语:

    ü         需求说明中包含了设计:

     

    Ø         需求验证:

    ü         未经验证的需求:

    ü         审查有效性:

     

    Ø         需求管理

    变更需求:控制需求变更,减少变更

    需求变更过程:当变更发生时需要有效机制和计划管理变更

    未实现的需求:需求跟踪可以避免发生为实现需求

    扩充项目范围:如果开始没有定义好项目范围,那么过段时间可能要扩充项目范围

    需求跟踪:方便管理需求执行、质量

     

    3 需求范围管理

    5.3.1 需求范围

           需求范围就是一个项目的需求范围,也就是项目范围。需求范围决定了这个项目或者产

    品的客户要求,主要包括功能要求。这个范围是整个系统后续开发的纲领,所以需要特别重视,范围确定和变更要慎重对待。

    5.3.2 需求范围管理

    Ø        造成范围界定不清的原因:

    ü        首先,没有完善的项目管理体系来指导项目的管理。

    ü        第二,对项目没能制定出清晰规范的范围变更控制过程。企业有管理体系,但不够完善和规范,对项目组的变更过程的制定没能起到有效的指导作用。变更是不可避免的,只要有效地加以管理、控制,同样可以达到各方满意的结果;

    ü        第三,是对范围的定义不够明确,做不到可量化、可验证程度。

    Ø        如何管理好项目范围:项目范围管理应该包含下面过程:启动、范围定义、范围核实及范围变更控制。下面将详述如何做好这些过程:

    Ø        启动过程:启动过程的一个输出就是项目章程。项目章程是一个重要的文档,这个文件正式承认项目的存在并对项目提供一个概览。项目章程将粗略地规定项目的范围,这也是项目范围管理后续工作的重要依据。项目章程中 还将规定项目经理的权利以及项目组中各成员的职责,还有项目其他干系人的职责。

    Ø        范围定义过程:范围定义是指将项目主要的可交付成果细分成较小的、更易管理的组分。这个过程中,项目组要建立一个工作分解结构(WBS)。

    ü        WBS的建立对项目来说意义非常重大,它使得原来看起来非常笼统、非常模糊的项目目标一下子清晰下来,使得项目管理有依据,项目团队的工作目标 清楚明了。如果没有一个完善的WBS或者范围定义不明确时,变更就不可避免地出现,很可能造成返工、延长工期、降低团队士气等一系列不利的后果。

    ü        制定好一个WBS的指导思想是逐层深入。先将项目成果框架确定下来,然后每层下面再把工作分解,这种方式的优点是结合进度划分直观,时间感强,评审中容易发现遗漏或多出的部分,也更容易被大多数人理解。

    Ø        范围核实过程:范围核实是指对项目范围的正式认定,项目主要干系人,如项目客户和项目发起人等要在这个过程中正式接受项目可交付成果的定义。这个过程是范围确定之后,执行实施之前各方相关人员的承诺问题。一旦承诺则表明你已经接受该事实,那么你就必须根据你的承诺去实现它。这也是确保项目范围能得到很好的管理和控制的有效措施。

    Ø        范围变更控制过程:范围变更控制是指对有关项目范围的变更实施控制。变更是不要避免的,关键问题是如何对变更如何进行有效的控制。控制好变更必须有一套规范的变更管理过程, 在发生变更时遵循规范的变更程序来管理变更。通常对发生的变更,需要识别是否在既定的项目范围之内。如果是在项目范围之内,那么就需要评估变更所造成的影 响,以及如何应对的措施,受影响的各方都应该清楚明了自己所受的影响;如果变更是在项目范围之外,那么就需要商务人员与用户方进行谈判,看是否增加费用, 还是放弃变更。因此,项目所在的组织(企业)必须在其项目管理体系中制定一套严格、高效、实用的变更程序。

      

    4 需求配置管理

    对配置知识不了解,所以没有话好说

    5 需求跟踪管理

    5.5.1 需求跟踪矩阵

    提示:正向跟踪和逆向跟踪合称为双向跟踪。不论采用何种跟踪方式,都要建立与维护需求跟踪矩阵(即表格)。需求跟踪矩阵保存了需求与后续工作成果的对应关系。矩阵单元之间的可能存在一对一一对多多对多的关系。由于对应关系比较复杂,最好在表格中加必要的文字解释。当需求文档或后续工作成果发生变更时,要及时更新需求跟踪矩阵。

    需求文档

    (版本,日期)

    设计文档

    (版本,日期)

    代码

    (版本,日期)

    测试用例

    (版本,日期)

    1

    标题或标识符,说明

    标题或标识符,说明

    代码名称,说明

    测试用例名称,说明

    2

     

     

     

     

     


    5.5.2
    需求问题处理

    提示:查找工作成果与需求文档之间的不一致性,分析原因,给出解决措施

    问题描述

    识别人、日期

    解决措施

    结果

    1

     

     

     

     

    2

     

     

     

     

     

     

     

     

     

     

    需求链的概念指的是需求能够上传下达,从客户传达到需求过程,并从需求过程传达到需求过程的下游开发链。而这个传达是可以逆向的。

        需求跟踪提供了一个表明与合同或说明一致的方法。更进一步,需求跟踪可以改善产品质量,降低维护成本,而且很容易实现重用( Ramesh 1998)。

        CMM三级中要求软件团体必须具备需求跟踪的能力:在软件工作产品之间,维护一致性。工作产品包括软件计划,过程描述,分配需求,软件需求,软件设计,代码,测试计划,以及测试过程。

        实际上,创建需求跟踪能力是困难的,尤其是在短期之内会造成开发成本的上升,虽然从长远来看可以减少软件生存期的费用,软件团体在实施这项能力的时候应循序渐进,逐步实施。

        需求跟踪的一种通用的方法是采用需求能力跟踪矩阵。它的前提条件是将在需求链中各个过程的元素加以编号,例如:需求的实例号,设计的实例号,编码的实例 号,测试的实例号。他们的关系都是一对一和一对多的关系。通过编号,你可以使用数据库进行管理,需求的变化能够立刻体现在整条需求链的变化上。

        需求跟踪矩阵并没有规定的实现办法,每个团体注重的方面不同,所创建的需求跟踪矩阵也不同,只要能够保证需求链的一致性和状态的跟踪就达到目的了。

     

     

    6 需求管理环节

    1 需求调研环节管理

    6.1.1 需求调研准备:

    Ø        调研前应该将所有项目前期资料进行汇总,与相关的前期销售人员进行交流,以便对项目有一个基本轮廓的认识。

    Ø        做好调研前使用资料的准备,如需求调研模板,需求调研问题列表等。

    Ø        制定需求调研计划   

    6.1.2 需求调研过程

    Ø        首先提高自己业务知识和熟悉用户的行业,对于人力资源的标准业务应该基本熟悉。

    Ø        需求调研中,学会尽量不使用IT行业的术语。

    Ø        提高自己的总结能力,书写一份完整的、前后一致的、可追踪的需求报告。

    Ø        确定调研方法:根据不同客户的业务特点确定不同调研方法。

    Ø        根据调研方法选择对应的调研分析工具

    Ø        保持一种和客户平等合作的心态,确定需求调研是为了给客户解决问题,探讨问题,而不是接受问题,更不是来指导工作的。

    Ø         

    6.1.3 需求调研总结

    Ø         出需求调研报告

    Ø         客户确认需求调研报告

       

    第2节           需求分析环节管理

    Ø         确定分析工具和分析方法

     

    第3节           需求编制阶段管理

    Ø        确定文档规范

    Ø        解决文档编制中出现的问题

    Ø        制定编制计划

    Ø        出需求文档

     

    4 需求度量阶段管理

    Ø         对需求进行分层,建立层之间的关系,然后对最底层需求进行分解,分解到功能点,然后对各层需求进行编号,度量的目的主要是实现精细化的管理、有效地对项目进行控制,对度量数据的分析用于辅助决策、经验积累、有效评估等。但是度量本身就是双刃剑,一方面度量对于 精细化管理是必要的前提,另一方面度量体系、度量的执行需要花费大量的人力成本,而且如果没有明确的目标和有效的方法来分析和利用这些数据,度量就又陷于 无谓的劳民伤财,成为组织过程的累赘。

    Ø         对需求分级管理,表示需求的优先级: 在每一次产品开发过程中,都会遇到这样一个问题:负责产品需求的领域专家罗列了长长的功能列 表,每个功能似乎都是不可或缺的,而当排出进度表后,却发现工期是公司不能接受的,没办法,必须裁剪需求。没有需求就不会有产品,而没有产品就没有利润。 如果需求过多,反而可能是陷阱——只有投入,没有产出。一个好的项目需求,必须有需求的优先级,便于进行项目的整体平衡。

    Ø         需求分类管理:在做工程项目的时候一定要将需求分出层次,不同层次的 需求侧重点是不一样的,描述的方式是不同的,管理的方式也是不同的。比如说,在企业里高层领导提出来的是目标性需求,中层管理人员提出来的是具体的业务流 程的需求,而作业人员提出来的是更侧重于操作性的需求。对于目标性的需求可能采用简短的几句话就可以描述清楚,但这是项目的决策性需求,需要很稳定,不能 轻易更改,在确定的时候需要慎之又慎。

     

    我把需求分成五个等级。五分等级也是工程技术上的常用方式,如同大学的五分制。

      一级需求(或改变)是关键性的需求,这种需求如果不满足,意味着整个项目不能正常交付使用,前期工作也会被全部否定。这是必须满足的,否则就意味着否定程序员自已。所以定为Urgent.; 这通常是属于补救性的debug类型,要救火。

      二级需求(或改变)是后续关键性需求,它不影响前面工作内容的交付,但不加以满足,新的项目内容无法提交或继续。所以是NECESSARY;一般新模块关键性的基础组件,属于这个级别。

      三级需求是后续重要的需求,它不能满足会令整体工作价值下降,为了体现项目价值,也是程度员自已的技术价值的证明,所以定为NEEDED;一般性的重大的有价值的全新模块开发,属于这个级别。

      以上三个等级是应该实施的,但时间性上可以作优先级的排列。

      四级需求是改良性需求,没有它并不影响已有功能的使用,但实现了,有可信的根据可以是BETTER.界面和使用方式的要求,一般在这个档次。

      五级需求是可选性需求,没有它没有谁会活不下去,有了它,没有根据一定带来好处,更多是一种设想,以及一种可能;通常只是需求代理人员的一种个人喜好。所以是MAYBE

      对于四级需求,工程人员项目有空,不妨做下去;对于五级需求,有兴趣有余力就做,没有兴趣或者没有余力,管他需求不需求,除非额外付大钱,就让提这些外行需求的家为一边凉快去。

     

     

    很多企业的度量陷于盲目,导致了很多负面的影响,进而影响整个组织对项目管理体系的理解和信任。有如下问题和误区存在:

    1.      不清楚组织的需求(到底需要度量什么);

    2.      不清楚度量的用途,认为度量总是有用的;

    3.      度量是不需要花费的或者投入是很小的;

    4.      直接用于考核,忽视了度量的导向作用的两面性(最常见的就是代码行作为程序员的成绩,导致了代码的重用性差,无效代码增多等负面影响);

    5.      在数据分析时孤立分析数据结果,没有考虑相关的度量指标的结果;

    6.      不相信数据,认为数据是没有用的。

    在这里不想介绍什么样的度量体系和方法、度量的技术和流程。仅仅结合度量在实际实施过程中的好的实践列举给大家。对于上述误区有以下实践和经验可以借鉴:

    1.      需要什么才度量什么,从组织的需要、项目的需要、产品的需要、过程的需要以及管理的需要等分析,根据目标来选择测量指标;

    2.      度量必须用于决策并支持决策才有意义,度量必须结合组织的商业目标并为实现这个目标而努力;

    3.      度量是耗时耗力的,因此测量不要花费过多的额外工作量,测量结合在工作过程中,而不是需要额外的工作,可以考虑使用工具,减少度量的成本;

    4.      不要直接用于考核,从积极和正向激励的角度出发来设置度量考核,如果用于考核要结合多个指标,并将数据处理后使用,不能直接使用;

    5.      数据分析要考虑影响因素和相关Metrics

    保证数据的完整正确,并相信数据,如果你不相信它,那它就没有任何意义。 

    5 需求评审阶段管理

     

    6 需求变更阶段管理

    需求变更是因为需求发生变化。根据软件工程思想,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更。

    无论需求变化的程度如何,只 要需求变化了就必须进行评估,这是基本的原则。此外,在一个项目组中必须明确定义一个需求管理员,由他负责整个项目的需求管理工作,确保在发生需求变更 时,受影响的产品能得到修改并与需求的变更保持一致,受影响的其它组也必须与客户协商一致。变化并不是人们最害怕的,最怕的是跟不上变化的步伐。同样,在软件开发过程中需求的变更会给开发带来不确定性,但只要把需求变更作为重点、难点小心加以控制,软件开发的进度、成本和质量也就有了"安全"的基础。     

    这时,如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效,抑或不按变更控制流程来管理需求变更,那么很可能造成项目进度拖延、成本不足、 人力紧缺,甚至导致整个项目失败。当然,即使按照需求变更控制流程进行管理,由于受进度、成本等因素的制约,软件质量还是会受到不同程度的影响。但实施严 格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响,这也正是我们进行需求变更管理的目的所在。

     

    6.6.1 实施需求变更管理需要遵循如下原则:

        1.建立需求基线。需求基线是需求变更的依据。在开发过程中,需求确定并经过评审后(用户参与评审),可以建立第一个需求基线。此后每次变更并经过评审后,都要重新确定新的需求基线。

        2.制订简单、有效的变更控制流程,并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时,这个流程具有一定的普遍性,对以后的项目开发和其他项目都有借鉴作用。

        3.成立项目变更控制委员会(CCB)或相关职能的类似组织,负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成,应该包括用户方和开发方的决策人员在内。

        4.需求变更一定要先申请然后再评估,最后经过与变更大小相当级别的评审确认。

        5.需求变更后,受影响的软件计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。

        6.妥善保存变更产生的相关文档。

      6.6.2 需求变更管理实践中的对策

    需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受,还要增加实施变更和验证两个步骤,有时还会有取消变更的步骤。变更控制流程如图所示。针对变更控制流程,笔者在实际工作中总结出了软件开发人员在需求变更管理实践中的几点对策:相互协作 很难想像遭到用户抵制的项目能够成功。在讨论需求时,开发人员与用户应该尽量采取相互理解、相互协作的态度,对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求,也应该仔细分析原因,积极提出可行的替代方案

    充分交流 需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要 求、考虑和设想,并加以分析和整理。同时,软件开发人员应该向用户说明,进入设计阶段以后,再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。

        安排专职人员负责需求变更管理 有时开发任务较重,开发人员容易陷入开发工作中而忽略了与用户的随时沟通,因此需要一名专职的需求变更管理人员负责与用户及时交流。

        合同约束 需求变更给软件开发带来的影响有目共睹,所以在与用户签订合同时,可以增加一些相关条款,如限定用户提出需求变更的时间,规定何种情况的变更可以接受、拒绝接受或部分接受,还可以规定发生需求变更时必须执行变更控制流程。

        区别对待 随着开发进展,有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影 响的需求。遇到这种情况,开发人员可以向用户说明,项目的启动是以最初的基本需求作为开发前提的,如果大量增加新的需求(虽然用户认为是细化需求,但实际 上是增加了工作量的新需求),会使项目不能按时完成。如果用户坚持实施新需求,可以建议用户将新需求按重要和紧迫程度划分档次,作为需求变更评估的一项依 据。同时,还要注意控制新需求提出的频率。

        选用适当的开发模型 采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建 立一个系统原型,再与用户沟通。一般用户看到一些实际的东西后,对需求会有更为详细的解释,开发人员可根据用户的说明进一步完善系统原型。这个过程重复几 次后,系统原型逐渐向最终的用户需求靠拢,从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。

        用户参与需求评审 作为需求的提出者,用户理所当然是最具权威的发言人之一。实际上,在需求评审过程中,用户往往能提出许多有价值的意见。同时,这也是由用户对需求进行最后确认的机会,可以有效减少需求变更的发生。

     

    1、需求变更的原因分析

      需求变更的表现形式是多方面的,如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中,变更可能来自方案服务商、客户或产品供应商等,也可能来源于项目组内部。虽然需求变更的表现形式千差万别,但究其根本不外乎以下几种原因:

      (1)、范围没有圈定就开始细化

      细化工作是由需求分析人员完成的,一般是根据用户提出的描述性的、总结性的短短几句话去细化的,提取其中的一个个功能,并给出描述(正常执行时 的描述和意外发生时的描述)。当细化到一定程度后并开始系统设计时,范围会发生变化,那细节用例的描述可能就有很多要改动。如原来是手工添人的数据,要改 成根据信息系统计算出来,而原来的一个属性的描述要变成描述一个实体等。

      (2)、没有指定需求的基线

      需求的基线是指是否容许需求变更的分界线。随着项目的进展,需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响,比如软件整体结构 已经设计出来是不容许改变需求范围的,因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展,基线将越定越高(容许的变更将越少),其过程如 下:变更请求à比较基线à变更实现。

      (3)、没有良好的软件结构适应变化

      组件式的软件结构就是提供了快速适应需求变化的体系结构,数据层封装了数据访间逻辑,业务层封装了业务逻辑,表示层展现用户表示逻辑。但适应变 化必须遵循一些松祸合原则,各层之间还是存在一些联系的,设计要力求减少会对接口入口参数产生变化。如果业务逻辑封装好了,则表示层界面上的一些排列或减 少信息的要求是很容易适应的。如果接口定义得合理,那么即使业务流程有变化,也能够快速适应变化。因此,在成本影响的容许范围内可以降低需求的基线,提高 客户的满意度。

      2、如何控制需求变更

      按照现代项目管理的概念,一个项目的生命周期分为启动、实施、收尾三个过程。需求变更的控制不应该只是项目实施过程考虑的事情,而是要分布在整 个项目生命周期的全过程。为了将项目变更的影响降低到最小,就需要采用综合变更控制方法。综合变更控制主要内容有找出影响项目变更的因素、判断项目变更范 围是否已经发生等。

      进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。为保证项目变更的规范和有效实施,通常项目实施组织会有一

      (1)、项目启动阶段的变更预防

      对于任何项目,变更都无可避免,也无从逃避,只能积极应对,这个应对应该是从项目启动的需求分析阶段就开始了。对一个需求分析做得很好的项目来 说,基准文件定义的范围越详细清晰,用户跟项目经理扯皮的幌子就越少。如果需求没做好,基准文件里的范围含糊不清,被客户抓住空子,往往要付出许多无谓的 牺牲。如果需求做得好,文档清晰且又有客户签字,那么后期客户提出的变更就超出了合同范围,需要另外收费。这个时候千万不能手软,这并非要刻意赚取客户的 钱财,而是不能让客户养成经常变更的习惯,否则后患无穷。相对于需求来说,什么WBS、风险管理、计划进度都是次要的,只要需求做好了就会一帆风顺。

      (2)、项目实施阶段的需求变更

      成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念——“需求变更是必然的、可控的、有益的。项目实施阶段的变更控制需要做的是分析变更请求,评估变更可能带来的风险和修改基准文件。控制需求渐变需要注意以下几点:

      需求一定要与投入有联系,如果需求变更的成本由开发方来承担,则项目需求的变更就成为必然了。所以,在项目的开始,无论是开发方还是出资方都要明确这一条:需求变,软件开发的投人也要变。

    需求的变更要经过出资者的认可,这样才会对需求的变更有成本的概念,能够慎重地对待需求的变更。

      小的需求变更也要经过正规的需求管理流程,否则会积少成多。在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低了开发效率,浪费了时间。但正是由于这种观念才使需求逐渐变为不可控,最终导致项目的失败。

      精确的需求与范围定义并不会阻止需求的变更。并非对需求定义得越细,就越能避免需求的渐变,这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的,并非需求写细了,它就不会变化了。

      注意沟通的技巧。实际情况是用户、开发者都认识到了上面的几点间题,但是由于需求的变更可能来自客户方,也可能来自开发方,因此,作为需求管理者,项目经理需要采用各种沟通技巧来使项目的各方各得其所。

      (3)、项目收尾阶段的总结

      能力的提高往往不是从成功的经验中来,而是从失败的教训中来。许多项目经理不注重经验教训总结和积累,即使在项目运作过程中碰得头破血流,也只是抱怨运气、环境和团队配合不好,很少系统地分析总结,或者不知道如何分析总结,以至于同样的问题反复出现。

      事实上,项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容,同时也可以作为对项目合同、设计方案内容与目标的确认和验证。项目 总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结,也包括项目中发生的变更和项目中发生问题的分析统计的总结。

      3、需求变更的处理流程

      需求变更既然不可避免,那么就必须有一套规范的处理流程。对于需求变更的处理流程应该分以下步骤:提出变更à变更评估à实施变更。

      需求变更处理流程

      因为现实世界的软件系统可能有不同的严格程度和复杂性,所以事先预言所有的相关需求是不可能的。系统原计划的操作环境会改变,用户的需求会改 变,甚至系统的角色也有可能改变。实现和测试系统的行为可能导致对正解决的问题产生新的理解和洞察,这种新的认识就有可能导致需求变更。CMM提出分配 需求的变更被复审,并加入到软件项目中来,其关键是在需求发生变更时,没有必要马上把这些变更付诸于软件开发工作之中。实际上,坚持把需求变更付诸开发 努力,企业就会形成一种混乱且不稳定的氛围,进而严重破坏项目的控制和管理。需求管理关键过程试图通过把分配需求的变更囤积到可管理的组中,等到开发工作 允许的时候再引人相应的方法,避免产生这种混乱的氛围。结果,需求管理创建了一个隔绝开发工作与所有真实的、潜在无序的、来自于客户的变更。这个缓冲器允 许真实的变更被注意、记录、追踪,同时开发工作又不会因此而被扰乱。开发项目应该周期性地暂停来吸收最新的需求变更积累,此时,所有的计划、设计、行为都 根据刚刚吸收的需求变更的影响进行更新。

      需求变更的控制当然与项目管理范畴之外的纯技术因素息息相关,比如面向对象的分析、面向对象的设计、面向对象的编码方式等等。但所有技术的发展 趋势都是一样,那就是为了使变更管理变得更容易,因此,不论在项目变更控制中采取什么方法、策略,对于项目本身的变化一定要时时洞悉,处处留意,只有这样 才能从真正意义上对项目进行很好的变更控制。

     

     

    7 需求管理原则

    Ø         从思想上重视、方法上得当:

    Ø         组织好需求管理相关人员和对其职责进行分配

    Ø         需求管理要及时:及时沟通、及时更新、及时评估

    Ø         需求管理要量化:

    Ø         需求管理要可控:

    Ø         需求管理要订立需求基线

    Ø         需求管理要对需求变更进行管理

    8 需求管理工具

    不了解,目前用Excel

    展开全文
  • 轻量级过程改进之需求管理

    千次阅读 2014-11-03 08:29:59
    需求管理在于管理产品研发过程中的客户需求,建立项目相关干系人对需求的共同理解,维护需求与所开发产品之间的一致性,并控制需求的变更。项目启动、项目计划和项目监控等改进域中,客户需求都是我们开发工作的输入...

    需求管理在于管理产品研发过程中的客户需求,建立项目相关干系人对需求的共同理解,维护需求与所开发产品之间的一致性,并控制需求的变更。需求管理的重要性不言而喻,在前面讲到的项目启动项目计划以及接下去要讲的项目监控这几个改进域中,客户需求都是我们开发工作的输入和基础,研发团队存在的意义也是围绕着客户的需求,以满足客户需求、提高客户满意度为工作的目标,项目管理团队更是如此。本文主要阐述在项目需求管理过程中涉及的主要规程、可能存在的问题、分析这些问题并提出相应的改进措施。

    一. 需求管理的规程

    关于需求管理,首先要明确它与“需求开发”之间的区别和联系。虽然很多场景下需求管理和需求开发可能由同一个人或同一个角色来实施,这种现象在小型团队尤为明显,但需求管理和需求开发是两个完成不同的改进域,在综述中我们就提到需求管理是属于项目管理类改进域,而需求开发则属于产品管理;在项目计划中我们也崇尚信息传递的不对称,由项目线来进行需求管理,而由研发线对项目需求进行过滤之后再进行需求开发也是这种思想的体现。在轻量级过程改进系列的上下文中,项目经理负责需求管理,管理的是用户需求;而产品经理负责需求开发,开发的是产品需求,两者所面临的问题以及改进的方法也是不同的,但正是通过需求管理和需求开发,来自客户的信息通过用户需求来到项目线,再通过产品需求转移到研发线,并通过需求跟踪形成了如下的端到端的闭环:


    注意,了解CMMI-DEV模型的朋友可能会发现上面这段描述和这张图与CMMI中的RD、REQM两个过程域中的描述有较大出入:在CMMI中需求调研、需求确认以及用户需求和产品需求的概念都是针对需求开发这个过程域,但这只是说明了需求管理和需求开发应该做些什么事情,而没有说明由谁来做。本文基于下图所示的项目线与产品线的关系,立足于站在项目经理和产品经理的角度上看待需求管理和需求开发这两件事情:


    如上图所示,个人认为由项目经理负责对外的面向客户的诸如需求调研、需求确认等工作;由产品经理来负责对内的面向产品的需求开发工作是合理和高效的。这里面实际上只是一些名词的解释和工作的划分问题,是对CMMI模型的一次裁剪,裁剪的依据是团队的组织结构以及具体项目的实施过程。

    本文关注需求管理工作,需求管理是一项持续性工作,通常包括的规程有:

    1.      需求调研

    • 目的:通过与客户进行直接接触获取来自客户的原始需求,并根据项目实施过程的需要在项目研发启动之后确定该项目中的各项系统需求和客户要求
    • 主要角色:项目经理主导,销售前期可能参与
    • 主要步骤:作为项目实施中的一环,项目经理根据组织级别《调研方案》中的各项调研内容与客户进行沟通并形成项目级别的《调研记录》。调研方案中的部分内容可能已经由销售人员在项目启动之前进行整理并体现在《项目交接单》中,项目经理需要根据销售人员的反馈完善《调研记录》。项目经理就《调研记录》形成初始化的《用户需求说明书》

    2.      需求确认

    • 目的:需求确认的目的在于维护用户和研发团队对用户需求的统一认识,确保在系统交付给用户时,用户和项目经理能够对用户需求的范围和完成情况达成一致,避免用户的个人主观意愿和理解对项目的结果造成影响。
    • 主要角色:项目经理主导
    • 主要步骤:项目经理根据《需求确认单》与用户就已调研完成的用户需求进行确认,《需求确认单》是一种Checklist,供用户和项目经理在用户需求上达成一致。

    3.      需求跟踪

    • 目的:需求跟踪的目的在于根据用户需求,建立和维护用户需求->产品需求->开发测试结果->用户需求之间的一致性,确保产品依据用户需求进行开发。
    • 主要角色:项目经理主导
    • 主要步骤:需求跟踪的途径是建立和维护一份《需求跟踪表》,通常测试人员是产品需求的最终确认者,所以项目经理需要根据测试人员的反馈,并根据产品需求和用户需求之间的对应关系维护《需求跟踪表》中的需求跟踪矩阵。通常产品需求是对用户需求的一种细化,所以需求跟踪矩阵是用户需求和产品需求之间的映射关系。关于产品需求我们将在“需求开发”中进行展开。

    4.      需求变更控制

    • 目的:需求变更控制的目的在于避免范围蔓延和潜变,即控制需求文档的变更,防止发生范围混乱而导致的用户需求确认无法正常进行。需求变更作为项目管理的常见场景,需要通过需求变更管理流程修改原用户需求中的内容,从而产生新的用户需求并付诸于开发。
    • 主要角色:项目经理主导,根据需要销售也可能需要介入
    • 主要步骤:通常需求变更的提出人是用户,项目经理需要根据用户提出的需求变更进行判断和过滤,如果此次变更涉及范围较大,则需要销售人员事先和客户进行沟通和协调并达成在项目合同上的一致;如果变更较小,则项目经理和客户就新的用户需求达成一致之后即可。需求变更的结果是形成新的用户需求,上述的需求调研、需求跟踪和需求确认都可能需要同步更新。需求变更控制的依据是《用户需求说明书》。

    二. 需求管理中的问题

    需求管理是项目范围管理的核心,通常用户需求与项目计划组成项目管理三角形中最重要的范围和时间管理这两个维度。在系统研发过程中,需求作为研发工作的源头发挥其重要作用,很多研发过程中的问题都是由于需求不明确或需求管理不当所造成,需求管理中典型的问题有:

    1.      需求调研不充分

    需求调研也是一项流程性工作,在每个项目启动之后、研发工作开展之前需要确保进行需求调研。在实际操作过程中,作为用户需求来源的一部分,项目经理团队都认为需求调研是一项必要的工作,但往往缺乏足够的重视和投入导致调研不充分,从而为后续的研发工作埋下隐患。需求调研不充分体现在缺少标准化的调研方案,缺少有效的调研信息保存和传递机制等。

    2.      没有区分用户需求和产品需求

    需求管理如同项目计划一样,需要在项目线和产品线之间形成信息过滤,过滤的结果就是形成面向用户的用户需求和面向产品的产品需求。如果没有区分用户需求和产品需求,把用户需求直接抛给研发团队、或者把产品需求直接交与用户确认都是不合适的。同时,根据本文第一部分提到的产品线与项目线的关系,用户需求和产品需求的混淆会导致无法确立正确的产品线。

    3.      无法建立需求跟踪机制

    用户需求和产品需求进行区分之后,势必要建立完善的需求跟踪机制维护用户需求和产品需求之间的双向跟踪关系,从而确保用户需求信息和产品需求信息都能得到跟踪和反馈。缺少需求跟踪机制会导致需求信息失去透明性,并引起由于信息传递过程所导致的不必要沟通成本和不理想的沟通效果。

    4.      缺乏需求确认规范

    需求确认面向客户,需要建立正式统一的工作规范。项目管理中涉及客户参与的部分都是应该形成规范的,需求确认作为用户需求管理的组成部分,需要在客户和研发团队之间达成一致。如果缺乏需求确认规范,需求的范围和完成情况无法得到客户的认可,导致客户对系统交付不满意无疑会影响到整个研发团队的工作。

    5.      需求变更缺乏统一流程
    需求变更不可避免,也并不可怕,需要考虑的是一旦产生需求变更,如何通过一个统一流程来应对需求变更,从而使客户、项目经理、研发团队都能对该需求变更达成统一认识并形成新的项目范围,确保后续需求跟踪和系统验收的正确执行。如果各个项目没有形成统一的需求变更控制流程,则来自各方的需求变更势必导致项目线的各自为政以及产品线的工作混乱。

    三.需求管理的过程改进

    如果一旦形成工作模式,需求管理相比项目计划会简单一点,对需求管理过程改进的切入点包括:

    1.      关注需求生命周期

    需求本身是有其生命周期的,但根据不同的项目线和产品线的关系,可能会形成不同的表现形式。根据已有产品线功能作为一个起点,通过需求调研进一步明确用户需求,完成需求确认并进行用户需求和产品需求的转化,进行需求跟踪是本文中提到的需求生命周期。关注需求生命周期是进行过程改进和裁剪的基础,如果团队的需求生命周期表现形式有所不同,自然其管理方式也应该有所不同。

    2.      关注需求信息传递

    个人认为信息透明是研发管理的核心,需求管理也不例外。很多项目上的问题和研发过程中的问题都是和信息传递的效果有直接关系。如何使用一定的沟通媒介和模式确保信息透明同样是需求管理工作所需要关注的一个方面,通过使用电子化、高效的信息管理系统是需求管理的一个有效切入点。

    3.      关注客户参与

    需求管理具有对内、对外两面性,其中对外的需求调研、需求确认都与基于客户管理,毕竟我们的系统最终是要交付和客户的。如何让客户能够尽量多的参与到需求管理的过程中,确保客户支持并积极配合需求调研等活动,需要项目经理和销售人员确保客户参与到需求管理过程中来,尽量保持客户的思路与我们保持一致。

    4.      关注流程规范化

    需求管理与后续的需求开发不同,需求管理会更多的偏重于流程性工作,需求调研、需求变更、需求确认等都需要流程的支持和约束,不建议各个项目有自己的工作方式,而应该强调统一和规范。流程的规范化需要过程资产建设作为支持,也需要管理理念的转变和加强。

    针对上述切入点,我们梳理需求管理过程改进的模式和实践包括:

    1.      建立用户需求和产品需求同步机制

    用户需求面向客户和项目,但用户需求即是产品需求的输入也是产品需求的输出。结合本文中提到的项目线/产品线关系,产品线需要项目线作为输入,反过来产品线也为新的项目提供系统功能的基本范围,两者之间需要建立同步机制才能确保需求管理的高效性和时效性,建立产品核心工作小组和产品平台通常是一项好的实践。产品核心工作小组负责产品需求的设计和开发并根据产品平台版本发布系统的产品需求,项目线根据产品需求和项目具体要求形成用户需求;另一方面,项目线收集项目需求并提交给产品核心开发小组确保其能够根据产品平台的建设需要进行需求的梳理和过滤。用户需求和产品需求同步机制能很大限度协助和完善需求管理工作。需求开发和产品平台属于产品管理范畴,关于产品管理我们将在后续系列文章中进行阐述。

    2.      使用电子化信息管理平台

    确保使用电子化信息管理平台进行需求的跟踪。需求跟踪的表现形式可以是一张简单的需求跟踪表,但需求跟踪表中的内容来自于研发团队日常的研发成果,如果没有高效和透明的信息化管理工具,则统计这些研发成果将是一件成本很高的工作。目前业界主流的项目管理工具都一定程度上支持需求的管理和跟踪功能,这里个人推荐Redmine作为团队的电子化信息管理平台。关于Redmine可参考我的博客:《研发范围和时间的“信息透明化”之Redmine统一平台》

    3.      确立配置管理理念和流程

    讲到需求管理就离不开配置管理。需求管理,尤其是变更管理是配置管理中的一个重要组成部分。配置管理中的配置项、基线、版本控制、状态报告等具体活动都应该引入到需求管理过程中来。通过建立粒度合适的基线,并执行变更控制的流程,确保版本控制在需求开发和系统实现中的实现来确保项目各方干系人都能对需求有一致的认识,并能够进行系统更新日志等的管理从而支持需求追述和反馈。

    4.      使用Checklist
    Checklist是一种简单但很实用的工具,在项目管理中很多地方都可以使用Checklist进行非正式的评审或信息同步,在需求管理过程中也能用来进行需求的控制:需求的调研可以预设需求调研项作为调研方案的一部分;需求的确认同样可以使用Checklist为客户和项目经理自身提供简单的确认结果。Checklist通常表现为语义明确的选择项或是否项,也可以根据具体需求进行灵活调整其表现形式。

    四. 需求管理的过程资产

    1.      调研方案

    调研方案主要包括以下要点:

    • 需求调研的范围说明,调研范围来自于项目启动过程中的项目范围描述
    • 需求调研的目标说明,确保客户方和项目经理都能明确调研的目的
    • 需求调研的计划说明,调研的主要工作计划安排
    • 需求调研的提纲,根据具体项目可能包括系统软硬件环境、系统集成的需要、具体业务逻辑的调研等,推荐采用Checklist形式进行组织

    2.      调研记录

    调研记录主要包括以下要点:

    • 项目基本信息
    • 调研的干系人和调研的方式,如访谈、正式的会议等
    • 调研内容,根据调研方案展开的具体调研项和结果

    3.      需求跟踪表

    需求跟踪表主要包括以下要点:

    • 用户需求和产品需求的映射关系,可以采用表格或矩阵的形式进行组织,通常确保用户需求的粒度要大于产品需求
    • 需求问题,对需求跟踪过程中的进度、范围等问题进行记录和处理

    4.      需求确认单

    需求确认单主要包括以下要点:

    • 用户需求的提纲性表述,具体的用户需求可以放在《用户需求说明书》中
    • 用户需求的完成情况整理
    • 用户需求承诺,典型的承诺方式如下:

    本需求文档建立在双方对需求的共同理解基础之上,我同意后续的开发工作根据该需求文档开展。如需求发生变化,我们将按照“需求变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。
    甲方负责人签字
    乙方负责人签字

    5. 用户需求说明书

    用户需求说明书主要包括以下要点:

    • 系统整体介绍
    • 系统功能性需求,包括界面风格、各个功能模块和功能点介绍
    • 系统非功能性需求,包括软硬件环境、质量要求等

    五.小结

    需求管理是项目管理的第三个改进域,相比其他项目管理过程而言,需求管理通常不能独立进行,而需要与产品管理中的需求开发等过程配合实施。本文中的需求管理偏向于用户需求管理,管理用户需求从项目到研发团队再到项目的一个闭环过程。作为研发工作的一种源头,需求管理通常要从过程改进的角度对其进行分析从而确保后续产品需求开发和研发工作的顺利展开。由于需求管理与需求开发关系比较紧密,下一个改进域我们讨论产品管理中的需求开发。

    展开全文
  • 产品需求管理——需求收集

    千次阅读 2014-05-23 22:57:56
    前言: 需求收集sh
  • 禅道需求管理规范

    万次阅读 多人点赞 2017-03-21 14:39:13
    需求管理规范 2 4.1 需求管理流程 2 4.2 需求开发指引 3 4.3 需求录入规范 6 4.4 需求评审规范 7 4.5 需求计划规范 7 4.6 需求关闭规范 7 4.7 需求变更 8 1版本记录 2目的 目前存在需求描述不明确,录入、评审不...
  • 文章概括为,纵向,横向,从面到点,最后是需求质量控制。...这个步骤是对用户业务需求的一个升华,是一个把用户业务管理流程优化,转化为软件产品,从而提升管理而实现的质的飞跃,这一步是否成功,直接关系
  • 如何做到项目准时交付之需求管理

    千次阅读 2018-12-02 12:10:16
    很多人可能都还不明白需求分析和需求管理之间的区别,通常我们说起来最多的都是需求沟通和需求分析,开会都是讨论需求如何如何做,这其实是需求分析的过程如何如何,而与需求有关的其他活动提及的比较少。...
  • 产品研发过程是不断迭代的过程,发生需求变更、设计变更的情况非常多,需要系统的管理变更。 1 产品变更管理方案 1.1 产品变更的原则 变更管理的原则是产品基准化、变更管理过程规范化,妥善保存变更所产生的相关...
  • [项目管理] 项目管理之需求管理

    千次阅读 2013-02-08 15:32:53
    一、需求管理的定义需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。需求可以定义为:系统必须符合的条件或具备的功能。需求管理可以定义为:需求管理是一种系统化方法,可用于获取、组织和记录...
  •  需求获取可能是软件开发中最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往错误的认识:用户知道需求是什么,我们所要做的就是和他们交谈从他们那里得到需求,只要问用户系统的目标特征,什么...
  • 国内外需求管理工具使用感悟!

    万次阅读 2015-07-09 10:41:52
    需求管理(REQM,Requirements Management)属于成熟度2级(受管理级)的过程域,是其他许多过程域实施的前提。对于暂未实施CMMI的企业,同样也可以借鉴CMMI的原则,实施和优化需求管理。 许多IT企业都过需求失控...
  • 软件需求变更管理

    千次阅读 2016-12-27 14:17:41
    在实际的软件开发过程中,需求变更是在所难免的,但是频繁的需求变更常常会导致整个项目开发的失败。在软件开发过程中唯一的不变就是改变...- 取消需求变更过程管理一旦发生需求变更,不得不修改对应的文档、修改设计、
  • Telelogic DOORS 是世界领先的需求管理工具;它通过改进需求沟通与协作,可以最大限度地提高业务流程优化工作的价值以及系统工程和软件开发项目的质量。DOORS 特别适合在同一地理位置工作的组织和在同一地理位置处理...
  • 考勤管理系统需求文档

    万次阅读 2016-01-07 09:30:36
    考勤管理系统需求文档 简介 背景  某软件公司,员工人数100人左右,大部分员工是软件研发人员,包括项目经理、软件设计师、程序员、测试工程师、实施工程师等,除此之外还包括行政人员、财务人员。公司在软件研发...
  • 医院信息管理系统需求分析

    万次阅读 多人点赞 2019-10-04 01:44:22
    需求说明文档描述了医院管理系统项目的要求,作为系统设计、项目目标以及项目验收的依据。需求分析详细描述了用户对功能的需求、对性能的需求以及对运行环境的需求。 软件开发小组的每位成员应该阅读本需求说明,...
  • 需求收集对于产品经理来说,都已经属于老生常谈了。在产品的立项和设计前需要先做需求调研,在这里我们就来谈谈如何进行需求收集和管理。 一、需求收集目的 需求收集的目的就是了解用户目前所需要的是什么,...
  • 酒店管理系统需求分析

    千次阅读 多人点赞 2019-06-19 20:32:00
    酒店管理系统需求分析 1引言 随着市场经济的发展,消费者消费意识的提高,酒店行业的竞争...用户希望通过使用酒店客房管理系统得到所需信息,达到提高管理水平的目的,希望新系统具有以下功能: 使用计算机...
  • ERP仓库管理系统需求

    万次阅读 2018-06-30 10:26:43
    ERP仓库管理系统需求 目录 1.系统管理... 2 2.供货管理... 12 3.仓库管理... 24 4.出货管理... 27一:系统管理1. 输入账号、密码进入系统功能:可能出现以下情况:1.1账号或密码错误,或者员工已经辞职离开: ...
  • 需求变更管理需求的可追溯性

    千次阅读 2017-01-05 23:02:01
    在项目管理过程中,总是难免会碰到需求的变更,需求变更之所以会产生,可能是用户不能清晰描述需求或对需求也不是特别明确,也可能是开发人员对需求理解与用户不一致,或者是用户需求确实更改,或者是遇到其他外部...
  • 软件需求管理平台之oBridge诞生    -李成功 1 软件需求管理应用平台 1.1引言 作为一位软件企业
  • 项目管理 : 需求管理的6个流程

    千次阅读 2019-06-11 21:45:42
    1.问题分析 问题分析可以通过了解问题及涉众的最初需要,并提出高层解决方案来实现。它是为找出“隐藏在问题之后的问题”而进行的推理和分析。问题分析期间,将对“什么是面临实际问题”和...需求来自各个方面,比...
  • 图书馆管理系统需求规格说明书

    万次阅读 多人点赞 2014-11-06 13:07:14
    文档信息:图书馆信息管理系统软件需求规格说明书 文档类别:管理文档 密 级:机密 版本信息:1.0 建立日期:2014-05-20   创 建 人: 审 核 者: 批 准 人: 批准日期:   编辑软件:Microsoft Office ...
  • 学生管理系统需求分析

    万次阅读 2019-10-05 10:22:49
    1.导言 1.1 编写目的 本文档描述了学生管理系统的功能和性能的要求,将作为对该...并没有涉及,而主要是通过建立模型的方式来描述用户的需求,为客户、用户、开发方等参与方提供一个交流的平台。 1.3 参考资料 [...
  • 【DOORS】如何基于DOORS实施需求管理

    千次阅读 2017-04-13 10:50:40
    IBM Rational DOORS,简称DOORS,是被业界广泛认可的需求管理工具,在国内外需求管理领域具有较高的市场占有率。需求管理作为传统的工程领域,理论发展相对成熟和健全。随着越来越多的企业开始注重在需求管理工程...
  • 产品经理如何有效进行需求管理?

    千次阅读 2020-01-19 16:47:40
    但是需求又是整个项目能否成功的决定性因素,所以我们必须对需求进行管理,从而使需求成为整个软件工程的基线。使得所有产品、设计、研发、测试、运维工作能围绕着统一的需求开展。保证项目能顺利进行,完成目...
  • 一切伟大产品的实现都是从需求管理开始的。敏捷开发中的需求管理大致分为三个阶段:需求调研,需求分析和需求确认。 需求调研阶段 产品立项后,产品经理便开始了和需求打交道的漫长过程。第一步就是需求的调研工作...
  • 需求开发与管理过程(个人笔记)

    万次阅读 2013-10-18 17:41:28
    软件需求工程包括了需求开发和需求管理两个部分,需求开发的目的是通过调查与分析,... 需求管理的主要活动包括:需求确认,需求变更和需求跟踪控制。 1. 需求获取 需求获取的目的是通过各种途径获取用户的需求信息,
  • 学籍管理系统的需求分析

    千次阅读 2013-06-20 09:29:12
    首先说说系统需求分析的过程,这个过程设计到的人员用户、需求分析人员、软件开发人员。  需求分析看似很简单,其实不然,需求...为了克服可能出现的问题,必须组织地进行需求分析阶段的各项活动。 1系统的
  • 需求管理工具DOORS应用总结

    千次阅读 2009-04-01 15:33:00
    "DOORS"逐渐为我们的需求,设计,以及测试管理打开了多扇门。在使用DOORS之前,项目组主要使用WORD对需求进行管理,... 经过质量管理部同事给我们一天的集中培训,我们对DOORS了初步的了解,当时感觉是DOORS的文档编

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 513,271
精华内容 205,308
关键字:

以下属于需求管理活动的有