和困难
(1)在沟通过程中,开发方与需求方双方工作范围没有具体明确,急需双方共同确定职责范围。软件开发方、软件需求方双方在项目开展过程中负责什么样的具体工作,不应该负责哪些工作,互相之间没有明确,导致工作责任不明确,出现问题后互相推卸[6] 。
(2)软件开发方、软件需求方双方各类人员的职责权利关系需要互相申明。比如是否上下属关系或者其他关系以及相互调遣权限。
(3)存在的突出问题是:软件需求方部分需求不能完整确认。由于软件需求方管理层人员的变动和管理决策的变化而导致项目需求有经常性变化[7] 。软件需求方不同部门的管理不统一,导致软件需求在具体相关部门前期开发调研的内容和后期试用时得到的需求内容有较大差别,甚至产生冲突[8] 。
(4)软件开发方作为进驻的定制项目,开发方需要软件需求方的大力支持和帮助,所以在遇到困难时迫切需要寻求软件需求方相关人员的帮助,软件开发方、软件需求方双方沟通过程中,软件开发方人员强烈感觉到软件需求方内部人员结构复杂,部门间以及部门和领导间的关系有待理顺。
3.2 通常获取需求的方法
(1)获取需求的来源:需求主要来自客户、合作伙伴、最终用户以及该领域的专家等几个方面。而通常需要掌握如何准确判断需求应来源于哪方面,谁是最真实的需求者,如何接近这些来源并从中获取信息。
(2)获得需求的方式:主要有现场考察、访谈、集体讨论、电话询问、问卷调查或者阅读用户编制的相关文件等。
(3)常规需求文档:其中每项工作都应该有相应的记录文档。如查阅了大量资料的内容与格式、各种应急防御措施、统计分析报表、系统规划书、旧系统业务状况、历史资料等,而其中在访谈过程中了解到的操作员的应用感受、技术交流与讨论以及其他各种形式的交互式讨论和分析等的记录报告,所有这些最终都需要体现在一份详尽的需求说明书中。
3.3 在项目开发中,逐步提出针对以上问题的解决方案
(1)本文认为,在初期常规的需求分析阶段,要求需求分析人员必须充分了解用户的目标与工作过程,设身处地替用户考虑问题,帮助用户将模糊的需求清晰化,将简略的需求明细化、完善化,将混乱的需求逻辑化、条理化。因此,本项目采取的比较有效的做法就是从团队中筛选一名经验丰富(包括深厚的业务和技术背景、善于沟通、能吃苦)的队员担任需求工程师,在前期分析阶段驻扎在客户公司,他的工作主要是界定项目的范围和需求变更管理,通过各类规范的模板文档来体现需求内容以及需求变更。其目的就是根据项目目标列表,在初步整理需求初稿的基础上,请业务部门专门进行分析提出修改需求意见,以及在最初阶段最终确认。由于软件需求方和软件开发方的背景不同,对同一问题的理解存在差异,这些差异如果不能在需求的最初阶段尽量弥合,那么必然导致需求增加与需求更改。
(2)任何项目都有需求变更与需求增加,这是IT项目中令人很头疼的问题。随着客户对需求可实现度的理解,IT项目客户的需求变更要比其他类型的项目变更多得多。所以,一方面我们必须将这种变更尽早完成在初期常规需求分析阶段,所使用较多的技术手段是模型法,让客户了解可能具有的功能。但另一方面,除了在需求收集阶段需要尽可能将需求细化、在后续阶段在不影响进度的前提下满足用户的变更需求外,还需要在适当的阶段尽量冻结一些不急需的需求,才不至于使项目陷入一种十分纠结的状态。当然,这还涉及后期需求增加的费用以及支付方式和客户达成共识的问题。
(3)整个项目下来,感觉到需求分析书不仅仅是初期常规需求阶段的一个成果,它更是整个开