浅谈软件项目中的需求管理

上传人:hh****1 文档编号:202821724 上传时间:2023-04-23 格式:DOC 页数:7 大小:28KB
收藏 版权申诉 举报 下载
浅谈软件项目中的需求管理_第1页
第1页 / 共7页
浅谈软件项目中的需求管理_第2页
第2页 / 共7页
浅谈软件项目中的需求管理_第3页
第3页 / 共7页
资源描述:

《浅谈软件项目中的需求管理》由会员分享,可在线阅读,更多相关《浅谈软件项目中的需求管理(7页珍藏版)》请在装配图网上搜索。

1、项目管理人员接着教化论文浅谈软件项目中的需求管理曾创能3320700632023年4月22日摘要: 需求管理在软件开发项目管理中起着至关重要的作用。本人以曾作为项目经理参加的国内某期货交易所核心结算业务系统(下称“结算系统”)的项目为例,阐述需求管理的流程和自己摸索出的一些需求管理方法和心得。关键词:项目管理 需求管理 软件项目开发引言:在如今软件开发领域,尽管各种开发技术越来越先进,可利用的软件开发工具和方法也越来越多,但仍旧有相当比例的软件项目失败。究其缘由,常常是由于在项目起先阶段没有正确地理解、确定和定义需求,或者是由于在项目进展过程中没有正确地管理需求。众所周知,项目管理的三要求为T

2、QC(时间、质量、成本)。我个人认为,在软件开发项目中,要使TQC目标最大化,范围管理中的需求管理有着至关重要的作用,这与当今中国软件开发的特征有很大关系。当前中国软件开发的领域集中在应用开发领域,多以开发业务管理系统为主。而中国是新型经济体,在企业管理等领域处于逐步摸索、不断变更,以适应国际化竞争的转型初期。在此转型阶段,各企业的管理模式、业务管理方法等有很大不同,且自身也处于不断否定自己的管理、不断变更自己的管理方法和调整业务模式之中。作为软件项目开发承接方,必需适应中国这一各企业“需求各不相同”、“需求多变”的国情。本人以曾作为项目经理参加的国内某期货交易所核心结算业务系统(下称“结算系

3、统”)的项目为例,阐述需求管理的流程和自己摸索出的一些需求管理方法和心得。 软件需求管理的流程:软件需求是软件项目开发工作的一个重要源头。需求管理一般由需求分析师和项目经理共同完成的。需求分析师尽可能精确的理解和获得客户需求及潜在需求,编写需求规格说明书,而项目经理则需通过加强需求管理,有效的防范和削减不必要的需求变更。按我多年项目开发管理阅历,我个人认为,需求阶段打算把握了各类需求(功能、非功能、潜在需求等)并有效地管理需求,项目也就已经胜利了一半。在我负责结算系统时,按需求工程的方法论,将需求管理的流程可划分为如下几部分: 制定需求管理安排 需求管理安排往往被软件项目管理人员所忽视,很多项

4、目经理在开发项目时,一上来就是让需求分析师跟客户谈需求去,这样做会导致需求工作的盲目性甚至可能让需求分析师无所适从。 在本项目启动时,我通过如下步骤制定需求管理安排:1、 确定需求沟通机制;2、 确定需求变更管理方法;3、 确定需求跟踪方法;4、 确定需求管理涉及的干系人,并明确职责;5、 明确需求管理工具;6、 编写需求管理安排。 需求调研 需求调研是需求分析师一项特别重要的工作。在本项目中,我确定了对期货核心结算业务吃得很透,具有5年以上相关阅历的技术人员作为需求分析师负责与客户的需求访谈和调研,并成立需求组,在需求组中还配备了软件设计师和软件测试工程师旁听。我认为,在需求阶段,虽然以需求

5、分析师为主,但软件设计师和软件测试工程师参加特别重要,他们可以了解第一手的需求信息。 需求分析和定义针对获得的用户需求进行分析和整理,并规格化,形成需求规格说明书。针对每项功能需求,定义需求的重要性、优先级、实现的难易程度。 需求确认针对需求规格说明,和客户业务、技术人员起来,通过讲解的方式,确认需求,并最终让客户方需求接口负责人签字确认。 管理需求变更管理需求变更是需求管理中特别重要的一环,也是阅历不足的项目经理简洁忽视的地方。在软件项目中,没有不变的需求,不能希望在需求阶段一蹴而就,就此确定下来。随着设计和开发的深化,有些原定的需求原来就可能显得不合理;加之时间的推移会伴随着客户业务的改变

