软件项目需求调研方法论

软件项目需求调研方法论
软件项目需求调研方法论

需求调研方法论

文件版本:文件编号:编制人:编制日期:审核人:审核日期:批准人:批准日期:

修改记录

版本号修订人修订日期修订描述

目录

1需求概述 (4)

1.1软件需求 (4)

1.1.1需求定义 (4)

1.1.2需求层次 (4)

1.1.3需求来源 (4)

1.2需求调研定义 (5)

1.3需求调研目的 (6)

1.4需求调研必要性 (6)

1.5需求调研是否可裁剪 (10)

1.6需求调研启动时机 (10)

2需求调研过程 (11)

2.1调研实施前活动 (11)

2.1.1识别调研范围 (11)

2.1.2组建调研团队 (11)

2.1.3确定调研方案 (12)

2.1.4调研准备 (16)

2.1.5前期沟通 (18)

2.2调研实施 (18)

2.2.1调研实施 (18)

2.2.2调研注意事项 (22)

3编写用户需求规格说明书 (23)

1需求概述

1.1 软件需求

1.1.1需求定义

需求是用户一种期望,是用户期望改善现状,解决某些问题或达到某种目标的需要。需求实现的过程,就是通过软件产品的功能达成用户目标,使之与用户期望目标相符的过程。

1.1.2需求层次

软件需求的三个层次

1.业务需求:反映了组织机构或用户对系统、产品高层次的目标要求。

2.用户需求:描述了用户使用产品必须要完成的任务。

3.功能需求:定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足业务需求。

4.非功能性的需求:不直接完成用户完成某项工作,但是在用户在操作系统过程中伴随产生的需要,描述了系统展现给用户的行为和执行的操作等,它包括产品必须遵从的标准、规范和约束,操作界面的具体细节和构造上的限制。

1.1.3需求来源

软件需求可以来自方方面面,这取决于所开发产品的性质和开发环境。

下面是几个软件需求的典型来源。

1. 访谈、调查用户或潜在用户

为找出新软件产品的用户需求,最直截了当的方法是询问他们。通过直接与最终用户的访谈或调查,了解用户目前管理或应用过程中存在的问题、思想或想

法、业务未来发展趋势,经过整理分析,形成软件需求。

2. 研究竞争对手同类产品

当用户在实际工作中产生出新的需求后,总会有对需求感觉灵敏的厂商嗅到商机,把用户的需求转换为产品。在我们没有更好条件深入到客户中进行调研的情况下,可以对竞争对手同类产品进行研究,发掘产品中的优点和存在不足,研究产品功能的目的和意义,倒推出软件需求。

3.需求分析人员的经验

需求分析人员要时刻保持对所在领域知识的敏感,勤于思考,结合积累的丰富的所在领域知识,加上自己的分析和判断,形成基于用户实际工作中需求的假设,形成软件需求。

4.市场支持活动

软件产品发布推广后,用户在实际工作中对软件产品进行检验。在市场售后的支持人员在对用户进行培训和提供技术支持工作的同时,他们收集了用户在使用系统过程中所遇到的问题,还接受了用户关于系统改进的想法。因此,可以通过收集市场支持人员接受的系统改进想法,并把它们转换为软件需求。

5. 政策制度和法律法规

公司所在的国家、行业的政策制度和法律法规是企业经营活动过程中必须遵循的规则,对公司活动有强制约束力。研究目标企业所在国家、行业的政策、法规和制度,发现其中信息化相关的要求,经过整理和分析形成软件需求。尤其是当企业所使用的法律法规、政策制度发生变动时,是软件产品更新换代的一个重大契机。

1.2 需求调研定义

通常情况下,用户无法独立直接提出完整、准确的需求,这就需要通过项目

组的介入,借助需求调研把用户已经表述的需求弄清楚,挖掘用户尚未说明的需求。需求调研指通过和用户进行沟通和交流而获取用户的需求的一系列活动,是为编写需求说明书而做的前期工作。换言之,需求调研就是假设用户已经掌握需求,通过某些手段或方法将需求准确、完整的描述出来,以便软件开发的后续活动顺利进行。

1.3 需求调研目的

需求调研就是了解参与实际工作的人们真正需要什么样程序的过程,获取准确、清晰、完整的用户需求信息,编写需求说明书,为后续工作提供依据。

需求调研有三个主要目的:

1、获取准确、清晰、完整的需求,包括功能需求和非功能需求;

2、确定需求的分级,划分需求优先级,指导后续工作;

3、收集调研对象业务资料,预测需求的发展趋势,为软件产品发展方向

提供依据。

1.4 需求调研必要性

1、需求调研是减小用户“期望差异”的关键一步

软件产品作为一种特殊的商品,是软件公司通过有限的技术手段、资源为了满足用户的需要而开发出来的。由于需求“效用”的不可计量,再加上软件产品不能直接创造价值的特殊性,用户就有可能会对最终产品产生“期望差异”,这种“期望差异”会影响用户对软件产品的满意度,影响软件产品的销售。需求调研就是要了解到用户的期望,以期在软件研发过程中减小这种差异,提高用户的满意度。

软件需求也可以说是用户在一定的条件下为了改善管理条件、追逐更大利润

的“欲望”。当欲望得到满足,人们会感到快乐和幸福,这就是“效用”。处于软件产品两端的用户和开发商由于受到客观条件的限制,双发不能传递准确的需求信息,在一开始无法在信息系统的需求上达成一致意见。由于技术能力的局限,用户很难准确地把系统需求传达给开发商;由于业务局限,开发商也很难准确获取用户真实的应用需求。需求信息的不对称和需求描述的错位,容易引起系统设计的缺陷,最终导致系统应用不理想甚至系统失败。

作为客观世界的存在,用户所处环境、思想等的不同,不同用户对同一领域的需求是存在差异的。软件产品是在有限的资源、有限的时间、有限的技术手段和条件下研发出来的,不可能获取所有潜在用户的需求,也不可能满足所有潜在用户的需要,这就需要软件产品确立目标用户,重点关注目标用户的需求。能够获取目标用户的满意,赢得目标用户的认同,促进目标市场的销售,就是一款成功的产品。

作为一家商业的软件公司,其追求的目标是利益最大化,利益的重要来源就是向市场推出更多令人满意的软件产品,获得市场的成功。如何令用户对我们推出的产品满意,是作为软件研发、销售人员时刻警惕和思考的主题。在我看来,让用户满意就是在用户看到、使用我们软件的时候满足其“期望”甚至超出他的“期望”,这就会引起用户的购买欲,从而带来销售机会。而获取、了解用户的期望值,是软件产品能够满足用户期望的先决条件,只有了解了用户的期望,通过产品研发最大限度的实现用户期望,提升用户的满足感,研发出的软件产品才能更好贴近用户的期望,提升用户期望的满足度。

结论:

1)软件产品一定要有目标客户,目标客户的需求才是需要重点关注的;

2)需求调研很重要,是软件产品能够赢得市场的先决条件,是任何软件公司、软件研发人员必须重视的一个环节。

3)需求调研和分析是信息化建设的第一步,牵一发而动全身,做好需求调研是软件产品成功的关键一步。

2、需求变动大,可能是因为需求不完整、不清晰。

参与过软件研发的很多人都有这样的抱怨“用户需求又变了,截至今天已经变了3次,很多工作得重新返工,真不知道下次还会不会变了。”,尽管无奈,又不得不对改变的需求重新评估、设计、开发、测试,这些变更不只是加大了软件研发的成本,对研发人员的积极性也是一种挫伤,降低了研发人员的成就感。

尽管需求发生变化时,对软件研发影响很大,但往往需求变更又是不可控的,需求变化是客观存在的,是作为软件研发人员必须正视和面对的问题随着目标用户的变化,目标用户认知的提高、用户内部环境的变化、外部境的变化、技术的进步等,需求也总是在不断改变的,往往是在前期需求得到满足后,会产生出更高层次的需求。

诚然,为保证软件研发的顺利进行,保证软件产品的按时交付,我们要对需求加强管理,控制需求变更,但是面对变更,我们更应该考虑如何减少变更发生的机会,让我们更多掌握研发的主动权。更何况控制需求变更,不可避免的要牺牲用户的满意度,在软件产品还没有交付到用户手中时,已经产生了“期望差异”,势必对产品的销售造成影响。

