《绩效评估项目——需求调研表优质资料.doc》由会员分享，可在线阅读，更多相关《绩效评估项目——需求调研表优质资料.doc（28页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、绩效评估项目需求调研表优质资料(可以直接使用，可编辑 优质资料，欢迎下载）信息化项目绩效评估试点工作咨询服务项目需求调研表（运维类项目）项目名称：建设单位：项目建设负责部门：项目负责人：联系 ：技术负责人：联系 ：填表人：填表时间：年月日说明：本调研表共5大项，建议由信息化主管领导组织填写。本调研表仅限于对被评估项目的相关情况进行调查。一 项目基本情况项目名称项目类别（按性质）新建 改建 扩建 项目编号建设单位项目类别（按投资额）一般（100万以下） 大型（100-500万） 重大（500万以上）运维单位监理单位项目类别（按技术）应用系统 公共平台 视频监控基础建设责任部门维护部门维护人员项目
2、类别（按主要作用与地位）决策支持类业务管理类（对外）业务管理类（对内）信息支撑类联系 审批单位及文号批准日期年 月 日项目金额（万元）（计划）项目金额（万元）（实际）采购方式公开招标 邀请招标 询价 单一来源 采购情况一次招标 多次招标所处阶段设计 开发/实施 测试 初验 试运行 验收 维护计划工期（天）计划开始时间 年 月 日计划完成时间年 月 日实际工期（天）实际开始时间年 月 日实际完成时间年 月 日主要用途采集 查询 其他数据采集机构层级采集部门（警种）市局分局派出所数据共享共享模式共享对象或数据来源（单位名称/系统名称)共享内容（数据名称)提供共享获取共享应用范围类别业务覆盖面综合类
3、市局个用户，应用警种分别是：分局个用户应用警种分别是：派出所 个用户警种条线类市局 直属各单位个用户分局 科技通信及相关部门个用户派出所 个用户部门类（说明：请在“”打）二 项目目标序号目标内容具体描述实现情况证明材料1目标明确性项目建设目标包含的建设内容是否明确，项目的立项、可行性研究报告、实施建议书的建设内容与实际招投标的建设内容是否一致。 项目立项文件 可行性研究报告 实施建议书 招投标文件2目标合理性项目的设立是否有相关的政策、文件支持，投资预算是否合理。 政府投资信息化导向目录3目标完成率目标完成率=实际完成的功能模块数/预定完成的功能模块数*100%。 项目立项文件 系统设计文件4
4、目标完成质量根据项目的监理报告或第三方评测报告，对建设项目总体质量进行评价。 监理报告 第三方评测报告5目标完成及时性项目是否如期完成。 项目合同 验收报告6目标变更合理性和合规性项目的目标变更是否有相关的政策、文件支持，是否经过相关的审批手续。 变更申请 审批文件（说明：请在“”打）三 产出与结果1、 运维服务序号运维服务内容具体描述完成情况证明材料1运维服务符合度所提供的运维服务是否满足合同和招标文件要求。 项目合同 招投标文件2运维服务流程规范性及执行所提供的运维服务是否有规范的服务流程，是否按照流程执行 运维方案 运维记录3运维服务管理制度及执行所提供的运维服务是否有运维管理制度，是否
5、按照相关制度执行。 运维方案 运维记录4运维服务及时性所提供的运维服务是否在规定的时间内响应。 项目合同 运维方案 运维记录5系统故障修复时间通过维修记录查看故障情况修复时间。 运维记录 运维日志6系统故障修复率（修改故障/发生系统故障）*100%。 运维记录 运维日志7运维记录和日志详细记录运维情况。 运维记录 运维日志8运维平台所提供的运维服务是否有相应的支撑平台。 项目合同 实施方案 运维平台资料9服务满意度使用系统的工作人员的评价，根据调查问卷汇总，满意度=（有效问卷中填报同意栏的总数/有效问卷数）*100%。 运维记录 运维日志 问卷调查（说明：请在“”打）2、 运维文档序号单位文档
6、内容具体描述实现情况证明材料1建设单位文档审批及时性需求、变更等文件按时间要求进行签字确认。 项目运维文件 项目监理文件文档审批合规性是否有意见、签字、时间。 项目运维文件 项目监理文件2运维单位、监理单位提交文档的完整性按阶段提交所需的文档。 项目运维文件 项目监理文件3提交文档的及时性是否按时提交。 项目运维文件 项目监理文件4提交文档的合规性是否有意见、签字、时间并进行审核等。 项目运维文件 项目监理文件5提交文档的符合性是否符合合同和标准要求。 项目运维文件 项目监理文件（说明：请在“”打）3、 售后服务序号售后服务内容具体描述实现情况证明材料1售后服务符合度所提供的售后服务是否满足合
7、同和招标文件要求。 合同2售后服务流程规范性及执行所提供的售后服务是否有规范的服务流程，是否按照流程执行。 实施方案3售后服务管理制度及执行所提供的售后服务是否有售后服务管理制度，是否按照相关制度执行。 实施方案4售后服务及时性所提供的售后服务是否在规定的时间内响应。 服务记录和日志5系统故障修复时间通过售后服务记录查看故障情况修复时间。 服务记录好日志6售后服务记录和日志详细记录售后服务情况。 服务记录好日志7使用满意度使用系统的工作人员的评价，根据调查问卷汇总，满意度=（有效问卷中填报同意栏的总数/有效问卷数）*100%。 用户评价（说明：请在“”打）四 投入与活动1、 资金投入序号投入内
8、容具体描述 投入情况证明材料1资金预算合理性预算价格如何获得？预算价格和投标价格的差值来进行分析？变更次数？。 建议书 批文2资金到位率资金到位率实际拨付资金/计划投入资金。 资金拨付文件3资金支付合规性和及时性资金支付是经过相关手续，计划支付金额：实际支付金额项目实际支出与预算批复（合同规定）的用途是否相符，实际支出调整的手续是否齐全、调整幅度大小及合理性。 合同 监理文件 支付证明4资金变更合理性和合规性引起合同额变化的变更次数及原因是否合理，是否经过审批手续。 合同 监理文件 支付证明 变更文件 审批文件（说明：请在“”打）2、 基础设施投入序号内容内容描述 投入情况证明材料1硬件设备投
9、入符合性及合理性硬件设备实际支出与预算批复（合同规定）的用途是否相符，使用是否合理。 立项文件 招投标文件 合同2软件投入的符合性和合理性软件实际支出与预算批复（合同规定）的用途是否相符，使用是否合理。 立项文件 招投标文件 合同3信息安全投入的符合性和合理性信息安全实际支出与预算批复（合同规定）的用途是否相符，使用是否合理。 立项文件 招投标文件 合同4其他投入的符合性和合理性其他实际支出与预算批复（合同规定）的用途是否相符，使用是否合理。 立项文件 招投标文件 合同（说明：请在“”打）3、 组织及管理（1） 建设单位及管理序号组织管理具体描述 投入情况证明材料1项目运维管理机构是否建立了项
10、目运维管理机构。是否确定了项目运维管理机构人员的组成。是否确定了机构成员的职责和任务。单位高层领导是否直接主管项目的运维管理工作。 批文 会议纪要2项目建设工作制度周例会制度、月例会制度、汇报制度。 会议纪要 周报 月报 专题报告3项目前期管理项目的立项、可行性研究报告和实施建议书的上报手续和相关部门的批复是否完备。 立项文件 招投标文件 合同4招投标管理制度及执行招投标管理制度的完备性，及执行落实情况评价。 招投标文件 招投标过程文件5合同管理制度及执行合同管理制度的完备性，及执行落实情况评价。 合同管理制度 合同管理记录6质量管理制度及执行质量管理制度的完备性，及执行落实情况评价。 质量管
11、理制度 质量管理记录7档案管理制度及执行档案管理制度的完备性，及执行落实情况评价。 档案管理制度 登记记录8安全保密管理制度及执行安全保密制度的完备性，及执行落实情况评价。 安全保密制度 检查记录9培训制度及执行培训制度的完备性，及执行落实情况评价。 培训管理制度 培训记录10项目建成后的日常运行及维护管理制度及执行运行及维护管理制度的完备性，及执行落实情况评价。 运维制度 运维记录（说明：请在“”打）（2） 运维单位及管理序号组织管理具体描述 投入情况证明材料1项目运维管理机构建立了运维单位的项目运维管理机构。机构人员组成是否合理确定了机构成员的职责和任务。项目经理资质情况及服务时间是否符合
12、要求。 批文 会议纪要2工作制度周例会制度、月例会制度、汇报制度。 会议纪要 周报 月报 专题报告3质量控制质量控制措施及手段是否合理有效。 质量管理制度 质量管理记录文件4进度控制进度控制措施及手段是否合理有效。 进度管理制度 进度管理记录文件5投资控制投资控制措施及手段是否合理有效。 投资控制制度 投资控制记录文件6合同管理合同管理措施及手段是否合理有效。 合同管理制度 合同管理记录文件7组织协调组织协调措施及手段是否合理有效。 组织协调制度 协调记录文件（说明：请在“”打）（3） 监理单位及管理序号组织管理具体描述投入情况证明材料1项目监理管理机构建立了监理单位的项目监理管理机构。机构人
13、员组成是否合理。确定了机构成员的职责和任务。总监理工程师资质情况及服务时间是否符合要求。 批文 会议纪要2工作制度周例会制度、月例会制度、报告制度。 会议纪要 周报 月报 专题报告3质量控制质量控制措施及手段是否合理有效。 质量管理制度 质量管理记录文件4进度控制进度控制措施及手段是否合理有效。 进度管理制度 进度管理记录文件5投资控制投资控制措施及手段是否合理有效。 投资管理制度 投资管理记录文件6变更控制变更控制措施及手段是否合理有效。 变更管理制度 变更管理记录文件7合同管理合同管理措施及手段是否合理有效。 合同管理制度 合同管理记录文件8安全管理安全管理措施及手段是否合理有效。 安全管
14、理制度 安全管理记录文件9文档管理文档管理措施及手段是否合理有效。 文档管理制度 文档管理记录文件10组织协调组织协调措施及手段是否合理有效。 组织协调制度 协调记录文件（说明：请在“”打）4、 进度及管理序号进度管理具体描述 投入情况证明材料1进度计划及合理性是否制定了进度管理计划，进度计划是否符合合同要求。 合同 实施方案 开发计划2进度执行情况每个阶段进度是否按进度进行执行及完成情况。 实施方案 周报 月报 监理文档3进度变更合规性及合理性进度变更是否按照规定进行，是否进行了合理性分析。 变更申请 变更确认单 补充协议（说明：请在“”打）5、 培训及管理序号培训管理具体描述 投入情况证明
15、材料1培训计划是否制定了培训计划，培训内容、人员等是否符合要求。 合同 培训计划2培训课程培训课程是否符合合同要求。 培训课件3培训人数培训人数是否符合合同要求。 培训签到表4培训效果培训是否达到预期效果。 用户意见 培训记录（说明：请在“”打）五、您对运维服务的评价序号评价内容评价说明1本服务的特点和创新之处2本服务的应用效果3本服务的有关经验4其他评价文档类型Document Type密级Confidentiality LevelXXX仅供收件方查阅文档编号DocumentCode版本Version共13页XXX08XXX管理系统需求调研报告Revision Record修订记录Date日
16、期Revision Version修订版本CR ID /Defect IDCR/ Defect号Sec No。 修改章节Change Description修改描述Author作者201x-xx-xx0。1初稿完成Catalog目 录1需求调研流程41。1调研整体流程41。2组成部分关系51.3分析过程62需求调研和分析的方法、策略和步骤72。1如何调研72。2如何分析72。3调研方法82.4基本策略82。5结构化方法分析步骤92。6UML方法分析步骤93需求调研相关要求103.1文档规范103。2需求管理123。3调研成果121 需求调研流程1.1 调研整体流程l 问题识别：解决目标系统做什
17、么，做到什么程度。需求包括：功能、性能、环境、可靠性、安全性、保密性、用户界面、资源使用、成本、进度。同时建立需求调查分析所需的通信途径。l 分析与综合：从数据流和数据结构出发，逐步细化所有的软件功能,找出各元素之间的联系、接口特性和设计上的限制，分析它们是否满足功能要求并剔除不合理部分,综合成系统解决方案，给出目标系统的详细逻辑模型。常用的分析方法有面向数据流的结构化分析方法SA（数据流图DFD、数据词典DD、加工逻辑说明）、描绘系统数据关系的实体关系图ERD、面向数据结构的Jackson方法JSD、面向对象分析方法OOA（主要用UML）、对于有动态时序问题的软件可以用形式化技术，包括有穷状
18、态机FSM的状态迁移（转换）图STD、时序图、Petri网。每一种分析建模方法都有其优势和局限性，可以兼而有之以不同角度分析，应该避免陷入在软件需求方法和模型中发生教条的思维模式和派系斗争，一般来说结构化方法用于中小规模软件、面向对象方法用于大型软件。l 编制需求分析文档l 需求评审1.2 组成部分关系需求分析可分为问题识别、分析与综合、编制需求分析文档、需求评审等四个阶段,包括以下几个方面：确定软件所期望的用户类;获取每个用户的需求；了解实际用户任务和目标以及这些任务所支持的业务需求；分析员与用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息；将系统级的需求分
19、为几个子系统,并将需求中的一部分分配给软件组件；了解相关质量属性的重要性;讨论得出实施优先级；将所收集的用户需求编写成需求规格说明和模型；评审需求规格说明，确保与用户达成共识.1.3 分析过程需求分析的任务是借助于当前系统的物理模型（待开发系统的系统元素)导出目标系统的逻辑模型(只描述系统要完成的功能和要处理的数据），解决目标系统“做什么的问题，所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求，通过逐步细化对软件的要求描述软件要处理的数据,并给软件开发提供一种可以转化为数据设计、结构设计和过程设计的数据与功能表示。必须全面理解用
20、户的各项要求，但不能全盘接受，只能接受合理的要求；对其中模糊的要求要进一步澄清，然后决定是否采纳;对于无法实现的要求要向用户作充分的解释。最后将软件的需求准确地表达出来,形成软件需求说明书SRS.l 获得当前系统的物理模型：首先分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程，并用一个具体的模型来反映自己对当前系统的理解。此步骤也可以称为“业务建模”，其主要任务是对用户的组织机构或企业进行评估理解他们的需要及未来系统要解决的问题，然后建立一个业务USECASE模型和业务对象模型。当然如果系统相对简单，也没必要大动干戈区进行业务建模，只要做一些简单
21、的业务分析即可。l 抽象出当前系统的逻辑模型：在理解当前系统“怎样做”的基础上，取出非本质因素，抽取出“做什么的本质。l 建立目标系统的逻辑模型：明确目标系统要“做什么”.l 对逻辑模型的补充，如用户界面、启动和结束、出错处理、系统输入输出、系统性能、其他限制等等.2 需求调研和分析的方法、策略和步骤2.1 如何调研需求调研涉及三个问题： 一是如何确定调研对象； 二是如何确定被调研对象； 三是采用何种调研方法； 调研对象的组成应以互补为原则，至少要由三类人员组成：技术人员、业务专家和管理者。被调研对象主要是人员和业务两类，其间主要涉及人与人、人与事物、事物与事物等三种关系. 其中，关键是确定调
22、研范围.调研范围包括关键域和关键活动。而关键活动又由关键流程加关键点构成。 找到关键域,明确关键流程和关键点，对需求调研至关重要，需要专家或咨询顾问介入。而能否把握这一时机并找准需求提炼的关键点，是考验需求调研人员的重要方面。优秀的需求调研人员不仅能认识问题之所在，还能藉此获取足够多的知识，最后成为问题领域的专家. 需求调研非常困难，必须引起重视。因为： 缺乏专门领域的知识,同时应用领域中的许多问题通常模糊，很难界定； 机构实践存在默认知识，难以描述； 多个知识源或信息源既有冲突又有重合； 被调研对象可能有认知偏见或者欠缺或有时不愿提供确切信息. 这些都会给需求调研人员带来障碍和困难。在这种情
23、况下，掌握必要的方法与技巧非常重要。2.2 如何分析需求工程是继软件工程之后的又一热点工程。从理论上说，包括调研需求、模拟和分析需求、需求描述、需求认可、需求演进这五个层次，并且逐层递进、螺旋式上升。需求分析是需求工程的核心，贯穿于系统整个生命周期。 需求分析的出发点在于：对调研的需求进行进一步提炼并指导需求的抽取；帮助需求分析人员发现问题.需求模拟则帮助检查验证对问题的理解。需求分析和模拟又包含三个层次的工作：需求定义、需求建模、需求模拟。需求定义，是对经调研获取的需求进行初步整理，抽取其中基本需求和关键需求予以界定，并为需求建模提供必要的需求元素.需求建模,是把抽象的需求通过概念、符号、数
24、学模型及逻辑结构表现出来。表现形式有自然语言、半形式化(如图、表、结构化英语等）和形式化表示等三种。自然语言形式具有表达能力强的优点,但不利于捕获模型语义;半形式化表示可捕获结构和一定的语义，也可进行一定的推理和一致性检查；形式化表示具有精确的语义和推理能力，但构造一个完整的形式化模型，需要较长时间和对问题领域的深层次理解。相对而言,图表形式的需求模型直观常用,比如组织结构图、系统流程图、网络拓扑图等.良好的需求概念模型应包括以下几个特点： 实现的独立性、足够抽象、足够形式化、可构造性、利于分析、可追踪性、可执行性、最小冗余性。2.3 调研方法1、 会谈、询问:围绕软件目标提出具体问题；2、
25、调查表：经过仔细考虑的书面回答可能比会谈中的回答更加准确；3、 收集分析客户使用的各种表格、有关工作责任、工作流程、工作规范、相关数据标准、业务标准的各种文字资料；4、 收集同类相关产品的宣传资料、技术资料、演示程序或软件程序;5、 情景分析：利用情景分析诱导用户能够把它们的需求告知分析员(可以描述当前一项业务怎么做、也可以描述设想的系统中此项业务怎么做)；6、 可视化方法:结和情景分析，利用画用户界面图、业务流程图、功能结构图、时序图等图形与客户进行讨论;2.4 基本策略1、 首先确定用户的软件开发目标，确定系统基本范围，然后围绕这一目标，确定要访问的部门和人员，要了解的业务,在基本范围内展
26、开调研;2、 以部门职责为基础搞清各种现有业务、要填写的表簿册文档报表等，其数据来源及去向;3、 以业务为主线，搞清每个业务的每个环节的流程关系、涉及部门、输入输出项；4、 以数据为主线，搞清数据采集方式、数据流向、数据之间的内在联系；5、 搞清哪些业务或数据是已建系统的，它们和新系统的关系是衔接还是替换；6、 应思考是否有新技术可以改进现有工作，用户提出的需求用现有技术能否实现。2.5 结构化方法分析步骤1、 画出数据流图。设计数据流图必须逐步求精；2、 决定哪些部分需要计算机化和怎样计算机化（取决于用户投资限制和自身技术限制）；3、 描述数据流细节，大型软件可以使用数据字典描述所有数据元素
27、；4、 定义处理逻辑(加工逻辑：每个加工处理做什么）；5、 定义数据存储，即定义每个存储的确切内容及其表示法（格式);6、 定义物理资源：如是文件需指定：文件名、组织结构(排序、索引等）、存储介质和记录;如是数据库需指定每个表的相关信息;7、 确定输入输出规格说明，如输入内容、输入屏幕、打印输出格式、输出长度等等；8、 确定硬件所需有关数值，如输入量、打印频率、CPU、记录大小、数据量大小、文件大小等等；9、 确定软硬件接口和环境需求。2.6 UML方法分析步骤一般的应用系统又是各组成部分：问题论域、人机界面、数据管理、任务管理，在OOA阶段重点对问题论域进行分析，对人机界面、数据管理、任务管
28、理等问题，OOA一般较少或没有分析，而是留待OOD阶段解决。1、 调研、识别系统需求；2、 分析问题领域:主要任务是充分理解领域问题和项目投资者及用户的需求，对需求进行抽象，提出高层次的解决方案)；（1） 确定系统范围和系统边界；（2） 确定系统的约束（环境和条件）;(3） 定义活动者；（4） 确定系统的综合要求（功能、性能、运行）;（5) 确定系统的数据要求(名称、范围、类型、数量、特点);(6) 建立USE CASE模型、绘制USE CASE图；(7） 绘制主要交互图;3、 建立静态结构模型（对象类图、数据库模型、包图）;4、 建立动态行为模型（顺序图、协同图、状态图、活动图)；5、 建立
29、系统物理模型(组件图、配置图）；3 需求调研相关要求3.1 文档规范A、三种编写方法1、 用好的结构化和自然语言编写文本型文档；2、 建立图形化模型，这些模型可以描绘转换过程、系统状态、和它们之间的变化、数据关系、逻辑流或对象类和他们的关系；3、 编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求.多种编写方法可在同一个文档使用，根据需要选择，或互为补充，以能够把需求说明白为目的.B、应有成果1、 各业务手工办理流程文字说明；2、 各业务手工办理流程图;3、 各业务手工办理各环节输入输出表单、数据来源；4、 目标软件系统功能划分（示意图及文字说明）；5、 目标软件系统中各业
30、务办理流程文字说明；6、 目标软件系统中各业务办理流程图(模型）；7、 目标软件系统中各业务办理各环节数据、数据采集方式、数据间的内在联系分析。8、 目标软件系统用户界面图、各式系统逻辑模型图及说明C、文档工具推荐1、 调研结果需求分析说明书格式参照开发文档模板;2、 单位组织结构图、功能模块分解图用VISIO绘制,或直接用WORD中的画图工具；3、 业务流程图用VISIO中的FLOWCHART模板绘制;4、 系统逻辑模型使用ROSE绘制活用VISIO中的UML模板绘制；5、 软件用户界面用VISIO中的WIN95 USER INTERFACE模板绘制；6、 数据物理模型用POWERDESIN
31、ER绘制;D、需求文档编写原则1、 句子简短完整，具有正确的语法、拼写和标点；2、 使用的术语与词汇表中所定义的一致;3、 需求陈述应该有一致的样式，例如“系统必须.”或者“用户必须.。”,并紧跟一个行为动作和可观察的结果。;4、 避免使用模糊、主观的术语，减少不确定性，如“界面友好、操作方便”；5、 避免使用比较性词语，如“提高”，应定量说明提高程度。3.2 需求管理需求调研分析过程是一个由粗到细、渐进明晰、持续完善的过程.在指导后面系统设计，编码阶段时都应当不断完善修改需求文档,因此需求管理非常重要。需求管理包括在工程进展过程中维持需求约定集成型和精确性的所有活动，它是CMM模型二级中的首
32、要KPA(关键过程域)，这些活动包括:（1） 定义需求基线（需求文档的主体）；（2） 评审提出的需求变更申请、评估每项变更可能的影响,从而决定是否实施变更；（3) 以一种可控的方式将需求变更融入到项目中；（4） 使当前的项目计划与需求保持一致；（5） 分析变更所产生的影响并在此基础上协商出新的约定；（6) 使每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪；（7） 在整个项目过程中跟踪需求状态及其变更情况。3.3 调研成果调研项调研数量调研成果业务专业词汇15词汇描述记录同行对比项目10项目对比描述及优劣势分析技术参考资料20参考资料描述文档状态文档编号 草稿 已发布 修改中编
33、撰编撰日期保密级别机密文档版本1。0。0项目名称用户需求调研计划书XXXXXXXXX科技文档控制修改记录：日期作者版本修改参考号备注2021-06-05V1.0此文档为初始版本文档。调研记录：时间部门被访者调研人备注6、13资材部采购科陈晓梅、王勇甘书钰、钟旭兴、黄维瀚目录1、调研目的42、调研的范围42。1、调研的职能范围42.2、调研的业务范围42.3、调研的地点范围53、调研的方式54、调研的阶段55、具体时间安排51、调研目的在项目的售前阶段，一般售前顾问会进行一些简要的沟通调研，来确定项目的建设方案。其目的是为了了解项目需求和现有问题，制定出相应的解决方案，是一个比较粗略的调研；在项
34、目初期方案后，需要确定最终的实施方案，并对工期和资源的进行估算，需要重新进行调研，以澄清俱乐部所有的业务细节，并进行业务规则与系统的匹配。调研结束之后，可以得到实施的应用解决方案。2、调研的范围2.1、调研的职能范围根据项目解决方案和业务分析报告所确定的项目实施范围，本次调研所涉及的职能部门以及项目组成员有（请项目进行补充)职能部门人数姓名人员资格条件总经理办公室人总经理或副总经理财务部人负责人或主管营销部人负责人或主管人负责人或主管人负责人或主管人负责人或主管人负责人或主管人负责人或主管人负责人或主管合计人注:以上所列职能部门人员，作为项目组成员以及关键用户，必须参加所有相关的项目调研。2。
35、2调研的业务范围调研的业务范围：调研时按照业务分析报告规定全部调研。具体包括：1、 企业基本情况2、 会员业务3、 营销业务4、 运营业务5、 财务业务6、 成本费用管理7、 基础数据8、 功能要求等2。3、调研的地点范围调研的具体地点为：3、调研的方式1 由客户方组织收集客户相关的文档(要求电子版）资料,如公司概况、主要业态和业务、业务流程，部门架构,财务核算制度、业务岗位责任制度等.2 个别交流，就某一具体问题或业务处理和相关业务人员直接交流。3 开会讨论，对跨部门、跨岗位的业务,可以把相关人员召集在一起,了解这些业务的真实情况。4、调研的阶段序号调研任务开始时间结束时间调研人员客户负责人员工作成果1准备调研提纲调研提纲2调研提纲提交客户调研提纲3总体调研基本情况、主要业务、相关部门及岗位设置等4部门业务调研部门业务处理流程、相关单据、管理重点、存在问题、期望等5基础设备调研（硬件和网络环境）现有硬件性能，提出更换的需求6基础数据调研整理基础数据调研报告7分析、整理调研结果，形成业务分析报告5、具体时间安排(请新纪元项目组按照第4小节的各阶段时间安排部门调研时间）各部门调研时间安排职能部门时间具体调研内容手工文件整理负责人电子文档整理负责人总部财务