需求管理_需求管理工具 - CSDN
精华内容
参与话题
  • 需求开发与需求管理

    千次阅读 2013-08-31 22:04:43
    需求开发与需求管理概述   在我看来, 项目管理的日常活动包括了:需求管理、故障管理、版本管理、任务管理。   需求管理贯穿了项目的大部分生命周期,故障管理则从第一个迭代版本出现直到产品维护阶段(包括内部...
     需求开发与需求管理概述
           在我看来, 项目管理的日常活动包括了:需求管理、故障管理、版本管理、任务管理。
           需求管理贯穿了项目的大部分生命周期,故障管理则从第一个迭代版本出现直到产品维护阶段(包括内部故障与外部故障)结束。
            所以:需求驱动开发,需求是开发的上游。
           在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级更详细、严格,并且在实施管理是更强调了解过程活动之间关系、过程的详细度量值以及过程的工作产品和服务。
     
     
     
     
     
     
     
     
     
    展开全文
  • 如何进行需求管理

    2016-04-08 15:29:33
    需求管理源于业务需要,始于需求挖掘,继而需求分析,需求定义,需求验证。周而复始。一,业务需要说明需求产生的原因,可能是高层制定的目标,中层对工作流程的调整,基层碰到无法解决的问题,用户需要,外部环境...
    ——https://www.zhihu.com/question/19844142
    需求管理源于业务需要,始于需求挖掘,继而需求分析,需求定义,需求验证。周而复始。
    一,业务需要说明需求产生的原因,可能是高层制定的目标,中层对工作流程的调整,基层碰到无法解决的问题,用户需要,外部环境变化,竞争对手策略变化或者政府政策调整等。
    需求人员在明确业务需要时,首先明确干系人,其次获取干系人要求/需求。可以采用的方法包括:行业基准(竞品),业务规则分析(产品分析),头脑风暴,焦点小组,功能分解,根源分析等。

    二,需求挖掘阶段的目标是找出干系人的真实需求。单方面的口头描述或者规范章程都可能与实际需求相差甚远,因此需要需求人员收集各方面需要,交叉验证,合理推导,发掘出用户的实际需求。
    工作步骤:确认干系人,收集实际情况,整合多方面信息,确认实际需要。方法包括:访谈,观察,问卷,焦点小组,头脑风暴,可用性测试,竞品分析,数据分析,文档分析,咨询专家等。

    三,需求分析阶段则是对已经收集的真实需求进行规整,包括两部分内容,组织整理需求和对需求排优先级。
    组织整理需求采用相同粒度描述需求,并描述需求间关系。主要方法包括:功能分解,业务规则分析,数据模型,流程模型,范围模型,用户经历,场景和用例,组织模型。
    需求优先级划分通过定义需求的优先级,为计划安排提供有价值的参考。可以参考的定义维度包括:时间,预算,业务价值,业务和技术风险,实施难度,成功可能性,规范和政策,与其他需求的关系,与干系人的协议,紧急程度等。可采用3/4级优先级定义,或者MoSCoW模型定义,其中M=必须 S=应该 C=能够W=将要。

    四,需求定义主要工作为根据前期整理的相关文档整理需求说明。输出包括:业务需要,需求陈述,组织整理后的需求以及需求优先级。需求说明主要包括:业务需要,业务需求和系统需求。
    ·
    五,需求验证包括需求检验和需求确认,即需求过程中的检查和需求完成的测试。
     
    需求管理从我工作的总结来看有以下几点
    1.客户的需求,
    从客户角度找到产品的核心的功能和用途,分析出客户对产品的要求的模型,最关注和重视的是哪些功能,并且从现有的数据和反馈中筛分出真正的客户需求,而不是从客户反馈简单判断客户是不是要这个东西,喜欢和讨厌某个功能,为什么喜欢和讨厌。。。以及客户的“建议”也需要去分析和判断。

    2,公司的需求,
    包括公司的商业规划,盈利的方式,盈利指标等等,以及公司高管和其他部门对产品的界面、功能、流程一些理解和要求。
    3,其他部门的需求

    其他部门对产品的工作量,技术门槛,资源是否满足等,以及产品项目对他们本身的利益等需求。
    4,同部门需求
    同部门对该产品的认识和想法、建议,是否配合以及利益影响。

    所有需求都是要经过反复筛选,并辨别出真正的答案,才是能给产品设计与开发,运营提供清晰的方向方法。对需求的分析是要不断追问为什么
     

    需求跟踪矩阵是个好东西,可以在需求分析阶段产出。


    展开全文
  • 1、Feature List:需求特性列表,日常的需求管理,管理好了,治大国如烹小鲜,管理不好,每时每刻被动煎熬。 2、Feedback List:反馈列表,各个渠道反馈的问题记录,可能有用户的骂声,Thats Great!,用户的痛点...

    对于PM来说,要管理好需求,离不开四个层面的列表管理。

    这里写图片描述
    1、Feature List:需求特性列表,日常的需求管理,管理好了,治大国如烹小鲜,管理不好,每时每刻被动煎熬。

    2、Feedback List:反馈列表,各个渠道反馈的问题记录,可能有用户的骂声,Thats Great!,用户的痛点出现了!维护好反馈列表,有可能会转化为需求。

    3、Bug List:缺陷列表,自己经常把玩产品过程中遇到的Bug记录或者交互异常问题,严重则进行立即修复Hot Fix发版,不严重下个版本顺带解决,当然也可以使用TAPD、禅道进行管理。

    4、Version List:版本列表,每次发版内容记录,版本新特性记录。Review每次发版,进行功能效果评估。

    这里写图片描述

    本次主要简述用户需求管理中的Feature List,需求功能管理:

    现实中关于需求管理会出现很多问题,诸如:

    • 需求跟着跟着跟丢了,没有记录导致的
    • 需求开发周期长,需求忘记了,没有记录导致。
    • 需求来源渠道不明,没有记录导致。
    • 需求太多、太复杂了,无从下手,没有树立需求池的概念。

    明白了没有记录就没有发生,就很难再出现扯皮的现象了,显然需求的记录和管理是很重要的,这是产品的基础能力。

    需求的来源也是很广泛的,诸如:

    • 来自用户研究、调研、访谈的
    • 来自数据分析的,数据驱动产品迭代
    • 来自Boss的
    • 来自市场部、商务部的
    • 来自运营团队的
    • 来自各个渠道的用户反馈的
    • 来自脑暴峰会的
    • PM自己想做的等等….

    可见需求来源太多了,先不说如何辨别需求的真伪,单纯的管理需求似乎就成了问题。

    那么,如何真正意义上的进行需求管理呢?

    需求管理应该分为三个层次,需求侧、技术侧、运营侧,需求的管理包括:需求策划管理、需求实现管理、需求效果评估管理。停留在需求侧是大部门产品经理的现状,兼顾技术侧的,有点偏重项目管理的角色,协调运营侧的,是产品负责人的角色,可以调动周围几乎所有资源,达成某种使命,这样的产品经理就慢慢的靠近CEO了,渐渐有了使命感,领袖的诞生就藏在表格里,潜移默化着每一位产品经理,看你能管到哪里…

    这里提供一份相对完整的需求管理基础架构(排除第三方管理工具,仅供参考)
    这里写图片描述

    首先

    需求侧管理:

    这里写图片描述

    1、需求编号:需求的编号,方便在需求池里管理检索查询需求。

    2、需求涉及端口:移动端、PC端、Web端、微信小程序、支付宝生活号等。当业务复杂时,或者产品经理负责的端口较多时,这种需求管理是很高效的。

    3、需求主要模块:基于端口下的模块,比如移动端下的、首页、我的、消息、发现、等。

    4、需求子功能:基于主要模块下的子功能,比如消息模块,涉及系统消息、内部IM消息、评价消息等。

    5、需求详情:需求真实意图描述,如果是比较简单、不复杂的小需求,直接描述要解决什么问题。如果不是小需求,则不仅需要描述要解决什么问题,还要把为什么要解决问题的原因一并记录下来。(解决问题的原因,多数情况下需要产品汪刨根问底的去问,去了解实际上用户的需求到底是什么和想解决怎样的用户需求)

    6、需求来源:刚才我们已经说明了需求的几点来源,不再赘述。

    7、需求类型:需求的类型每个公司都不一样,一般来说需求类型主要是记录此类需求属于哪一个类别的,主要需求类型有:新增功能、功能改进、体验提升、BUG修复等。

    8、需求优先级:需求的优先级有很多种,P1、P2、P3、P4等;高、中、低等,自己能看懂就行。

    9、需求版本号:需求规划的版本号,产品的最高发版权限。

    技术侧协调:

    PM这个词产品经理和项目经理共用,当公司没有项目经理,或者需要产品进行时间进度管理时,显然产品的责任就上了一层,产品负责人,需求的策划管理层次完成后,开始执行你的实现落地管理。

    这里写图片描述
    10、预期时间:预估上线的时间,这个时间对高层的领导来说很重要的,有的领导有明确的deadline,那就必须记录清楚,并执行到位。

    11、PRD:产品经理开始协调交互设计师,讨论需求,进行PRD落地。

    12、UI:确定PRD后,将文档同步给UI,将设计师进行输出UI设计稿。

    13、SRV:后台组拿到PRD,进行数据库创建、预研实现方案等。

    14、iOS: iOS和安卓都属于前端FE,管理之所以分开,是因为每个公司技术储备资源都不一样,两个前端研发进度也会有差异性,所以分开管理。

    15、Andriod:同上

    16、QA:进行测试验收,质控管理。

    17、发布状态:预估什么时候能达到发布状态,这个预估也非常重要,一个人预估能力是否准确,也间接说明了他对产品、交互、设计、前端、后端、测试等整个团队职能的深度理解。

    18、上线时间:上线前还要进行ShowCase,进行一轮生产环境测试,将相关人员拉到大会议室,进行全员找茬,很管用。上线后记录上线时间,进行时间存根留底。

    运营侧协调:

    这里写图片描述
    运营侧的需求协调主要涉及数据、内容、和渠道发布的管理。

    19、产品运营:上线前后的数据分析,及汇报,产品经理需要知道一手的数据信息,要保证数据信息渠道畅通,并协调运营分析结果,挖掘潜在的用户行为,驱动产品方向,懂技术的产品可以了解可视化数据以外的细节数据,动用结构化查询语言SQL操控数据库里的每一个死角,(产品懂技术,无疑于流氓会武术)。

    20、内容运营:上线前后的内容供给,产品涉及的图片、文案、信息、案例等都需要在需求开发阶段协调内容运营资源进行整理输出,作为需求目标达成有力支撑。

    21、渠道运营:渠道运营除了ASO、新增、活跃、下载,传包外,还有收集渠道侧的用户反馈,及提供渠道侧的具有参考意义的数据信息,产品上线前后需要和其了解需求方向上的信息,以便输出新的决策。

    需求的管理贯穿整个团队,所以产品的需求管理不只是需求的记录,而是需求的策划、实现、效果评估都需要。每个产品经理的需求管理方式可能都不尽相同,适合自己的方法论才是最好的,但是需求管理的好坏、管理能力的强弱是一眼能看出来的,至于我们想治大国如烹小鲜,还是每时每刻被动煎熬,就要看我们的需求管理能力了,优秀在路上,慢慢培养吧…

    展开全文
  • 项目管理 : 需求管理的6个流程

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

    1.问题分析

    问题分析可以通过了解问题及涉众的最初需要,并提出高层解决方案来实现。它是为找出“隐藏在问题之后的问题”而进行的推理和分析。问题分析期间,将对“什么是面临实际问题”和“谁是涉众”等问题达成一致。而且,您还要从业务角度界定解决方案,以及制约该解决方案的因素。您应该已经对项目进行过商业理由分析,这将便于您更好地预计能从构建中的项目中得到多少投资回报。

    2.理解涉众需要

    需求来自各个方面,比如来自客户、合作伙伴、最终用户或是某领域的专家。您需要掌握如何准确判断需求应来源于哪方面、如何接近这些来源并从中获取信息。提供这些信息主要出处的个人在本项目中称为涉众。如果您正在开发一个在您公司内部使用的信息系统,那么在开发团队中应包括具有最终用户经验和业务领域专业知识的人员。通常讨论将在业务模型这一级上展开,而不是在系统这一级上展开。如果正在开发一个要在市场上出售的产品,那么您可以充分调动营销人员,以便更好地了解该市场中用户的需要。获取需要的活动可使用这样一些技巧:访谈、集体讨论、概念原型设计、问卷调查和竞争性分析等。获取结果可能是一份图文并茂的请求或需要列表,并按相互之间的优先级列出。

    3.定义系统

    定义系统指的是解释涉众需求,并整理为对要构建系统的意义明确的说明。在系统定义的初期要确定以下内容:需求构成、文档格式、语言形式、需求的具体程度(需求量及详细程度)、需求的优先级和预计工作量(不同人在不同的实践中通常对这两项内容的看法大不相同)、技术和管理风险以及最初规模。系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型。系统定义的结果是用自然语言和图解方式表达的系统说明。

    4.管理项目规模

    为使项目高效运作,应仔细根据所有涉众的需求确定优先级,并对项目规模进行管理。有的开发人员仅仅重视所谓的“复活节彩蛋”(即开发人员感兴趣或觉得有挑战性的特性),而不是及早将精力投入降低项目风险或提高应用程序构架稳定性方面,这已使太多的项目蒙受损失。为确保尽早解决或降低项目中的风险,应以递增的方式开发系统。要慎重选择需求,以确保每次增加都能缓解项目中的已知风险。要达到目的,您需要和项目的涉众协商每次迭代的范围。通常,这要求具备管理项目各个阶段的期望结果的良好技能。除了控制开发过程本身,您还需控制需求的来源,并控制项目可交付工件的外观。

    5.改进系统定义

    系统的详细定义应能让涉众理解、同意并认可。它不仅需要具备所有功能,而且应符合法律或法规上的要求,符合可用性、可靠性、性能、可支持性和可维护性。感觉构建过程复杂的系统就应该有复杂的定义,这是一种常见的错误看法。这会给解释项目和系统的目的造成困难。人们可能印象深刻,但他们会因不甚理解而无法给出建议。应该致力于了解您制作的系统说明文档的读者。您可能常会发现需要为不同的读者准备不同的说明文档。

    我们认为用例方法是传达系统目的和定义系统细节的一种行之有效的方法,它常与简单的可视化原型结合使用。用例有助于为需求提供一个环境,利用它可生动地说明系统使用的方式。

    系统详细定义的另一个构件是说明系统采用的测试方式。测试计划及要执行测试的定义将会说明要核实哪些系统功能。

    6.管理需求变更

    定义需求时无论怎样谨慎小心,也总会有可变因素。变更的需求之所以变得难以管理,不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性,而且也因为对某个需求的变更很可能影响到其他需求。应确保赋予需求一个有弹性的结构,使它能适应变更,并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系。管理变更包括建立基线、确定需要追踪的重要依赖关系、建立相关项之间的可追踪性,以及变更控制等活动。

    展开全文
  • 大规模敏捷需求管理

    千人学习 2019-06-26 11:44:34
    课程介绍一个具有操作性的大规模敏捷需求管理方案。这个方案平衡需求运作的灵活性和规律。方案包涵大型需求管理各环节,从需求价值分析需求,决策、可视化、度量、验证、等。如果你团队或组织面临需求管理的挑战,...
  • 需求管理

    千次阅读 2018-12-19 09:57:55
    本文阐述了信息系统项目的需求管理需求管理在信息系统中的目的是确保项目各方对需求的一致理解,管理和控制需求的变更,实现从需求到最终产品的双向跟踪。在本项目中,我重点关注以下几个方面的需求管理工作。  ...
  • 需求管理进阶

    2020-07-22 11:19:10
    需求管理的第一要务就是要将这些伪需求排除,只做确定性的需求。 需求管理有三大任务:需求收集,需求细化以及需求管控 需求收集(业务分析): 需求一般由业务人员或者产品经理提出。我们经常发现绝大多数人提...
  • 对项目需求管理的认识和体会

    千次阅读 2018-06-12 17:33:55
    下面是对一位项目经理关于需求管理的访谈: 做了那么多个项目,我深深感到对项目的需求把握管理好了,是项目成功的关键。对需求的管理大概有那么几个活动,首先是需求获取,这是一个确定和理解客户的需要和期望的...
  • xx产品需求管理 说明 本需求管理针对xx产品开发,范围包括新增需求和需求变更。 需求管理工具 Jira 需求新增/变更流程 状态 转换条件 下一状态 处理人员 备注 open 打开 ...
  • 国内外需求管理工具使用感悟!

    万次阅读 2018-08-06 16:40:57
    需求管理(REQM,Requirements Management)属于成熟度2级(受管理级)的过程域,是其他许多过程域实施的前提。对于暂未实施CMMI的企业,同样也可以借鉴CMMI的原则,实施和优化需求管理。 许多IT企业都有过需求失控...
  • osrmt(开源的需求管理工具)的截图

    千次阅读 2007-01-17 10:00:00
    http://www.osrmt.com/gpage4.html 看上去很不错,有时间下来看看 
  • 网站后台管理系统需求分析 一、 功能列表: 1. 后台管理员登录 2. 超级管理员对普通管理员的注册功能 3. 登录日志记录功能 4. 管理管理管理员信息的增删改查) 5. 权限设置 二、 超级管理员登录...
  • 我说CMMI之七:需求管理过程域

    千次阅读 2010-10-19 19:39:00
    我说CMMI之七:需求管理过程域先讲讲需求管理的含义。何谓需求管理需求管理就是管理需求的一致性。这里讲的需求指什么?指的产品与产品构件需求,对于软件而言通常就是软件需求规格说明书(SRS)。在CMMI模型中将...
  • 禅道项目管理软件配置及使用教程

    万次阅读 多人点赞 2018-05-30 17:33:41
    它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体,是一款专业的研发项目管理软件,完整覆盖了研发项目管理的核心流程。禅道将产品、项目、测试这三者的概念明确分开,产品人员、开发团队、...
  • 学生宿舍管理系统之需求分析

    千次阅读 2018-11-01 22:43:06
    第二章 需求分析 1.需求分析的任务  需求分析的任务是调查应用领域,对应用领域中的信息要求和操作要求进行详细分析,形成需求分析说明书。重点是调查,收集与分析用户在数据管理中的信息要求,处理要求,数据的...
  • 需求分析:需求调研的七种方法

    万次阅读 2016-12-21 10:48:31
    需求获取一般包括这几种方式:观察法、体验法、单据分析法、报表分析法、问卷调查法、访谈法、需求调研会法。这是需求调研的“七种武器”,它们各有优缺点,无论你想要了解的是什么需求,都需要将这些方式组合应用,...
  • 需求分析师面试 思路

    万次阅读 多人点赞 2010-06-19 11:21:00
    1.需求调研前需要做哪些准备? 从各种渠道了解客户所在行业的行业信息; 向和对方有过业务接触的同事了解对方的信息如现哪些系统和业务流程、对方的管理组织结构是怎样的; 是否可以搜集到对方的一些文字情信息如...
  • 教务管理系统需求分析

    万次阅读 2017-03-26 17:56:57
    一、前言1.1 编写目的教务管理工作是高等学校教育工作的一项重要内容,是整个学校管理的核心和基础。教务管理工作是指学校管理人员按照一定的教育方针,运用先进的管理手段,组织、协调、指挥与指导各方面人员的活动...
  • 软件质量管理实践小结

    万次阅读 2013-07-01 16:14:16
    最近读了下《软件质量管理实践-缺陷预防清除管理实用方法》一书,感觉写的不错,小结之。 1 缺陷的主要信息:缺陷标识,缺陷类型,严重程度,优先级,状态,起源。 2 缺陷的主要类型:系统,数据,... 需求管理:主要
  • web项目经理手册-需求变更管理

    千次阅读 2007-08-05 22:55:00
    web项目经理手册-需求变更管理版权声明:如有转载请求,请注明出处:http://blog.csdn.net/yzhz 杨争 需求变更管理是web项目管理中最重要的一个环节,需求变更管理的有效性直接影响项目的成功与否。 对待变更的...
1 2 3 4 5 ... 20
收藏数 1,093,358
精华内容 437,343
关键字:

需求管理