换个角度看这个问题,用户的需求总是发生变化,很有可能是我们原本就没有完全获取用户的需求,或者没有挖掘出用户隐含的需求,研发所依据的需求是不完整、不清晰的。通过需求调研,是获取完整、清晰用户需求的很好途径,有了完整、清晰需求作为研发依据,可以很好降低需求发生变化的几率。

结论:

1)需求变化是客观存在的,作为软件研发人员必须保持良好心态处理好需求变更;

2)需求在一定的时间范围、一定的环境下(经济环境、组织结构、发展期间、IT 应用水平)、一定的用户群体范围内是确定的,或者说是相对确定的。

3)加强需求管理,进行需求调研,尽快、尽早获取完整、清晰需求是比控制需

求变更更好的办法;

3、错误越早修复成本越低

需求阶段是软件研发中的一个重要阶段,其成果是研发后续各阶段工作的重要依据,对研发有着重大影响,需求质量的高低往往决定着一个项目的成败。做好需求调研是获取完整、准确、清晰需求的前提,准确的需求是项目成功的关键。据权威机构对软件各阶段发现错误修复成本的统计,如下图:

从上图可以看出,在软件研发过程中,越到后面阶段修复错误的成本越高,而且往往是需求阶段成本的成百上千倍。进行需求调研,可以尽早使不清晰的需求更加明确,可以对不准确的需求进行修订,补充完善需求,尽早发现错误,尽快修复,减少研发过程中后续阶段的潜在错误数,缩短研发周期,降低研发成本。

结论:

需求调研可以有效减少研发过程中潜在的需求错误数量,降低研发成本。

1.5 需求调研是否可裁剪

在实际的研发过程中,由于外部环境或内部环境的压力,软件研发往往面临着时间紧、任务重的局面,为了能够保证按时交付软件产品,项目管理者往往会选择裁剪或压缩需求调研,而给软件编码和测试预留充足时间,结果往往是项目结束时按期交付了产品,质量如何就不好说了。

在我看来,这样的过程是很危险的,很可能是花费了大量的时间成本和人力成本,得到一个并不被市场认可的产品,公司浪费了人力财力,参与其中的研发人员也不能从中获取成就感。即使软件研发团队面临着工作量大、人员不足、时间紧张的局面,研发团队也不能在不了解需求的情况下直接编码,凭自我感觉做事。

需求不清晰、不完整、不稳定是项目最大的风险,可能导致项目的返工,导致项目延期,最终导致项目的终止。一个有生命力的软件产品,必然要以真实用户的需求为依据,严谨的研发过程为保证,从用户中来,回到用户中去。

需求调研的过程是否可以裁减,我认为是可以的,只要需求是清晰、完整、准确的,并且研发团队与用户对需求的认知是一致的,在这样的条件下,需求调研过程是可以裁减的,但是建议项目团队出具需求文档,便于项目的传承交接。在其他情况下,需求调研过程应该都是不可以裁减的,但可以根据条件选择适合的调研方式。

1.6 需求调研启动时机

从软件研发阶段来看,项目立项后,软件产品范围和目标用户就确定了,产品人员就可以着手准备进行需求调研了。

2需求调研过程

2.1 调研实施前活动

2.1.1识别调研范围

需求调研范围对需求调研过程影响重大,决定了需求调研对象、调研参与人员和调研周期的长短,清晰、准确的需求调研范围是调研活动获得成功的先决条件,在决定进行需求调研后,必须要尽快识别需求调研范围,确定调研内容。

调研范围从宏观上划分了调研内容边界,决定了本次调研的主要内容,可以依据产品范围和预期目标分析目标组织特征和业务特征,确定需求调研范围,划分清楚调研业务边界。

如果一次需求调研范围过大,则可能导致调研实施周期长,调研质量不稳定。在这种情况下,项目管理者可以依据经验把调研范围划分成若干个业务域,识别其中关键的业务域,确定调研重点,便于调研过程的控制。

2.1.2组建调研团队

项目成功的一个重要前提条件就是有一个责权分明、强有力的执行团队。根据项目需求调研工作要求,为及时有效沟通,更好的推进需求调研工作,组建调研团队,可以视项目大小和复杂程度确定人员要求和数量。需求调研工作的参与方包括业务用户和调研实施人员:

1、业务用户:由熟悉调研范围相关业务实际工作的用户组成,负责提出需求,评审需求结果,协助调研实施人员完成需求调研工作;

为保证需求调研的质量,需求调研应该选择尽可能多的用户进行调研,但是由于项目时间和成本上的原因,不可能对所有的用户都进行需求调研,所以要识别出能够确定需求和便于了解业务流程的用户作为每类用户的代表。

系统用户在很多方面存在着差异,例如:知识技能、所处岗位(所进行的业

务过程)、权限、地理上的布局以及个人的素质和喜好等等。根据这些差异,你可以把这些不同的用户分成不同的用户类,从每类用户中选择具有代表性的部分用户作为调研对象。每类用户户至少选择一位能真正代表他们需求的人作为代表并且能够作出决策,用户代表往往是本类用户中三类人:对项目有决定权的领导、熟悉业务流程的专家、系统最终用户。每一个用户代表者代表了一个特定的用户类,并在那个用户类和开发者之间充当主要的接口,用户代表从他们所代表的用户类中收集需求信息,同时每个用户代表又负责协调他们所代表的用户在需求表达上的不一致性和不兼容性。

用户类不一定都指人,也可以包括其他应用系统、接口或者硬件,这样做使得与系统边界外的接口也成为系统需求。将用户群分类并归纳各自特点,并详细描述出它们的个性特点及任务状况,将有助于需求的获取和系统设计。

2、调研实施人员:由熟悉调研业务领域人员组成,负责组织、协调和开展需求调研工作,记录调研内容,编写需求说明书。

调研实施人员是整个需求调研过程的执行者,通过调研实施人员按计划、按步骤的与用户沟通,收集调研范围需求,最终出具需求规格说明书。

调研实施人员的能力和活动对需求调研的进度、质量起着重大影响作用。调研实施人员的组成应以互补为原则,至少由三类人组成:技术人员、业务人员和管理者,根据需求调研范围选择能力与之相匹配的人员参与调研。

确定调研实施人员后,结合调研实施人员能力和调研内容,以充分发挥个人特长和利于需求调研为原则,确定调研实施人员角色,并结合调研范围进行分工。

3、需求调研管理人员:负责需求调研工作的整体工作部署,重大业务、进度等事项的协调,调研进度和质量的控制。

2.1.3确定调研方案

在进行调研前,项目负责人要充分了解参与调研双方的基本情况,依调研对象的工作习惯、业务能力及调研人员能力、调研进度要求等因素选择调研方式。

2.1.

3.1 调研方式

?主导型调研

参与调研的用户对调研范围业务领域内知识、经验不足,没有系统、完整的认识,在调研过程中需要充分发挥调研实施人员的“专家”作用,利用调研实施人员掌握的知识、经验整理需求概要内容,提交给用户进行分析和初步确认,最终由用户和调研实施人员对需求内容进行细化、确认的过程称之为主导型调研。

此种调研方式对调研实施人员能力要求高,调研实施人员可以根据项目时间要求自由安排进行调研,进度风险较低。但是由于缺少业务用户的支持,需求质量往往依赖于调研实施人员的能力,导致需求结果与业务用户的真实意图可能存在偏差,给调研进度和需求质量带来风险。

采用主导型调研方式,调研实施人员不仅要求具备业务领域内知识和丰富经验,还要有良好的沟通协调能力,在调研过程中,要反复和业务用户进行沟通,对双发达成一致的需求必须由业务用户签字确认。

?引导型调研

业务用户在调研业务领域内有较为完整、系统的知识、经验积累,在调研过程中,调研人员利用自身掌握的知识引导业务用户将需求阐述完整、清晰,最终由用户对需求进行确认的过程称之为引导型调研。

此种调研方式的调研过程业务用户和调研实施人员相互配合程度高,调研实施人员可以根据项目进度要求安排调研计划,按计划进行调研。调研实施人员通过引导业务用户提出需求,利用自身的知识积累、职业判断、整理需求信息,由业务用户对需求进行确认,此种调研方式的进度和质量风险最小。

?被动型调研

业务用户强势,且在调研领域内知识、经验丰富,对未来建设系统有较为清晰的认识,在调研过程中采取由业务用户主动说明、阐述需求,调研人员记录、

分析需求的方式,或由业务用户按照调研实施人员要求出具需求的方式,称之为被动型调研;

