‘壹’ 如何写一份易用的产品需求文档
我很少会写传统意义上的产品需求文档;甚至,我连word都很少用。用惯了Axure的任意布局方式,再用word感觉非常别扭,尤其是在添加图片时,简直感到捉急。当然,这不是我不用word写需求文档的根本原因。简单来谈一下,为什么软件开发项目中,需要需求文档这么个东西?在稍微大一点的开发团队中,产品经理未必能向所有开发人员,传达具体的产品开发需求。这时就需要一份文档来供所有的项目参与人员阅读。而产品经理又常常爱拍脑袋、容易变卦,所以文档也是开发人员约束产品经理的一项武器。在产品上线前的测试环节,测试人员也同样会拿产品需求文档来验收产品质量。当团队进入新人时,文档也可以让新人更快地了解产品。总的来说,产品需求文档有三个核心作用:
1.传达产品开发需求;
2.保证各部门沟通有理有据,
3.产品质量控制有具体标准
由此可见,产品需求文档是必不可少的。那一份好的需求文档,就应该能准确传达出产品的开发需求。那么产品需求文档该用什么方式写,才能更好地传达出产品开发需求呢?就我所见,行业大多产品经理都是用Word+Axure原型的方式组成产品需求文档。那这种方式,是否真的能方便地表达出产品需求?我问了很多程序猿,他们在开发时,一般都是看着效果图和原型图写代码,只有在遇到问题时,才会查看word文档。也就是说,开发需要一边写代码,一边看效果图,一边看原型,还要时不时查看文档。而且,大多数程序猿都不会逐字逐句去读产品经理的长篇大论。那产品经理写word真的合适吗?这样的用户体验真的好吗?花费大量时间写word真的有价值吗?在Axure画原型的同时,我们为什么不能直接在旁边标注呢?这样岂不是方便快捷很多吗?其实,当下流行一种直接在原型图上标注的需求文档撰写方式。在新版的Axure8中,也已经推荐了原型加标注的需求文档样式。Axure8新增了一组部件—不干贴,就是方便产品设计人员进行功能标注。这份需求文档是我打磨一年,所产出的。目的就是希望打造出一份易于团队协作的产品需求文档。之所以不贴出源文件的下载链接,也是希望其他产品人看到后,可以有所启发,从而做出合适自己团队的需求文档。不发任何原文件或HTML文件。
‘贰’ 怎样写一个系统的需求分析一般都包括哪些内容
方法 ⑴首先调查组织机构情况 包括了解该组织的部门组成情况,各部门的职能等,为分析信息流程作准备。 ⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据,如何加工处理这些数据,输出什么信息,输出到什么部门,输出结果的格式是什么。 ⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。 ⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成,哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。 常用的调查方法有: ⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求,但比较耗费时间。 ⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。座谈时,参加者之间可以相互启发。 ⑶请专人介绍。 ⑷询问 对某些调查中的问题,可以找专人询问。 ⑸设计调查表请用户填写 如果调查表设计得合理,这种方法是很有效,也很易于为用户接受的。 ⑹查阅记录 即查阅与原系统有关的数据记录,包括原始单据、账簿、报表等。 通过调查了解了用户需求后,还需要进一步分析和表达用户的需求。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
‘叁’ 需求分析常用方法
行为事件分析
行为事件分析是根据运营关键指标对用户特定事件进行分析。通过追踪或记录用户行为事件,可以快速的了解到事件的趋势走向和用户的完成情况。
以用户投标的行为事件为例,出借人在完成投标过程中,所进行的注册、认证、开户、充值、投资等行为,都可以定义为事件,也是完成投标成功的一个完整事件。
确定投标行为事件后,我们可以根据事件属性细分维度:用户来源、性别、出生年月、注册时间、绑卡时间、首次充值时间、首次投资时间、标的ID,标名、期限、利率、还款方式等。然后从中找出符合指标的规律,并制定针对性的措施。
用户留存分析
用户留存分析是一种用来分析用户参与情况与活跃程度的模型。通过留存量和留存率,可以了解用户的留存和流失状况。比如用次日留存、周留存、月留存等指标来衡量产品的人气或粘度。以渠道访问的用户留存为例,我们对APP端有过访问行为的渠道用户进行留存分析。用户留存一般符合40-20-10法则,即新用户的次日留存应该大于40%,周留存大于20%,月留存大于10%才符合业务标准。我们做用户留存分析主要验证是否达到既定的运营目标,进而影响下一步的产品决策。
漏斗模型分析
漏斗模型分析是用户在使用产品过程中,描述各个阶段中关键环节的用户转化和流失率情况。比如在日常活动运营中,通过确定各个环节的流失率,分析用户怎么流失、为什么流失、在哪里流失。找到需要改进的环节,要重点关注,并采取有效的措施来提升整体转化率。
邀请人将活动专题页分享给好友,之后进行的注册、认证、开户、充值到投资,用漏斗模型分析一些关键节点的转化率。其中用户注册转化率为68%,实名认证转化率为45%,绑卡开户转化率为29%,线上充值转化率为17%,投资标的转化率为8%。
漏斗模型分析可以验证整个流程的设计是否合理。经过对比发现,访问到注册的转化率为68%,远低于预期的80%。这次运营策略是用户必须先注册才能领取新手福利。之后采取A/B测试的方式,优化为先领取新手福利再诱导用户注册。经过数据对比分析,注册转化率提升了20%。因此,通过对各环节相关转化率的比较,可以发现运营活动中哪些环节的转化率没有达到预期指标,从而发现问题所在,并找到优化方向。
行为路径分析
行为路径分析就是分析用户在产品使用过程中的访问路径。通过对行为路径的数据分析,可以发现用户最常用的功能和使用路径。并从页面的多维度分析,追踪用户转化路径,提升产品用户体验。
不管是产品冷启动,还是日常活动营销,做行为路径分析首先要梳理用户行为轨迹。用户行为轨迹包括认知、熟悉、试用、使用到忠诚等。轨迹背后反映的是用户特征,这些特征对产品运营有重要的参考价值。我们可以记录用户从注册、认证、开户、充值到投资的行为轨迹。通过分析用户的这些行为轨迹数据,来验证访问路径是否和预期指标的一致。
‘肆’ 怎么写需求分析
一、需求分析的目的
需求分析是一项软件工程的活动,其目的包括以下几点:
完整地获取用户要求,清楚地理解索要解决的问题;
描述清楚软件的功能和性能;
指明软件与其他系统元素的接口;
建立软件必须满足的约束(如运行环境等)。
二、需求分析的任务
需求分析是研究用户要求,以得到目标系统的需求定义的过程。需求分析的基本任务是软件开发人员和用户一起完全弄清用户对系统的确切要求。具体步骤包括下面几点。
1. 需求获取
调查研究的方法有访谈、分发调查表或开会等。
(1)访谈 :正式访谈和非正式访谈 。
(2)分发调查表:调查表中列出需要的内容,让用户书面回答问题。
(3)开会 :可采用开会-讨论-确认的方法进行调查。
2. 需求建模
需求分析建立起来的模型为日后的软件设计提供了可被翻译成数据、体系结构、接口和处理过程设计的模型。
2.1软件需求的层次
1).业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明。
2).用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例(usecase)文档或方案脚本说明中予以说明。
3).功能需求(functional requirement) 定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求
‘伍’ 如何写业务需求
需求分析是一项重要的工作,也是最困难的工作。该阶段工作有以下特点:
(1)用户与开发人员很难进行交流
在软件生存周期中,其它四个阶段都是面向软件技术问题,只有本阶段是面向用户的。需求分析是对用户的业务活动进行分析,明确在用户的业务环境中软件系统应该"做什么"。但是在开始时,开发人员和用户双方都不能准确地提出系统要"做什么?"。因为软件开发人员不是用户问题领域的专家,不熟悉用户的业务活动和业务环境,又不可能在短期内搞清楚;而用户不熟悉计算机应用的有关问题。由于双方互相不了解对方的工作,又缺乏共同语言,所以在交流时存在着隔阂。
(2)用户的需求是动态变化的
对于一个大型而复杂的软件系统,用户很难精确完整地提出它的功能和性能要求。一开始只能提出一个大概、模糊的功能,只有经过长时间的反复认识才逐步明确。有时进入到设计、编程阶段才能明确,更有甚者,到开发后期还在提新的要求。这无疑给软件开发带来困难。
(3)系统变更的代价呈非线性增长
需求分析是软件开发的基础。假定在该阶段发现一个错误,解决它需要用一小时的时间,到设计、编程、测试和维护阶段解决,则要花2.5、5、25、100倍的时间。
因此,对于大型复杂系统而言,首先要进行可行性研究。开发人员对用户的要求及现实环境进行调查、了解,从技术、经济和社会因素三个方面进行研究并论证该软件项目的可行性,根据可行性研究的结果,决定项目的取舍。
编辑本段方法
⑴首先调查组织机构情况
包括了解该组织的部门组成情况,各部门的职能等,为分析信息流程作准备。
⑵然后调查各部门的业务活动情况
包括了解各个部门输入和使用什么数据,如何加工处理这些数据,输出什么信息,输出到什么部门,输出结果的格式是什么。
⑶协助用户明确对新系统的各种要求
包括信息要求、处理要求、完全性与完整性要求。
⑷确定新系统的边界
确定哪些功能由计算机完成或将来准备让计算机完成,哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。
常用的调查方法有:
⑴跟班作业
通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求,但比较耗费时间。
⑵开调查会
通过与用户座谈来了解业务活动情况及用户需求。座谈时,参加者之间可以相互启发。
⑶请专人介绍。
⑷询问
对某些调查中的问题,可以找专人询问。
⑸设计调查表请用户填写
如果调查表设计得合理,这种方法是很有效,也很易于为用户接受的。
⑹查阅记录
即查阅与原系统有关的数据记录,包括原始单据、账簿、报表等。
通过调查了解了用户需求后,还需要进一步分析和表达用户的需求。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
编辑本段案例
(1)需求分析报告的编写目的
本需求分析报告的目的是规范化本软件的编写,旨在于提高软件开发过程中的能见度,便于对软件开发过程中的控制与管理,同时提出了本铁路售票系统的软件开发过程,便于程序员与客户之间的交流、协作,并作为工作成果的原始依据,同时也表明了本软件的共性,以期能够获得更大范围的应用。
(2)产品背景明细
软件名称:铁路售票系统
(3)缩写及缩略语
铁路售票应用系统软件:基本元素为构成铁路售票及相关行为所必须的各种部分。
需求:用户解决问题或达到目标所需的条件或功能;系统或系统部件要满足合同、标准,规范或其它正式规定文档所需具有的条件或权能。
需求分析:包括提炼,分析和仔细审查已收集到的需求,以确保所有的风险承担者都明其含义并找出其中的错误,遗憾或其它不足的地方。
模块的独立性:是指软件系统中每个模块只涉及软件要求的具体的子功能,而和软件系统中其他的模块的接口是简单的。
本工程描述:
(1)软件开发的目标:
完善目前铁路售票系统,使之能跟上时代的发展。同时通过实践来提高自己的动手能力。
(2)应用范围:
理论上能够实现于铁路部门的售票系统,其目的在于在原有的系统基础使得铁路售票实名化,以期实现完善日常生活中铁路售票的各种缺陷。
‘陆’ 项目需求分析怎么写
项目需求分析的概念需求分析是指理解用户需求,就软件功能与客户达成一致,估计软件风险和评估项目代价,最终形成开发计划的一个复杂过程。(这个和我在微软体验到的又不太一样,微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度,这一点也可以理解,因为公司的性质有根本差别)在这个过程中,用户的确是处在主导地位,需求分析工程师和项目经理要负责整理用户需求,为之后的软件设计打下基础。需求分析阶段结束后,要求得到:1.SRS文档(System Requirement Specification); 2.DRM 文档;3.Acceptance Plan. 从广义上理解:需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解:需求分析指需求的分析、定义过程。 一、为什么要需求分析需求分析就是分析软件用户的需求是什么.如果投入大量的人力,物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.
需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.
问题识别
就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括:功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率),安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.
分析与综合
逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).
制订规格说明书
即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.
评审
对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。 四、需求分析的方法需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.
原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.
原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统,针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:先构造一个功能简单而且质量要求不高的模型系统,作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求,发展成为最终系统。进化型属于这种策略.
‘柒’ 如何写一份人才需求及跟进报告
工作计划的格式和要求工作计划是一个单位或团体在一定时期内的工作打算。写工作计划要求简明扼要、具体明确,用词造句必须准确,不能含糊。(一)工作计划的格式:1.计划的名称。包括订立计划单位或团体的名称和计划期限两个要素,如“育才二中××组2008—2009年度下学期工作计划”。2.计划的具体要求。一般包括工作的目的和要求,工作的项目和指标,实施的步骤和措施等,也就是为什么做、做什么怎么做、做到什么程度。3.最后写订立计划的日期。(二)工作计划的内容。一般地讲,包括:1.情况分析(制定计划的根据)。制定计划前,要分析研究工作现状,充分了解下一步工作是在什么基础上进行的,是依据什么来制定这个计划的。2.工作任务和要求(做什么)。根据需要与可能,规定出一定时期内所应完成的任务和应达到的工作指标。3.工作的方法、步骤和措施(怎样做)。在明确了工作任务以后,还需要根据主客观条件,确定工作的方法和步骤,采取必要的措施,以保证工作任务的完成。(三)制订好工作计划须经过的步骤:1.认真学习研究上级的有关指示法。领会精神,武装思想。2.认真分析本单位的具体情况,这是制订计划的根据和基础。3.根据上级的指示精神和本单位的现实情况,确定工作方针、工作任务、工作要求,再据此确定工作的具体法和措施,确定工作的具体步骤。环环紧扣,付诸实现。4.根据工作中可能出现的偏差、缺点、障碍、困难,确定预算克服的法和措施,以免发生问题时,工作陷于被动。5.根据工作任务的需要,组织并分配力量,明确分工。6.科组计划草案制定后,应交全体人员讨论。计划是要靠群众来完成的,只有正确反映群众的要求,才能成为大家自觉为之奋斗的目标。7.在实践中进一步修订、补充和完善计划。计划一经制定出来,并经正式通过或批准以后,就要坚决贯彻执行。在执行过程中,往往需要继续加以补充、修订,使其更加完善,切合实际。
‘捌’ 如何快速的写好需求
碰到任何问题,最长见的思维方式即为:问题三要素——是什么、为什么、怎么做。这是几乎所有行业、所有人群面对事情时,最常见的思维方式。
笔者认为基于最经典、高效、实用的思维方式的基础上,可以每个人针对不同的知识体系、思考方式、经验总结等维度,总结出自己的思维方式。
笔者常使用的方式为多年前从社会经济学老师那里学来的,做了补充和优化,分享给大家:
在特定的时间、特定的地点、特定的人群因为特定的原因而做了特定的事件。达成该特定事件前,有哪些预期,实际达成的效果是什么样的,中间有怎么的落差,以后处理该类事件时,如何优化方式。
按照上述思维方式,我们将要写的需求文档当做一个特定的事件,通过剖析该特定事件被触发的前置条件、后置补充内容,来实现对需求文档的分析。
二、什么是需求文档?
笔者将需求文档定义为:用于阐述产品,满足协同人员开发的内容文档。该定义中有两个重要点:
1. 阐述
即为说明要开发的产品是什么。此处的“是什么”区别于产品说明文档,产品说明文档类似于商品说明书,用于告知使用者我的产品该怎么使用。
而此处的“是什么”是告知该产品的相关人员,该产品有哪些功能,这个功能要怎么呈现,该怎么实现。具体包含以下几个方面:
(1)为什么要做这个产品?
该产品是来自哪里的需求,是内部版本迭代优化、Bug修复、新增功能点,还是来自业务部门的需求,或者来自用户的反馈需求。
必须交代清楚做该产品的项目背景,一方面有利于开发人员更好的了解整体项目,从而更顺利地制定项目计划、项目进度、项目达成;
另一方面,产品开发完成后存档的文档,有助于后续对该产品的复盘、版本迭代,Bug问题溯源,甚至对出现人员异动时,有助于接盘人员快速了解项目,熟悉产品整体的前因后果。
(2)该产品要解决哪些冲突?
需求来自于用户的冲突,用户在使用中遇到了什么困难、疑惑、焦虑等不可调和的问题等待被解决。
在与用户开展调研、访谈等沟通时,充分了解用户的冲突,及急需解决的痛点,有助于产品经理在产品规划阶段,更精准地把握好方向,做出更符合用户诉求的产品。
同时,在了解冲突的沟通中,除了精准获取到用户的核心诉求,还会得到很多非核心诉求,这些来自于用户潜意识中的需求,为以后产品的发展提供了很好的帮助。
将这些需求罗列出来,整理到需求池,有助于以后与用户、业务进行再次沟通时作对比,从而去伪存真,对需求池中的需求做好优先级排序,并根据实际业务发展阶段和公司整体要求,划分好产品阶段,对需求池中的需求进行实现,从而促使产品朝向更好的方向发展。
(3)该产品实现了哪些目的?
任何产品的实现,不仅仅要满足用户的需求,更要在解决冲突时达成更多的目的。而这个目的分为物质层面和精神层面两个维度。
1)物质层面
产品的上线,解决了公司业务层面的流程,满足了业务需要,满足了用户的使用,这是产品首要,且是最核心的目的。
而在满足最核心目的之后,是否有一些延伸的产品需求——减少了操作步骤、优化了交互流程,为实现公司层面的获客、激活、留存、转化、二次推广等各环节起到促进作用。
2)精神层面
产品的上线,解决了用户的困难、疑惑和焦虑,解决了业务部门无法正常使用过程中的烦躁不安,这是产品最核心的目的在用户心里的反馈。
同时,在解决用户优先级最高的负面情绪的前提下,使得用户对产品的感官,对企业品牌的好感度提升,是产品上线所能达成的最好效果了。
2. 满足协同人员
即该需求文档是给哪些协同人员看的。此处的“协同人员”不仅仅是开发人员,而是产品从交付原型至最终上线,过程中所涉及的所有参与者。
这些协同人员基于各自岗位和职责,对需求文档的要求也是不一样的,这是所有产品经理在编写需求文档时应尤为注意的点。
‘玖’ 需求分析怎么写
1、功能分解方法。
将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口,子功能再继续分解。便可得到系统的雏形,即功能分解——功能、子功能、功能接口。
2、结构化分析方法。
结构化分析方法是一种从问题空间到某种表示的映射方法,是结构化方法中重要且被普遍接受的表示系统,由数据流图和数据词典构成并表示。此分析法又称为数据流法。
其基本策略是跟踪数据流,即研究问题域中数据流动方式及在各个环节上所进行的处理,从而发现数据流和加工。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。
3、信息建模方法。
它从数据角度对现实世界建立模型。大型软件较复杂;很难直接对其分析和设计,常借助模型。模型是开发中常用工具,系统包括数据处理、事务管理和决策支持。
实质上,也可看成由一系列有序模型构成,其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。
(9)如何写一份需求方法扩展阅读:
需求分析的特点
1、确定问题难。主要原因:一是应用领域的复杂性及业务变化,难以具体确定;二是用户需求所涉及的多因素引起的,比如运行环境和系统功能、性能、可靠性和接口等。
2、需求时常变化。软件的需求在整个软件生存周期,常会随着时间和业务而有所变化。有的用户需求经常变化,一些企业可能正处在体制改革与企业重组的变动期和成长期,其企业需求不成熟、不稳定和不规范,致使需求具有动态性。
3、交流难以达到共识。需求分析涉及的人事物及相关因素多,与用户、业务专家、需求工程师和项目管理员等进行交流时,不同的背景知识、角色和角度等,使交流共识较难。
‘拾’ 需求分析具体要怎么写要包括哪些内容
方法⑴首先调查组织机构情况 包括了解该组织的部门组成情况,各部门的职能等,为分析信息流程作准备。 ⑵然后调查各部门的业务活动情况 ⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。 ⑷确定新系统的边界 常用的调查方法有:⑴跟班作业通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求,但比较耗费时间。 ⑵开调查会通过与用户座谈来了解业务活动情况及用户需求。座谈时,参加者之间可以相互启发。 ⑶请专人介绍。 ⑷询问对某些调查中的问题,可以找专人询问。 ⑸设计调查表请用户填写 如果调查表设计得合理,这种方法是很有效,也很易于为用户接受的。 ⑹查阅记录即查阅与原系统有关的数据记录,包括原始单据、账簿、报表等。 通过调查了解了用户需求后,还需要进一步分析和表达用户的需求。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。