软件需求调研“五步法” 收藏-阿里云开发者社区

开发者社区> 云计算> 正文
登录阅读全文

软件需求调研“五步法” 收藏

简介:
  软件需求调研“五步法” 收藏 
摘要 
客户需求,是软件生产加工的“原材料”,是团队展开工作的“依据”,是项目管理的“基石”,需求调研是获取这此基础信息的启始阶段,良好开始是成功的一半。在需求调研分析阶段,项目经理和需求分析人员无法推动需求调研,客户参与积极性不高,获取客户需求信息不完整,且没有得到客户的认可。将决定能否奠定项目成功的保障,决定软件项目实施的成败。本文介绍“B项目”需求调研不深入所造成项目经理的无奈,分析其中问题原因,归纳总结需求调研的“五步两点法”。 

关键字 
调研提纲,调研计划,调研文档,仿真界面 

案例背景 
“B项目”2007年7月份启动,发2008年3月底验收,项目实施时间仅1年时间,项目经理程正义全权负责需求调研。由于项目合同要求时间短,且与其它项目相似,在需求调研过程中,采用系统迁移方式,需求调研也是边挖掘边完善,直至于2008年3客月份,系统验收。 

在验收过程中,发现经过迁移的系统架构无法满足南京卫系统架构的要求,客户的需求并不像从其它项目迁过的一样及其发展,系统验收前一个月,系统修改的工作量非常大,以至于无法验收。项目二期工作已经开始招标,作为一期的合作方,很想继续与客户合作下去,但苦于当前无法顺利验收。 

在一次项目例会上,面对这样的商机及目前的情况,项目经理反思为什么出现这样的局面,究其原因需求调研不深入。 

案例分析 
通过以上案例,我们不难看出,使项目经理面临这样困境原因有许多方面,其中需求调研不够深入。 

?  项目经理没有获得有效的需求调研,需求调研未达到预期的效果。 

?  在需求收集整理过程中,有的部门提不出需求,有的部门提出需求已经严重超出范围;各个部门业务有重叠部分,有的业务有所冲突。 

?  前段时间刚刚签字确认下来的需求,刚刚开始进行设计,客户接到上级的通知,政策发生了一些变化,要进行需求调整。 

?  在为期半年的需求调研中,需求经过多次评审,多次变更,需求原型不知道改过多少次,但还是没有确定下来,项目进度严重延误,但他也感到很庆幸,因为还没有设计开发,变更只限于需求文档、系统原型。 

在需求调研过程中,要搞清楚以下几个方面的内容: 

(1)、认识用户的特点 

?  用户提不出需求,没有进行专业咨询,缺乏整体规划。开发商对行业认识有限,需求难以确认,致使项目延期。 

?  用户随意提需求,用户需求无人把关,没有信息监理。用户对项目实施周期认识不足,给予的实施周期过短,需求非常苛刻。 

(2)、认识角色的特点 

用户通常涉及到三种角色:决策人员、业务经办人员和信息中心人员,而各种角色具有个性特征: 

?  决策人员。通常是管理层的领导,有决策权,偶尔出席需求调研会议,较少时间审阅需求文档。 

?  业务经办人员。通常是各处室、科室的工作人员,参与具体需求调研,熟悉业务需求,但是很多业务不能拍板。 

?  信息中心人员。通常是信息中心技术人员,负责系统实施工作,掌握一定的技术技能,不一定十分了解需求,无法推动需求调研进度,且在三种角色中处于最弱势地位。 

综合这三种角色的特征,往往是:决策人员没时间审阅文档,不便于拍板;业务熟悉文档,但没有权限签字;信息中心人员既无权决策、又不熟悉业务,然而负责系统实施。因此,项目需求难以确认。 

(3)、需求调研的特点 

在需求调研过程中,我们碰到客户需求内容具有以下特点: 

?  大量政策文件,大量表格、且内容分散。如在本项目案例中,客户提供书面资料有26份,且全是一本本厚厚的书,要深入熟悉这方面的需求,需要花大量的时间。 