此种调研方式对调研人员要求最低,但调研人员不能掌握调研进度,无法对收集到的需求质量进行判断,因而进度风险较大。

采用被动型调研方式,调研人员要提前做好调研提纲,把调研内容划分成若干个可独立调研的调研点,并按照调研提纲制定调研计划,按照调研计划进行调研,并在过程中加强监控,发现偏差尽快采取措施,降低进度偏差风险。在调研过程中,把调研对象提出的需求与调研提纲进行比较,分析收集的需求是否全面,保证需求质量。

2.1.

3.2 调研策略

1、由粗到细,从宏观到微观,由外到内,逐步深入

需求调研是一项系统工程,调研过程是围绕业务需求展开的,调研收集的用户需求必须参照业务需求。调研过程必须先从宏观上了解用户业务的整体概况,再逐步依序有计划的深入细节,在过程中不断修正对业务概况的理解,直至完成整个调研活动。因为对于用户的业务而言,我们是外行,如果从业务细节着手,很容易迷失方向,失去对业务核心的把握。同时要认识到,对于一个外行而言,我们对细节的理解也必定是有限的,不要指望自己能够无穷的、彻底的了解每一个细枝末节。一是项目是有计划、有成本控制的,不可能有无限的时间给你了解,二是用户作为业务领域专家,对业务有很好的理解,作为调研实施人员也没有必要熟悉每个细节,因为未来的系统也不可能完全包办所有业务的细节,还有很多事情是要靠用户企业中这些具有专业技能的人来做的。

2、从不同层次的用户代表那里收集不同层次的需求

不同层次的用户由于工作内容、擅长业务等的差异,造成不同层次用户往往对同一业务有着不同层次的需求。作为调研人员,我们要明确知道哪类需求应该从哪个层次的用户获取,并在调研过程中检查需求调研对象的层次和获取需求的

层次是否一致。通过由上到下的逐级访谈,对未来系统的描述就从一个大黑箱变成多个小黑箱,再变成透明、明确、详细的系统定义的过程。

通过调研企业高层决策者,更多的是了解系统预期目标、功能蓝图;通过调研业务操作人员,可以收集业务细节和操作细节。

3、以业务领域为主线,搞清楚每个业务的环节流程关系

1)按照调研内容的关联程度和特征,把调研内容划分成若干个调研主题,先理清楚每个主题的目标以及和其他主题发生的关系;

2)理清楚每个主题内部存在的活动以及和其他主题之间发生的活动,并划分清楚每个活动的边界;

3)针对每个活动进行调研,弄清楚每个活动的流程环节和内容。

2.1.

3.3 调研方法

需求调研方法一般有实地观察法、面谈法、问卷调查法、查阅资料等方法。

1、实地观察法

不和调研对象进行正面接触,而是在旁边对具体业务进行观察,参观调研对象的工作流程,观察调研对象的操作。根据观察收集到的信息,进行整理和分析,出具需求规格说明书。

2、面谈法

与调研对象进行面对面交谈,由调研对象描述业务信息和需求信息,调研人员向调研对象提出事先准备好的问题,并记录访谈过程。经过对访谈过程记录的整理和分析出具需求规格说明书。

3、问卷调查法

调研人员根据调研内容将相关问题制成问卷表格,向调研对象发放调研问

卷,调研对象根据实际业务填写问卷表格,调研人员按时回收问卷表格。调研人员根据收集到调研问卷进行整理和分析,获取需求,出具需求规格说明书。

4、查阅资料法

收集调研对象在调研范围内相关的规章制度、规范指南、工作过程产出等书面资料,并对收集到的资料进行整理和分析,获取需求的方式。对于需求调研来说,访问调查宜采用直接面谈,并且使用非标准化的方式,这样便于发挥和沟通,通过调研过程的互动,可以激发调研对象积极性,收获调研实施前遗漏的需求;问卷调查法是标准化调查,可作为一种辅助手段,对于较为复杂的信息系统调研,不建议问卷调查作为唯一调研方法;而实地观察法和查阅资料法,作为由调研人员主动实施的调研方法,依赖于调研人员的主观判断,有一定局限性,可作为一种辅助手段对收集需求进行判断。

几种常用调研方法比较表:

调研方法调研周期调研成本人员要求调研效果

实地观察法长次高次高中

面谈法次长高低优

问卷调查法中中中良

查阅资料法短低高差

2.1.4调研准备

为确保调研工作的顺利开展,在调研实施开始前,应安排一系列支持性工作,加强团队管理和建设,保障调研工作的顺利进行。

1、编制需求调研计划

需求调研过程是项目的一个阶段,需求调研计划是项目计划的一个组成部分。在需求调研范围、调研团队确定后,调研负责人预估工作量,编制调研计划。

通常来说,需求调研过程是非标准化的过程,在调研的过程中围绕主题进行发散性的探讨,编制需求调研计划,任务的粒度一般只需到业务块,由调研人员把握具体进度,调研人员可以视调研过程的实际情况在“大”计划指导下灵活调整细节计划。

2、编制调研活动使用的文档模版

调研活动的主要成果是记载需求的一系列文档,为便于文档的理解和后期整理、使用,软件需求应使用统一的模版,并按照一致的规范编写,调研过程使用的文档模版主要包括调研记录模版、用户需求说明书模版、软件需求说明书模版等。编写规范和模版确定后,在调研组内进行推广、培训。

3、准备调研过程使用的工具,并分发给参与调研人员,如word、excel、visio

等。

4、制作调研提纲

为确保调研质量,在调研活动实施前,调研人员应根据调研范围编制调研提纲。

调研提纲至少应包括如下几个方面:

1)调研对象的基本情况

2)调研对象的预期目标1

3)调研业务的功能需求

4)调研业务的非功能需求

调研提纲是贯穿于整个调研活动,在调研实施过程中,调研人员可以根据调研提纲引导用户提出需求,检查用户提出需求是否完整;调研结束前,调研提纲是判断调研是否完成的一个重要依据,调研提纲所有内容都已经收集到相关用户需求,调研活动可以宣告完成。

5、调研背景培训

向调研人员介绍本项目的主要目标、项目范围和重点工作,避免在需求调研过程中业务人员所提需求超出范围,抓不住重点;介绍调研对象基本情况,包括调研对象目前总体状况、主要业务、组织机构和关键人物等;

培训调研对象的行业知识,学习调研对象使用的术语,标准,以便能够准确的理解用户的需求,提高调研人员的行业知识面;

2.1.5前期沟通

在调研实施前的准备工作基本就绪,调研工作实施前,由调研工作负责人将调研工作计划、团队及分工等信息告知业务用户,便于业务用户进行调研的相关准备工作。

2.2 调研实施

2.2.1调研实施

一、倾听、记录需求

以用户为主,面对面的进行沟通和交流,完全倾听用户的心声,调研实施随时记录用户所说的一切有用信息,并使用调研记录模版格式记录下自己的认识和问题。用户完成某一主题的表述后,调研人员复述自己记录的需求内容,在复述的同时可以结合自己的认识和记录的问题发表建议,使得记录的需求条理化、合理化。

调研内容应至少包括以下内容:

1. 用户和本行业业务现状及存在问题;

2. 调研对象涵盖业务的组织机构及对应职责和权限;

3. 调研对象主要业务及业务的大概流程,每个业务的流程流经哪些部门,

业务如何在部门之间流转;

4. 调研对象解决问题、改变现状的需求内容。

5. 调研业务未来发展趋势是怎样的?

6. 非功能方面的需求

调研记录是调研人员在调研过程中记录下调研对象的意思表述,是需求最为原始的记录,是进行需求分析、总结的唯一依据。调研记录的质量高低直接决定了需求质量的好坏,写好调研记录不仅要求调研人员如实记录调研对象的真实意图,还需要根据自己的理解将用户繁琐、含糊不清的语言转换为言简意赅的语句。

调研记录应至少包括业务流程、工作方法和具体内容,推荐使用4W1H的方式编写调研记录,4W即“What、Who、When、Why”,1H即“How”。

What

需求是要做什么,实现什么目标?通过把调研内容划分成若干领域,逐步弄清各个领域的工作流程和工作内容。

Who

处理过程中涉及了哪些部门、人或岗位,业务过程会有哪些相关者?

When

在什么时间或什么条件下发生,如果是周期性构成,周期有多长?

Why