6、和发展,需求变更是不行避开的。管理需求变更,是项目胜利的关键因素。在结算系统项目中,我采纳如下方式对需求变更进行管理:1、需求变更申请需书面提出,并由客户方需求接口人签字认可。当我方收到需求变更申请时,先由项目组经理与客户方需求接口人协商,协商未果,由包括双方领导在内组成的CCB审核,是否接受变更;2、CCB审核确定接受的需求变更,录入需求管理工具TD,并通知相关方(包括设计组、开发组、测试组),评估影响范围及工作量;3、针对需求变更,进行相应的设计和开发的调整;4、验证需求变更是否完成。 需求跟踪针对需求列表,定期对需求进展进行跟踪。需求跟踪是指跟踪一个需求从定义、实现到验证的全过程,包括编

7、制每个需求同系统各类元素之间的联系文档,这些元素包括其他类型的需求、体系结构、其他设计组件或模块、源代码模块、测试用例、帮助文件等。需求跟踪的目的是建立与维护“需求-设计-编码-测试”之间的一样性,确保全部的工作成果符合用户需求。假如采纳手工操作方式,对需求进行跟踪,将是一个特别繁重的体力活。在本项目中,我们应用TD管理工具,该工具把需求定义、设计(每项设计关联一个或多个需求点)、开发(建立开发模块与需求点的关联矩阵)、测试(每个测试用例关联一个或多个需求点)有机的联系在一起。我负责专人(本项目以系统集成人员兼职)来定期扫描和跟踪需求的进展,可以让我随时了解项目的进展以及离完全符合客户全部需求

8、还有多远的距离。软件需求管理的心得体会 要充分识别客户的需求和潜在需求客户的需求各种各样,纷繁困难,我们要从中将这些需求进行分类。有些需求是现有的业务规则和功能、有些是对现有工作的埋怨、有些是客户依据自己理解设想的业务规则和功能。针对各类需求,我们要有不同的对待方法,尤其要慎重对待对现有工作埋怨的需求,这类客户他对现实不满,但又没有想法设想一套新的业务规则和功能,这时候须要我们充分理解,抓住客户埋怨的本质,通过自身对客户业务的理解,帮助客户设计一套能解决他的埋怨的新的规则和功能。在本项目开发中,我们有重点地针对客户埋怨较大或较多的需求,内部召集相关人员充分挖掘客户的需求和潜在需求,并运用快速开

9、发工具AxureRP-Pro搭建系统原型,以直观易懂的界面作为沟通工具,充分探讨其是否满意客户的真实需求。 需求确认特别重要 在以前的项目中,常常在项目验收时存在客户反悔、扯皮的事情,而项目开发时需求文档等各类开发文档却都很齐全。究其缘由,跟需求没有正式确认有很大关系。有些项目经理或需求分析人员埋怨项目时间紧,客户需求人员没空,所以免了需求确认这一环节。但我认为这一环节肯定不能免。哪怕项目组再忙,客户再忙,肯定要想方法让客户书面确认需求并签字。在本项目中,需求分析完成后,我通过给客户逐步讲解需求,同时逐步让客户对需求进行确认。在客户需求变更后,我通过会议纪要、需求变更单等让客户确认签字以爱护当

10、前协商的成果。 需求双方都要务实须要双方领导层达成共识,需求是无止境的,项目胜利才是关键的。在本项目初期,我恳求我方领导和客户方领导多次沟通,定下保证明现项目主要需求,肯定要保障项目胜利的基调,并为此做了一些物质上的一些激励,即我方拿出项目合同额10%的钱,激励由甲、乙双方共同实际参加此项目的项目人员,当然包括客户方的需求人员,假如项目按时上线,实现全部主要的日常业务功能,那么就可以参加共享此项目奖,否则该项目奖池归零。 设计实现别让需求扩大化 追求完备是技术人员的通病。在校期间,课程设计等计算机实现方面,学生追求算法完备可以认为是一种美德,但项目是受多种因素约束的,我们不行能实现完备无缺的项