?  政策多变。今天一个会议精神,明天一个通知,后天一个新条例,政策经常发生变化,同时也引发需求变更。有时候,一个系统建设还没完成,政策可能全部发生改变,需求完全与原来的不一样,需求变更超过80%。 

?  信息建设落后。在本项目案例中,客户是政府机关,有许多的C/S模式的系统在使用,这些系统相对比较落后,但功能稳定。在信息化过程中,用户习惯于将操作模式带到B/S模式下,用户根据其中知道的功能,随意增加内容。 

(4)、需求交流 

    从需求沟通交流的角度出发,主要具有以下特点: 

?  不同业务处室、或同一业务处室不同业务人员对同一个业务需求的理解不一致,交流时往往会浪费大量时间在用户自己内部争执上,甚至用户内部互相推诿,客户内部对业务需求的理解无法达成共识,开发商面临业务需求多头解释。 

?  需求交流的形式基本停留在会议交流上,而且往往事先缺乏足够的准备,会议主题不明确,往往是就事论事,会议效率不高。 

?  调研会议、交流计划常常因用户无法参加会议而变更,需求调研计划执行困难。 

综合以上各方面的特征,客户需求具有一定的特征,但每个项目的客户需求都自有自身的特点,做好需求调研,本文概括为“五步两点”法: 

第1步、理顺组织架构及沟通流程 
(1)、良好的项目组织结构,是软件项目成果的保障之一,软件项目管理,要建立合理的组织结构,包括三方的组织架构: 

?  开发方。根据项目目标,组建项目实施团队,明确、落实各个岗位角色职责,不能忽略QA、CM、测试人员,及兼多个项目设计开发人员的工作职责。 

?  客户方。明确客户项目组织结构,参与到本项目中各个人员的工作职责,及工作配合内容。 

?  第三方。根据情况,项目组可以有第三方组织介入,如:信息监理公司、客户咨询公司、软件测试等,为实现项目目标共同协作。 

在本项目案例中,双方不仅设置各自的项目组架构,同时邀请第三方信息监理公司,以在双方之间进行沟通协调,在验收测试中,邀请第三方评测中心,对系统进行验收测试,以确保产品质量。 

合理的项目组织结构,在关注是否有必要建议邀请第三方的同时,更加要考虑客户是否建设项目组织结构,开发方项目组织的内在结构。 

(2)、明确的沟通协调流程 

项目需求是双方共同理解的过程,共同理解其实也是不断沟通交流的过程,政府项目需求采集中的信息量大、原始资料多、内容多变等需求特点,要能够准确的理解这些需求,在不断提高自身素质、业务水平的前提下,更要明确沟通协调流程,以提高沟通的效率。 

确定沟通协调平台。客户例会,或三方客户例会,是沟通协调的重要平台,在例会上,集中解决项目中存在的问题。对于客户例会,根据项目大小及多方协商,确定沟通的频率。关于例会的时间、地点、频率等,根据双方的协定而确定。 

(2)、确定沟通交流方向。如果沟通方向不对等,项目需求发现漫延、拓展,将会引起需求范围扩大,增加项目成本,从而影响项目进度,因此要确定沟通交流方向。主要是:确定横向交流方向、确定纵向交流方向。 

?  双方领导层的沟通交流。 

?  项目经理与客户方信息技术负责人、业务负责人的沟通交流。 

?  需求人员与客户业务人员的沟通交流。 

在本项目案例中,沟通交流方向比例明确,在横向方面,主要有三个沟通协调方向,领导层、管理层、执行层;在纵向方面,也有三个沟通协调方向,开发方项目组、客户技术组、客户业务组。如图所示:“B项目沟通协调流程图” 

第2步、确定需求调研计划 
需求调研计划,是展开需求调研工作的开始,指导整个需求过程,在制定需求调研计划中,要全面考虑,尽量周全,能够想到的尽量在计划在内,但同时要注意如下几点: 