为什么会产生这个需求,需求的目的是什么?

How

如何完成需求处理过程,为完成业务目标所采用的方法或手段是怎样的?

二、引导需求

由于用户语言表达、个人能力、所处环境等原因,有时不能很好表达内心想法,这样的情况下调研实施人员的业务背景和经验往往对需求收集有效性有很大的影响。需求调研过程不是简单的听用户讲,而是需要我们去引导用户讲出他们真正面临的问题和解决问题的想法,通过我们积极的沟通让用户把他们真实的想法真正的表达出来。

引导用户的需求应做到能够描述用户的常规需求外,能够发掘用户的潜在需求,争取能够提出用户的兴奋需求,挖掘用户的隐性需求,这样作出的软件才有生命力,才能真正体现出软件的价值。

引导用户需求的几种常用方法:

?向用户讲述基本的计算机操作。

?向用户演示将要实施的系统的原型。

?从软件开发中需求的完整、准确、清晰、一致等几个方面入手,使得

?用户提出的需求完整、准确、清晰、前后一致。

?从显性需求出发,推断用户需求的真实意图,超越显性需求,发掘

?潜在的隐性需求。

三、评估需求

不是所有需求都是受欢迎的,也不意味着用户提出的所有需求都是正确的。在调研过程中,往往存在着如下情况:

?由于用户所处环境(如工作内容的差异)的不同,不同岗位、层次

?的用户的需求层次不同,彼此间对类似业务提出的需求存在着差异;

?由于用户个人能力的原因,对类似业务提出的需求不一致,相互矛

?盾;

?由于用户对计算机知识了解不多,提出的需求无法利用信息化手段

?实现,或花费很高的成本实现并不重要的需求;

这就需要调研人员在充分理解需求的基础上,对需求的合理性、可实现性进

需求分析:需求调研的七种方法

需求分析:需求调研的七种方法要想给人做管理软件,首要的事情自然是把人家现在的业务内容、管理方式弄清楚。即使你是这个领域的业务专家,也要明白一点,无论业务内容是否相同,管理方式一定是不同的,业务可以复制,技术可以复制,管理不能复制。例如,要给仓库做管理系统,需要先了解这个仓库是怎么管理的,怎么出库,怎么入库,怎么盘点,怎么核算;需要给采购部做管理系统,需要先了解采购部是怎么运作的,怎么制定采购计划,怎么下采购单,怎么签订采购合同,等等。 开发信息管理系统,首当其冲的需求来源就是如何将现在的手工业务电子化,没有这一步,说什么资源整合,说什么提高效率,说什么降低成本,说什么智能决策,都是浮云。对于管理软件来说,需求获取重点在如何理解客户业务,这是需求获取阶段最重要,也是最困难的事情,当然,对于需求分析者来说,理解业务与需求获取往往是交错进行的,很难割裂开来。 需求获取一般包括这几种方式:观察法、体验法、单据分析法、报表分析法、问卷调查法、访谈法、需求调研会法。这是需求调研的“七种武器”,它们各有优缺点,无论你想要了解的是什么需求,都需要将这些方式组合应用,针对你想要了解的内容,以及需要了解的对象的工作特点,采用不同的方式。学会并坚持使用这七种武器后,我想你很快就会成为需求调研的真正高手。 观察法 观察法,就是你自己跑到工作现场,看!这个看上去相当简单,貌似走马观花,有些不在行的兄弟会弄得跟公费旅游一般,车间里走走散散心,撩撩HR妹子,就认为是观察法调研了,其实不然。这种方法,关键是要看人家是怎么工作的,拿了什么,干了什么,用了什么工具,送出去什么,什么时候填写了什么单据,制作了什么报表,等等。 体验法 体验法,就是你自己亲自到相关部门去顶岗,做一段时间的业务工作,有了亲身体验自然更容易理解这个岗位的工作。这种方法,最大的优点就是理解业务比较深刻。一旦你几乎成了某岗位的一员后,想想,还有什么比自己帮自己做软件更能够把握需求呢?要给超市收银员写个软件,先到超市卖几天东西,要给仓库做软件,先到仓库发两天货,你的软件偏离用户需求的可能性会大幅度降低。

需求调研的方法

需求调研方法及实战 概述 需求调研和需要分析,可以说是软件工程中极为重要的一环。据统计,失败的项目中有70%以上都是由需求引起的,例如:需求不完整、需求变更等等。在这方面是有着血和泪的教训的。 那么如何才能做好需求?其原则也很简单,就是从外到内、从粗到细、从浅到深。具体的说,就是从公司级、部门级、操作级三个层次进行需求调研和需求分析。 需求开发的具体流程如下: 1.根据合同确定项目目标和范围 2.确定系统干系人 3.选择用户代表 4.熟悉业务领域,建立词汇表 5.做好访谈计划、访谈问题大纲 6.获取每类用户的需求 7.分析用户工作流程 8.确定用例 9.建立领域模型 10.确定非功能需求 11.确定设计约束 12.划分需求优先级 13.编写需求规格说明书 下面将举例说明需求调研的三个层次(本文中的例子取材于笔者亲身参与的一个项目)。公司级 在对客户的业务知识、项目背景有一定的了解后,开始访谈客户公司的高层领导,了解他们对项目的期望、目标(要符合SMART的原则)、及该项目的投资回报率。这些信息可用于对需求的把握和对需求优先级的排序。 在这个阶段中,还需要将业务分解成大的业务模块,定义每个业务模块之间的接口。这样的好处是可以将一个大的系统分解为多个小的系统,降低系统的复杂度。例如:

部门级 在这个阶段中,将上个阶段分解的业务模块落实到具体的业务部门中,访谈该部门经理。获取该部门的业务流程。流程建模的方法如下: 1.找出业务事件 2.识别一个业务事件的相关业务活动 3.确定业务活动之间的关系 4.业务活动的输入、输出信息 5.负责业务活动的部门、岗位 流程建模后,将流程中的每个节点进行分析,判断其是否在系统的范围内。如在系统范围内,将其定义为用例。同时了解部门经理的管理需求,找到业务流程的管控点,生成报表。下面是一个流程建模的实例:

需求调研流程(DOC)

XXX管理系统需求调研报告

Revision Record 修订记录

Catalog 目录 1需求调研流程 (4) 1.1调研整体流程 (4) 1.2组成部分关系 (5) 1.3分析过程 (6) 2需求调研和分析的方法、策略和步骤 (6) 2.1如何调研 (6) 2.2如何分析 (7) 2.3调研方法 (8) 2.4基本策略 (8) 2.5结构化方法分析步骤 (9) 2.6UML方法分析步骤 (9) 3需求调研相关要求 (10) 3.1文档规范 (10) 3.2需求管理 (11) 3.3调研成果 (12)

1需求调研流程 1.1 调研整体流程

●问题识别:解决目标系统做什么,做到什么程度。需求包括:功能、性能、环境、 可靠性、安全性、保密性、用户界面、资源使用、成本、进度。同时建立需求调查 分析所需的通信途径。 ●分析与综合:从数据流和数据结构出发,逐步细化所有的软件功能,找出各元素之 间的联系、接口特性和设计上的限制,分析它们是否满足功能要求并剔除不合理部 分,综合成系统解决方案,给出目标系统的详细逻辑模型。[常用的分析方法有面 向数据流的结构化分析方法SA(数据流图DFD、数据词典DD、加工逻辑说明)、 描绘系统数据关系的实体关系图ERD、面向数据结构的Jackson方法JSD、面向对 象分析方法OOA(主要用UML)、对于有动态时序问题的软件可以用形式化技术, 包括有穷状态机FSM的状态迁移(转换)图STD、时序图、Petri网。每一种分析 建模方法都有其优势和局限性,可以兼而有之以不同角度分析,应该避免陷入在软 件需求方法和模型中发生教条的思维模式和派系斗争,一般来说结构化方法用于中 小规模软件、面向对象方法用于大型软件。] ●编制需求分析文档 ●需求评审 1.2 组成部分关系 需求分析可分为问题识别、分析与综合、编制需求分析文档、需求评审等四个阶段,包括以下几个方面:确定软件所期望的用户类;获取每个用户的需求;了解实际用户任务和目标以及这些任务所支持的业务需求;分析员与用户的信息以区别用户任务需求、功能需求、

XX项目需求调研方案

广东烟草商业系统营销大集中信息系统建设项目 需求调研计划 (第一期) 编号:LCRJ-06085100802-RM-01-01 (版本:V2.0) 二○○六年九月

