扫描二维码，关注希赛网站
专注在线职业教育23年
下载APP
小程序
本篇文章是2009下半年信息系统项目管理师论文考试论信息系统项目的需求管理的模板范文。希望对广大考生对即将来临的软考有参考借鉴的作用。
论信息系统项目的需求管理
【摘要】
2011年1月，我作为项目经理参与了中国移动通信集团北京有限公司业务活动监控系统的建设。
中国移动通信集团北京有限公司（简称北京移动）业务活动监控系统提供了北京移动全球通、动感地带、神州行全品牌全业务活动的监控，包括实体营业厅、网上营业厅、短信营业厅、WAP营业厅业务办理，通过图形化的方式，及时发现并展示业务办理失败环节，及时发送短信告警，通知相关维护人员及时解决业务办理问题。
北京移动业务活动监控系统建设周期自2011年1月至2011年12月份共12个月，总投资800万元，其中软件费用500万元。项目组团队成员60人，北京移动在信息系统部牵头，共有市场部、业务支撑中心、工程建设中心等多个部门参与。最终将提供北京移动全球通、动感地带、神州行全品牌共52项业务的监控。
该项目因涉及到北京移动全品牌、全业务的监控，在需求管理方面有着非常鲜明的特点，比如需求获取时需求接口人比较多，需求规模庞大等。另外在项目期间也经历了一次较大规模的需求变更。
综上所述，北京移动业务活动监控系统项目在需求管理方面遵循了需求管理的一般原则，遇到了一些问题，同时也有自己鲜明的特色。
【正文】
随着科技的发展，现代企业对信息系统的要求越来越高，而作为项目前期非常重要的需求管理环节，是项目成败的关键。项目需求管理的目的是确保各方对需求的一致理解，在现代项目管理中，从需求收集、需求确认到最终的产品确保相关利害干系人对需求的一致理解比较困难，需要项目团队相关人员在遵循项目规则的前提下在项目中发挥主观能动性，协调各方利益，管理和控制需求的变更，从需求到最总产品的双向跟踪。而项目经理作为项目的负责人，在需求管控方面也需要投入很多的精力对需求管理进行整体把控。项目的需求管理流程主要包括制定需求管理计划、求得对需求的理解、求得对需求的确认、管理需求变更、维护对需求的双向跟踪、识别想工作与需求之间的不一致等过程。北京移动业务活动监控系统也遵循了该基本流程将需求管理分为了：制定需求管理计划、需求获取、需求分析、需求确认、需求跟踪和需求变更管控等几个方面。
一、制定需求管理计划。
制定需求管理计划的主要步骤有：1、建立需求管理的组织方针2、确定需求管理需使用的资源3、分配责任4、确定需求管理项目干系人，并确定介入时机5、制定需求跟踪矩阵6、制定需求变更审批流程等。
根据制定需求管理计划的主要步骤，北京移动业务活动监控系统在项目启动后，我作为项目经理，首先成了需求组，并指定了需求组组长。单独成立需求组，并在项目初期指定需求组负责人对于现代信息系统项目明确需求管控职责非常重要。
根据项目组内部讨论，将需求组根据办理业务的渠道细分成了三个小组实体营业厅组、网上营业厅组、短信营业厅组，每组6人分别负责各自办理渠道内的全球通、动感地带、神州行业务的需求获取、分析。此时项目经理只需要管控需求组中几个负责人，无需深入管理到每个需求人员，节约了管理成本，提高了效率。
北京移动所有业务是由维护中心负责，维护中心每个工作人员负责维护一个或多个业务流程。三个小组深入北京移动现场，在信息系统部的协助下，首先收集了北京移动全球通、动感地带、神州行三个品牌所有用户可以办理的业务，根据业务名称找到对应的维护人员，确定为需求管理接口人，形成了第一版的需求接口人联系表。
在确定了所有业务之后，项目经理召集需求组全体成员讨论并形成了第一版的需求跟踪矩阵。该需求跟踪矩阵随后发送给了需求接口人联系表中的所有人员，并得到了所有人肯定的回复。
此时需求管理计划制定过程进行的比较顺利，因此项目组和北京移动信息系统部共同制定了一个非常简单的需求变更审批流程，就将制定需求管理计划阶段推进到需求获取阶段。而恰恰是此时项目管理计划中需求接口人分析的不足和需求变更审批流程制定的不严谨造成了后续需求获取和需求变更的一些被动，后边详细论述。
二、需求获取
前文已经提到，北京移动业务活动监控系统是要监控北京移动所有品牌下的所有业务流程，而负责业务流程维护的维护中心里，每个维护人员负责一个或几个业务流程的维护。
基于以上原因，现有流程已经在使用过程中有非常清晰的流程图，并且有对应的业务流程负责人。通过需求访谈和业务实地体验三个需求小组非常顺利的在短短两周内就已经收集并完成了第一版的《用户需求说明书》。
我作为项目经理，将第一版《用户需求说明书》发布给相关干系人以后，召开了项目组和北京移动相关人员的第一次的需求评审会议，相关人员在提出各自意见后，项目组进行了收集，并完善了《用户需求规格说明书》。北京移动业务活动监控系统第一版需求收集非常顺利，首先得益于北京移动用户各部门的全力配合，其次是前期合理分配的三个小组提高了效率。短短两周已经获得了全部业务流程，如此效率获得了北京移动信息系统部的肯定。
三、需求分析和需求确认
在更新《用户需求说明书》后，以此为基准，需求组成员各自对自己负责的部分进行了需求分析，利用两个月的时间，形成了第一版《需求规格说明书》。通过第二次的需求评审会议，定版《需求规格说明书》和《需求跟踪矩阵》。
在此我不详细论述需求分析和需求确认的详细过程，仅从北京移动业务活动监控系统项目经理和需求负责人的角度强调一个需求分析和需求确认中非常容易忽视的环节“采购需求分析”。
需求分析不只要分析信息系统的各项业务，还需要对项目采购需求进行分析。北京移动业务活动监控系统中对短信营业厅各项业务的监控需要“短信猫”设备作为探测工具，模拟各项短信业务的办理。“短信猫”是需要项目组事先进行需求分析，确定“短信猫”合适型号后发起采购流程。
而项目组在需求分析阶段，未对采购需求进行足够详细的分析，也未在需求确认环节予以确认，以至于引发后续需求变更。
四、需求跟踪
信息系统项目需求管理中，需求跟踪是非常重要的环节，它贯穿项目始终，实现需求到最终产品的双向跟踪。
需求跟踪使用是《需求跟踪矩阵》，在需求分析完毕后，所有的项目需求将形成一个需求基线，项目组内部、客户方所有干系人都以此基线为准跟踪项目需求。
北京移动业务活动监控系统需求分析完毕后，需求组内的三个小组并未解散，而是整体进入到设计组，和设计组、开发组的项目成员一起工作，这样做的优势是很好的传承了需求理解、并对需求起到了很好的跟踪和监控。作为项目经理，在项目组每周周例会上，都要听取需求组各小组长的汇报，共同核对设计、开发的内容是否符合需求跟踪矩阵。在产品各个模块、流程初步成型后，也邀请用户参与测试，从北京移动用户方确认需求的实现情况。
邀请用户参与需求跟踪是对需求进行掌控非常好的方式。北京移动业务活动监控系统在集成测试后期，项目组和用户在准备测试短信营业厅业务功能时，用户机房维护人员及时提出，已采购的短信猫电源因是进口产品，电源规格不符合机房要求。项目组紧急核对需求跟踪矩阵，发现在需求分析阶段对该问题未进行核实。经确认已采购短信猫无法满足要求后，项目组提请了需求变更。
五、需求变更管理
在需求跟踪中提到，如遇到实际情况与原需求不符合，一定要提起项目变更，经需求变更控制委员会审批通过后，才能对需求进行变更，更新相应的《用户需求说明书》、《需求跟踪矩阵》、《需求规格说明书》等文档。在北京移动业务活动监控系统中，因已采购“短信猫”电源不符合机房要求，需重新更换，发起项目变更。
而在项目管理计划制定环节，仅制定了一个非常简单的项目变更流程，流程如下：发起项目需求变更申请，项目经理、北京移动相关接口人及相关人员审核、变更控制委员会审批、需求变更执行。
而此次变更所涉及短信猫采购属于采购部，机房管理人员属于网络运营中心，都不是变更控制委员会成员，甚至机房管理人员都不在需求接口人联系表中。项目组紧急更新了需求接口人联系表，重新根据最新的需求接口人联系表发布了最近版本《需求跟踪矩阵》，并提请了《需求变更申请》。
经过变更控制委员会的审核，批准了此次变更，需更换的“短信猫”设备也向厂家申请更换型号。此次需求变更虽然未影响项目最终上线，但缺是项目组在需求管控中的一个比较大的失误。
综上所述，北京移动业务活动监控系统需求管理过程中有优点也有失误。项目需求管理的目的是确保各方对需求理解的一致，而为确保各方对需求的理解一致首先要对需求相关干系人进行详尽的分析，并制定《需求干系人列表》，在这个方面北京移动业务活动监控系统项目做的不是很完美，未将机房管理人员加入需求干系人，导致后续项目采购需求变更。项目需求跟踪和求得对需求理解、确认方面做的非常好。北京移动用户及时得到用户需求的结果，需求分析的结果，每个阶段都召开需求讨论会议，使得每个需求接口人都对项目整体需求有所了解，并取得一致，甚至得到了很多很好的建议。
项目在需求变更控制方面有待改进，比如应更加喜欢变更审批流程。仅采用SVN管控需求文档，未采用变更控制系统等。
总之，项目的需求管理在项目过程中非常重要，在很大程度上影响项目的成败，作为信息系统的项目经理更应该重视项目的需求管理。
相关推荐：
