CMMI on line

做中国最专业的CMMI网站!
欢迎光临 CMMI on line 登录 | 注册 | 帮助
in 搜索

需求管理(Requirements Management)

本主题共有 14 篇回复,最新回复发表于 01-08-2009, 14:56,作者 Hilton
帖子排序: 上一主题 下一主题
  •  07-18-2006, 0:49 38

    Idea [I] 需求管理(Requirements Management)

    人是会死的,需求是会变的。相信大家都经历了很多需求变更的痛苦,项目被拖延,成本高涨,十有七八是需求管理没有做好导致的。有哪一些需求管理方面的常见问题呢,这里列举一下:
    1.因为项目进度赶等原因,在很多需求还没有明确情况下,便开始开发的工作。
    2.开始客户只能提出模糊的需求,客户喜欢先让你做个东西给他看,然后他才可能逐渐提出真正的需求,而需求调研人员,对此没有什么好的处理办法。
    3.客户以种种原因不签需求,项目组在不签需求的情况下,便开始开发工作。
    4.客户不承认之前提出来的需求,项目组又不能得失客户,项目成员苦不堪言。
    5.需求经常变化,无法控制。
    6.设计、代码与需求不对应,特别是需求变更时,不知道应该修改哪部分,也不知道会有哪些影响。
    ......

    这方面的问题可真是“罄竹难书”了,需求管理这个PA提供了能解决以上大部分问题的最佳实践。

    RM(Requirements Management)只有一个Specific Goals:Manage Requirements
    Requirements are managed and inconsistencies with project plans and work products are identified.

    中文大意是:
    管理需求并且识别出需求与项目计划、工作产品不一致的地方。
    这句话有两层意思:
    1.需求要被管理,被管理的意思又有两层:一是需求要被确认,二是要控制需求变更
    2.需求要用来指导下游的工作产品,如:计划、设计、测试等

    下面简单介绍一下这个Specific Goals下的5个Specific Practice:

    第一个SP是:理解需求。
    开发者应该理解客户的需求,如果这点做不到,后面的工作是没有意义的。所以,那种在没有理解需求的情况下,就仓促开发的做法是不合适的。
    当然,如果想通过做原型来获取需求不在此列,另外,大家也千万不要误解,在没有完全理解需求前一定不能开展开发工作,如果部分需求已经掌握,有部分需求还没有掌握,那也是可以先开展已掌握部分需求的设计、编码工作的,这时需要考虑没有确定部分的需求对这些工作可能带来的影响。
    这个SP的英文原文是:Develop an understanding with the requirements providers on the meaning of the requirements.

    第二个SP是:确认需求,就是要和客户签署需求。
    我想大家都非常理解这点的重要性,但大家可能会说,说得容易,客户就是不签,咋办?客户不签需求,主要是两方面的原因:
    1)客户不确定需求。
    2)客户担心签了需求后,他就不好变了。
    对于原因一,解决办法就是大家需要把SP1理解需求做好,如何把需求理解做好,更详细的内容可以参考3级的需求开发(RD),这里先不详细解说。
    对于原因二,要消除客户的顾虑,首先签署需求不是单方面的约束,其实也是对开发方的约束,就是说我们要承诺做出这样的一个东西,如果做不出来,客户可以追究我们的责任,另外一个方面,要跟客户说清楚,需求是可以变的,现在签署只是标志着当前的一个工作里程碑,当前签订的需求,是我们后续工作的一个基准。
    大家可能又会问如果只能确定一部分需求,客户还是不愿意签,咋办?那就先签确定部分的需求呗!
    这个SP的英文原文是:Obtain commitment to the requirements from the project participants.

    第三个SP是:管理需求变更。
    需求不是不可以变,只不过需要管理。客户今天说改这,明天改那,后天又不算数,咋办?怎样才算管理需求变更呢?
    1.要充分理解客户提出来的需求变更,深究其原因,不能客户一说变就变,超过一半的客户变更要求,其实都是不合理的,或者是有其它更好的替代办法的。
    2.客户提出来的变更要求,要书面记录,并让客户确认,和客户讨论需求变更过程来往的邮件要保存好,和客户面谈、聊电话后,要发邮件总结当此会谈达成的要点共识,总之就是要有书面记录。
    3.客户提出来的需求变更,要分析所有的影响,包括增加多少的工作量,需要修改或者增加哪些设计文档代码等,可能会引发什么风险等。所有这些要列出清单,反馈给客户,让客户确认。
    4.如果需求变更导致项目成本和进度变化太大,超出可承受范围,则需要高层领导出面,和客户协商调整费用。
    这个SP的英文原文是:Manage changes to the requirements as they evolve during the project.

    第四个SP是:维护需求的双向跟踪。
    需求是用来指导后续工作的,所以需求与计划、设计、编码、测试等后续工作都需要维护好对应的关系,这个工作与第三个SP是关系密切的,如果这个关系没有维护好,那么SP1.3也不可能做好。
    这样是不是双向跟踪就能做好呢?不是,双向跟踪的意思不是由A能找到B,由B又能找到A就叫双向跟踪。双向跟踪是只纵向和横向跟踪,前面提到的只是纵向跟踪,纵向跟踪的意思是上下游工作产品之间的跟踪关系。而横向跟踪指的是需求与需求之间的关系、设计与设计之前的关系、代码与代码之间的关系等。其中一个需求变化了,有可能影响另外一些需求,其中一个设计变了也可能影响另外一些设计。
    所以,这个双向跟踪网络,将会是一个很强的网络,任何一点发生变化,能找出全部受牵连的地方。
    这个SP的英文原文是:Maintain bidirectional traceability among the requirements and the project plans and work products.

    第五个SP是:识别出需求与下游工作产品不一致的地方。
    这里有两层意思:
    1.需求变更时,利用双向跟踪表找出需要修改的地方,并用跟踪表来发现不一致的地方并调整。
    2.编写或者修改计划、设计、代码、测试计划、测试用例等需求下游工作产品的时候,要注意要与需求保持一致。
    这个SP的英文原文是:Identify inconsistencies between the project plans and work products and the requirements.


    CMMIonline 版权所有
    欢迎转载,但请给出指向本网站的链接:
    http://www.cmmionline.net
    版权声明见:
    http://cmmionline.net/forums/thread/1340.aspx
  •  07-18-2006, 17:34 39 回复至 38

    回复: 需求管理(Requirements Management)

           需求一直是项目或产品最需要关注的地方,因为他几乎没有不变的。

           那么上面描述的是需求管理上的内容,也非常正确。

         需求管理是CMMI L2的PA ,需求开发是CMMI L3的PA .其实我个人认为应该先需求开发再需求管理的,所以,不管是过L2的组织应该将需求开发考虑进去。

         这里不描述CMMI 的内容,我从管理手段进行描述下,我们怎么样来实践这2个PA.

          需求开发的最终输出为需求规格说明书。

         需求管理的重点为RTM及变更控制。

         我们知道需求规格说明书比较好做(也都会做),关键点还是在RTM及变更控制了。

        在国内的非常大型的企业中,也在考虑开发些工具进行管理,他们的可行性分析中,做出来需要投入1000 万RMB.国外也有这样的管理工具,如:IBM,他们的工具比较贵也比较不太适用国内的企业,并且价格不低。

          我想解决这个问题还是需要工具,利用CMMI的思路进行做,基本可以满足要求。

        有关这个方面的信息,我这边有开发工具了,需要了解的,可以多交流。

  •  07-19-2006, 12:25 42 回复至 39

    回复: 需求管理(Requirements Management)

    说得非常有道理,其实做需求管理的时候,不可能不管需求开发的,我也很认同需求开发不做好,需求管理也很难做好。
    大家不要有这样的一个误区,要先做到2级要求,才可能做到3级的。其实我们在做2级的时候,很多3级的PA我们已经在做了,如TS、RSKM、VAL、VEL等。

    CMMI除了阶段式表述方式外,还有连续式,其实连续式更科学一点,不过为了大家理解方面,我会以阶段式为主来阐述,以后我会再详细说说连续式。


    CMMIonline 版权所有
    欢迎转载,但请给出指向本网站的链接:
    http://www.cmmionline.net
    版权声明见:
    http://cmmionline.net/forums/thread/1340.aspx
  •  06-12-2007, 11:38 626 回复至 38

    回复: 需求管理(Requirements Management)

    SP1.2   的原文是 Obtain commitment to the requirements from the project participants.

    那么这里的project participants是该理解成客户呢?还是项目成员呢?

    从字面意思来看我觉得应该是取得项目成员的承诺。

    • 帖子点数:0
  •  06-12-2007, 20:54 627 回复至 626

    回复: 需求管理(Requirements Management)

    应该包含客户及项目成员,取得客户的确认,目的是确保做的东西是客户确认的,取得项目组成员的确认,目的是确保需求已经经过评估,是可行的。


    CMMIonline 版权所有
    欢迎转载,但请给出指向本网站的链接:
    http://www.cmmionline.net
    版权声明见:
    http://cmmionline.net/forums/thread/1340.aspx
  •  07-11-2007, 16:02 702 回复至 627

    回复: 需求管理(Requirements Management)

    我的理解是所有的Stakeholders,包括客户,项目成员,以及项目之外的所有人(行政,HR等支持部门,以及High Level管理人员)。。。项目需求需要这所有的人都能够理解,并给予充分的支持。。。


    -=P.CHi=-
  •  07-11-2007, 18:11 703 回复至 39

    回复: 需求管理(Requirements Management)

    什么工具?


    -=P.CHi=-
  •  01-24-2008, 17:54 1521 回复至 38

    回复: 需求管理(Requirements Management)

    能否解释一下什么是需求追溯矩阵?举个例子或者提供个模板来看看。
    • 帖子点数:0
  •  01-24-2008, 21:02 1522 回复至 1521

    回复: 需求管理(Requirements Management)

    举个例子,需求与设计的关系,需求与设计通常是多对多的关系。

    这样我们可以画一张表,每一行代表一条需求,每一列代表一条设计,这样就可以在行与列的交叉点将有关系的设计与需求打上标记。

    通过这样的表,可以清楚看到每一条需求对应有哪些设计,每一条设计对应有多少条需求。


    CMMIonline 版权所有
    欢迎转载,但请给出指向本网站的链接:
    http://www.cmmionline.net
    版权声明见:
    http://cmmionline.net/forums/thread/1340.aspx
  •  09-03-2008, 10:16 8494 回复至 38

    回复: 需求管理(Requirements Management)

     
    SP 1.1 获得对需求的理解
    與需求提供者一起瞭解需求之意義。
    當專案成熟且需求已衍生後,全部的專案活動或專
    業領域將收受需求。要避免需求不知不覺的到來,
    須建立準則,以指定需求收受的適當管道和正式的
    來源。執行需求收受活動時,須與需求提供者一起
    CMMI for Development
    Version 1.2
    需求管理(REQM) 463
    分析需求,以確保對需求的意義能達成共識。此分
    析和對話的結果,才是被議定的需求。
    典型的工作產品
    1. 區別適當需求提供者的準則清單
    2. 需求評估和接受準則
    3. 依準則進行分析的結果
    4. 經議定的需求
    細部執行方法
    1. 建立區別適當需求提供者的準則清單。
    2. 建立客觀的需求評估及接受準則。
    缺乏評估及接受準則常常導致需求確認不夠充
    分、昂貴的重做成本,或客戶退件。
    需求評估及接受準則,舉例如下:
    • 清晰而適當地表達
    • 完整
    • 相互的一致性
    • 可個別界定
    • 可適當地實作
    • 可驗證(可測試)
    • 可追溯
    3. 分析需求,以確保其符合已建立之準則的要求。
    4. 與需求提供者達成需求共識,使專案成員可對需
    求承諾。
    • 帖子点数:0
  •  12-18-2008, 14:59 10380 回复至 38

    回复: 需求管理(Requirements Management)

    针对上面的说明,我还是存在一些疑虑,我们要进行需求管理,要进行需求确认,那么什么样的问题需要确认?再有,需求确认的时候肯定是要把要确认的需求都整理出来,那么什么样才可以认为是可以了呢?比如准备一个需求确认表,他的出口标准该是什么样的比较合适啊?

  •  12-18-2008, 22:37 10411 回复至 10380

    回复: 需求管理(Requirements Management)

    全部的需求都是需要确认的,这些确认是指和客户确认。当然一般情况下是项目组内部先达成一致,然后再和客户确认。


    CMMIonline 版权所有
    欢迎转载,但请给出指向本网站的链接:
    http://www.cmmionline.net
    版权声明见:
    http://cmmionline.net/forums/thread/1340.aspx
  •  12-23-2008, 16:48 10589 回复至 10411

    回复: 需求管理(Requirements Management)

    谢谢您的答复。:-)
  •  01-08-2009, 14:26 12853 回复至 702

    回复: 需求管理(Requirements Management)

    或者说是与过程相关的干系人。
    • 帖子点数:0
  •  01-08-2009, 14:56 12854 回复至 38

    回复: 需求管理(Requirements Management)

    张总,想请教!我在一个约80人的软件开发公司工作,之前负责一个产品线的项目开发,现在公司成立了专门的项目管理部,老板要我负责,大半年过去了,可我感到困惑……主要问题:

    1 主要的客户信息和业务的信息(如需求信息等),已经形成习惯,客户和业务都习惯于找老板,只要老板认可了,就自然容易执行下去。老板是辛苦了,可我不明白,就说CMMI中的需求管理,我该怎样做好呢?

    2 以前我单独负责一个产品线,要建立一个流程,比较容易实现。可现在,感觉其它产品线的经理们对流程似乎不怎么感兴趣,觉得浪费他们的时间,他们觉得有事直接找老板效率最高。

    不好意思说,现在公司的项目管理部形同虚设了……


    中小企业最缺的就是技术型的管理人才……
以 XML 格式显示 RSS 新闻频道
CMMI on line 版权所有 ( 粤IC备07073557号)
Powered by Community Server, by Telligent Systems