目录 1概述 (4) 1.1背景 (4) 1.2目的 (4) 2调研前的准备工作 (4) 2.1确定需求调研方式 (4) 2.2确定调研各方负责人 (4) 2.3确定需求调研时间和地点 (5) 2.4参与需求调研工作的人员安排和通知 (5) 2.5需求调研的组织准备 (5) 2.6需求调研纲要资料 (5) 3需求调研过程概述 (5) 3.1对V3总体业务架构及主体业务流程汇报调研 (6) 3.2对V3具体业务功能及操作进行交流调研 (6) 3.3整理需求调研成果 (6) 3.4需求调研成果确认 (6) 3.5最终需求调研成果汇报 (6) 4调研单位时间安排 (7) 5基础业务上线模块主要流程(当前上线重点) (8) 6附件:需求调研时间安排 (8)

1概述 1.1背景 广东烟草营销大集中系统是浪潮软件在烟草行业承接的规模最大的软件工程,也是需求最复杂的烟草商业企业应用系统,为了保证需求调研过程的有序、完整、规范,获得高质量需求成果,明确调研的方法和工作步骤,特制定本需求调研计划。 1.2目的 随着烟草行业的发展,软件的产品化进一步提高,整体团队逐步规模化,对烟草业务的理解逐步加深,软件功能也更加完善。这一系列的变化,对软件实施前的需求调研及业务咨询的工作,越来越体现出其重要性。需要一个系统的、完整的需求调研计划帮助大家顺利的进行需求调研工作的开展,同时也保证需求调研工作的质量。 本次调研进行集中式调研交流: 1、首先是整体业务架构和业务流程方面的需求调研和交流 主要由省公司相关管理人员、地市公司分管领导及部门负责人参与,主要对业务流程方面进行确认,保证大方向的准确性。 系统涉及的相关部门有:专卖管理部门、营销管理中心、物流配送中心、财务管理中心和信息中心。 2、然后针对具体流程进行实际业务操作层的需求调研和交流 主要由各地市公司代表的部门负责人及核心操作人员参与,是在确认了业务流程的基础上,进行系统功能方面的差异及易用性等方面的交流讨论。2调研前的准备工作 2.1确定需求调研方式 本次需求调研,采用集中式需求调研的方式,即集中各地市公司代表的相关领导和核心业务人员进行需求调研和交流。 2.2确定调研各方负责人 省公司负责人:

如何进行管理信息系统需求调研分析

如何进行管理信息系统需求调研分析 摘要:本文是在管理信息系统需求调研实践和学习中的一些经验总结,有些是自己的体会,有些来自专家的书本或文章,希望与大家分享,并起到一个抛砖引玉的作用,如有不妥之处欢迎指正。 一、软件需求的定义 IEEE软件工程标准词汇表(1997年)中定义的需求为: (1)用户解决问题或达到目标所需的条件或能力; (2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力; (3)一种反映上述条件和能力的文档说明。 二、需求分析的几个方面 需求分析可分为问题识别、分析与综合、编制需求分析文档、需求评审等四个阶段,包括以下几个方面:确定软件所期望的用户类;获取每个用户的需求;了解实际用户任务和目标以及这些任务所支持的业务需求;分析员与用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息;将系统级的需求分为几个子系统,并将需求中的一部分分配给软件组件;了解相关质量属性的重要性;讨论得出实施优先级;将所收集的用户需求编写成需求规格说明和模型;评审需求规格说明,确保与用户达成共识。 软件需求的各组成部分如下图所示:

三、需求文档规范 A、三种编写方法 1、用好的结构化和自然语言编写文本型文档; 2、建立图形化模型,这些模型可以描绘转换过程、系统状态、和它们之间的变化、数据关系、逻辑流或对象类和他们的关系; 3、编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求。 多种编写方法可在同一个文档使用,根据需要选择,或互为补充,以能够把需求说明白为目的。 B、应有成果 1、各业务手工办理流程文字说明; 2、各业务手工办理流程图; 3、各业务手工办理各环节输入输出表单、数据来源; 4、目标软件系统功能划分(示意图及文字说明); 5、目标软件系统中各业务办理流程文字说明;

需求调研步骤与方法

第一章:前言 目的: 需求调研是为需求说明书做前期工作,可以说需求说明书说是从需求调研表中得到或抽取而出。 需求调研是要了解现实世界中做实际工作的人们真正需要什么样的程序的过程,再把这些需求展开细节整理由设计部开发,再由销售部销售给用户。 标注:调研顾名思义就是调查和研究客户的想法,我感觉应从以下几个步骤入手: 客户想要什么? 认真倾听客户说话,因为客户在说的时候,他多半同时在想自己要什么东西。他说完了,轮到咱了,首先复述客户需求,在复述的同时我们就可以发表建议了。此时态度要把握好,要把客户的需求合理化、简单化。说白了就是程序别太复杂,风险能排全排除掉,别搞个逻辑又复杂又不实用的东西出来。 客户要这干什么用? 听完所有的需求,提炼出客户所要东西的重点,围绕重点开始研究,复述客户的需求。作事千万别说:“我以为”。别怕麻烦,现在多说几遍大家都还是客气,比以后大家对需求有争执强。 他为什么这么想? 客户大多不是IT专家,大多是行业专家,对自己所作的行业至少对本公司的行业流程比较清楚,所有我们就需要搞清楚他们的行业流程或说业务逻辑,看看他们到底想让我们用程序为他们实现什么功能,他们要干什么? 会不会有别的想法? 通过以上四步我们的目标是:搞清客户的要求,找出要求的逻辑,客户想要的结果,同时排除开发的风险,挖掘与控制潜在的要求。 需求调研的目的是:双方对未来产生结果的认同,达成共识的基础是双方对结果均有理解,而不能一味期望客户提供他们的要求。 第二章 2.1. 确定工具 没有什么工具是好还是坏的问题,问题是关键是如何使用它们,无论是什么工具也只是一个辅助工具,也不是生成工具。 工具的选取要求是自己(本组)熟悉的工具,不能是一件最新时髦工具而自己对它了解很少,结果大部分时间花在学习工具上,而不是使用它为你工作。 工具最好也是要求是普通流行的,因为要考虑交流的问题。 2.2. 要做什么就要先了解什么 如果做的项目是你所不了解的一个行业,同组最好要有专家----最终用户做为这个专家是最好的,最少你有了解这个专业,不是要你成为专家,但最少要了解一定的专业知识(最少专有词汇你要知道),不然您甚至不知道去问什么问题或者如何去问他们,甚至于人家在

软件项目需求调研提纲

项目名称:山东xxx系统项目 需求调研提纲财务部分(Financial) 总帐管理(General Ledger) 基础项目: 1.财务部门的组织架构及部门职责?人员分配情况(用户权限)? 2.目前是否使用财务软件?使用何种软件?软件用户如何分工? 3.公司有几套财务帐?之间关系如何?有无内部往来业务? 4.目前所使用的会计科目结构以及科目结构变化的处理? 业务处理: 5.有哪些外币业务? 6.是否进行科目预算管理? 7.是否有专项核算管理? 8.凭证审批流程,审批的级次? 9.有无自动结转凭证? 10.是否需要凭证自动冲回? 11.银行对账和日记账管理? 12.会计期间的跨度和要求 13.年度及结帐流程(月结和年结)? 济南分公司ADD:济南市

帐表查询和打印: 14.凭证的显示格式、打印格式和要求? 15.账薄的显示格式、打印格式和要求? 16.财务分析报表、格式和要求(以财务科目数据为基础,单项计算公式)? 17.相关财务制度? 现金管理(Cash Management) 基础项目 1.相关资金管理制度及流程 2.有无专门的资金管理系统?如何和财务系统衔接? 业务处理 1.目前公司是否有多个银行账户?银行账户要备注那些信息? 2.如何进行银行对帐? 3.如何编制现金流量表? 4.是否做现金预测方面的工作,如何做? 5.如何制定公司付款计划? 账薄查询 资金管理方面的主要报表(单项计算公式)? 济南分公司ADD:济南市

业务部分(Distribution) 采购(Purchase Order) 1.公司目前的采购行为是否直接受门店销售需求的影响,如何影响? 2.公司目前对原料的采购采取何种方式? ●按批量采购(经济采购量) ●按单一订单需求采购 ●按最低库存量采购 3.采购组织结构 ●采购人员构成 ●采购岗位职责 ●采购流转单据 供应商管理 1.对于采购,供应商的确认原则是什么? 2.现行的供应商认证与管理工作是怎样运作的?采购部负责哪些工作?3.是否进行供应商评估?若有,评估标准如何?如:价格、质量和服务等?4.有无完善的供应商信息管理? 5.现有供应商信息的内容?如名称、地址等? 济南分公司ADD:济南市

软件系统需求调研

软件系统需求调研 摘要: 本文是在管理信息系统需求调研实践和学习中的一些经验总结,有些是自己的体会,有些来自专家的书本或文章,希望与大家分享,并起到一个抛砖引玉的作用,如有不妥之处欢迎指正。 关键字:需求、调研 一、软件需求的定义 IEEE软件工程标准词汇表(1997年)中定义的需求为: (1)用户解决问题或达到目标所需的条件或能力; (2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力; (3)一种反映上述条件和能力的文档说明。 二、需求分析的几个方面 需求分析可分为问题识别、分析与综合、编制需求分析文档、需求评审等四个阶段,包括以下几个方面:确定软件所期望的用户类;获取每个用户的需求;了解实际用户任务和目标以及这些任务所支持的业务需求;分析员与用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息;将系统级的需求分为几个子系统,并将需求中的一部分分配给软件组件;了解相关质量属性的重要性;讨论得出实施优先级;将所收集的用户需求编写成需求规格说明和模型;评审需求规格说明,确保与用户达成共识。 软件需求的各组成部分如下图所示:

三、需求文档规范 A、三种编写方法 1、用好的结构化和自然语言编写文本型文档; 2、建立图形化模型,这些模型可以描绘转换过程、系统状态、和它们之间的变化、数据关系、逻辑流或对象类和他们的关系; 3、编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求。 多种编写方法可在同一个文档使用,根据需要选择,或互为补充,以能够把需求说明白为目的。 B、应有成果 1、各业务手工办理流程文字说明; 2、各业务手工办理流程图; 3、各业务手工办理各环节输入输出表单、数据来源;

软件需求分析方法

欢迎阅读 软件需求分析(Software Reguirement Analysis)是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,建立可确认的、可验证的一个基本依据。 1)对实现软件的功能做全面的描述,帮助用户判断实现功能的正确性、一致性和完整?性,促 使用户在软件设计启动之前周密地、全面地思考软件需求; 2)了解和描述软件实现所需的全部信息,为软件设计、确认和验证提供一个基准;