?  确定被调研的部门、角色,具体业务人员。信息化建设是为人服务的、为管理服务的,因此,需求调研从被调研的部门角色开始,在客户方确定项目组组织架构、确定沟通协调之时、需求调研之前,要明确被调研所涉及的部门、角色。在需求调研计划中,确定参与需求调人员的姓名、联系方式等一些详细信息。 

?  确定需求调研方式。需求调研方式多种多样,主要包括两种情况: 

n  (1)、客户描述客户要求、展示现有的手工操作、系统操作方式,主动向开发方提供信息,开发方组织需求调研,采用一对一沟通、会议、问卷等方法,使用文档、或原型来协助理解需求。 

n  (2)、系统改造,对相关的系统进行整理,然后向客户展示,然后组织需求调研。无论使用哪种方式,在需求调研之前,要确定下来。 

?  确定调研的步骤和工作输入、输出。在本案例中,调研活动包括两个方面: 

n  从文档方面有:1.讨论交流,2.业务培训,3.文档编制,4.文档提交,5.反馈修改,6文档确认; 

n  从系统原型方面:1.页面设计,2.用户试用,3.反馈修改,4.界面确认;两个步骤同步进行,相辅相成。 

第3步、良好调研过程文档 
在需求调研过程中,涉及到许多的中间过程的文档,这些文档是形成用户需求的基础,过程文档主要包括两大类文档: 

需求管理类文档: 

?  需求调研计划。 

?  需求调研提纲 

?  需求变更申请(确认)单 

?  需求跟踪表 

?  需求确认书 

需求调研类文档: 

?  用户提交的原始需求 

?  需求调研报告 

?  用户交流备忘录 

?  需求调研会议纪要 

良好的过程文档记录,主要包括以下几大特点: 

(1)、书面描述客户的需求,无论是客户口述,还是客户的想法,先以用书面的形式将录下来,这些书面的形式就是一份良好的过程文档。 

(2)、不要遗漏客户的需求,作为客户需求的凭证,由于需求较多,不容易管理,有了过程文档进行记录,不容易遗漏某个想法、或某次需求。 

(3)、分阶段的、逐步确认需求,每次需求都有一份过程文档进行记录,但每次都要进行一次需求确认,在一边收集、一边整理的过程中,同时也一边让客户确认。 

第4步、漂亮的用户分析报告 
也就是将历次的需求调研结果,经协过需求分析的而形成的结果,是客户需求的正确描述的文档,是与客户达成需求共识内容的体现,也是开发商需求调研成果的表现。“漂亮”的需求文档,主要包括以下内容: 

?  正式的文档封面 

?  工整规范的目录结构 

?  专业的需求表述方式(SRS或者USE CASE) 

?  章节内容清晰明了,行文规范 

?  完整的内容(不要忘记非功能性需求) 

?  有必要编制一个需求文档的说明 

?  一个“漂亮”的需求文档模板,可以指导需求调研过程活动 

第5步、直观的系统仿真界面 
系统仿真界面,也称为系统原型,主要是描述用户的操作场景,一方面作为双方共同理解客户需求的依据,另一方面,也可以作为系统开发的原型基础,主要具有以下特点: 

?  不是一些静态页面的组合,而是动态的、可操作的,直观地给客户展示操作页面。制作相对简单,修改比例方便,即需求反复变更,在开发之前,返工的工作量也会很小。 

?  界面设计的前奏。作为界面设计的基础,在客户需求确定之后,就在此基础上进行设计开发,通常地说,也是一个增量式的系统原型。 

?  仿真界面的签字确认,是需求确认的重要部分。在客户确认需求时,仿真界面也要得到客户的认可。 

系统仿真界面,与实际系统的主要区别是:后台部分没有代码,界面基本相同,如图所示,“XX系统”的仿真界面。

小结 
?  做好客户需求需要考虑的因素很多,也不可能三言两语能够说清,任何一个细节处理不当,都有可能带来风险,本文的主要是结合项目实例,将自己的体会与大家分享。 

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
云计算
使用钉钉扫一扫加入圈子
+ 订阅

时时分享云计算技术内容,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。

其他文章