数据库需求分析报告【精选9篇】
数据库需求分析报告 篇一
关键词：联机分析处理 多维分析 数据挖掘 XBRL 高校智能财务分析
一、引言
随着高等教育的改革，高校的大规模扩招，高校的财务状况也迎来了更为复杂的局面，需要对影响高校正常运行的各种财务问题进行实时、有效的监控，进行必要的财务分析。高校财务分析是指以事业计划、财务预算、会计报表和其他相关资料为依据和起点，采用针对性的方法，对高校一定时期内业务活动进行系统剖析、比较和研究，并对现行校内财务管理的经验进行总结和评价，揭示其中存在的问题，逐步认识和掌握学校财务活动的规律，改进财务管理工作，提高财务管理水平。高校财务分析是高校财务管理工作的重要组成部分和重要手段。高校财务分析可以帮助上级财政部门、教育行政管理部门把握学校的财务状况和发展趋势，了解高校的宏观信息和财务风险，为高校领导层做出科学决策提供依据。
本文探讨了高校数据仓库、多维分析、高校数据挖掘、XBRL技术，针对高校智能财务分析系统的设计目标与实现功能，设计了系统功能模块结构，构建了高校智能财务分析系统架构模型，并就系统多维数据仓库设计和知识库设计进行了研究。
二、高校智能财务分析系统设计
（一）系统设计总体目标
高校智能财务分析系统设计的目标是：能为高校提供一种全方位财务分析以及最佳分析评估模型的量化分析工具，来满足高校上级主管部门，高校管理者、决策者等对高校财务分析与价值评估方面的需求，包括能提供更细致的财务报表、财务状况分析、财务趋势分析、财务成果分析、现金流量分析、财务风险分析等主要以财务指标为基础的资金、资本、资产分析，在此基础上从战略决策的角度考虑，为上级主管部门、高校领导层提供对高校持续发展影响较大的财务数据和分析报告，满足对高校财务运行情况的评估要求；给高校管理层及其上级主管部门提供风险分析和未来发展的预测分析，提高高校抵御财务风险的能力，实现高校决策过程的科学化和智能化。
（二）系统功能结构设计
1.确定高校智能财务分析主题。根据高校智能财务分析的目的和要求，在高校智能财务分析系统中主要确立了三大主题，分别是高校智能财务分析、高校财务报告智能编制与、高校财务绩效评价。其中高校智能财务分析主题又包括营运能力分析、偿债能力分析、发展能力分析、非财务因素分析等多个子主题；高校财务报告智能编制与主题包括高校财务报告编制、财务报告等子主题。
2.智能财务分析系统功能模块结构。根据高校智能财务分析系统设计的主题和目标，设计的高校智能财务分析系统功能模块结构如图1所示。
3.智能财务分析系统架构设计。根据高校智能财务分析系统设计的主要目标及实现的功能，设计的高校智能财务分析系统架构如下页图2所示。
系统采用“多维数据仓库―智能数据挖掘―XBRL模式导入”的系统结构。主要包含三大部分，第一部分是数据库系统和模型库系统的结合，它是决策支持的基础，主要通过ETL异构数据析取平台将高校财务系统及相关系统的业务数据，进行抽取、清洗、净化、加载、格式转换等进入多维数据仓库中，为领导层决策提供定量分析的辅助信息。第二部分一方面通过多维分析、多维报表、智能数据挖掘从数据仓库提取反映数据本质的综合数据和信息；另一方面数据经过预处理，导入为XBRL模式数据，智能数据挖掘从XBRL模式数据中依据算法挖掘出符合高校财务报告需求的知识，并提供多种格式输出。第三部分是专家系统部分，本部分将财务专家和智能数据挖掘算法相结合，将从数据仓库中挖掘到的知识放入高校财务专家系统知识库，经专家系统进行知识推理后形成辅助决策的定性信息。
4.高校财务数据仓库的设计。高校财务数据仓库是高校智能财务分析系统环境的核心，目的是通过对整个高校财务数据及相关部门数据进行梳理，构建一体化的数据存储环境，可以使高校面对的大量错综复杂的数据得到灵活的处理，为高等学校智能财务分析与决策提供所需关键、有用信息。高校智能财务分析系统数据仓库采用星形架构，由一个事实表和一组维表组成，设计模型时，选择财务分析指标作为数据仓库的主题，建立事实表，并从高校财务分析与决策的角度出发确定维度，如指标、项目、时间等。然后构建维度的层次关系，层次关系以分析指标和受众群体的不同来进行构建。本智能财务分析系统初步设定了六个维度：校内单位（包括院级单位及校内其他部门）、项目、指标、财务专家、时间、往来单位。高校智能财务分析系统数据仓库模型星形结构如图3所示。
5.高校财务专家系统知识库设计。
（1）专家知识获取。在整个高校财务专家知识库的知识获取过程中，采用基于知识工程师的知识获取方式，通过知识工程师准备高度结构性的问题组织高校财务领域专家以问答方式进行面谈，获得原始知识，并整理为自然语言描述，然后通过转换，把知识语言通过知识编辑器输入，知识获取流程如图4所示。
（2）知识库设计。高校财务专家知识库采用概念―事实―规则的产生式知识表示体系，知识库中的知识由事实和规则两部分组成，事实知识由概念组成，规则知识由事实组成，知识库中需要的各种规则，可以描述如下：
<规则>：：=（<规则名称>，<前提1/原因1>|<前提2/原因2>|…<结论/现象>，<可信度，CF>
则知识库基本的表示形式为：
IF A（前提或原因）THEN B（结论或现象）ON CF（可信度），含义为“如果A成立则有置信度CF的结论为B”。
（3）推理机设计。推理机实施推理，并对推理进行控制，是规则的解释程序。高校财务知识推理过程如下：使用者输入已知事实，系统搜寻可用知识，构成知识集，事实与规则如匹配成功，即执行规则结论，如匹配冲突，则调用相应的解决冲突策略进行消解，推理出新的可用事实，加入到动态数据库中，作为下一步推理的已知事实，实现知识库的扩充，它是一个不断循环、持续反馈以使知识库不断完善的过程，这样反复运行，直到求解成功。
三、结论
高等学校财务数据的分析是高等学校管理决策和快速、健康发展的基础，传统的基于人工的财务分析手段，在高科技发展的今天，已然落后，必然被智能财务分析系统所代替，结合商业智能技术、智能数据挖掘技术、数据仓库技术和OLAP技术的高校智能财务分析系统通过实现对高校财务动态的监控，对高等学校财务实现智能的分析，以及为管理者提供科学、合理的决策依据，可以想象，其必将为高校财务管理与决策带来一系列影响深远的变革。
参考文献：
1.袁隽媛，谢健。基于OLAP的高校财务决策研究[J].中国管理信息化，2010，13（17）：2-5.
2.彭成，佟秋利。高校财务多维查询分析系统[J].计算机工程与设计，2012，33（5）：2 057-2 062.
数据库需求分析报告 篇二
高速公路机电工程主要包括以下主要系统：监控系统、通信系统、收费系统、通风系统、照明系统、供配电系统及消防系统。各个系统所包括的设备种类繁多，以高速公路机电工程最典型的三大系统(监控、收费、通信)为例，基本的子系统就包括：信息采集、信息传输、信息、信息存储与统计分析等发，基本设备分布在监控、收费、通信等管理中心及公路沿线的外场，一个工程少则几十种设备，多则上百种设备，设备的数量随着公路的里程和公路的等级增加或减少而相应变化。在高速公路机电工程的后期维护过程中，需要对所有设备的运行状况及故障出现的情况、处理方法等，按照ISO9000质量体系的要求，将所有的情况记录在日常维护日志及故障处理表等文件中，并根据出现故障设备的数量及种类，进行故障数据的统计分析和计算，定期做出工程项目的阶段故障分析报告，为以后的工程施工过程中的质量控及设备采购、订货提供可靠的科学依据。在相当长的时间内，高速公路机电工程维护中的故障处理表记录的大量故障数据，完全是人工填写后输入计算机，再按照一定的规则进行数据处理和计算分析后，形成阶段故障分析报告。由此可知，高速公路机电设备的后期维护是一个需要大量人力和物力的工作。因此，要做到工程维护管理工作的高效和数据的准确，需要我们设计一个高效、科学的工程维护管理系统，及时分析设备的故障原因及故障率，根据设备的故障率，在工程的设备采购阶段，尽可能的使用性价比高、质量优良、可靠性高的产品，确保高速公路机电系统的正常运转，保证高速公路的安全畅通，同时也能尽量降低企业的工程成本。根据ISO9000管理体系的要求和实际工程建设的施工过程，我们建立了如下ISO9000质量管理体系的维护工程工作流程。根据如图1所示的维护工程工作基本流程，利用先进的计算机技术、网络技术及可靠性分析与设计方法，设计的工程维护管理系统将解决如下问题：
(1)能够完成现阶段工程维护工作中需要人工完成的数据管理工作。
(2)能够使高速公路机电工程维护管理工作标准化和自动化。
(3)提高维护人员的工作效率和减轻工作强度，同时，也为工程项目的质量管理及过程控制，提供更加科学和准确的依据。
1、基本需求分析
由工程维护工作流程，本系统需要完成以下几个主要方面的功能：
(1)维护保养/例行检查记录表(维护日志):日常巡查设备的养护日志。(2)故障处理记录表：巡查中出现的设备故障、故障处理方式、用户意见等信息，详细地记录在表格中。
(3)阶段故障分析报告：根据阶段出现的故障设备的类型及数量，进行分析计算，给出本工程项目的设备故障率。
(4)日常维护月报：按月形成当月本工程项目的日常维护情况汇总。
2、基本用户分析
本系统是按照质量管理体系的程序要求，为工程维护管理工作而设计的，在工程项目的责任期，用于施工企业工程项目的日常维护管理工作；在责任期后，也可以根据需要用于高速公路运营方的设备日常维护工作。
二、系统基本组成及功能
本系统根据需求，设计为以下几个模块：
1、工程项目基本数据库
(1)高速公路机电工程中的常用系统及设备的标准化名称库。
(2)设备安装位置信息库：包含本工程项目中的设备或系统在项目中室内、外场的位置(桩号或安装位置)等。
(3)工程项目设备数据库：包含本工程项目的设备数量、设备商信息、设备的分类等。
(4)机电工程常用设备或系统的故障信息库。
2、工程项目维护记录表格库
按照ISO9000质量管理体系要求的文件格式，根据基本数据库及每日的维护工作的具体情况，输入基本数据，生成以下维护记录表格。
(5)维护保养/例行检查记录表(维护日志)。
(6)故障处理记录表。
(7)阶段故障分析报告。
(8)工程维护月报表。
3、故障数据处理分析模块
本模块的设计是建立在可靠性设计的基本概念上，相关的可靠性设计的基本定义简述如下：可靠性的基本定义：产品在规定的时间内完成规定功能的能力(简称3要素：规定条件、规定时间、规定功能)。故障率的定义：指工作到某一时刻尚未发生故障的产品，在该时刻后单位时间内发生故障的概率，称之为产品的故障率。用数学公式表示为：λ(t)=dr(t)/Ns(t)dt式中：λ(t)为故障率；dr(t)为t时刻后，dt时间内故障产品数；Ns(t)为剩余的产品数，即t时刻后尚未故障的产品数。可按下式进行工程计算：λ(t)=Δr(t)/Ns(t)Δt式中：Δr(t)为t时刻后，Δt时间内故障产品数；Δt为所取得时间间隔；Ns(t)为剩余的产品数，即t时刻后尚未故障的产品数。任何一个工程项目，都是由许多子系统组成，而子系统则是由许多的产品设备组成，对于一个机电系统集成企业来说，其系统的可靠性是保证工程质量优良很重要的一个环节。但是，产品的性能优良、功能齐全，不是用户考虑的惟一要求，产品的可靠性，易维修，使用维护保养费用的多少，产品寿命的长短等因素，都是用户关注的。良好的工程质量，不仅能够给机电系统集成企业提高竞争优势，而良好的产品质量，则能够减少工程维护成本，使企业能够从中获得更大的经济效益。故障数据处理分析模块的基本功能是根据可靠性设计的基本定义和计算公式，在一定的时间周期内，对工程维护过程中所记录的故障处理表的数据进行统计分析，计算出产品设备的阶段故障率，为最终形成的故障阶段分析报告提供科学、准确的数据。
三、系统的设计与实现
本软件的设计与实现是根据系统的需求分析，确定了软件系统的基本构成，根据维护工程工作的流程，设计了软件系统的基本流程。软件系统的开发基于MicrosoftSQLSever和VC++，运行平台为WindowsXP及以上操作系统，可视化的操作界面，使工程的维护管理工作实现自动化，系统可以实时查询各个项目的现场设备的故障状态记录及处理情况，设备的阶段故障率可根据需要随时提取计算结果。
四、结语
本系统是基于ISO9000质量体系管理的质量过程控制节点，对高速公路机电工程施工企业后期工程维护管理工作而设计的，其中的故障数据处理分析模块，基于可靠性分析与设计的基本概念，对高速公路工程维护工作中出现的产品故障数据进行统计、分析，计算出设备的阶段故障率，使得工程项目的质量控制更具有科学性及可操作性，为企业提高工程的质量、企业的竞争力和经济效益提供一个有效的手段。本系统也可根据需要扩展到高速公路的运营维护工作中，为高速公路的工程施工单位及高速公路的运营单位的日常设备维护管理提供一个科学和高效实用的方法，同时，为施工单位工程质量控制提供一个有效的环节。
数据库需求分析报告 篇三
数据库设计属于系统设计的范畴，通常把使用数据的系统称为数据库应用系统，把数据库应用系统的设计简称为数据库设计。数据库设计把数据库应用系统分为需求分析阶段、概念结构设计、逻辑结构设计、物理结构设计、数据库实施阶段、数据库运行与维护六个阶段。下面简要介绍各个步骤的主要任务及方法。
1.需求分析阶段
需求分析是在项目确定之后，用户和设计人员通过详细的调查研究，充分了解用户的组织机构、业务规则、数据需求等等。所谓需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。需求分析是数据库设计最基础的工作，如果这个阶段的工作不准确或有误，那么后面几个阶段的任务就会有偏差，如果到测试阶段才发现错误再去更改必然会付出很大的代价，因此必须高度重视这个阶段的人任务。需求分析阶段的后期编写系统分析报告，主要包括：系统的概况、目标、范围、现状等；系统及子系统的结构说明；系统的功能划分；系统的组织机构联系图；数据流程图；功能模块图及数据字典等内容。然后将此需求分析报告提交给用户的决策部门讨论审查，通过审查以后的需求分析报告作为今后各阶段设计和工作的依据。
例如：公司职工人事档案资料繁多，查询、统计、更新等各方面工作都不能更快更好进行，急需一管理系统实现人事资料的录入、维护、统计、查询等工作，明确要求后将具体事项形成书面报告审查后作为今后设计的依据。
2.概念结构设计
概念结构设计的目标是产生出一个能反映组织信息需求的概念模型，其特点有简单明确表示用户业务数据需求、数据之间的联系、数据约束条件等。概念结构的策略有四种自顶向下、自底向上、逐步扩张、混合策略。概念结构设计的最著名、最常用的方法是实体-联系方法，简称E-R方法。它虽然只有几个基本元素（实体、属性、联系），但能够表达现实世界复杂的数据、数据之间的关系和约束条件。
E-R图设计是对需求分析阶段所得到的数据进行分类、聚集、概括，确定实体、属性和联系，具体步骤如下：
2.1选择局部应用
数据流图是对业务处理过程从高层到底层的一级级抽象，高层抽象流图一般反映系统的概貌，对数据的引用较为笼统，选择适当层次的数据流图，让这一层的每一部分对应一个局部应用，实现某一项功能。
2.2逐一设计局部E-R图
规划好各个局部应用之后，对每一个局部应用设计局部E-R图，按照局部应用的数据流图，从数据字典中提取数据，使用抽象机制，确定局部应用中的实体、实体的属性、实体标示符、实体间的联系和类型，但是许多实物是实体还是属性没有明确的界定，要根据具体情况判断，一般来说，属性不能再分，属性也不能和其他实体发生联系，因为联系是实体和实体间的联系。
2.3 E-R图合并
根据局部应用设计好的局部E-R图之后，就可以对各局部E-R图进行合并，合并的目的是在合并过程中解决局部E-R图之间存在的冲突，消除存在的信息冗余，使之成为供用户理解的统一的、精练的全局概念模型。对所有的局部E-R图合并之后，就形成了全局E-R图，从而完成了概念结构设计。
3.逻辑结构设计
逻辑结构设计是在概念结构设计的基础上进行的数据模型设计，一般有层次、网状模型和关系模型，现在绝大多数DBMS都是基于关系模型的，此阶段的主要任务有确定数据模型、将E-R图转换为指定的数据模型、确定完整性约束、确定用户视图。
例如：部门（1）————职工（M）。
4.物理结构设计
在实现数据库逻辑结构设计之后，就要确定数据库在计算机中的具体存储。数据库在计算机物理设备上的存储结构与存取方法称为数据库的物理结构。数据库的物理设计完全依赖于给定的数据库软件和硬件设备。层次和网状模型物理设计比较复杂，而关系DBMS对物理设计要求很少，由DBA来实现。物理结构设计需要确定数据分布、确定存储结构、确定存取方式。
5.数据库实施阶段
确定了数据库的逻辑结构和物理结构以后，可以利用DBMS提供的数据定义语言建立数据库的结构。
例如：CREATE TABLE 职工库。
（职工编号 CHAR（6） NOT NULL，
姓名 CHAR（8） NOT NULL，
性别 CHAR（2），
所属部门 CHAR（10），
PRIMARYKEY KEY （职工编号））；
当数据库的结构建成之后，就可向数据库中加载数据，由于数据库中的数据量非常大，为了避免浪费大量人力财力时间等，通常专门设计一个录入子系统来提高效率，满足用户的要求。该子系统一般包括数据录入、录入过程的数据校验、代码转换、数据完整性约束、安全性检查等功能。
6.数据库的运行与维护
数据库设计与应用开发工作完成之后系统便进入运行与维护阶段。为保证数据库系统的安全稳定运行，需要综合考虑可能遇到的各种问题，指定详尽的运行计划和应对措施。任何因素导致系统初选问题，都可能给用户带来损失。
数据库的运行与维护阶段主要任务有：
6.1维护数据的安全性和数据完整性
为保障系统的稳定运行，必须制定运行策略。数据库的运行离不开用户的访问和操作，安全性策略包括网络安全、用户的权限管理、设备的安全及数据的安全等方面。按照设计阶段提供的安全和故障规范。实施授权和设定密码，并经常检查系统的安全性和可靠性，实施备份、恢复和数据重组的任务。
6.2监测并改变数据库性能
经常对数据库存储空间的状况和响应速度进行评价分析，确定优化和改善的措施，及时调整系统的运行状况。
6.3数据库的维护
在数据库系统的运行过程中，可能会由于某些原因需要修改数据库的结构，称为数据库的重构，重构包括表结构的修改和视图的修改。还要根据用户环境的扩大，适时的向数据库增加一些新的数据和功能。
6.4及时修改错误
系统运行过程中难免发生一些错误，需要及时运行修改错误，弥补设计时的欠缺。
数据库需求分析报告 篇四
分析报告没有固定格式，结构安排也相对比较灵活，由经济活动分析的目的、需要决定。常见的经济活动分析报告一般包括标题、正文、署名三部分内容。
(一)标题
全面分析报告的标题，一般要写明单位、时间、分析内容、文种等四项内容，如《××商场20xx年1月份销售情况分析》;专题分析报告的标题，一般是揭示分析报告的主要内容与范围，如《产品库存积压的原因何在？》;部门分析报告的标题，一定要标明部门，如《××市建工系统企业20xx年主要经济指标的分析》。
(二)正文
正文可分为导语、主体、结尾三部分。
1.导语
它是分析报告的开头部分，这—部分往往针对分析的问题，或简要介绍被分析对象经济活动的基本情况，如评价产销形势、计划指标及指标完成情况；或交代分析的目的、起因；或指出存在的问题等等。这一部分应开门见山，直截了当地叙述主要问题，尽快引入主体部分。
2.主体
主体部分集中反映着经济活动的分析过程及其结果，经济活动分析报告的核心部分，主要阐释经济活动“怎么样”、“为什么这样”及“应该怎么办”的问题。体现在结构上即表现为“基本情况——原因分析——对策建议”这样三个相互关联的层次。
(1)基本情况：一般采用对比、分解、综合的方法，运用大量数据说明经济指标的完成和变化情况及其存在的问题，展示经济活动的基本情况。有时还可列出表格并叙述说明。
(2)原因分析：要从分析的对象和目的出发，对经济活动的具体情况予以具体细致地分析，找出主客观影响因素，并对其经济效益作出客观评价。在分析中，既要分析成绩取得的原因，总结经验，又要善于揭示矛盾，分析问题产生的症结；既要重视客观因素的分析，也不能忽视主观因素的分析。如果是全面分析报告，则要对各项重要的经济指标逐项进行分析；如果是专题分析报告，则要对该专题的内容和要点展开分析；如果是部门分析报告，则要抓住几个主要经济指标或一两个重点问题进行分析。这部分的写作必须实事求是，依据确凿的数字和翔实的资料(包括计划资料、统计资料、会计核算资料等)，运用适当的分析方法(包括对比分析法、因素分析法、动态分析法、综合分析法、调查分析法等)，对一种经济现象发展变化的全过程，追本溯源，抓主要矛盾，突出重点问题，恰如其分地进行分析评价。
(3)对策建议：它应以主体部分为基础，抓住要害，有针对性地提出切实可行的建议或措施，观点要鲜明，切忌模棱两可，意见要中肯，措施要有的放矢。
3.结尾
由于主要内容已在主体中涉及到了，因此，大多数经济活动分析报告都不再有单独的结尾，而在写完对策建议后自然作结，行文上显得干净利落。也有一些经济活动分析报告有独立的结尾，或者总结回顾以照应前言，或者预测前景以展望未来，或者补充说明，使内容更加全面。不管哪种写法，都要简短精粹，切合需要。
(三)署名
在正文之后右下方签署提出报告的单位或个人姓名，说明写作日期。如标题已标示单位或个人姓名时，只写日期即可。
分析报告范文
随着inter的发展，电子商务将从新闻、宣传企业形象等功能，进到网上办公、网上采购、电子支付等具有交互功能的新阶段。这些交互大部分介于计算机系统、电子商务应用程序和软件组件之间，即动态电子商务(dynamice-business)。webservices是一种基于标准的应用集成方式，它可以将运行在intra/inter分布式服务器上的应用集成在一起，使地理上分布在不同区域的计算机和设备协同工作，为用户提供各种各样的服务。
一、系统需求分析
目前国内不少机电流通企业已经在利用网络技术进行运营管理和业务拓展，但仍存在一些制约因素：第一，库存资源贫乏和库存资源的高风险；第二，资金的短缺和高财务成本；第三，原有基于client/server二层应用体系结构的连锁经营管理系统给连锁分销体系的建立的带来了局限性、高成本和风险。案例分析报告。
通过对it互联网信息技术现状和发展趋势研究，利用成熟的webservices技术，实施商务模式的变革，将进销存商务运作范畴从公司内部提升到整个机电行业，来达到引入和共享社会资源，不但可以完全解决库存资源和资金的问题，还能大大降低公司经营的风险。同时，基于互联网三层应用体系结构应用，为公司分销体系的建立带来前所未有的光明前景：
集社会资源为我所用，并以此树立行业地位和迅速扩大市场份额，并具备可控性、低成本、低风险和高效率。并由此建立了“合作与服务”的经营理念。
系统目标如下：
(1)为机电流通企业提供全程服务，而不仅仅是简单的信息。
(2)系统具有开放性、平台无关性，能够与现存的电子商务系统很好地兼容。
(3)机电流通企业可以根据自己的特别要求进行定制，而且过程不复杂。
(4)方便应用服务提供商(applicationserviceprovider，asp)扩展和维护系统功能。案例分析报告。
二、系统功能设计
整个系统由信息系统和交易系统二部分组成。信息系统主要是为交易系统提供辅助服务，为机电行业和产品提供全面的信息咨询和技术服务支持，随着交易规模的扩大而将提供的机电产品交易行情指数；交易系统主要是采用会员制方式为机电行业制造商、行业总商、分销商、物流商和客户提供在线供货、在线、在线分销、在线仓储物流配送和在线采购。如图所示：
(1)为机电行业的产品制造商提供快速进入市场的渠道；为制造商提供了高效、便捷、低成本、低风险、高可控性的商务模式；使制造商具备对库存产品资源的集中管理、合理配备和对物权的绝对控制和调度的能力和手段；具备了对产品的价格在应对市场变化而拥有统一而有效的调控手段和能力；具备了借助互联网的应用而建立起具有无限扩展前景的产品分销体系的条件；实现了社会库存产品资源的共享。
(2)为机电行业的分销商提供了高效、低成本、低风险的销售商务模式；实现分销商零库存，避免了库存积压或沉淀而造成的损失；实现了对庞大的社会库存产品资源的享用。
(3)为机电产品的消费用户提供高效、便捷、低成本的采购渠道和手段，节约人力成本，提高采购效率和采购透明度，并有望实现产品消费单位所渴望的备品备件零库存目的。
(4)为物流配送企业实现了网上产品配送单接收功能、网上配送单的维护、跟踪、查询和处理的管理功能等。加快物流配送企业业务信息传递，提升了工作效率和服务质量，为物流配送企业实施规模经营奠定了良好的基础。
三、系统实现
1、三层体系结构设计思路
根据目前大多数机电流通企业计算机应用的需求分析情况，构建基于webservices成熟的电子商务解决方案，以先进成熟的计算机和通信技术为主要手段，建立以三层体系为主体的系统构架，来实现机电流通企业的电子商务系统。
该电子商务交易系统通过局域网和互联网专用线路完成整个系统的数据管理和通讯。系统采用先进的三层结构体系，将业务应用逻辑集中到中间层处理，增加了系统的适应性、维护性和可靠性。
在总部建立数据中心，作为核心数据库，存储各个基地汇总上来的业务数据，并使用双机集群技术保证数据库服务器的高可用性。
在总部建立应用服务器，存放所有应用逻辑，供客户端连接调用。
客户端不需安装数据库客户端，只需一次性安装系统动态库，即可使用浏览器进行业务处理，并可得到非常友好的交互性。
2、系统实现
基于webservices的电子商务系统是一种需要订货方与供货方之间相互配合才能发挥最大效率的系统。订货方系统的实现需要利用大量的供货方提供的webservices，同样供货系统也是如此。为简单说明问题，本文只给出订货方系统的部分实现方法。
订货方选用windows20xxserver sqlserver20xx visualstudio。实现。windows20xxserver是微软在服务器操作系统nt基础上的升级版，进一步增加了系统的易用性、稳定性、界面友好性。sqlserver20xx数据库与windows20xx系统紧密结合，在功能上有了很大的扩充，性能进一步提高，是中小企业数据库软件的首选。visualstudio。开发工具作为微软、计划中的重要一员于20xx年一经推出就受到了广大开发人员的喜爱，它强大的开发环境、高效的开发效率、翔实的资料信息是其他开发工具所无法比拟的。在编程语言方面选用了c#语言，c#语言是微软新推出的一种专门为网络编程量身定做的编程语言。它是在继承了java、c、c 等语言的优点后发展起来的一门简单易学、高效优质的语言。c#语言吸收了java语言的虚拟机概念，利用ctl这个运行库做到了跨平台运行；同时，它与windows的紧密结合也使它成为windows下编程的最好选择。因此，在系统实现时选用了上述组合。
(1)订货方采购单的web服务实现。利用visualstudio。开发环境建立一个aspxweb服务，命名为listpurchaseservice(具体代码略)。此服务首先检索采购订单数据库，把还没有完成的采购订单信息检索出来，并利用dataset格式给供货方。dataset是微软推出的一种新的基于xml的数据格式。因此只要信息接收者有一个xml解析器就可以进行数据分析。当然，如果可以利用。开发环境的话，开发效率和运行效率都会有大幅度提升。
(2)订货方提供的供货方基本信息修改web服务的实现。此服务可以使供货方动态地修改自己的基本信息，如公司名称、公司密码、公司电话、联系人、产品简介等。但公司编号、公司信用等级是由订货方维护，供货方只能浏览，无法修改。
(3)订货方利用供货方提供的web服务实现流水化电子。采购实现流水化电子采购需要供货方提供一整套的web服务，包括产品信息的检索、采购单的处理、网上议价、订货单的处理等。
四、需要解决的关键问题
1、webservices的实现
使用webservices部署数据库应用系统时，若不知道webservices的url，必须使用发现工具来完成对webservices站点的发现工作；若已知url，发现工作可省略。发现webservices后，必须使用webservices描述语言工具wsd1、exe来创建服务。服务是一个位于本地计算机上的class，它封装了服务通信所需的所有复杂的功能。因此在应用系统中，可以像与本地对象交互一样与服务进而与webservices服务器进行交互。
2、webservices的安全
创建了公用的webservices后，任何知道该服务url的人都可以使用。因此必须采取措施来确保webservices的安全，以便只有被授权者才能使用它们。例如，可使用soap报头(xml)来发送认证信息(作为命令的一部分)，只有合法用户才能访问该服务。
数据库需求分析报告 篇五
关键词：高校后勤 财务管理模式 信息化平台
中图分类号：G475 文献标识码：A
文章编号：1004-4914（2012）05-094-02
评价一个财务信息系统成功与否的关键在于这个系统是否完成预期的建设目标，是否给高校的后勤财务管理带来效率和水平的真正提高。在财务信息化平台的建设过程中，可充分利用高校应运而生并迅速发展起来的新的信息技术手段和现代化设备，进一步拓展财务管理信息系统的各项功能，向集高校后勤财务管理与信息化校园于一体的“一体化”管理方向迈进。因此，高校后勤财务信息化平台应以账务核算、预算管理、资金管理和项目管理等模块建设为核心，结合校园一卡通系统，整合形成校园后勤管理的一整套业务流程。
一、后勤财务信息化的需求与系统管理目标的设计
（一）后勤财务信息化的需求分析
从高校后勤管理的实际出发，针对高校具体的财务管理状况和管理目标进行调研，作出符合实际情况的后勤财务信息化需求分析和评价。对于要达到的既定目标，既要用发展的眼光又不能脱离现实条件，尽可能细化、量化好系统需求方案制定前的组织调研工作。
1.理清高校的管理体制和结构。高校的办校规模不同，管理体制也不尽相同，无论是哪一方面的管理都要服务并服从于高校的整体管理，后勤财务信息系统要为学校的财务管理服务这一点无可厚非。部分高校多个校区，属于多级次的管理体制。管理体制的差异影响财务信息系统组织机构的功能设置，并对实施方案中的软硬件环境（诸如网络环境、软硬件设备的选择、人员的配备和岗位的设置）等要求产生影响。因此，只有明确了整个财务管理的组织结构以后，才能对财务信息系统的建设作出既科学又实用的规划和设计方案。
2.确定目标工作流程。完成系统需求分析后，要着手对后勤财务信息系统运行的整个工作流程进行分析和前景规划。通过对后勤财务信息系统工作流程与现行的财务工作流程进行比较，如果两个流程的差异很大，那么应该及时同财务主管领导做细致的沟通，分析可能出现的问题，杜绝可能出现的漏洞，确认目标工作流程的可操作性。为方便今后开展工作，经过反复研究论证后的最终工作流程的分析报告也需要得到财务主管领导的签字认可，方能进行下一步的工作。
3.信息化平台的目标定位。对于将要建设的后勤财务信息系统需要达到的目标应该有一个相对准确的描述和合理定位，包括这个系统要实现的功能目标和性能目标，以及为实现这样的目标对整个系统要进行多大规模的资金和人力投入，怎样投入等。整个系统建设周期的计划是什么，阶段性目标是什么，特别是如何进行对系统建设完工后的验收、使用和评价等。
4.出具需求分析报告。通过前期各阶段的准备工作，对系统的需求分析进行了论证调研得出结论后形成书面报告。需求分析报告将成为系统设计的依据和今后系统改造的基础资料。
（二）设计信息管理系统的目标方案
详细了解高校后勤财务管理状况以后，作出对具体的财务管理需求的分析报告，设计制定目标方案。理论上，财务信息化的目标与财务管理的目标应该保持一致，但我们必须要考虑财务信息化的阶段性发展问题这一客观因素的存在。不同阶段会面临要解决不同的问题，不能一刀切的看待遇到的各种障碍性因素，更不能主观期望从一开始就解决所有的财务管理问题，这种想法是不切实际的。在开始设计具体的实施方案前，对高校的财务管理状况要有一个比较整体、客观和细致的了解。要内外兼明，尤其是对于高校后勤现行的财务管理体制、上级部门的支持情况、部门内部的业务流程、人员配备和岗位设置情况，以及高校整体的信息化水平、软硬件环境等做一个比较细致的调查。应当明确高校后勤目前最迫切需要解决的财务管理问题，通过信息化平台建设能否解决这一问题，能否做到通过一定程度上制度的变革来为财务信息化扫清障碍，领导层是否做好了这方面的思想准备。因为，当我们决定开始启动财务信息系统后，都会在一定程度上引发财务管理体制“地震”，因而需要事前做好方方面面的准备工作。
二、后勤财务信息管理系统的建设
根据已经确定的需求分析报告对后勤财务信息管理系统进行规划、设计，制订出具体的设计方案。设计方案的内容包括：系统的网络环境要求、系统需要的硬件和软件配置、财务信息系统软件的选购、系统的运行维护、人员和岗位配置等，整合这些具体的设计方案就形成一个相对完整的后勤财务信息系统设计。
（一）硬件平台的设计与构建
1.规划和设计网络环境。通常情况下，单一校区的高校后勤多采用集中式财务管理模式，规模较大的高校后勤则采用分级管理。规模较大且多个校区的高校比较适合采取分散布局、集中管理的模式。建设后勤财务信息管理系统时，不同的管理模式对网络环境的要求也不一样。在设计后勤财务管理信息系统建设的方案时，一般都会优先考虑财务网络的建设方案。单一校区的高校，往往选择物理上与其他网络隔离的独立的网络环境，这样的网络环境安全系数比较高，缺点是与其他管理系统的数据共享和交换受限。规模较大且拥有多个校区的高校，在选择后勤财务信息管理系统的网络环境时，要考虑的因素就相对复杂得多。首先要考虑的是安全因素，其次要考虑到建设实施的成本问题。在校区间相距较远的条件下，构建独立的财务专用网络会产生较高的成本，这样建设难度就比较大。近些年来，高校的校园网络建设和发展速度较快，绝大部分高校都拥有自己的校园网，这是发展的必然趋势。所以，通过依托“校园网”建设“财务局域网”成为一种较好的解决方案。利用VNP技术，依托校园网搭建一个财务专网，成为一种较为现实可行的做法，因为这种做法不仅大大降低了建设成本，而且在技术上和安全性能上也有一定的保障。网络布局方案设计完成后，还应考虑网络环境建设需要的网络设备条件。网络设备的挑选通常按性能价格比的原则，在建设资金保障充分的前提下，可选择稳定性好、质量高的产品。
2.服务器及周边设备的选型与配置。服务器的选择非常重要，在选择前要先咨询这方面的专家。系统的应用规模和发展趋势是选择服务器种类的重要考量因素。同时要考虑到发展的需要，适当留有冗余。服务器工作环境要得到保障，条件允许的情况下，服务器最好设在通风、散热条件好、环境整洁的独立机房内。
（二）软件平台的建设
1.操作系统软件的配置。当前应用较广的操作系统有Linux、Unix、WindowsServer系列等等。高校在建信息系统的软件平台时，常会选择一种作为主要的操作系统软件。不过，也有混用的情况，如果从管理便捷性方面考虑，多种操作系统并用的情况往往会出现系统不兼容的现象，因此不利于管理。
2.选择数据库系统软件。数据库系统软件在很大程度上直接影响到系统处理财务信息的效率和质量。目前常用的数据库软件有SQLServer、Informix、Oraele、MySQL等，这些数据库软件在性能方面各有各的特点。不同操作系统对软件功能要求也有所不同。在建设财务信息化平台之前，要根据后勤财务管理的要求，同时考虑其他管理系统的需求，以便选择更适合后勤财务管理的数据库软件系统。
3.选择财务管理系统软件。在选择财务管理系统软件时要考量多方面的因素，软件应用的核心问题是它的配置。财务管理软件系统是整个财务信息系统运行的载体。财务管理软件取得的途径有两种：一是购买，另外一种是自行开发。在后勤财务信息化平台建设过程中，高校后勤财务管理系统软件的规划与选择是核心工作，一方面要考察财务管理系统软件在功能上是否能够满足高校后勤财务管理的需要，另一方面还要考虑自身的个性化需求。现在绝大多数高校都采用直接购买的方式取得软件，因为，这种方式的建设周期可以大大缩短，而且没有开发风险，系统运行也会比较稳定。但是，这种商品化软件通常都是通用软件，很可能存在短时间内无法满足单位的个性化需求的问题。
三、财务信息化平台的实施
（一）硬件平台的运行
系统硬件平台能够稳定的运行取决于很多因素，包括服务器及其配套设备、网络设备、备用电源供给、客户端设备配置等。硬件平台系统运行的稳定性、数据的安全保障是首要和重点考虑因素。财务信息系统因其功能的特殊性，在硬件设备配置的选择方面要求相对较高。首先做好网络设备的暗转与调试，其次做好服务器及周边硬件设备的安装与调试。
（二）软件平台的运行
要保证软件平台的正常运行，首先要做好操作系统软件和数据库软件的安装工作，然后进行财务管理软件系统的安装和调试。这时应注意确定财务管理信息子系统的使用规模和顺序。通常高校后勤在安装使用新系统过程中，首先要保证历史工作的正常运转和延续，因而会比较谨慎地选择一个或者几个有把握的子系统进行试运行，待稳定运行一个阶段后再使用其他子系统。当然，也有高校采用新旧系统同时运行一段时间的方法。各高校可根据自身的实际情况进行选择。另外，财务软件的初始化工作也是非常关键的环节之一。系统初始化的工作不仅重要，而且工作量也很大。为了保证财务信息系统安全、稳定地运行，同时还要在服务器和客户端上一并安装防病毒软件、数据备份软件等。
［基金项目：黑龙江省教育会计学会科研课题，编号：1155KJXH402；黑龙江省人文社会科学研究项目，编号：11552175］
参考文献：
1.肖富宁。高校财务信息化建设若干问题的探讨。首都经济贸易大学硕士论文，2009
2.许永斌。我国电算化会计信息系统模型改造理论基础。会计研究，1996
3.薛云奎，饶艳超。会计信息系统(第二版).复旦大学出版社，2008
4.于金红。税务会计应用的障碍性因素及发展思路研究。财会研究，2011（12）
5.王海林。试论会计信息系统运行阶段的风险与控制。会计之友，2009（1）
6.邹秀华。高校财务管理信息化建设研究。中国科技信息，2008（3）
（作者简介：于金红，黑河学院副教授，研究方向：财务会计理论与方法；宁艳杰，黑河学院，经济师，研究方向：高校财务管理；戴长松，黑河学院 黑龙江黑河 164300）
数据库需求分析报告 篇六
【关键词】反洗钱 可疑交易 报告 模式 研究
一、引言
近年来，顺应国际反洗钱发展趋势和金融行动特别工作组（FATF）反洗钱标准的变化，作为我国反洗钱主管部门的人民银行提出了“风险为本”和“法人监管”的反洗钱工作理念，并在金融机构启动了“可疑交易集中处理”试点，这对当前金融机构双向报送的可疑交易报告模式带来了挑战。新形势下，如何构建有效的可疑交易报告模式，提高可疑交易信息处理质量和效率，更好的发挥对打击洗钱犯罪的作用是人民银行亟待解决的问题。
二、当前可疑交易报告模式存在的弊端
（一）双向报送不完全适应风险为本和法人监管要求
目前，我国对金融机构反洗钱可疑交易报告采取基于“规则为本”的双向报送模式，即金融机构按照确定的标准向反洗钱监测中心报送一般可疑交易报告和向人民银行分支机构报送重点可疑交易报告。近年来，双向报送模式取得一定成效，但也存在一些问题：一是金融机构以合规标准筛选出海量可疑交易报送给反洗钱监测中心，但缺乏人工分析的一般可疑交易报告大多成为垃圾数据，反洗钱监测中心不得不花费大量资源进行二次研判，造成了人力物力浪费。二是金融机构向人民银行分支机构报送重点可疑交易报告具有区域局限性，给人民银行分支机构带来履职风险。重点可疑交易往往涉及全国多个省市，仅凭人民银行分支机构获取的客户信息和交易情况难窥全貌，造成重点可疑价值被人为降低，影响了挖掘利用。同时，人民银行分支机构对接收的重点可疑交易如认为价值不高，可不予接收或退回。但由于对可疑交易质量的研判没有统一标准，一旦退回的重点可疑交易线索牵涉案件，将带来履职风险。
在风险为本和法人监管模式下，带来两方面变化，一是法人监管更多强调金融机构的法人责任。从可疑交易报告方面看，金融机构法人要切实承担反洗钱可疑交易报告义务，这要求金融机构要理顺内部关系、统一内部操作，客观上需要取消双向报送，实施单向总对总报送。二是风险为本模式下，人民银行将逐步取消客观标准，主要由金融机构自主判断来报送可疑交易，可疑交易没有了一般可疑和重点可疑之分，使双向报送模式一定程度上失去了存在基础。
（二）在金融机构可疑交易报告集中处理模式下，双向报送成本更高
当前，工商银行在全国开展了可疑交易报告集中处理试点，招商银行、民生银行等金融机构也积极开展可疑集中处理准备工作，可疑交易集中处理已成为金融机构可疑交易报告的趋势。如工商银行的可疑交易集中处理中心一般设置在二级分行或省分行，在设立集中处理中心的省份，其地市分行已不再履行可疑交易分析职能。招商银行拟设立专门归总行管理的反洗钱监测分析中心，集中处理可疑交易，其他分支行不再主要承担可疑交易分析工作。在集中处理模式下，如果金融机构继续按目前的双向报送模式报送，则需要向不承担可疑交易分析的分支机构所在地人民银行报送重点可疑交易报告，这就需要其总部对已经集中分析的数据进行二次分离，并按地区筛选出重点可疑交易反馈当地分支机构，由当地分支机构再上报当地人民银行，这将进一步增加报送成本，使金融机构本已集中的可疑交易又被分离，不符合“可疑交易集中处理”降低金融机构成本的改革方向。
（三）当前人民银行分支机构、基层金融机构人力资源配备难以切实保证重点可疑交易分析质量
从人民银行层面看，一方面目前大量地市中心支行仍未设立专门的反洗钱科室。以山东省为例，全省17个地市人民银行中心支行中，11个没有专职的反洗钱部门，6个设立专职反洗钱部门的中心支行，人数多在4-5人，人力资源明显不足。另一方面，随着风险为本监管思路在人民银行的逐步贯彻，风险评估工作将全面展开，人民银行分支机构要承担风险评估、分类监管和重点检查等繁重职责，人员少、任务重的矛盾愈发突出，将进一步影响对重点可疑交易报告的分析质量和报送数量，双向报送模式难以适应最新的反洗钱监管要求。
从金融机构层面看（以商业银行为例），商业银行可疑交易分析职能目前主要前置到地市分行甚至支行，支行承担大部分可疑交易分析职能，可自行决定是否将可疑交易上报给总行和将重点可疑交易报给分行，由分行报当地人行。由于商业银行基层支行人员配备、技能储备明显不足，报送的重点可疑交易质量较差，这也是目前推行可疑交易集中分析模式的重要原因。
随着人民银行推行风险为本和法人监管，金融机构推行“可疑交易集中处理”，以往双向报送模式难以有效开展。
三、发达国家可疑交易报告模式借鉴
（一）美国
1.接收金融机构可疑交易报告的有关组织及职能
美国金融犯罪执法网络（FinCEN）负责反洗钱情报收集、处理和分配，根据“以大额现金交易报告为主、可疑交易报告为辅”的要求，综合金融机构报告的信息形成金融交易数据库，结合其他政府部门及公众的信息提供情报报告，分析可疑交易，并按需要反馈给相关部门而设立并运作的。金融犯罪执法网络主要任务一是存储和分析金融机构和非金融机构以各种形式提交的可疑行为报告和现金交易报告；二是为侦办案件提供情报和分析帮助，向政府部门提供数据接口服务，供司法部门调查人员和监管部门管理人员在其权限范围内查询可疑行为报告和现金交易报告。
2.信息收集与使用
FinCEN实施入门（Gateway）计划，将反洗钱情报在相关部门间传递和共享，使各种反洗钱力量有机结合在一起，从而以情报为纽带组织起部门间的合作。每一个加入这一计划的联邦、州和地方执法机关都需同FinCEN签订一个协议，经授权后，该机关及其人员就可以借在线访问FinCEN的数据资源。计划提供了专门的搜索和分析程序在完成使用者查询请求的同时，也自动将请求中的信息要素与已有的案例或其他执法机构的执法库的索引进行匹配，找出相关信息，满足执法部门的情报需求。为确保金融情报信息数据库安全，FinCEN与342个外部使用者签订了备忘录，明确责任，确保信息合法使用。
（二）英国
1.接收金融机构可疑交易报告的组织及职能
英国“打击严重有组织犯罪局（Serious Organized Crime Agency，SOCA）”负责收集分析与洗钱和恐怖融资有关的可疑交易报告；识别犯罪资产；开展对未知犯罪或恐怖活动的先期调查，并对有组织犯罪威胁开展评估；向执法部门提供线索，并提供协助以打击洗钱和恐怖活动；侦查刑事、民事案的犯罪收益或税收追回；负责对经济金融调查员开展培训等职责。
SOCA在其犯罪资产部内设立英国金融情报中心（FIU），负责收集分析与犯罪收益和恐怖融资有关的可疑交易报告，识别犯罪资产，开展对未知犯罪或恐怖活动的先期调查，向执法部门提供线索，并提供协助以打击洗钱和恐怖活动。金融情报中心同时还承担反假币的职能。
2.数据收集与使用
英国情报中心（UKFIU）网络数据库（ELMER）收集信息报告主体报送的可疑交易信息，并对可疑信息自动实施搜寻情报调查、汇集、分析处理，由联络中心对ELMER中搜寻到的可疑信息进行分析，将不适合的可疑报告信息返回给报告主体，适合的则向执法机构提交推荐及建议。在遵循保密安全前提下，SOCA准许其他执法机构直接接入可疑交易报告数据库，并鼓励充分使用。SOCA与多家执法机构订立合作协议，准许其直接接入可疑交易报告数据库。截至2010年末，英国已有78家执法部门可以直接接入可疑交易报告数据库，使用可疑交易报告数据来开展工作。
从发达国家可疑交易报送模式来看，反洗钱可疑交易报送均由金融机构总部报送至监管机构总部，监管机构总部统一进行分析研判，并根据情况反馈至下级机构和其他有关部门，使信息得到充分利用。同时可疑交易报告仅有一种类型，无一般可疑交易报告和重点可疑报告的区分。
四、构建我国可疑交易报告新模式的设想
根据风险为本监管要求，借鉴国外工作模式，本论文提出“金融机构总对总报送、监测中心纵横向反馈，人民银行阶梯式使用”报告模式设想。
（一）“总对总报送”
即取消可疑交易双向报送模式，由金融机构对经分析甄别的可疑交易直接总对总报送至反洗钱监测中心，金融机构的可疑交易报告质量直接由金融机构总部负责，反洗钱监测分析中心全面履行可疑交易报告的分析职能。
（二）“纵横向反馈”
即借鉴发达国家充分利用可疑交易数据库、最大限度发挥金融机构情报价值需要，由反洗钱监测中心向人民银行开放数据库。考虑到人民银行分支机构人员配备，并与反洗钱法规定的行政调查权由省级以上人民银行承担的规定相衔接，建议反洗钱监测中心可疑交易数据库反馈至总行反洗钱局和省级人民银行分支机构两个层次。对总行反洗钱局，建议中心反馈全部可疑交易数据，对省级人民银行则反馈本辖区数据。
（三）“阶梯式使用”
按照总行、省级分行、地市中心支行（含支行）三个级别，有侧重性的分级使用数据。下级机构可根据需求向上级行提出数据使用申请，由上级行可临时赋予数据查询、数据下载权限。上下级机构在分析使用数据时进行有效联动，总行、反洗钱监测中心从全国层面进行分析考虑，分支机构从辖区角度进行分析，并承接总行、反洗钱监测中心协查等工作任务，上报分析成果，确保分析质量。
1.统筹使用反馈数据进行可疑交易监测分析
人民银行总行侧重分析数额大，影响广的案件线索或可疑交易；省级分行侧重分析监测涉及本辖区金融机构和客户的数据，在分析辖区可疑线索基础上，积极配合完成总行布置的可疑线索，并向总行上报有价值的分析成果；地市中心支行（含支行）侧重现场检查领域的使用，以涉案线索进行回溯性检查。
2.深入挖掘可疑交易信息在评估中的作用
总行可在法人监管中着重考虑金融机构总行（总部）的反洗钱系统建设、董事会重视程度；省级分行可根据可疑交易报告情况，重点关注金融机构部门配合、业务风险防控情况，同时可对总行（总部）设在当地的金融机构履行人总行监管职责；地市中心支行（含支行）可根据可疑线索倒查一线业务人员履行反洗钱义务状况，同时可对总行（总部）设在当地的金融机构履行监管职责。
五、政策建议
为适应本论文提出的新的报送模式，建议修改《金融机构大额交易和可疑交易报告管理办法》并出台相关指引，明确标准，规范操作。
1.确定新的可疑交易报告标准
修改《金融机构大额交易和可疑交易报告管理办法》，将金融机构报送可疑交易的主观判断要求进行规定，为后续深入开展集中报送试点和推行全面总对总报送提供制度支撑。
2.在反洗钱监测中心向人民银行总行、人民银行省级分行反馈数据时，应明确定位、加强管理
一是制定数据反馈及使用办法，规定各级人民银行数据利用方法及获取程序。二是升级系统数据库，使反馈数据、数据下载及使用的痕迹都在系统中有日志记录，规范数据传递和使用流程，严防泄密风险。三是重新修订行政调查管理办法，对分支行行政调查及资金监测工作重新定位。
3.明确人民银行分支机构在“法人监管”和“总对总报送”模式下的反洗钱监管责任
一是对辖区有法人金融机构的，人民银行分支机构应全面实施管理，可对其外地设置的“可疑交易集中处理中心”进行延伸管理，以体现法人监管工作思路。二是在当地有“可疑交易集中处理中心”的金融机构分支机构，当地人行在反洗钱评估、风险监管和现场检查时，可以纳入可疑交易报告分析内容。三是对当地无“可疑交易集中处理中心”的金融机构分支机构，日常监管中可不予考虑金融机构操作层面的可疑交易报告情况，侧重评价其内部控制、上下级可疑交易报告流程等机制建设方面内容。
参考文献
[1]中国人民银行反洗钱局。中国反洗钱专题研究（2011）[M].北京：中国金融出版社，2012.
[2]中国人民银行反洗钱局。中国反洗钱专题研究（2010）[M].北京：中国金融出版社，2011.
[3]杜金富。银行业反洗钱与反恐怖融资培训手册[M]. 北京：中国金融出版社，2011.
数据库需求分析报告 篇七
教学内容：软件工程概述；补充介绍选题方法。实践内容：分组与选题。（1）分组。将一个班的学生分为若干个项目组，每组3～5人，每组有一名组长作为项目经理组织后续的项目开发，负责给成员分配角色，如系统分析员、软件设计师、软件开发工程师、软件测试工程师。根据角色，每个成员都有相应的任务。（2）选题。在项目驱动教学法中，项目选择是关键步骤，关系到整个项目能否顺利实施。因此，在各组自选项目时要注意：尽量选择自己熟悉的流程来构建软件系统，如图书馆借还书系统；所选系统有3～5个功能模块，过于复杂则难以把握，过于简单则缺乏整体性；尽可能选择与实际需要相结合的项目、科研创新基金项目等；项目开发所需的软硬件都是可获得的，所需开发技术是学生已掌握的或短期内可掌握的。最后，教师要认真审查学生选题，避免重复，控制规模，确保可实现。
2.需求分析阶段
教学内容：软件需求分析原理、结构化分析法、面向对象分析法；补充介绍主流建模工具、开发平台、Web开发环境。实践内容：深入了解和分析需求，形成文字化需求说明；安装建模工具，使用Rose/Visio进行需求建模，绘制用例图和活动图，完成软件需求分析报告。配置开发环境，熟悉开发环境的使用，编程实现“登录”功能。教师及时批阅和评价需求分析报告，重点检查用例分割的粒度是否合适，指出学生在运用方法和工具解决实际问题时存在的不当之处，对突出问题进行集中讲解，确保学生建立正确的认识，树立信心。
3.软件设计阶段
教学内容：软件设计原理、结构化设计法、面向对象设计法；补充介绍平台设计、界面设计及工具的选择、数据库设计及数据库管理系统的选择、程序设计语言及编程环境的选择、出错处理。实践内容：在Rose/Visio中绘制类图、顺序图、状态图；用PDL对关键处理进行描述；对典型界面进行设计；数据库基表设计；完成软件设计报告。编程实现“读取数据库数据并显示到页面”的过程。教师及时批阅和评价软件设计报告，重点关注类图的合理程度、顺序图表达细度等，指出存在的问题，确保学生充分经历软件设计阶段的各种设计任务。
4.实现和测试阶段
教学内容：软件测试方法、主流测试工具介绍。实践内容：编写系统源代码；设计测试用例，进行单元测试、集成测试和系统测试；完成系统测试报告。教师及时批阅和评价测试报告，指出可能存在的漏洞。在系统完成后，根据开发文档对系统进行整体检查，重点关注学生常常疏忽的出错处理问题，在软件用户友好性方面提出更高要求，增强其专业素质。
5.结束语
初步的教学尝试表明，在项目驱动的软件工程教学模式下，教师和学生的工作量都有大幅增加。教师必须熟悉开发过程和主流开发平台，必须有实际开发经验以应对学生遇到的各种问题，必须积极引导和评价以增强学生开发软件的自信心和成就感。学生则必须依据自身能力进行自主学习与协作学习，在项目开发过程中充分发挥主观能动性和创造性思维，全面提高其作为软件专门人才的综合素质。
数据库需求分析报告 篇八
关键词：CDIO工程教育模式；数据库课程设计；教学改革
中图分类号：G64 文献标识码：A 文章编号：1009-3044（2015）05-0141-03
Reform and Practice of Course Design of Database based on CDIO
LU Lu， LING Jie
（School of Computer Science and Technology， Guangdong University of Technology， Guangzhou 510006， China）
Abstract： Aiming at the problems of the shortcomings of the traditional pattern of traditional course design of database，Based on the concept of the CDIO engineering education， combining with the present teaching situation of course design of database of computer-related specialty in an university of Guangdong， the specific measures on the teaching system and evaluation for course design of database is expounded. The practice results show the teaching reform expands the students' open minds，stimulates students' initiative and raises the students' practical abilities .
Key words： CDIO engineering education； Course Design of Database； teaching reform
CDIO工程教育模式是近年来国际工程教育改革的最新成果。从2000年起，麻省理工学院和瑞典皇家工学院等四所大学经过四年的探索研究，创立了CDIO工程教育理念。CDIO代表构思（conceive）、设计（design）、实施（im-plement）、运行（operate），它是“做中学”和“基于项目教育和学习”（Project based education and learning）的集中概括和抽象表达。它体现了现代工程师所应具备的服务于现代工业产品从构思、设计、实现到运行的全过程所必须拥有的基本能力。CDIO培养大纲将工程毕业生的能力分为工程基础知识、 个人能力、 人际团队能力和工程系统能力四个层面[1-2]。然而我国工科的教育实践中还存在不少问题，如重理论轻实践、忽视团队协作精神等问题。国内外的经验表明CDIO的理念和方法是先进可行的，适合于工科教育的教学改革。
1 数据库课程设计传统教学模式培养现状
数据库课程是计算机及其相关专业课程体系中的核心和基础；而数据库课程设计是数据库课程的实践科目，其特点是综合性强，对动手操作能力要求比较高。但是，传统数据库课程设计的教学模式，往往偏重理论，这会让学生处于课堂教育与实践操作严重脱节的尴尬境地。因此，针对计算机专业人才培养的现实需求，数据库课程设计教学改革势在必行。
2 数据库课程设计教学改革研究
为了达到让学生主动学习的目的，基于CDIO的模式理念，本文构建了数据库课程设计教学内容体系。该体系自始至终与数据库理论内容以及CDIO模式相结合，通过项目驱动，让学生参与其中，按照数据库设计的每个阶段由学生自发独立的发现问题以及解决问题，最终完成课程设计的各个内容。
2.1 数据库原理教学内容以及传统数据库课程设计教学安排
数据库原理针对计算机相关专业本科教学内容主要涉及关系数据库、关系数据库标准语言SQL，数据库安全性完整性、关系数据理论、数据库设计、查询优化、数据库恢复和并发技术[3]。
以广东某高校计算机学院为例，数据库原理理论教学56课时，授课时间为学期第1周至第16周。数据库课程设计16课时，课程设计准备工作主要集中在第13周到16周，设计完成以及检查时间为第17周。（教学内容与进度如图1所示）
这种传统教学的弊端主要体现在：
1）理论教学与实践操作相互脱节。学生不能发挥主动学习的积极性；
2）课程设计实践操作部分学时少，准备不够充分；
3）课时分布不均匀，前松后紧，学生动手实践部分大多放在学期末，容易造成学生在期末考试的压力中忽略动手能力的提高和培养，眉毛胡子一把抓；
4）单凭一个课程设计报告和程序很难衡量学生对知识的理解和掌握程度；
鉴于以上的内容，本文提出了基于CDIO模式的新的数据库课程设计教学体系。
2.2 数据库课程设计教学模式改革
数据库课程设计教学模式改革主要体现在：课程设计在理论教学中贯穿始终。基于CDIO的数据库课程设计教学改革内容如图2所示。
2.2.1 课前准备
CDIO模式不仅重视个人能力的培养，同时也关注团队协作的能力培养。因此，团队协作也作为数据库课程设计教学改革的一个重要内容。为了学生沟通方便，每个行政班中以寝室为单位（4个学生）组成若干个开发团队，选取组长，并且向老师上报各个组员的分工情况，之后各个开发小组可以根据老师给出的备选题目进行选题。
2.2.2构思（Conceive）
CDIO的精髓在于让学生“做中学”。但是对于没有任何数据库基础知识的学生来说，课程开始就投入到实践中是不现实的，所以范例教学十分重要。在理论教学开始时教师利用大概2周的时间，讲解数据模型、数据库系统结构、数据库系统的组成、数据库技术的研究领域以及前沿的知识体系、开发工具，让学生对该领域的知识产生浓厚的兴趣。然后，教师可以从典型案例着手――以学生管理系统为例，讲解如何进行业务流程分析、功能分析和数据需求分析，如何绘制用例图，在数据库设计过程中如何完成数据流图和数据字典分析，让学生在范例讲解中一步步的学会如何绘制ER图，如何设计数据字典中的各项内容。该阶段是构建系统蓝图的阶段，所以，教师要引导学生立足于不同项目的实际需求，通过调查问卷、查阅资料、客户走访等形式，深入探析软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件各项有效的需求，与此同时，在确定需求过程中，团队成员之间的磨合与沟通也是必不可少的。通过各个成员的协调，才能最终确定该团队共同的软件需求以及数据库整体规划策略。该阶段的汇报成果即是各团队小组的需求分析报告。
2.2.3设计（Design）
数据库设计包括概念结构设计、逻辑机构设计和物理结构设计，所涵盖的理论知识点比较多。传统数据库原理教学和数据库课程设计在设计阶段几乎是相互脱节的，见图1。为了能让学生提高完成项目的主动性以及自我认知性，数据库课程设计调整幅度也相对比较大。
1）课堂学习关系数据库时，引导学生以课程设计中的选题项目为基础，编制相关的关系代数的演算
2）课堂学习关系型数据库标准语言SQL时，引导学生以课程设计为基础，利用SQL语句解决数据的增删改查的一系列问题，并且针对需求分析中不同的设计模块，设计不同的SQL操作，其中包括单表查询、多表查询、模糊查询、相关子查询、不相关子查询、多表更新操作、视图操作等。
3）课堂学习数据库的安全性和完整性时，通过一系列反例，例如违反实体完整性的数据操作会带来怎样的后果；违反了参照完整性的操作会有哪些危害等等，让学生强烈感知如何能设计出效率高、安全性较好的数据库基本表。此时，可以让学生根据项目选题设计出系统的各个分ER图并且形成初步ER图，在合并过程中找出冲突和问题所在，为后续内容做准备。
4）课堂学习规范化理论时，利用循序渐进的方法，举例说明，让学生利用范式的思想，对项目中的表格进行规范化分析，判断属于第几范式，有什么样的优缺点，能否进行优化。此时，课程设计的概念结构设计，逻辑结构设计已经初具雏形。
5）课堂学习第七章数据库设计时，结合实例，让学生独立完成概念机构设计中的消除冲突与优化，完成由基于项目的初步ER图到基本ER图的转变；同时结合需求分析中的数据字典，根据联系转换为关系表的知识点以及规范化理论，对初步的逻辑结构表进行修改和完善。
该阶段的汇报成果是各团队小组的概要设计报告。
2.2.4实现（Implement）
设计阶段其实是将任务离散化，那么实施阶段就是将项目综合化。该阶段中，书本上的重点内容已经基本结束，学生可以根据学过的基础知识自由发挥，将之前的需求文档以及概要设计文档进行拓展和完善，并且将自己设计的关系代数以及SQL语句转换成高级程序语言中的数据库操作的语句。这时候，有能力的同学也可以根据老师上课讲授的查询优化等内容针对具体项目实际进行查询算术优化和物理优化，并且对比执行效率，感受在不同的实际应用中对不同问题的处理方式。
该阶段的汇报成果是各团队小组成员的详细设计报告的综合文档。
2.2.5运作（Operate）
系统模型建立好之后，要进行软件的各项测试。学生可以通过学习恢复和并发控制等内容，对系统的完整性、安全性等性能进行进一步的改善，完善详细设计报告，补充系统测试内容以及使用系统安装使用说明。最后，通过小组的公开答辩，向老师和全班同学展示系统的设计思路、完成过程以及跟同学们交流心得和体会，并由其他非小组成员的同学作为评委进行点评。
2.3 课程设计考核评价改革
课程设计是一门衡量学生动手操作能力、综合运用能力的科目，所以这门课程更要体现对学生是实践能力的检验。数据库课程设计考核评价改革主要体现在：改变单一的评分标准为多角度综合性评价标准（如图3所示）。
2.3.1 项目文档（分数比例50%）
项目文档包括需求分析报告、概要设计报告、详细设计报告。
1）需求分析报告（分数比例10%），内容包括：
①可行性分析；
②拟采用的开发工具；
③用例图；
④数据字典，包括数据项，数据结构
⑤软件模块初步设想以及每个模块可能进行的操作。
2）概要设计报告（分数比例20%）：
①数据库设计方面：分ER图和总体基本ER图（标明各实体之间联系的类型）、逻辑结构设计（有完整性约束说明，标明主码、外码，分析范式类型）、物理结构设计（索引、存储路径等）、数据库完整性设计（违反实体、参照完整性时的解决办法，比如触发器、存储过程等）
②软件设计方面：功能结构图以及各功能模块主要功能（明确小组成员的分工）
3）详细设计报告（分数比例20%），内容包括：
①系统与后台数据库连接的执行过程；
②系统各模块的主要界面和UI接口；
③系统各个模块的流程图以及详细实现过程；
④关键问题的解决方案；
⑤总结系统后续有待优化和改善的方面。
2.3.2 项目成果演示（分数比例40%）
该类别主要考核的方面如下：
1）系统运行正确；
2）功能完善：有增、删、改、查功能，输入、输出功能；
3）有基本的统计、报表功能；
4）有多表连接查询、自身连接查询、字符串匹配查询、模糊查询、分组查询等；
5）工作量饱满，系统实现技术的难度；
6）是否符合软件开发规范；
2.3.3 团队综合素质（分数比例10%）
该类别主要通过系统演示、课题答辩以及团队的出勤和会议纪要等信息考核团队成员的协同合作的能力，而且，尤其要注意有些同学过分依赖他人的思想。所以答辩过程中要求每个小组成员都要对自己所做的内容进行阐述和说明。
3 结束语
通过一系列的基于CDIO模式课程设计教学改革，使得每一个同学都有公平的主动参与的机会，同学们从这门课程开始就主动思考项目中各种实际问题，由“学中做”转变为“做中学”，极大发挥了学生的积极性和创造力，从而使得数据库课程设计的实践教学取得了非常好的教学效果。很多同学都对数据库产生了浓厚的兴趣，而且也有一部分同学毕业之后选择了数据库相关的行业。
参考文献：
[1] E.F.Crawley. Creating the CDIO Syllabus， a universal template for engineering education， fie， vol.3，Pp.F3F8 -13， 32nd Annual Frontiers in Education （FIE’02）， 2002.
[2] 薛红芳。 基于CDIO 的项目驱动式数据库课程教学模式改革研究[J]. 吉林省教育学院学报，2014（7）：10-11.
数据库需求分析报告 篇九
引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。
1.1 编写目的
说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。
如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或子系统。
1.2 项目风险
具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括：
任务提出者；
软件开发者；
产品使用者。
1.3 文档约定
描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括：
正文风格；
提示方式；
重要符号；
也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。
1.4 预期读者和阅读建议
列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括：
用户；
开发人员；
项目经理；
营销人员；
测试人员；
文档编写入员。
并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。
1.5 产品范围
说明该软件产品及其开发目的的简短描述，包括利益和目标。把软件产品开发与企业目标，或者业务策略相联系。
描述产品范围时需注意，可以参考项目视图和范围文档，但是不能将其内容复制到这里。
1.6 参考文献
列举编写软件产品需求分析报告时所用到的参考文献及资料，可能包括：
本项目的合同书；
上级机关有关本项目的批文；
本项目已经批准的计划任务书；
用户界面风格指导；
开发本项目时所要用到的标淮；
系统规格需求说明；
使用实例文档；
属于本项目的其它己发表文件；
本软件产品需求分析报告中所引用的文件、资料；
相关软件产品需求分析报告；
为了方便读者查阅，所有参考资料应该按一定顺序排列。如果可能，每份资料都应该给出：
标题名称；
作者或者合同签约者；
文件编号或者版本号；
发表日期或者签约日期；
出版单位或者资料来源。
2. 综合描述
这一部分概述了正在定义的软件产品的作用范围以及该软件产品所运行的环境、使用该软件产品的用户、对该软件产品己知的限制、有关该软件产品的假设和依赖。
2.1 产品的状况
描述了在软件产品需求分析报告中所定义的软件产品的背景和起源。说明了该软件产品是否属于下列情况：
是否是产品系列中的下一成员；
是否是成熟产品所改进的下一代产品；
是否是现有应用软件的替代品(升级产品);
是否是一个新型的、自主型的产品。
如果该软件产品需求分析报告定义的软件系统是：
大系统的一个组成部分；
与其它系统和其它机构之间存在基本的相互关系。
那么必须说明软件产品需求分析报告定义的这部分软件是怎样与整个大系统相关联的，或者(同时)说明相互关系的存在形式，并且要定义出两者之间的全部接口。
2.2 产品的功能
因为将在需求分析报告的第4部分中详细描述软件产品的功能，所以在此只需要概略地总结。仅从业务层面陈述本软件产品所应具有的主要功能，在描述功能时应该 针对每一项需求准确地描述其各项规格说明。如果存在引起误解的可能，在陈述本软件产品主要功能的作用领域时，也需要对应陈述本软件产品的非作用领域，以利 读者理解本软件产品。
为了很好地组织产品功能，使每个读者都容易理解，可以采用列表的方法给出。也可以采用图形方式，将主要的需求分组以及它们之间的联系使用数据流程图的顶层图或类图进行表示，这种表示方法是很有用的。
参考用户当前管理组织构架，了解各个机构的主要职能，将有助于陈述软件产品的主要功能。
2.3 用户类和特性
确定有可能使用该软件产品的不同用户类，并且描述它们相关的特征。往往有一些软件需求，只与特定的用户类有关。描述时，应该将该软件产品的重要用户类与非重要用户类区分开。
用户不一定是软件产品的直接使用者，通过报表、应用程序接口、系统硬件接口得到软件产品的数据和服务的人、或者机构也有他们的需求。所以，应该将这些外部需求视为通过报表、应用程序接口、系统硬件接口附加给软件产品的附加用户类。
2.4 运行环境
描述了本软件的运行环境，一般包括：
硬件平台；
操作系统和版本；
支撑环境(例如：数据库等)和版本；
其它与该软件有关的软件组件；
与该软件共存的应用程序。
2.5 设计和实现上的限制
确定影响开发人员自由选择的问题，并且说明这些问题为什么成为一种限制。可能的限制包括下列内容：
必须使用的特定技术、工具、编程语言和数据库；
避免使用的特定技术、工具、编程语言和数据库；
要求遵循的开发规范和标准
例如，如果由客户的公司或者第三方公司负责软件维护，就必须定义转包者所使用的设计符号表示和编码标准；
企业策略的限制；
政府法规的限制；
工业标准的限制；
硬件的限制
例如，定时需求或存储器限制；
数据转换格式标淮的限制。
2.6 假设和约束(依赖)
列举出对软件产品需求分析报告中，影响需求陈述的假设因素(与己知因素相对立)。如果这些假设因素不正确、不一致或者被修改，就会使软件产品开发项目受到影响。这些假设的因素可能包括：
计划使用的商业组件，或者其它软件中的某个部件；
假定产品中某个用户界面将符合一个特殊的设计约定；
有关本软件用户的若干假定(例如：假定用户会熟练使用SQL语言。);
有关本软件开发工作的若干假定(例如：用户承诺的优惠、方便、上级部门给予的特殊政策和支持等。);
有关本软件运行环境的一些问题；
此外，确定本软件开发项目对外部约束因素所存在的依赖。有关的约束可能包括：
工期约束；
经费约束；
人员约束；
设备约束；
地理位置约束；
其它有关项目约束；
3. 外部接口需求
通过本节描述可以确定，保证软件产品能和外部组件正确连接的需求。关联图仅能表示高层抽象的外部接口，必须对接口数据和外部组件进行详细描述，并且写入数 据定义中。如果产品的不同部分有不同的外部接口，那么应该把这些外部接口的全部详细需求并入到这一部分实例中。
注意：必须将附加用户类的特征与外部接口需求加以区分，附加用户类的特征描述的是通过接口取得软件产品的数据和服务的人的需求；而外部接口需求描述的是接口本身的需求。
3.1 用户界面
陈述需要使用在用户界面上的软件组件，描述每一个用户界面的逻辑特征。必须注意，这里需要描述的是用户界面的逻辑特征，而不是用户界面。以下是可能包括的一些特征：
将要采用的图形用户界面(GUl)标准或者产品系列的风格；
有关屏幕布局或者解决方案的限制；
将要使用在每一个屏幕(图形用户界面)上的软件组件，可能包括：
选单；
标准按钮；
导航链接；
各种功能组件；
消息栏；
快捷键；
各种显示格式的规定，可能包括：
不同情况下文字的对齐方式；
不同情况下数字的表现格式与对齐方式；
日期的表现方法与格式；
计时方法与时间格式；
等等。
错误信息显示标准；
对于用户界面的细节，例如：一个特定对话框的布局，应该写入具体的用户界面设计说明中，而不能写入软件需求规格说明中。
如果采用现成的、合适的用户界面设计规范(标准)，或者另文描述，可以在这里直接说明，并且将其加入参考文献。
3.2 硬件接口
描述待开发的软件产品与系统硬件接口的特征，若有多个硬件接口，则必须全都描述。接口特征的描述内容可能包括：
支持的硬件类型；
软、硬件之间交流的数据；
控制信息的性质；
使用的通讯协议；
3.3 软件接口
描述该软件产品与其它外部组件的连接，这些外部组件必须明确它们的名称和版本号以资识别，可能的外部组件包括：
操作系统；
数据库；
工具；
函数库；
集成的商业组件
说明：这里所说的“集成的商业组件”，是指与系统集成的商业组件，而不是与软件产品集成的商业组件。例如：中间件、消息服务，等等。
描述并且明确软件产品与软件组件之间交换数据或者消息的目的。描述所需要的服务，以及与内部组件通讯的性质。确定软件产品将与组件之间共享的数据。如果必 须使用一种特殊的方法来实现数据共享机制，例如：在多用户系统中的一个全局数据区，那么就必须把它定义为一种实现上的限制。
3.4 通讯接口
描述与软件产品所使用的通讯功能相关的需求，包括：
电子邮件；
WEB浏览器；
网络通讯标准或者协议；
数据交互用电子表格；
必须定义相关的：
消息格式；
通讯安全或加密问题；
数据传输速率；
同步和异步通讯机制；
4. 系统功能需求
需要进行详细的需求记录，详细列出与该系统功能相关的详细功能需求，并且，唯一地标识每一项需求。这是必须提交给用户的软件功能，使得用户可以使用所提供 的功能执行服务或者使用所指定的使用实例执行任务。描述软件产品如何响应己知的出错条件、非法输入、非法动作。
如果每一项功能需求都能用一项，也只需要用一项测试用例就能进行验证，那么就可以认为功能需求已经适当地进行描述了。如果某项功能需求找不到合适的测试用例，或者必须使用多项测试用例才能验证，那么该项功能需求的描述必然存在某些问题。
功能需求是根据系统功能，即软件产品所提供的主要服务来组织的。可以通过使用实例、运行模式、用户类、对象类或者功能等级来组织这部分内容，也可以便用这些元素的组合。总而言之，必须选择一种是读者容易理解预期产品的组织方案。
用简短的语句说明功能的名称，例如：“4.1系统参数管理”。按照服务组织的顺序，逐条阐述系统功能。无论说明的是何种功能，都应该针对该系统功能重复叙述4.1~ 4.3这三个部分。
可以通过各种方式来组织这一部分内容，例如采用：使用实例、运行模式、用户类、对象类、功能等级等，也可以采用它们的组合。其最终目的是，让读者容易理解 即将开发的软件产品。一般来说，每个使用实例都对应一个系统功能，因而按照使用实例来组织内容比较容易让用户理解。
对应一些被共享的独立使用实例，可以定义一些公用系统功能。
必须特别注意的是，在2.2节“产品的功能”中描述的全部需求，以及它们的规格说明；必须在某个系统功能描述中有所反映，而且不应重复。
4.1 说明和优先级
对该系统功能进行简短的说明，并且指出该系统功能的优先级是：高、中、还是低。需要的话，还可以包括对特定优先级部分的评价，例如：利益、损失、费用和风险，其相对优先等级可以从1(低)到9(高)。
4.2 激励/响应序列
列出输入激励(用户动作、来自外部设备的信号或者其它触发)并且定义针对这——功能行为的系统响应序列，这些序列将与使用实例中相关的对话元素相对应。
描述激励/响应序列时，不仅需要描述基本过程，而且应该描述可选(扩充)过程，包括例外(引起任务不能顺序完成的情况称为例外)。疏忽了可选过程，有可能影响软件产品的功能；如果遗漏例外过程，则有可能会引发系统崩溃。
如果采用流程图来描述激励/响应序列，比较容易让用户理解。
4.3 输入/输出数据
列出输入数据(用户输入、来自外部接口的输入或者其它输入)并且定义针对这些输入数据的处理(计算)方法，以及相应地输出数据，描述对应区别：输入数据和输出数据。
当有大量数据需要描述时，也可以分类描述数据，并且注明各项数据的输入、输出属性。
对于每一项数据，均需要描述：
数据名称；
实际含义；
数据类型；
数据格式；
数据约束；
对于复杂的处理方法，仅仅给出算法原理是不够的，必须描述详细的计算过程，并且列出每一步具体使用的实际算式；如果计算过程中涉及查表、判断、迭代等处理方法，应该给出处理依据和相关数据。如果计算方法很简单，也可以将其从略，不加描述。
5. 其它非功能需求
在这里列举出所有非功能需求，主要包括可靠性、安全性、可维护性、可扩展性、可测试性等。
5.1 性能需求
阐述不同应用领域对软件产品性能的需求，并且说明提出需求的原理或者依据，以帮助开发人员做出合理的设计选择。尽可能详细地描述性能需求，如果需要，可以针对每个功能需求或者特征分别陈述其性能需求。在这里确定：
相互合作的用户数量；
系统支持的并发操作数量；
响应时间；
与实时系统的时间关系：
容量需求
存储器；
磁盘空间；
数据库中表的最大行数。
5.2 安全措施需求
详尽陈述与软件产品使用过程中可能发生的损失、破坏、危害相关的需求。定义必须采取的安全保护或动作，以及必须预防的潜在危险动作。明确软件产品必须遵从的安全标准、策略、或规则。
5.3 安全性需求
详尽陈述与系统安全性、完整性问题相关的需求，或者与个人隐私问题相关的需求。这些问题将会影响到软件产品的使用，和软件产品所创建或者使用的数据的保 护。定义用户身份认证，或备授权需求。明确软件产品必须满足的安全性或者保密性策略。也可以通过称为完整性的质量属性来阐述这些需求。一个典型的软件系统 安全需求范例如下：“每个用户在第一次登录后，必须更改他的系统预置登录密码，系统预置的登录密码不能重用。”
5.4 软件质量属性
详尽陈述对客户和开发人员至关重要的在软件产品其它方面表现出来的质量功能。这些功能必须是确定的、定量的、在需要时是可以验证的。至少也应该指明不同属性的相对侧重点，例如：易用性优于易学性，或者可移植性优于有效性。
5.5 业务规则
列举出有关软件产品的所有操作规则，例如：那些人在特定环境下可以进行何种操作。这些本身不是功能需求，但是他们可以暗示某些功能需求执行这些规则。一个 业务规则的范例如下：“进行达到或者超过10，000，00元人民币的储蓄业务时，必须通过附加的管理员认证。”
列举业务规则时，可以根据规则的数量，选取合适的编目方式。
5.6 用户文档
列举出将与软件产品一同交付的用户文档，并且明确所有己知用户文档的交付格式或标准，例如：
安装指南
纸质文档，16开本；
用户手册
纸质文档，16开本；
在线帮助
电子文档，与软件产品一同分发、配置；
使用教程电子文档，与软件产品一同分发、配置。
6. 词汇表
列出本文件中用到的专业术语的定义，以及有关缩写的定义(如有可能，列出相关的外文原词)。为了便于非软件专业或者非计算机专业人士阅读软件产品需求分析 报告，要求使用非软件专业或者非计算机专业的术语描述软件需求。所以这里所指的专业术语，是指业务层面上的专业术语，而不是软件专业或者计算机专业的术 语。但是，对于无法回避的软件专业或者计算机专业术语，也应该列入词汇表并且加以准确定义。
7. 数据定义
数据定义是一个定义了应用程序中使用的所有数据元素和结构的共享文档，其中对每个数据元素和结构都准确描述：含义、类型、数据大小、格式、计量单位、精度 以及取值范围。数据定义的维护独立于软件需求规格说明，并且在软件产品开发和维护的任何阶段，均向风险承担者开放。
如果为软件开发项目创建一个独立的数据定义，而不是为每一项特性描述有关的数据项，有利于避免冗余和不一致性。但是却不利于多人协同编写需求分析报告，容 易遗漏数据，也不方便阅读。因此还是建议为每个特性描述有关的数据项，汇总数据项创建数据定义，再根据数据定义复核全部数据，使得它们的名称和含义完全一 致。必须注意的是，为了避免二义性，在汇总数据项时应该根据数据项所代表的实际意义汇总，而不是根据数据项的名称汇总。
在数据定义中，每个数据项除了有一个中文名称外，还应该为它取一个简短的英文名称，该英文名称应该符合命名规范，因为在软件开发时将沿用该英文名称。可以使用等号表示数据项，名称写在左边，定义写在右边。常见数据项的描述方式如下：
原数据元素
一个原数据元素是不可分解的，可以将一个数量值赋给它。定义原数据元素必须确定其
含义、类型、数据大小、格式、计量单位、精度以及取值范围。采用以星号为界的一行
注释文本，描述原数据元素的定义。
选择项
选择项是一种只可以取有限离散值的特殊原数据元素，描述时一一枚举这些值，并用方
括号括起来写在原数据元素的定义前。在两项离散值之间，使用管道符分隔。
组合项
组合项是一个数据结构或者记录，其中包含了多个数据项。这些数据项可以是原数据元
素，也可以是组合数据项，各数据项之间用加号连接。其中每个数据项都必须是数据定
义中定义过的，结构中也可以包括其它结构，但是绝对不允许递归。如果数据结构中有
可选项，使用圆括号把该项括起来。
重复项
重复项是组合项的一种特例，其中有一项将有多个实例出现在数据结构中，使用花括号
把该项括起来。如果知道该项可能允许的范围，就按“最小值：最大值”的形式写在花
括号前。
8. 分析模型
这是一个可选部分，包括或涉及到相关的分析模型，例如：
数据流程图；
类图；
状态转换图；
实体-关系图。
9. 待定问题列表
以上就是差异网为大家带来的9篇《数据库需求分析报告》，希望对您有一些参考价值。