3)为软件管理人员进行软件成本计价和编制软件开发计划书提供依据; 需求分析的具体内容可以归纳为六个方面:软件的功能需求,软件与硬件或其他外部系统接口,软件的非功能性需求,软件的反向需求,软件设计和实现上的限制,阅读支持信息。 软件需求分析应尽量提供软件实现功能需求的全部信息,使得软件设计人员和软件测试人员不再需要需求方的接触。这就要求软件需求分析内容应正确、完整、一致和可验证。此外,为保证软件设计质量,便于软件功能的休整和验证,软件需求表达无岔意性,具有可追踪性和可修改性。2.1、????? 软件功能需求 1 不 (5)??? 尽可能不使用“待定”这样的词。所有含有待定内容的需求都不是完整的文件,如果出现待定的部分,必须进行待定部分内容说明,落实负责人员、落实实施日期。 2)功能描述的无岔意性和可追踪性 需求功能描述的无岔意性、可追踪性和规范化: (1)??? 功能描述必须清晰地描述出怎样输入到怎样输出,并且输入、输出描述应对应有数据流描述、控制流描述图,这些描述必须与其它地方描述一致;

(2)??? 可以用语言、方程式、决策表、矩阵或图等对功能的描述。如果选用语言描述必须使用结构化的语言,描述前必须说明该步骤(或子功能)的执行是顺序,选择, 重复,还是并发,然后说明步骤逻辑。整个描述必须单入单出。 (3)??? 描述时,每一个功能名称和参照编号必须唯一,且不要将多个功能混在一起进行描述,这样便于功能的追踪和修改。 (4)??? 功能描述应注意需求说明和程序设计的区别。需求设计仅仅是软件的功能设计,它给出软件运行的的外部功能描述,以及为了实现这一外部功能必须做哪些事情(采 2.2、 2.3、 (2)??? 处理容限、精度、采样参数的分辨率,误差处理等; (3)??? 可靠性的MTBF要求,可维护性、安全性要求等。(对可能的不正常的输入给以正常响应是可靠性的重要内容,这属于功能性需求。) 2.4、????? 软件反向需求 软件的反向需求描述软件在那些情况下不能做什么。这一条是随软件实际要求而定。有两类情形需要采用反向需求的形式。第一种情况:某些用户需求适宜采用反向形式说明,如数据安全性要求属于这类形式。第二种情况:对一些可靠性和安全性要求较高的软件,有些必须描述软件不能做些什么。如控制点火时序,我们必须交代清楚在那些情况下不能点火,否则会造成故障。

软件项目需求调研提纲

文档项目:调研提纲 项目名称:山东xxx系统项目 需求调研提纲财务部分(Financial) 总帐管理(General Ledger) 基础项目: 1.财务部门的组织架构及部门职责?人员分配情况(用户权限)? 2.目前是否使用财务软件?使用何种软件?软件用户如何分工? 3.公司有几套财务帐?之间关系如何?有无内部往来业务? 4.目前所使用的会计科目结构以及科目结构变化的处理? 业务处理: 5.有哪些外币业务? 6.是否进行科目预算管理? 7.是否有专项核算管理? 8.凭证审批流程,审批的级次? 9.有无自动结转凭证?版本号V1.0 文件编号Sdxxx20130228

10.是否需要凭证自动冲回? 11.银行对账和日记账管理? 12.会计期间的跨度和要求 13.年度及结帐流程(月结和年结)? 帐表查询和打印: 14.凭证的显示格式、打印格式和要求? 15.账薄的显示格式、打印格式和要求? 16.财务分析报表、格式和要求(以财务科目数据为基础,单项计算公式)? 17.相关财务制度? 现金管理(Cash Management) 基础项目 1.相关资金管理制度及流程 2.有无专门的资金管理系统?如何和财务系统衔接? 业务处理 1.目前公司是否有多个银行账户?银行账户要备注那些信息? 2.如何进行银行对帐? 3.如何编制现金流量表? 4.是否做现金预测方面的工作,如何做?

5.如何制定公司付款计划? 账薄查询 资金管理方面的主要报表(单项计算公式)?

业务部分(Distribution) 采购(Purchase Order) 1.公司目前的采购行为是否直接受门店销售需求的影响,如何影响? 2.公司目前对原料的采购采取何种方式? 按批量采购(经济采购量) 按单一订单需求采购 按最低库存量采购 3.采购组织结构 采购人员构成 采购岗位职责 采购流转单据 供应商管理 1.对于采购,供应商的确认原则是什么? 2.现行的供应商认证与管理工作是怎样运作的?采购部负责哪些工作?3.是否进行供应商评估?若有,评估标准如何?如:价格、质量和服务等?4.有无完善的供应商信息管理?

需求咨询调研方案设计

需求分析调研方案 项目调研总体目标: 需求分析是反复进行,逐渐深化,不断改进的过程 1.根据工程总目标,明确调研目标、层次; 2.根据目标设计调研方式,编写调研提纲,确定调研对象; 3.编写每阶段调研日记,汇总完善调研报告; 4.画出标准业务流程图,做到全面清晰; 5.绘制数据流程图; 6.以简明清晰的思路,浅显易懂的自然语言描述业务步骤; 7.找出业务关键点及瓶颈工序; 8.编写供参考的先进的方法与改进建议。 分阶段调研目标与规定 第一阶段:初步调研 调研目标 初步调研首要目标是对企业全局的了解,可具体分解为: 1.企业概况 2.企业的经营特点 3.企业的生产特点 4.企业的组织机构 5.企业行业地位 6.企业技术现状 调研对象 1. CIMS工程总负责人,必要时邀请总经理参加 2. 总部各职能科室负责人 调研方式 1. 参阅公司资料为主 2. 配合问答 调研范围 了解企业总体概况 调研时限 根据公司规模及组织结构的复杂程度,掌握在2~7天左右

调研提纲 一、针对企业概况,了解以下问题: 1.企业背景,历史演变过程 2.企业所属行业 3.企业的资产、产值、利税等生产经济指标 4.企业人数及素质 5.企业体制、组织机构 6.其它有关情况 二、针对企业经营特点做以下调研: 1.经营机制、目标 2.销售策略 3.财务制度、成本分摊办法、独立核算情况 三、针对企业生产特点做以下调研: 1. 企业产品的种类、型号、技术含量、结构特点、市场占有率 2.企业生产方式: a是离散、连续或半连续 b生产批量:是多品种小批量还是单件大批量生产 c是按订单还是按库存或其他方式组织生产 3.企业的产量、产值、利润目标 4.对产品使用安全性的要求,对使用环境的要求 四、针对企业组织机构做如下调研 1.绘制组织结构图 2.描述各职能科室职责 3.对企业的生产流程做简明调研 4.各分公司或子公司的总体概况、相互关系、与母体公司的关联程度 五、针对企业的行业了解下述情况 1.企业在行业及整个国民经济中的地位 2.产品的市场占有率 3.行业发展现状、企业的竞争目标 六、针对企业技术现状做如下调研 1.企业设备、先进、精密、自动化程度 2.计算机资源情况、数量、型号,可自动化系统的应用情况 3.技术人员的水平、能力 调研的注意事项 初步调研是针对公司总概况的调研,绝大部分公司对上述内容都有文件档案。顾问调研前一定要详细阅读相关资料,找出关键点与有疑问的地方重新拟定调研提纲,做到简洁、明快,尽量减少介绍人员对熟悉事物的反复介绍。 第二阶段:现状分析 在第一阶段的调研基础上对各职能科室及分公司做进一步调研

项目需求调研方案

****公司 信息系统建设项目 需求调研计划(第一期) (版本:V2.0) 二***年九月

目录 1概述 (4) 1.1背景 (4) 1.2目的 (4) 2调研前的准备工作 (4) 2.1确定需求调研方式 (4) 2.2确定调研各方负责人 (4) 2.3确定需求调研时间和地点 (5) 2.4参与需求调研工作的人员安排和通知 (5) 2.5需求调研的组织准备 (5) 2.6需求调研纲要资料 (5) 3需求调研过程概述 (5) 3.1对软件产品总体业务架构及主体业务流程汇报调研 (6) 3.2对软件产品具体业务功能及操作进行交流调研 (6) 3.3整理需求调研成果 (6) 3.4需求调研成果确认 (6) 3.5最终需求调研成果汇报 (6) 4调研单位时间安排 (7) 5基础业务上线模块主要流程(当前上线重点) (8) 6附件:需求调研时间安排 (8)

1概述 1.1背景 **系统是**软件公司承接的规模最大的软件工程,也是需求最复杂的应用系统,为了保证需求调研过程的有序、完整、规范,获得高质量需求成果,明确调研的方法和工作步骤,特制定本需求调研计划。 1.2目的 随着地产行业的发展,软件的产品化进一步提高,整体团队逐步规模化,对地产业务的理解逐步加深,软件功能也更加完善。这一系列的变化,对软件实施前的需求调研及业务咨询的工作,越来越体现出其重要性。需要一个系统的、完整的需求调研计划帮助大家顺利的进行需求调研工作的开展,同时也保证需求调研工作的质量。 本次调研进行集中式调研交流: 1、首先是整体业务架构和业务流程方面的需求调研和交流 主要由集团公司相关管理人员、项目公司分管领导及部门负责人参与,主要对业务流程方面进行确认,保证大方向的准确性。 系统涉及的相关部门有:信息中心、***。 2、然后针对具体流程进行实际业务操作层的需求调研和交流 主要由各项目公司代表的部门负责人及核心操作人员参与,是在确认了业务流程的基础上,进行系统功能方面的差异及易用性等方面的交流讨论。2调研前的准备工作 2.1确定需求调研方式 本次需求调研,采用集中式需求调研的方式,即集中各项目公司代表的相关领导和核心业务人员进行需求调研和交流。 2.2确定调研各方负责人 集团公司负责人: 项目公司代表负责人: 软件公司负责人:

软件系统实施计划方案

新疆气象大数据服务平台 实施方案

一、软件项目实施方案概述 我方提供全方面的实施方案,技术人员在软件技术、软件功能、软件操作等方面进行系统调试、软件功能实现、人员培训、软件上线使用、后期维护等一系列的工作,我们将这一系列的工作称为软件项目实施。大量的软件公司项目实施案例证明,软件项目是否成功、用户的软件使用情况是否顺利、是否提高了用户的工作效率和管理水平,不仅取决于软件产品本身的质量,软件项目实施的质量效果也对后期用户应用的情况起到非常重要的影响。 项目实施规范主要包括项目启动阶段、需求调研确认阶段、软件功能实现确认阶段、数据标准化初装阶段、系统培训阶段、系统安装测试及试运行阶段、总体验收阶段、系统交接阶段等八个阶段工作内容。下面将分别介绍每个项目实施阶段。 二、软件项目实施方案 (一)项目启动阶段 此阶段处于整个项目实施工作的最前期,由成立项目组、前期调研、编制总体项目计划、启动会四个阶段组成。 阶段主任务

1、成立项目组: 部门经理接到实施申请后,任命项目经理,指定项目目标,由部门经理及项目经理一起指定项目组成员及成员任务。 2、前期调研: 项目经理及项目组成员,在商务人员配合下,建立与用户的联系,对合同、用户进行调研。填写《用户及合同信息表》。在项目商务谈判中,商务经理积累了大量的信息,项目组首先应收集商务和合同信息,并与商务经理一起识别哪些个体和组织是项目的干系人,确定他们的需求和期望,以确保项目开发顺利。 3、编制《项目总体计划》: 《项目总体计划》主要包括以下几方面内容:项目描述,项目目标、主要项目阶段、里程碑、可交付成果等。 4、启动会: 项目组与用户共同召开的宣布项目实施正式开始的会议。会程安排如下: 共同组建项目实施组织,实施组织的权利和职责;双方签署《项目实施协议》; 项目组介绍《项目总体计划》和《项目实施协议》,包括以下内容:项目目标、主要项目阶段、里程碑、可交付成果及计划的职责分配(包括用户的); 项目实施中项目管理的必要性和如何进行项目管理,项目的质量如何控制; 项目实施中用户的参与和领导的支持的重要作用; 阶段验收、技术交接和项目结束后如何对用户提供后续服务。 (二)需求调研确认阶段 此阶段的主要工作是我方的项目实施人员向用户调查用户对系统的需求,包括管理流程调研、功能需求调研、报表要求调研、查询需求调研等,实施人员调研完成后,会编写《需求调研分析手册》,并交付用户进行确认,待用户对《需求调研分析手册》上所提到的需求确认完毕后,项目实施人员将以此为依据进行软件功能的实现。如果用户又提出新的需求,实施人员将分析需求的难度及对整个系统的影响程度来确定是否给予实现。

需求调研的步骤和方法

需求说明书建立过程 简介:本文教您如何做好需求说明书的前期工作需求调研。 第1章前言 目的 需求调研是为需要说明书做前期工作,可以说需要说明书说是从需求调研表中得到或抽取而出。 需求调研是要了解现实世界中做实际工作的人们真正需要什么样的程序的过程,再把这些需求开进细节整理由设计部开发,再由销售部销售给用户。 第2章前期准备 2.1. 确定工具 ?没有什么工具是好还是坏的问题,问题是关键是如何使用它们,无论是什么工具也只是一个辅助工具,也不是生成工具。 ?工具的选取要求是自己(本组)熟悉的工具,不能是一件最新时髦工具而自己对它了解很少,结果大部分时间化在学习工具上,而不是使用它为你工作。 ?工具最好也是要求是普通流行的,因为要考虑交流的问题。 2.2. 要做什么就要先了解什么 ?如果做的项目是你所不了解的一个行业(专业)同组有要最好有要专家----最终用户做为这个专家是最好的,最少你有了解这个专业,不是要你成为专家,但最少要了解一定的专业知识(最少专来词汇你要知道),不然您甚至不知道去问什么问题或者如何去问他们,甚至于人家在说什么你也不知道。 ?相应的专业资料是必须的,最少要有专业入门书籍和对应的资料,也需要求更深入的一些资料。当然有专家的参入就另当别论。 ?如果行业的难度不是很大,可以通入分析人员的自我学习在短时间内了解行业,也许可以不用专家,否则专家是必须的。 2.3. 建立设计环境 一定建立一个专门的设计环境来为本项目服务,进行一定的资源分配,进行必要的文件管理。 2.4. 真正了解自己和用户 ?那些是用户可能明确要达到的目地 ?要知道那些是自己能做到的,那些是自己不能做的。

软件需求分析方法

软件需求分析(Software Reguirement Analysis)是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,建立可确认的、可验证的一个基本依据。 软件需求分析是一个项目的开端,也是项目实施最重要的关键点。据有关地机构分析结果表明,我们设计的软件产品存在不完整性、不正确性等问题80%以上是需求分析错误所导致的,而且由于需求分析错误造成根本性的功能问题尤为突出。因此,一个项目的成功软件需求分析是关键的一步。 一、软件需求分析理论 如果我们用数学方法来描述软件需求分析,可以将一个应用软件定义为S,可能应用软件涉及功能性问题非常广,我们用抽象化理论分析,可以划分为各个功能域,可以用D1、D2、… Dn表示,那么,我们可以用一个表达式描述为 S={D1,D2,D3,…Dn} 但是,功能域Di依然存在着有若干个问题P1、P2、P3、… Pm组成,并且每个功能对应于子系统中的一个软构件,我们可以表示为 Di={P1,P2,P3,…Pm} 同样,功能Pj有若干个行为F1、F2、F3、… Fk,每个行为对应于软构件中的实现方法Pj={F1,F2,F3,…Fk} 一个软件包含了所有功能的集合,同时包含了实现所有功能的所有方法和算法描述。需求分析是依据于用户需求,经过需求问题识别,进行分析、消化与综合,制订规格说明,评审,分为四个阶段,形成用户需求与设计同步,设计满足用户需求目标。 需求分析方法始终贯穿着吸收、同化、贯彻方法和手段,用商业化行为解决需求与实现中存在的矛盾,解决用户需求与商业化产品融通,解决规范与个性化追求。 二、软件需求分析目标 软件需求分析的主要实现目标: 1)对实现软件的功能做全面的描述,帮助用户判断实现功能的正确性、一致性和完整性,促使用户在软件设计启动之前周密地、全面地思考软件需求; 2)了解和描述软件实现所需的全部信息,为软件设计、确认和验证提供一个基准; 3)为软件管理人员进行软件成本计价和编制软件开发计划书提供依据;

