需求调研步骤与方法.doc
- 文档编号:2614459
- 上传时间:2022-11-03
- 格式:DOC
- 页数:4
- 大小:35KB
需求调研步骤与方法.doc
《需求调研步骤与方法.doc》由会员分享,可在线阅读,更多相关《需求调研步骤与方法.doc(4页珍藏版)》请在冰豆网上搜索。
第一章:
前言
目的:
需求调研是为需求说明书做前期工作,可以说需求说明书说是从需求调研表中得到或抽取而出。
需求调研是要了解现实世界中做实际工作的人们真正需要什么样的程序的过程,再把这些需求展开细节整理由设计部开发,再由销售部销售给用户。
标注:
调研顾名思义就是调查和研究客户的想法,我感觉应从以下几个步骤入手:
客户想要什么?
认真倾听客户说话,因为客户在说的时候,他多半同时在想自己要什么东西。
他说完了,轮到咱了,首先复述客户需求,在复述的同时我们就可以发表建议了。
此时态度要把握好,要把客户的需求合理化、简单化。
说白了就是程序别太复杂,风险能排全排除掉,别搞个逻辑又复杂又不实用的东西出来。
客户要这干什么用?
听完所有的需求,提炼出客户所要东西的重点,围绕重点开始研究,复述客户的需求。
作事千万别说:
“我以为”。
别怕麻烦,现在多说几遍大家都还是客气,比以后大家对需求有争执强。
他为什么这么想?
客户大多不是IT专家,大多是行业专家,对自己所作的行业至少对本公司的行业流程比较清楚,所有我们就需要搞清楚他们的行业流程或说业务逻辑,看看他们到底想让我们用程序为他们实现什么功能,他们要干什么?
会不会有别的想法?
通过以上四步我们的目标是:
搞清客户的要求,找出要求的逻辑,客户想要的结果,同时排除开发的风险,挖掘与控制潜在的要求。
需求调研的目的是:
双方对未来产生结果的认同,达成共识的基础是双方对结果均有理解,而不能一味期望客户提供他们的要求。
第二章
2.1.确定工具
没有什么工具是好还是坏的问题,问题是关键是如何使用它们,无论是什么工具也只是一个辅助工具,也不是生成工具。
工具的选取要求是自己(本组)熟悉的工具,不能是一件最新时髦工具而自己对它了解很少,结果大部分时间花在学习工具上,而不是使用它为你工作。
工具最好也是要求是普通流行的,因为要考虑交流的问题。
2.2.要做什么就要先了解什么
如果做的项目是你所不了解的一个行业,同组最好要有专家----最终用户做为这个专家是最好的,最少你有了解这个专业,不是要你成为专家,但最少要了解一定的专业知识(最少专有词汇你要知道),不然您甚至不知道去问什么问题或者如何去问他们,甚至于人家在说什么你也不知道。
相应的专业资料是必须的,最少要有专业入门书籍和对应的资料,也需要有更深入的一些资料。
当然有专家的参入就另当别论。
如果行业的难度不是很大,可以通过分析人员的自我学习在短时间内了解行业,也许可以不用专家,否则专家是必须的。
【读后感】充分做好准备,尽可能了解客户所在行业的信息,学习专业术语;请教客户行业中人,找出令他们苦恼的问题。
2.3.建立设计环境
一定建立一个专门的设计环境来为本项目服务,进行一定的资源分配,进行必要的文件管理。
2.4.真正了解自己和用户
哪些是用户明确要达到的目地;要知道哪些是自己能做到的,哪些是自己不能做的;对于不能做的处理方法,如拒绝,转包等;那些是用户想要做到的。
2.5.列出人员分配表和所有工具列表
明确项目人员分工;统一项目所用的工具;统一项目文件模版;其它资源列表(资料,相关网站,资询电话...)。
【读后感】:
项目管理的工具可以参考使用任务跟踪管理ToDoList、信息管理系统myBase和思维导图MindMapper,在需求调研过程中,应该做好三种准备,保持两种心态,做到五种提高:
三种准备:
1)调研前应该将所有项目前期资料进行汇总,与相关的前期销售人员进行交流,以便对项目有一个基本轮廓认识。
2)做好调研前使用资料的准备,如需求调研模板,需求调研问题列表,需求调研资源列表,演示用的已有产品(通过演示已有产品,引导客户在我们拥有的技术上讨论细节而不是空谈。
)
3)做好不怕一切困难的准备。
两种心态:
1)保持一种和客户平等合作的心态,确定需求调研是为了给客户解决问题,探讨问题,而不是接受问题,更不是来指导工作的。
2)平静面对需求变更的心态,在需求调研过程中,往往双方对需求理解不一致,造成需求调研前后矛盾,应当心平气和的去引导客户,达到需求理解基本一致。
三种提高:
1)首先提高自己业务知识,对于人力资源的标准业务应该基本熟悉。
2)其次应该努力的去熟悉用户的行业,学习用户使用的术语和标准,以便能够准确的理解用户。
这就需要我们阅读用户所在行业的资料、文章,尽量多选取一些整体性介绍的文章,这样可以在短时间内能够对该行业有一个全面的认识,这样我们就能够较好的和用户进行交流了。
3)需求调研中,学会尽量不使用IT行业的术语,而采用浅显易懂的口头语言来解释IT行业中高深莫测的术语,以便用户能够很好的理解,提高自己的沟通交流能力。
4)提高自己的速记能力,文字表述能力以及归纳,能迅速的记录需求调研核心的问题,总结归纳形成原始的需求调研资料。
5)提高自己的总结能力,书写一份完整的、前后一致的、可追踪的需求报告。
第3章调研过程
3.1.搜集需求得到需求说明书
注意:
虽然最终必须要编成基于计算机解决方案的描述,但到目前为止,我们关注的焦点的文档在相应领域方面的部分。
记住这里没有计算机方面的行话,如果是编写一个会计软件,那么一位会计师都应该清楚地理解程序员写的会计方面的问题说明书。
需求说明书问题中,不要太正式。
只要描述能表达您想要做的事情就行了,就和另外一个人在说话一样就可以。
对于客户或相应人员了解问题时,一定要有记笔记的习惯,谈上几个小时,很多细节是记不住的。
3.2.整理,检查和细化需求说明书
对于客户的需要进行必要的整理和分类,从用户那里会得到很多信息,不进行必要的整理就不能从中进行合理的分析。
分清有用功能、可选用功能、无用功能及不可实现功能。
对于用户来讲他可以说出他想要的很多功能,但这些功能间的关系有时是清晰的,但对于很多用户来讲想通过计算机或新系统实现他以前没有的功能,在这时他所提出的新需求的可行性和与其它模块之间的关系就已经不清,所以对于分析员来讲,要从用户的需求中分清有用功能和无用功能和可选功能,进行分别区分处理,比如不可实现功能请用户放弃。
不要忽略明显的错误:
用户倒是不经常提及他需要的东西,而这些东西对问题来说都是很基本的,要细化检查一定有注意这个问题。
你认为的也许不是对的:
对于系统分析员对需求分析的自认为的情况要加以注意,对于一个行业来说,有些规则可以不是最合理,但它就是那样存在和使用,所以对于每一个非明确确定的需求,要由专业人员来审定。
除非你就是专家。
3.3.改进
最初的第一次需求在分析,细化一定有不明及不确定之处,那么就把整理出一份问题细化问询表,对发现的问题进行整理,列出不明之处,可根椐以下格式:
问询人:
问题:
业务不清问题列表(业务描述不清):
1….是什么含义?
2…..与XX是什么关系?
多种选择可以列表(请用户进行选择):
1……有多个可能,那么现在我们使用
A……B…….C……..D……
把问询表提交用户,根据反馈对需求再分析,这个步骤可重复多次,最终了解需求,确定需求说明书
3.4.审核需求
自我审核:
把自己从用户的角度来考虑,是否合理,是否可以提高效率,是否可以达到目的,是否有完整。
由用户来评价:
由最终用户来评价你所列的需求是否达到了用户要求(用户人数1-3人,再多也没有什么益处)。
重复过程,最终通过审核完成需求说明书。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 调研 步骤 方法