11、目。我们的设计人员肯定不要把需求放大,放到一个更完备,适应性更强的模型中,这样无形中扩大了项目范围,加大了项目的实现成本,对项目对个人都是有害的。我们在提炼客户需求的时候,可以采纳“往前跨半步”的方式,满意客户现在以最近的将来可能须要的需求以满意系统的敏捷性,切忌追求更加抽象化,更加完备,盲目扩大需求范围,要知道,简洁是美,适用的才是最好的。 严格规范需求变更限制流程项目开发中,需求变更是永恒的主题,我们要实行恰当的措施,正视这个问题。以前项目开发过程中,由于客户方相关人单方面跟项目某一个开发人员指出说原理解的需求不正确,需重新拟定,导致后来需求变更泛滥,项目无法收尾的惨剧。在本项目中,由双方

12、领导层、双方项目经理等组成变更限制委员会CCB,并要求开发人员不得私自答应或接受客户某一个需求提出人员的需求变更,全部变更必需以客户方需求接口人汇总整理后,以书面方式提出向开发方项目经理申请,开发方项目经理可以与客户方需求接口人探讨是否接受和拒绝需求变更,当不能达成一样时,交由CCB,由CCB确定是否变更,确有变更的,录入到变更限制系统TD,并通知各方实施变更。通过这套机制,客户要实现需求变更不是那么随意,有很多人会参加监督这一变更过程,客户也胆怯自己的形象受损,有效杜绝了客户需求提出人员对需求的朝令夕改和源源不断提出的可有可无的需求的状况发生。 别忽视需求跟踪不要等到UAT时,才发觉需求未实

13、现,或实现不全,这样会让验收工作苦笑不得,影响在客户方的形象。在本项目中,我委派系统集成人员兼做定期的需求跟踪,每个月一次,以检查正在进行的设计和开发,其功能点是否符合对应的需求。 抓住客户方需求接口人 在项目启动初期,肯定要要求客户规定唯一一个需求接口人,这个接口人就是项目开发方的教练(coach)。在需求阶段,需求接口人需始终跟需求组一起,跟客户的各个部门一起探讨客户需求,全部部门的需求需经需求接口人同意。这样做好处很多,客户方需求接口人起着沟通项目甲乙双方桥梁的作用,甚至算半个乙方(项目开发方)的人。在探讨和汇总客户各部门、各人员的需求时,客户方需求接口人可以帮项目组过滤一些无用或很次要

14、的需求,也可以协调客户部门各人员需求的冲突,更可以协调项目甲、乙双方的需求理解偏差和冲突。客户方需求接口人还可以通过全程参加项目需求管理,了解更多以前没有机会了解的业务,提升自身业务实力,这也是他(她)所乐见的。在项目验收时,客户方需求接口人可以依据自身全程参加,更深化地理解系统需求的重点,在验收或试用阶段假如有实际操作人员有反悔的状况,他(她)可以以更深化地对业务和对系统的理解来调停。 苦练内功,适当引导客户需求 有很多时候,项目组开发人员埋怨客户需求太霸道,实现起来很别扭。但究其缘由,发觉是由于你别客户牵着鼻子走,客户说怎样就怎样,但客户又不是计算机设计专家,导致项目开发人员埋怨不断。我们

15、在项目开发过程中,肯定先要虚心听,且要多问几个为什么,然后在自己公司找相关业务专家、行业顾问多询问,以更简洁、更合理的模型来满意客户需求。假如自己公司缺乏行业阅历,肯定要聘请业务专家、行业顾问等专业人士,通过行业学问和业务的培训和专业指导等方式,提高项目团队特殊是需求分析师对客户需求的把握实力。此外,还可以对客户方业务人员供应免费的计算机和软件开发等基础支持的培训,以便引导客户需求提出人员以更接近技术人员的方式提出合理的需求。结尾 以上是我在负责国内某期货交易所的结算系统项目中,对需求管理流程的一些相识和心得体会,供广阔同行沟通,希望能抛砖引玉,为我国信息系统项目管理水平提高做点应有的贡献。-参考文献: 信息系统项目管理师教程(第2版)作者简介:曾创能,35岁,上海某软件公司开发总监,从事银行、证券、期货领域软件项目开发十余年,具有多年的信息系统架构设计和项目管理阅历,在项目管理、部门建设方面有很多独到之处,有十余个负责的金融项目曾获得过行业大奖。第7页 共7页

展开阅读全文
温馨提示:
1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!