软件项目需求调研方法论

需求调研方法论 文件版本:文件编号: 编制人:编制日期: 审核人:审核日期: 批准人:批准日期: 修改记录 版本号修订人修订日期修订描述 目录 1需求概述 (2) 1.1软件需求 (2) 1.1.1需求定义 (2) 1.1.2需求层次 (2) 1.1.3需求来源 (2) 1.2需求调研定义 (4) 1.3需求调研目的 (4) 1.4需求调研必要性 (4) 1.5需求调研是否可裁剪 (8) 1.6需求调研启动时机 (8) 2需求调研过程 (9) 2.1调研实施前活动 (9) 2.1.1识别调研范围 (9) 2.1.2组建调研团队 (9) 2.1.3确定调研方案 (10) 2.1.4调研准备 (14) 2.1.5前期沟通 (16) 2.2调研实施 (16)

2.2.1调研实施 (16) 2.2.2调研注意事项 (20) 3编写用户需求规格说明书 (21) 1需求概述 1.1 软件需求 1.1.1需求定义 需求是用户一种期望,是用户期望改善现状,解决某些问题或达到某种目标的需要。需求实现的过程,就是通过软件产品的功能达成用户目标,使之与用户期望目标相符的过程。 1.1.2需求层次 软件需求的三个层次 1.业务需求:反映了组织机构或用户对系统、产品高层次的目标要求。 2.用户需求:描述了用户使用产品必须要完成的任务。 3.功能需求:定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足业务需求。 4.非功能性的需求:不直接完成用户完成某项工作,但是在用户在操作系统过程中伴随产生的需要,描述了系统展现给用户的行为和执行的操作等,它包括产品必须遵从的标准、规范和约束,操作界面的具体细节和构造上的限制。 1.1.3需求来源 软件需求可以来自方方面面,这取决于所开发产品的性质和开发环境。 下面是几个软件需求的典型来源。

