需求管理
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
需求管理
摘要:
2011年7月,我参与了某企业“高清卡口式智能电子警察“项目的建设。在项目中担任项目经理职务,主要负责项目的管理工作。该项目是受某市公安局交警指挥中心的委托而开发的,目的是为了改善城市道路交通环境,提升公众出行安全系数。系统兼具电子警察和卡口功能。(121)
本文结合作者的经验,以“高清卡口式智能电子警察“项目为例,讨论了项目的需求管理过程以及采用的措施和方法。作为建设方的项目经理,我认为需求管理在信息系统项目中目的是确保项目各方对需求的一致理解,管理和控制需求的变更,实现从需求到最终产品的双向跟踪。在具体工作中,采取了利用头脑风暴法获取需求,利用业务流程分析、数据流图等进行需求分析,利用评审进行需求验证,制定双向跟踪矩阵进行需求管理等相关管理方案。通过这些措施和方法,有效地控制了项目范围和成本,成功地完成了项目,受到用户方的高度评价。
正文:
项目概述;
随着我国国民经济的持续快速发展,车辆剧增,由此导致交通阻塞,交通事故发生频率高,交通环境污染,交通治安混乱等一系列问题,严重影响了人民的生活。在城市交通的关键点——道路交叉口,由于汇聚了多个方向的交通流量,加上机动车非机动车混行等因素,成为城市路网中交通拥堵发生的重点地段。而车辆闯红灯等违法现象,更是成为引发道路交通事故的主要诱因之一。单纯依靠人为管理,浪费人力资源,效果也不明显。因此,向科技要警力,向管理要效益成为各个城市交通管理部门进行违法自动检测系统建设的动力。
为进一步利用科技手段实现对闯红灯、逆行等违法行为进行有力地治理,防止此类交通违章行为的发生,减少由此引起的事故,并促进交通秩序良性循环,提升公众出行安全系数,某市公安局交警指挥中心特委托我公司开发“高清卡口式电子警察”。
项目启动后,我被任命为该项目的项目经理,全面主持项目的管理工作。
该项目规模庞大,一期投资投资600万,要求在2012年1月1日前全面竣工并投入使用。该项目将负责某市110万辆机动车数据,涉及部门人员众多,涵盖的知识技术领域范围广,是一个大型、复杂的综合性项目。在有关领导的亲切关怀下,在项目干系人的配合与支持下,我与项目组全体组员并肩作战,通过近6个月的努力,终于在2011年12月20日全面通过验收。项目总成本为万原,比计划提前10天,为公司挣得万利润。
项目采用B/S架构,Windows为开发平台,c#,c++为开发语言,数据库使用的是oracle 10g。该项目除了具备实时监控功能外,还具有高清抓拍、大容量高速存储、自动检测车辆及车牌识别、全程轨迹跟踪、自动预警拦截等系统功能。项目涉及的子系统较多,主要包括车辆检测模块、图像采集模块、信息处理模块、数据检索模块、违章检测模块等几个部分。
该项目的成功与合理的需求管理以及项目干系人的大力支持是密不可分的,下面分别对项目需求管理过程中需求获取、需求分析、需求定义、需求验证、需求管理(制定需求管理计划、需求变更管理、需求跟踪)等几个方面加以简要论述。
需求管理和范围管理的关系:
需求开发、需求管理、范围管理的区别和联系主要如下:
1)首先通过需求开发来获取项目的需求,在此基础上确定项目的范围、进行项目范围管理。项目管理者联盟
2)对于项目需求,可以根据需求的紧急重要程度、项目本身和项目双方的实际情况,分步或分期满足。确定每期应满足的需求后,本期的范围管理就有了基础。
3)需求管理处理需求的变更,需求的变更同时会引起项目范围的变更。
需求获取:
首先联系并了解用户方。我同用户进行联系并取得了对方相关人员的名单,了解了他们的角色及职责。将可能使用产品的客户分成不同类别。详细描述出它们的个性特点及任务状况。为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。
制定需求管理计划,包括如何规划、跟踪和汇报各种需求活动;需求管理需要使用的资源;培训计划;项目干系人参与需求管理的策略;判断项目范围与需求不一致的准则和纠正规程;需求跟踪结构,即哪些需求属性将列入跟踪矩阵,并可在其他哪些项目文件中追踪到这些需求;配置管理活动等。
制定需求管理计划后,我召开了联合讨论会。联合各类关键客户代表,分析人员,开发团队代表一起,采用头脑风暴法来讨论需求。由此拟出需求文档的底稿,确定了项目的质量属性和其它非功能需求。
需求分析:
需求分析包括提炼、分析和仔细审查已收集到的需求,以确保所有的干系人都明白其含义并找出其中的错误、遗漏或其它不足的地方。
分析还包括与客户的交流以澄清某些易混淆的问题,并明确哪些需求更为重要。其目的是确保所有干系人尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。我们从以下几方面对收集的需求进行分析:
1)分析需求可行性。计算机不能代替现实世界中的所有工作。在允许的成本、性能要求下,对每项需求进行业务流程分析,分析业务流程中哪些是需要信息化管理的,而哪些不需要。同时为业务流程的合理化改造提供建议。明确与每项需求实现相联系的风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。
2) 确定需求的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。给每个需求建立优先级有助于解决冲突,安排阶段交付,并且做出必要的取舍。
3) 为需求建立数据流图。用来表达系统内数据的流动并通过数据流描述系统功能。数据流图还有助于找到不正确的、不一致的、遗漏的和冗余的需求。
4) 创建数据字典。在需求阶段,数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。
需求定义:
用户需求要用一种标准使用实例模板编写成文档。而软件需求规格说明则包含了软件的功能需求和非功能需求。我们根据下面几方面定义了软件的需求规格说明文档。
1) 采用S R S模板:定义了软件需求文档标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。
2) 指明需求的来源:为了让所有干系人明白S R S中为何提供这些功能需求,每项需求都要能追溯来源。
3) 为每项需求注上标号:制定一种惯例来为S R S中的每项需求提供一个独立的可识别的标号或记号。这种惯例应当很健全,允许增加、删除和修改。作了标号的需求使得需求能被跟踪,记录需求变更并为需求状态和变更活动建立度量。
4) 记录业务规范:业务规范是指关于产品的操作原则,比如谁能在什么情况下采取什么动作。将这些编写成S R S中的一个独立部分。
5) 创建需求跟踪能力矩阵:建立一个矩阵把每项需求与实现、测试它的设计和代码部分