论信息系统项目的需求管理和范围管理

　　【摘要】以某高校数字化图书馆信息管理系统集成项目开发为例，首先介绍了项目基本情况以及作者在其中所承担的主要工作和职责介绍，详细论述了对需求管理和范围管理的认识及它们之间的区别与联系，对项目范围管理过程中采用的具体方法和工具作了阐述，结尾总结了从该项目中所获得的宝贵经验。
　　【关键词】需求管理；范围管理；信息化建设；图书馆；数字化；
　　中图分类号：TP311文献标识码：A
　　一、引言
　　本文作者在研读《信息系统项目管理师》和PMBOK项目管理知识体系后，为了理论与实践相结合，有幸作为某公司项目经理助理身份，参与了某高校数字化图书馆项目建设为例，探讨项目需求管理和范围管理在项目实施过程中的重要性，结合实例全面阐述项目需求与范围管理过程，以及个人的经验教训。
　　二、项目背景、范围、需求概况
　　2013年6月，我作为某公司的项目经理助理参与了某高校数字化图书馆的项目建设。该项目投资约500万元，采用招标的方式进行。我公司为最终中标单位，该项目建设周期为3个月。该项目涉及到网络建设、服务器集群、SAN存储、应用软件二次开发等方面，该项目跨专业，跨行业，属于典型的信息系统集成项目，存在的风险高。
　　需求是指用户对目标系统在功能、行为、性能、设计约束等方面的期望。需求工程包括需求开发和需求管理，是个不断反复的需求定义、文档记录、需求演进的过程，可以划分为：需求获取、需求建模、形成需求规格、需求验证、需求管理。而项目范围则是为了达到项目的目标，为了交付具有某种特征的产品和服务，项目所规定要做的。范围管理就是要确定哪些工作是项目应该做的，哪些工作不应该包括在项目里。首先通过需求开发来获取项目需求，在此基础上确定项目范围，进行项目范围管理。需求管理是对已批准的需求进行生命周期管理。只有通过需求分析过程之后才能确定项目的范围，需求的并更会导致项目范围的变更。针对业务需求不确定性高、项目范围广等特点，在需求管理和范围管理中都采取了如下的措施：
　　三、用简化的原型法来进行需求分析
　　需求分析对项目有举足轻重的作用，充分的需求分析可以使得开发和测试更能够了解客户的需求，把一些技术难点和可能遇到的难点问题提出来，尽早解决，并且达到一致，避免项目后期返工，减少缺陷成本。为了做好需求分析，我们在该项目的需求分析中采用了简化的原形法。
　　首先对业务需求《数字化图书馆信息系统业务需求文档》进行快速的分析，弄清楚业务部门的对数字化图书馆信息系统的基本需求，详细阐述该项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准，未来发展的接口预留等一个基本的业务需求规格说明，并提交给3名业务人员。由业务和开发人员共同讨论确定初始需求的可用性，形成初步一致意见。接着在基本的业务需求规格说明上，搭建简易的原型系统，该原型系统包括简单的客户端信息交互需求和业务逻辑处理服务，尽量仿真实际工作环境下的功能需求，要与实际系统的操作过程完全相同，由于图书管理系统是现有系统的迁移，故考虑可用性但不用实现。最后由业务人员和开发人员共同评价和改进原型，最终完成了《数字化图书馆信息系统项目软件需求规格说明书》，业务人员对该文档进行了签字确认。
　　四、工作分解结构WBS的滚动式规划
　　工作分解结构WBS可以清晰的展示项目工作之间的相关关联，在该项目的范围规划和管理中，我使用project2010来进行WBS分解，分多个层次。第一层分解为计划阶段、需求分析、设计阶段、编码实施（包括编码开发和单元测试）、集成测试、系统测试、验收测试、试运行。第二层，针对各个阶段再按照各个阶段产出物的领域进行分解，如：需求分析分解为：页面展示分析、功能流程分析、非功能性需求分析流程、运行维护需求；设计阶段分解为：系统概要设计、系统详细设计、数据库表设计；编码实施分解为：手机WEB客户端、业务逻辑应用服务开发、交易网关改造；系统测试分解为：系统功能测试、系统性能测试；接着再向下分解。
　　当然工作分解结构也是个渐进明细的过程，需要滚动式规划，刚开始进行规划时设计、开发的工作包可以具体到每个人23个工作日的工作内容，但是系统测试、验收测试的工作包只是做了大致的整体估算；但随着项目实施的展开，当开发编码工作进入尾期的时候，就可以对测试的工作包进行细化，当系统测试工作进入尾期的时候，就可以对验收测试、试运行的工作包进行细化。分解的粒度逐步变小，总的原则就是能清晰计划、估算、监控、管理项目具体执行工作为准。
　　五、建立纵向需求跟踪矩阵，并定期审查跟踪
　　需求跟踪矩阵是在项目范围管理和需求变更控制过程中一个一个非常有效的方法，但对于复杂项目来说建立和维护这个需求跟踪矩阵的工作量是非常巨大、烦琐的。我在该项目中平衡项目管理的投入和产出，分别建立用户需求和系统设计、用户需求和测试用例的需求跟踪矩阵，简化需求跟踪矩阵的复杂度；对用户需求、系统设计、测试用例都采用统一编号的方式，并采取分层编号方式，便于实现跟踪和管理。针对不同的用户需求，考虑需求、设计、代码、测试用例的颗粒度大小。比如对于功能性需求的实现，设计一般细化到功能组件，代码细化到具体的应用程序，测试用例则是一组测试用例的集合。通过适度的颗粒度降低需求跟踪矩阵的复杂度。
　　六、制定需求变更流程来管理需求变更
　　需求管理和项目管理的一个核心内容就是需求和范围的变更管理，需求管理会导致范围变更，而范围变更可能会造成需求无法实现或遗漏。我深知需求和范围变更的好坏直接关系着项目的成败，所以在项目规劃初期就成立了变更控制委员会CCB，由我、技术经理、业务经理、测试经理、配置管理员、质量管理员组成，并明确了通过Butterfly变更管理工具来管理变更流程。需求变更流程根据变更的严重程度来分层次进行管理和审批，变更可以分为：轻微变更、严重变更、极其严重变更。
　　我具体了解情况后，认识到项目成员对需求管理和范围管理的认识和贯彻程度存在问题。于是我立即组织全体项目成员进行需求管理和范围管理的培训，并要求所有的需求和范围变更都需要通过Butterfly变更管理工具来管理，经过变更影响评价后，由拥有不同层次批准权限的技术经理、项目经理助理和CBB来决定是否给予批准或拒绝。同时加大对变更请求的后续检查，包括批准和拒绝的范围。在项目例会上通报未经批准的变更，一定程度上保证了需求变更管理的实效，防止了项目范围蔓延。
　　七、明确项目范围说明书，并且不断修改和优化
　　项目范围说明书是项目最重要的文档，它说明了为什么要进行这个项目，明确项目的目标和可交付成果，是业务需求部门和技术实施部门之间的协议基础。主要包括：项目目标、项目可交付物、项目边界、产品验收标准、约束条件、项目的假定。主要是包括三方面内容：项目的合理性说明、项目的目标、项目的可交付物，在项目启动后就应该尽快编写出来，而且随着项目的深入，不断地堆项目范围说明书进行修改和细化。通过上述的需求管理和范围管理的措施及一些具体操作细节，数字化图书馆信息系统于2013年9月顺利完成，得到了用户方的肯定和好评。
　　【参考文献】
　　〔1〕柳纯录。信息系统项目管理师教程〔M〕。北京：清华大学出版社，2012。
　　〔2〕袁慧香。地质资料业务管理信息系统项目需求管理的过程与分析〔D〕。中国地质大学（北京），2014。
　　〔3〕陈世昌。范围管理在信息系统集成项目中的探讨〔J〕。经营管理者，2015，17：81。
　　〔4〕孙尧。信息系统集成项目中的范围管理〔D〕。北京邮电大学，2008。