软件项目实施方案模板

XX集团XX有限公司XX防控管理系统 实施方案

XX科技有限公司 一、软件项目实施方案概述 软件产品用户购买软件产品之后,不能立即进行使用,需要软件公司的技术人员在软件技术、软件功能、软件操作等方面进行系统调试、软件功能实现、人员培训、软件上线使用、后期维护等一系列的工作,我们将这一系列的工作称为软件项目实施。大量的软件公司项目实施案例证明,软件项目是否成功、用户的软件使用情况是否顺利、是否提高了用户的工作效率和管理水平,不仅取决于软件产品本身的质量,软件项目实施的质量效果也对后期用户应用的情况起到非常重要的影响。 项目实施规范主要包括项目启动阶段、需求调研确认阶段、软件功能实现确认阶段、数据标准化初装阶段、系统培训阶段、系统安装测试及试运行阶段、总体验收阶段、系统交接阶段等八个阶段工作内容。下面将分别介绍每个项目实施阶段。 二、软件项目实施方案 (一)项目启动阶段 此阶段处于整个项目实施工作的最前期,由成立项目组、前期调研、编制总

体项目计划、启动会四个阶段组成。 阶段主任务 1、成立项目组: 部门经理接到实施申请后,任命项目经理,指定项目目标,由部门经理及项目经理一起指定项目组成员及成员任务,并报总经理签署《项目任务书》。 2、前期调研: 项目经理及项目组成员,在商务人员配合下,建立与用户的联系,对合同、用户进行调研。填写《用户及合同信息表》。在项目商务谈判中,商务经理积累了大量的信息,项目组首先应收集商务和合同信息,并与商务经理一起识别哪些个体和组织是项目的干系人,确定他们的需求和期望,以确保项目开发顺利。 3、编制《项目总体计划》: 《项目总体计划》主要包括以下几方面内容:项目描述,项目目标、主要项目阶段、里程碑、可交付成果等。 4、启动会: 项目组与用户共同召开的宣布项目实施正式开始的会议。会程安排如下: 共同组建项目实施组织,实施组织的权利和职责;双方签署《项目实施协议》;

软件项目需求调研方法论

需求调研方法论 文件版本:文件编号:编制人:编制日期:审核人:审核日期:批准人:批准日期:

修改记录 版本号修订人修订日期修订描述

目录 1需求概述 (4) 1.1软件需求 (4) 1.1.1需求定义 (4) 1.1.2需求层次 (4) 1.1.3需求来源 (4) 1.2需求调研定义 (5) 1.3需求调研目的 (6) 1.4需求调研必要性 (6) 1.5需求调研是否可裁剪 (10) 1.6需求调研启动时机 (10) 2需求调研过程 (11) 2.1调研实施前活动 (11) 2.1.1识别调研范围 (11) 2.1.2组建调研团队 (11) 2.1.3确定调研方案 (12) 2.1.4调研准备 (16) 2.1.5前期沟通 (18) 2.2调研实施 (18) 2.2.1调研实施 (18) 2.2.2调研注意事项 (22) 3编写用户需求规格说明书 (23)

1需求概述 1.1 软件需求 1.1.1需求定义 需求是用户一种期望,是用户期望改善现状,解决某些问题或达到某种目标的需要。需求实现的过程,就是通过软件产品的功能达成用户目标,使之与用户期望目标相符的过程。 1.1.2需求层次 软件需求的三个层次 1.业务需求:反映了组织机构或用户对系统、产品高层次的目标要求。 2.用户需求:描述了用户使用产品必须要完成的任务。 3.功能需求:定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足业务需求。 4.非功能性的需求:不直接完成用户完成某项工作,但是在用户在操作系统过程中伴随产生的需要,描述了系统展现给用户的行为和执行的操作等,它包括产品必须遵从的标准、规范和约束,操作界面的具体细节和构造上的限制。 1.1.3需求来源 软件需求可以来自方方面面,这取决于所开发产品的性质和开发环境。 下面是几个软件需求的典型来源。 1. 访谈、调查用户或潜在用户 为找出新软件产品的用户需求,最直截了当的方法是询问他们。通过直接与最终用户的访谈或调查,了解用户目前管理或应用过程中存在的问题、思想或想

相关文档
最新文档