管理系统需求精选(十四篇)

序言：作为思想的载体和知识的探索者，写作是一种独特的艺术，我们为您准备了不同风格的14篇管理系统需求，期待它们能激发您的灵感。

篇1

关键词：车辆管理系统；需求分析

中图分类号： C93 文献标识码： A

0 引言

车辆管理系统需求分析是车辆管理软件系统开发中最重要的一个阶段，是系统开发之前的必要技术环节，需求分析为最终用户和软件开发者双方对系统的定位、认识、运行环境、功能和性能需求等方面进行明确，需求分析作为设计实现的基线，为系统的应用功能设计、开发提供依据。本文对智能化住宅小区车辆管理系统的需求进行分析。

1 系统业务需求

住宅小区车辆管理系统主要业务是对固定住户车辆、临时来访车辆进行管理，管理员对系统数据进行管理和维护几个方面。具体需求为：

1.1住宅小区内固定住户车辆的车主

住宅小区内固定住户车辆的车主在出入出入口时，经车辆检测器检测到车辆后，将感应磁卡在出入口感应区掠过，通过阅读器进行读卡、判断卡的有效性，从而识别该车辆是否在车辆数据库中有记录（即判断该车辆是否为物业管理部门登记的住户车辆），同时摄像机摄录该车的图像。对于有效的感应磁卡，自动道闸的闸杆应升起放行并将相应的数据存入数据库中。若为无效的感应磁卡或进出场的车辆图像出现异常情况时，则不给予放行[1]。

1.2临时来访的社会车辆的车主

对临时来访的社会车辆的车主，在车辆检测器检测到车辆后，按入口控制机上的按键取出一张临时感应磁卡，并完成读卡、摄像和放行。在出场时，在出口控制机上读卡并交纳停车费用，同时进行车辆的图像对比，无异常情况时道闸升起放行，否则不予放行。

1.3系统管理员的日常使用

系统管理员负责对系统数据库进行查询、管理和对系统的日常维护。首先，管理员负责发放标签卡，在此过程中要对相应的标签卡的内容进行修改，用来识别不同的车辆，同时在数据库中创建相应车辆信息，把指定车辆和指定的标签卡联系起来，用于车辆识别。其次，管理员可以查询该数据库，用以实现特殊情况下人工实现车辆的识别和事件的处理，管理员可以修改数据库，以实现数据的更新、修正以及备份和恢复。除此之外，管理员可以强制控制停车器、报警器等硬件装置，以实现故障情况下车辆的进出口管理。最后，由于系统的管理员几乎可以对系统做任何操作，因此整个系统要实现对管理员身份的认证，以确保数据和系统硬件不会被其他人恶意操作。

2 系统目标需求

本系统的设计目标是针对小区的车辆管理的实际业务情况，设计出一套通用化、自动化、智能化的车辆监管系统。其目标需求如下：

1.为小区提供一个统一的车辆管理平台，实现车辆的自动化管理。

2.使用安全、可靠的信息管理方式，辅助物业人员完成小区内车辆监管工作。

3.使用高度智能化的软硬件设备，完成车辆出入检查，减少人工操作提高工作效率。

4.能自动区分合法车辆与非法车辆，并能拦截非法车辆、发出警报。

5.能实时检测车辆出入情况。

6.能查看、统计任意时段车辆信息。

3 系统功能需求

住宅小区出入口车辆管理系统应用在小区出入口，其基本功能是对出入车辆的监督、记录、缴费及分类管理，实现对出入小区车辆信息的查询，实现对车辆情况、小区车位使用情况的汇总统计。因此系统功能应有以下需求：

3.1脱机运行功能

系统控制器增加CPU处理器，系统硬件具有运算功能，在脱机状况下，不仅IC卡能作到临时卡脱机收费，远/近距离磁卡也可以做到脱机识别。

3.2栏杆自动控制功能

出入小区时，业主车辆的磁卡和访问车辆的临时标签卡这类有效标签卡刷卡时，栏杆自动抬起，车辆驶出/入后（即来往车辆通过地感线圈），栏杆自动落下。

3.3车辆自动检测功能

实现车辆自动检测、统计、计数，便于稽查管理。

3.4车辆分类管理

物业管理部门通过对卡片的分类管理，从而实现对不同类的车辆的管理，包括固定车、临时车等，相关部门根据不同需求，分别发行业主车卡和临时租卡。业主车卡实行预交费用；临时卡随到随取，简捷方便。停车场管理简捷，能有效防止高峰期缴费造成堵车。

3.5车辆出入控制管理

1.访问车全自动出卡，一车一卡防反复出卡；

2.有效卡刷卡自动抬闸，车过后自动落下；

3.出入场操作语音提示，无效卡报警提示；

4.防砸车功能，能独立控制闸机，可以用遥控器控制闸机和手动开关栏杆。

5.收费数据自动管理功能

所有收费交易自动入帐、管理，受有收费过程系统数据自动完成登记、存储。所有收费数据自动通过网络传输至收费网络服务器。

4 系统性能需求

小区车辆管理统应该具有良好的性能。因此，系统在性能方面应该有以下几种基本需求：

4.1数据精准度

要按照严格的数据格式输入，否则系统不给予响应进行处理。查询时要保证查全率，所有相应域包含查询关键字的记录都应能查到。因为通常有文件的记录会很多，系统采用两种方法进行查询：直接查询和模糊查询。

4.2稳定性

通过良好的系统架构设计，通过软硬件设备的运用，通过安全加密技术的保障，保证系统运行的稳定性。

4.3响应和访问速度

可稳定支持10个以上的用户数量；在局域网环境条件下，客户端访问系统平均响应时间≤3秒；数据综合查询事务≤5秒。

4.4不间断运行

系统客服务器端须提供24小时不间断正常运行，以保障系统业务全天候提供应用。

5 系统安全性需求

RFID系统很容易受到各种各样的攻击，主要是由于其通信是通过电磁波的形式，而且RFID标签设备具有一定的尺寸和成本限制。因此，其安全性与隐私性是人们一直所研究和讨论的主要问题。RFID系统安全机制目前主要采用两种方法，即物理机制方案和加密机制方案。

物理机制主要有Kill命令机制，静电屏蔽，阻塞法，主动干扰等，这些方法主要用在一些低成本的标签中，因为这类标签有严格的成本限制，因此很难采用密码机制。

Kill命令机制在设计上是从物理上杀死标签，而标签一旦被使用了Kill命令，便不能再重新使用了，这是一个不可逆的操作。

静电屏蔽则可以对标签进行屏蔽，它需要把标签放置于有静电屏蔽功能的物理设备范围内，标签不能再接受来自阅读器的信号，这样需要一个额外的物理设备，增加了系统成本。

阻塞法则依靠树遍历反冲突协议来起作用，阅读器每次发送读取命令总获得相同的应答数据，从而来保护标签，此方法需要额外一个阻塞标签，增加了系统成本。

物理安全机制存在着增加系统成本，阻止失败等多种弊端，因而，人们越来越多的在密码技术的安全机制上提出不同的方法。

数据加密传输时采用密码加密的方法，对数据信息加密后再进行通信，由阅读器或上位机单方面进行操作，从而节省标签的成本。小区出入口车辆管理系统需要采用MD5加密算法，计算机或阅读器将数据（明文）加密转换为密文后，发送给标签进行存储，当阅读器要读取标签中数据时，标签将存储区中密文发送给阅读器，阅读器将收到的密文解密，并与后台数据库比对[2]。

以上是住宅小区车辆管理系统设计的基本需求，也系统开发的设计的基本要求，是系统开发的目标方向。

6 小结

本文主要从系统的设计目标、设计原则、安全性、业务要求、实现功能、和性能几个方面对小区车辆管理系统的需求进行了分析，为我们进行车辆管理系统的设计开发明确了方向。

参考文献

篇2

当前许多承担基础设施建设等大型项目的投融资平台由于业务性质特殊，缺少通用软件支持，长时间处于手工填写报表的工作状态，本文针对投融资平台公司的建设投资业务，进行了计算机信息化管理系统的需求分析，为后续的设计开发奠定基础。

【关键词】

投融资平台；投资管理系统；需求分析

1前言

浦发集团是一家国有独资有限责任公司，负责上海浦东新区城市基础设施项目的投融资建设等业务。其本身并不参与具体的工程建设业务，通过为项目提供资金支持来跟踪，管理大量建设项目的运行。本文在用户调研的基础上，遵循需求分析的流程［1］，通过应用结构化和快速原型等分析方法［2］，得到《浦发集团基础设施项目投资管理系统》的需求文档。

2功能需求

浦发集团的基础项目投资方式主要有两种，一种是BT模式，也就是建成后移交模式。一种是BOT模式，也就是建设，运营一段时间后再移交的模式。项目主要是政府部门提出的公共建设项目，如轨道交通，道路，公交，公共绿地等。政府职能部门，如建交委，环保局等是项目的最终接收方，但他们本身并不参与项目建设，而是委托给浦发集团这样的投融资平台公司进行操作。而浦发集团本身也不进行实际项目的建设，他们通过招标将实际的建设工作交给专业的代建公司来完成，本身只完成对项目资金流的管控工作。所以业务涉及跨企业合作，一个是具体建设的代建公司，他们主要根据项目的建设进展情况提出资金使用需求。一个是浦发集团公司，他们主要负责项目资金的募集，审核，拨付。系统以立项的建设项目为核心，由代建公司根据项目进展提出资金申请，集团公司多个部门进行审核，通过后付款给代建公司。系统有两类用户，代建公司和集团公司，有三大主要功能，建设项目管理，资金管理以及回购管理。其中，建设项目管理主要是把各种项目信息管理起来，使得业务中各相关方都能方便地检索到需要的项目信息，从而为处理申请和审核业务提供依据。项目信息包括三大类，项目基本信息，相关合同信息以及与该项目有关的合同外费用支出信息，也就是项目相关的非合同信息。项目信息的创建者是代建公司的工作人员，该信息将由集团公司市政部的相关工作人员来做复核，复核通过后即可作为后续资金申请的依据。这里的项目信息除了项目名称，关联公司等最简单的基本信息外，就是与项目相关的费用预算，支付条件等和资金相关的信息，体现了本系统的围绕着资金流进行项目管控的特色。而资金管理资金管理是核心业务，主要包括资金计划，资金申请和审核，以及审核通过后的资金拨付三方面功能。资金计划是代建公司根据正在进行中的项目情况，制定出各个项目的月度及年度资金使用计划。资金计划的目的是预估未来的资金需求量，集团公司的投资金融部会汇总各个代建公司的资金计划，以此为依据，开展融资活动，以确保项目资金及时到位，保证项目的正常开展。集团公司会定期召开资金计划会议，审议各个代建公司提交上来的资金计划，生成汇总的审核通过后的集团公司资金计划。代建公司根据项目需要向集团公司提交用款申请，集团市政部先审核用款申请是否合乎标准，通过后，转交给投金部和计财部，这些部门通过后，再由市政部复审，确保无误后，提交给集团领导最终审批。资金申请的依据是项目的合同或非合同信息，受合同支付条件约束，同时也不能超出已经确定的资金计划。资金申请获批后，代建公司就可以提起付款申请了。相关的资金就会按照合同支付条款分期分批的打入代建公司的银行账户。最后，回购是指政府职能部门在项目完成后将建成的基础设施整体购买的行为。回购需要集团公司和政府签订回购合同，一般情况下，政府并不是一次性付清款项，而是在一个回购合同中协商好的回购期内，分期分批的付款。由于不是一次性付款，就会产生资金成本，集团公司会在回购合同中约定相应的利息。系统需要根据回购合同生成申请信息，供回购款申请时使用。回购管理主要就是管理回购项目的回购合同信息以及回购申请的审批。

3非功能需求

考虑到业务本身的特点，在非功能需求方面将安全性和稳定性作为首要目标。要求系统具有硬件和软件两方面的容错功能。另外，考虑到使用该系统的人员分散在不同的多家公司，所以要求系统易于部署，兼容性好，支持多种操作系统，并且具备一致的用户界面。同时要求系统易于维护，可以方便地配置不同用户的相应权限。

4结论

遵循着软件工程思想，对浦发集团的投资管理业务进行了需求分析，阐述了业务范围及内容，明确了不同的用户角色和业务流程。

作者：彭小勇 单位：上海大学计算机工程与科学学院

参考文献:

篇3

关键词：频谱管理；统一建模语言；用例

中图分类号：TP311文献标识码：A文章编号：1009-3044(2009)04-0959-02

Requirements Analysis of Battlefield Electromagnetic Spectrum Management System Based on UML

LIANG Guo-qing1,2, CHEN Jian2

(1.Brigade 69296 of PLA, Kashi 844200, China; 2.C4ISR Technology Key Lab of NUDT, Changsha 410073, China)

Abstract: There are many stations that using frequency in the battlefield, but the useable electronmagnetic spectrum is finity, tradition electromagnetic spectrum management is handwork, however, is not fit the modern war, cry for the computer assistant management. The article introduces characteristics of UML, and describes battlefield electromagnetic spectrum management system's requirements by UML.

Key words: electromagnetic spectrum management; UML; use case

1 引言

高技术条件下的作战，参战力量多元，各种各样的电子信息作战装备同时应用于战场，加之敌方激烈的电磁干扰以及民用电磁设施的影响，使得战场电磁环境极其复杂，可用频谱资源十分有限。在这种情况下，只有加强战场电磁频谱管理才能充分、合理地利用电磁频谱，达成最佳作战目的[1]。但频谱管理是一个非常复杂的过程，它包括许多需要注意的步骤和问题，只有把它们全部考虑在内，才有可能有效利用无线电频谱。由于战场用频台站数量之大，利用传统的手工方式管理台站，凭借传统的经验审批频率以及被动式查找干扰等管理行为已不能适应现代化战争，因而必需有效的计算机支持。为此，需要开发研究战场频谱管理系统。通过战场频谱管理软件，指战员可以迅速了解战场电磁态势，分配电磁频谱资源，避免（或减小）用频台站间互扰问题，构造出有利于己而不利于敌的战场电磁环境。本文采用先进的统一建模语言（unified modeling language, UML）对战场频谱资源管理系统进行需求分析，可为战场频谱资源管理系统的开发提供较为完整的需求信息。

2 UML简介

UML是一种标准的图形化建模语言，是面向对象技术发展的重要成果。它融合了Booch、OMT和OOSE方法中的基本概念，并在这些方法的基础上，广征意见，集众家之长，扩展了现有方法的应用范围。UML适用于以面向对象的技术来描述任何类型的系统，而且适用于系统开发的不同阶段，可以应用于任何领域。

UML作为一种标准的图形化建模语言有如下特点：UML的词汇表和规则注重对系统进行概念上和物理上的描述；UML符号的表示法定义了规范的可视化元素，并为开发者使用这些可视化元素进行系统建模提供了标准；UML可以对重要的分析、设计和实现进行详细描述，所建模型具有精确性、无歧义性和完整性；用UML描述的模型可与各种编程语言直接相连[2]。

作为一种建模语言，UML中有3类主要元素，即基本构造块（basic building block）、规则（rule）和公共机制（common mechanism）。图是UML中最重要的元素之一，共分9种图：用例图、顺序图、协同图、类图、对象图、状态图、活动图、构件图和部署图。

用例图（Use case diagram）是UML在系统需求分析阶段来捕获用户需求的有效手段和方法。它用于显示若干角色（Actor）之间的连接关系，并不描述系统内部对该功能的具体操作方式，即通过用例建模，描述系统应向外提供何种功能，形成系统的问题域。活动图、类图、顺序图主要用于分析阶段，状态图、类图、对象图、协作图主要用于设计阶段，构件图和部署图主要用于实现阶段[3]。

3 战场频谱管理系统需求建模分析

3.1 战场频谱管理系统功能剖析

战场频谱管理系统功能包括[4,5]：

1）项目管理 为了便于管理频谱数据及存贮计算结果，在设计之前将频谱管理纳入项目管理范围，内容包括建立新项目、打开已有项目。

2）频谱监测 实现对检测站的控制和监测数据的分析处理等，包括检查监测站的配置、选择监测站设备及监测天线；对信号进行测试，查看一定频段内频率占有情况；对信号参数进行测量，计算信号的频偏、带宽和载频；查找干扰源位置。

3）电磁兼容性分析 对可能受到的或产生的干扰进行预测，从频率、时间、空间和能量四维角度考察各电子设备间的电磁隔离度，分析所产生干扰的大小及影响范围，评价干扰的危害程度。

4）频率规划与指派 为各种无线电业务划分无线电频谱的过程，为有效使用频谱，划分的频段必须符合预期业务要求的传播条件。

5）电子系统数据库 为各类电子系统建立数据库，记录其特性参数。这些数据是进行敌我识别，生成对抗措施的基本资料。

6）电磁态势显示。对战场上各种电磁信号的类型、属性和分布情况进行分析，并用图形、分析报告等方法将战场电磁态势表现出来。

7）网络服务 主要完成两种功能：一是网络通信，即实现数据的收发、传输；二是实现简单的网络管理。

3.2 战场频谱管理系统用例模型

根据上述的系统需求分析，对系统进行需求分析。在UML中用例图可从系统的外部看到系统的内部功能，它采用一些图形符号和文字来记录使用者的要求。用例图的基本元素有角色、用例、关系。

角色是指与系统交互的人或物。角色有3类：系统的使用者、外部系统、时间。战场频谱管理系统的角色有直接使用该系统的人和外部数据库，其中外部数据库有地理信息系统（GIS，Geographic Information System）和无线电台（站）设备数据库。

用例是系统提供的一种功能，是系统、子系统或外部参与者交互的动作序列的说明。战场频谱管理系统的顶层用例有：项目管理、频谱监测、电磁兼容性分析、频率规划与指派、数据管理、电磁态势显示、网络服务等7个用例。系统顶层用例图如图1所示，顶层图反应了系统总的需求情况。

3.3 顺序图

顺序图用来反映若干个对象之间的动态协作关系，主要反映对象之间发送消息的先后次序，说明对象之间的交互过程。顺序图由若干个对象组成，每个对象用一条垂直的虚线表示（线上方是对象名）。每个对象的正下方有一个矩形条，它与垂直的虚线相叠，矩形条表示该对象随时间流逝的过程（从上至下），对象之间传递的消息用消息箭头表示，它们位于表示对象的垂直线条之间。

1）基本数据输入顺序图。使用者通过数据管理的基本数据输入窗口输入基本数据，一部分基本数据由使用者根据战场情况和要求，从数据窗口输入，另一部分与地理有关的数据可通过查询地理信息系统来获得，与设备有关的信息可从无线电（台）站数据库中获得。基本数据输入结束后，保存在频谱项目数据库中，供后面的设计模块调用。基本数据输入顺序图如图2所示。

2）电磁兼容性分析顺序图。基本电磁数据输入结束后，就可以进行各功能计算了，这里以电磁兼容性分析为例。在电磁兼容性分析窗口中，通过变换参数的计算各种干扰，得出台站干扰的大小及影响范围，实时显示在该参数状态下电磁态势图上，最后结果保存在频谱项目工程数据库中，供后面的设计模块调用。电磁兼容性分析顺序图如图3所示。

3.4 活动图

活动图描述系统中各种活动的执行顺序，活动图常用于描述一个操作执行时的流程，也可以用于描述一个用例的处理流程，或者某种交互流程。活动图由一系列活动组成，当某个活动执行完毕之后，控制将沿着转移箭头转向下一个活动。在UML中没有流程图，可以用活动图来描述系统的总体或局部流程。图4为战场频谱管理系统总体活动图，可分为项目管理、工程数据建立与管理、数据管理、电磁兼容性分析、网络管理、频率规划与指派和电磁态势显示等7个部分。

4 结束语

本文采用UML对战场频谱管理系统进行了需求分析，开发建设战场频谱管理系统有利于战场电磁资源的管理，提高电磁资源的处理速度，降低电磁资源管理的成本。

使用UML对系统需求进行描述可以帮助用户和分析人员对问题描述和理解达成共识，较少语义差异，保障分析的正确性，克服传统需求分析在问题领域、系统功能描述方面精确度低的问题。在实际应用中，UML可以根据不同的系统，从不同的角度，以不同的详略程度对系统需求进行构造。

参考文献：

[1] 谷岩峰,高常见,安渭琳.战场电磁频谱实时管理问题研究[J].国防科技,2007(5):71-73.

[2] 孙朝霞,李春光,马莉.基于UML的车辆管理系统需求分析[J].青岛建筑工程学院学报,2005,26(2):71-73.

[3] 郑益民,倪宏革,郝令涛.基于UML的公路涵洞CAD系统的需求分析[J].烟台师范学院学报:自然科学版,2005,21(4):306-309.

篇4

【关键词】中小供电企业；信息管理系统

一、信息管理系统的概念和功能

信息管理系统，是由人、计算机及其他设备等组成的能进行信息的收集、传递、存贮、加工、维护和使用的系统。其所承担的主要任务是充分利用现代计算机及网络通讯技术加强企业的信息管理，通过对企业所拥有的人力、物力、财力、设备、技术等资源的调查了解，建立正确的数据，加工处理最终编制成各种信息资料，并给管理层提供最新最准确的信息，便于进行正确的决策，以促进提高企业的管理水平和经济效益。

从上世纪50年代中期计算机用于管理领域以来，信息管理系统经历了从简单到复杂，从单机到网络，从功能单一到功能集成，从传统到现代的一系列演化。根据其发展的时序和特点，可将信息管理系统的发展历程大致划分为电子数据处理系统（EDPS）、管理信息系统（MIS）、决策支持系统（DSS）三个阶段。主要涉及经济学、管理学、运筹学、统计学、计算机科学等诸多学科，是多种学科混合紧密联系的一门新兴技术。就其功能来看，信息管理系统是组织理论、会计学、统计学、数学模型及经济学的产物，综合使用计算机技术、网络通信技术、数据库技术等，是多学科交叉的边缘技术。从社会技术系统的观点来看，信息管理系统和组织结构之间是相互影响的，引进信息管理系统将导致新组织结构的产生，而现存的组织结构又对信息管理系统的分析、设计、引进的成功与否产生了重要影响。

二、中小供电企业信息化现状

上世纪末，电力企业已初步尝试探索实施信息化，如今已有近20年的时间，企业信息化覆盖面已涉及到电力生产、管理、经营和社会服务等多个环节。作为关系到国家经济和人民生活的国家基础性行业的电力企业，近年来信息化的应用在提升电力行业管理水平、服务质量等方面取得了一些成绩。但是从电力企业信息化的目前现状来看，仍存在着一定的问题，如信息管理机构不健全、信息孤岛较多、有些地方存有信息盲点、技术平台不完善、缺乏统一的信息化标准、存在信息安全漏洞等。从2008年起，电力行业信息化跨入了大发展时期，信息系统数量、资产、应用水平等都出现了显著的增长并形成了一定的规模，企业面对种类繁多的平台和各式各样的应用，信息管理部门必须结合生产、管理、经营和社会服务的实际需求，结合自身的技术优势和企业特点，做出最合适的选择，从而促进电力企业信息化健康有序稳步的发展。

现代信息技术的普及给劳动生产率的提高带来了新的机遇，促进了世界各国产业结构的升级，刺激世界经济新的增长。信息化的应用加快了普通劳动力与科技人才在不同行业、不同国家、不同性质企业之间的流动。信息化的迅速普及，现代信息技术的迅猛发展和全球信息化的汹涌浪潮，正从根本上改变人们的生产方式、生活方式乃至文化观念，促使人类走向新的文明。面对信息化，中小供电企业相对于其他行业有着以下显着的特点：

（一）管理集成度高

电力行业由于其生产、消费的特点，发电、送电、变电和配电等必须同步，电力产品不可能像其他机械业、手工业等具有时效性。这种工作流程时时的特殊性质要求高强度的管理信息集成。而中小供电企业主要涉及变电和配电环节，其管理行为必须全面覆盖从变电、配电、送电到用电的整个过程。信息管理系统（MIS）必须将企业的各个部分、生产的全过程密切组合成为一个相互联系的有机体，集成从原料采购、设备维护、工程施工、用户服务以及资金结算等企业运转的全部过程。

（二）生产环节复杂

电力工业虽然只生产单一产品，但其生产过程却极为复杂，用户对电力产品的需求是24小时不间断的，设备维护、故障抢修的各个环节都需要等众多功能部门的配合，管理流程和数据流程极为繁杂。这就要求电力企业的MIS具有高度敏捷性，时时更新联动，能够建立支持企业各部门和各企业的密切联系，确保各个环节运行流畅。

（三）安全、稳定性要求高

电力产品在人们日常生活中占据着不可比拟的特殊地位，也正是因为这样，电力企业的生产、传输、供应和服务的及时性、可靠性具有极强的经济意义。因此，电力企业的管理在某一程度上需要较高的可靠性与保密性。这就要求电力企业MIS的构建必须以稳定、安全、便捷为前提，同时具备功能扩展能力，以适应不断进步的信息化发展和计算机技术提升的要求。

（四）行业信息化发展相对滞后

上世纪90年代末，我国电力行业才渐渐地走出垄断面对市场化竞争，每一次变革都会使企业内部、外部的结构发生巨大的变化，导致电力企业的MIS的建设无法及时更新达到完善；不同企业、不同部门的管理流程和数据处理流程都又各自不同的操作模式和习惯，既没有统一的操作要求，也没有规范合理的规章制度。这对电力企业规模化MIS建设带来了信息控制、开发通用、数据及时准确的信息软件的困难。

三、中小供电企业信息管理系统需求分析

国家电网的“十二五”规划提出：到2020年全面建成统一“坚强智能电网”。智能电网的提出，对电网企业、发电企业的未来战略规划和信息化战略规划，都作出了更新的指导思想，也指明了电力企业信息化发展的未来方向。发电企业的信息化应用朝着深化应用和优化应用的方向进一步迈进，集团化、统一化的发展思路在大型集团型发电企业中全面确立，行业内的两化融合程度势必得到进一步提高。就目前中小供电企业的信息化需求实质来看，管理系统主要内容包括：办公自动化系统（OA），电力调度自动化系统（SCADA），以及电力营销管理系统等等。

（一）办公自动化系统（OA）

根据中小供电企业点多线长、人员相分散的实际情况，OA系统首先要建立内部通信平台，即内部的邮件系统，以方便企业内部的通信和信息交流，并基于安全性、便捷性考虑，应实现有条件限制的与Internet邮件互通。其次是信息的平台，即时电力企业信息，提供交流平台，例如新鲜新闻、信息简报、内容通告等能够在员工之间得到及时、广泛的传播。再次是工作流程自动化平台，例如公文的收发、审批、处理，以及请示、汇报等流程化工作的自动化处理，以解决多岗位、多部门之间的协同工作问题，旨在规范各项工作，提协同工作效率。最后是信息查询平台，通过设定不同用户等级，检索查看不同权限的文档、图片等信息，实现不同层次的文档共享、查阅和使用。与此同时，OA系统还应充分考虑信息集成，具备数据接口功能，能把企业原有的MIS、ERP、财务信息系统等业务系统数据，集成到工作流系统中，使员工能有效获取并处理信息，提升供电企业整体反应速度和决策能力。

（二）电力调度自动化系统（SCADA）

电力调度自动化系统是保障供电设备安全和经济可靠运行的重要技术手段之一，是采用计算机信息及网络通讯技术等，在线为各级电力调度机构和生产运行指挥人员提供系统运行信息、分析决策技术依据和控制手段的数据处理系统。其主要功能包括：数据采集、信息处理、统计计算、远程操作、报警处理、实时数据监控及分析等。重要环节应采取双机热备，当任一台服务器出现故障时，所有运行在该服务器上的数据可以自动完整地切换到另一台服务器上，确保系统的可靠性和稳定性。系统需要有健全的权限管理功能，能快速、平稳地自动或人工切除系统本身的故障，故障切除时不能影响系统内其他设备正常运行。调度主控站是整个系统的核心，从全局实现调度自动化的监视和控制，分析电网运行状态，协调各变电所内RTU之间关系，确保整个电力系统处于最佳运行状态。

（三）电力营销管理系统

市场竞争形势日益发展，建立完善的创新信息化营销体系是满足不断深化的市场化变革和日益发展的客户服务需求的必由之路。按业务逻辑关系分，电力营销管理系统一般包括：客户服务、营销业务、营销质量管理、营销管理决策支持四个层次。客户服务层与客户进行交互并为客户提供直接的服务，主要通过规范服务标准，提供优质服务，共享服务资源，提供多种项目服务，如：故障抢修，信息咨询，用电业务查询，投诉、举报、建议，电费催缴等。营销业务层是客户服务层的支持层，对系统内的基础信息进行采集、加工和处理，主要进行各类供电服务事务地处理，保证业务处理过程中的数据安全、有序地在各业务部门之间流通。同时负责向客户服务层实时提供客户的用电信息，如：业务受理，电费抄、核，电费计算，帐务管理、线损管理、计量管理、用电检查等。营销质量管理层通过工作流程平台，监控各部门工作状况，提供监督手段，实时考核绩效，如：营销业务的稽查、各项营销指标的统计等。营销管理决策支持层是为营销决策提供依据的综合信息分析和处理中心，主要向管理人员和领导者提供营业管理功能，主要从市场分析、客户分析、市场预测、需求侧管理四个方面分析电力营销工作的经营状况和政策实施效果，进而预测供电市场需求。

目前供电企业在信息化应用方面存有不足，已经影响了企业管理水平的提升与竞争力的提高，企业需要大力推进管理信息化的进程，实现信息一体化。信息管理系统作为一项系统工程，同样需要专门的机构来推进和企业各个部门的配合。建立健全信息化推进组织体系，推动供电企业信息管理系统的发展是实现企业经济可持续发展的必由之路。

参考文献

[1]黄梯云．管理信息系统[M]．北京：高等教育出版社，2002

[2]刘满成．论企业管理信息系统建设的问题和对策[J]．经营管理．2006（4）

[3]2009～2010年中国电力行业信息化发展研究年度报告

篇5

关键词：社区医疗；登记管理；管理系统；数据库

DOI：10.16640/ki.37-1222/t.2017.08.205

通过对社区医疗管理系统相关工作人员的需求分析，我们明确了社区医疗管理系统在设计方向，软件需求，以及系统性能上的方向和目标，从而结合社区医疗系统相关工作人员需求分析以及更好设计系统来进行编码[1]。我们要从实际出发，尽量多和社区医疗管理系统工作人员交流，原因是最初的调研工作在日后的交流过程中会不断挖掘出新的需求，通过对用户的交流了解用户实时的需求，并不断完善该社区医疗管理系统，从而了解社区医疗管理系统工作人员最真实的需求，并在社区医疗管理系统中得到实现。与此同时，更要记录每个阶段用户不同的需求分析，这个过程是系统开发人员设计和实现社区医疗管理系统的有价值的考量[2]。我们也需要对系统做出准确的预算，并且将从用户需求抽象出系统所需要设计和开发的功能。

1 社区医疗管理系统开发有如下信息

（1）系统设计要求简洁实用，开发出对于用户十分实用的功能，与用户需求分析紧密联系，通过开发人员撰写实用，简单的社区医疗管理系统手册，辅助用户能够了解并使用该社区医疗管理系统使用技巧。

（2）社区医疗管理系统为相关使用人员提供相应的居民健康数据，利用所提供的销售数据来确保社区医疗管理人员能够及时统计当前居民健康状况。

（3）社区医疗管理系统需要严格控制开发成本，并且以保证社区医疗管理系统管理人员能够通过该系统获得更多利益。

（4）社区医疗管理系统需要拥有一套完整的管理方案，并且还需要成熟稳定的制度保证用以获取稳定的健康档案数据，为智能化管理社区医疗系统提供好的支撑和数据支撑。社区医疗随着其业务和规模的不断发展，因此对系统的要求也会逐渐提升，因此要不断根据社区医疗相关工作人员需求扩展系统功能。

（5）社区医疗管理系统由于其面对的是完整社区的应用，因此该系统设计出的是一个整体规模不大的操作系统，相对于传统医院这样的大型诊疗机构，社区医疗并没有承担过重的经济负担。同时，通过对社区医疗智能化的管理，可以大幅度减少社区医疗日常开销，所以对社区医疗是由很深远的影响。

2 社区医疗管理系统具有以下功能

（1）登录管理。 工作人员分为：系统管理员、社区医务人员和社区居民，系统会根据用户角色不同为用户分配不同的权限 。在这三类操作人员中，系统管理人员拥有的权限最大，并且独享用户名密码，并且也拥有授权用户的能力，系统管理人员是权限最高的用户，他能够同时管理多个系统的数据。社区医务人员，是权限仅次于系统管理人员的管理者，其负责对社区居民健康档案管理，健康档案的查询等工作，而当系统出现问题时，其无法完成修复管理工作。社区居民是系统人员中权限最小的，他只负预约诊疗时间等日常工作。

（2）健康档案管理。社区医疗管理系统实际上就是为社区居民建立医疗档案，并根据医疗档案上面的内容对社区居民作出相应的病案处理，所以对社区居民健康档案的管理是本系统的核心也是重中之重。社区居民健康档案的管理包括对其进行添加修改删除，社区居民提供他们对应的姓名、年龄、疾病史等基本参数后，社区相关工作人员则要建立相应的医疗档案。

（3）添加医学信息功能 。社区医疗管理系统有别于传统的医院医疗系统，他们面向的对象只是该社区的居民，因此如何向社区居民普及慢性病常识也是本系统设计的重点。社区医疗人员需要定期向系统中添加医学信息，社区居民通过对医疗信息的普及来完成惠民政策。

（4）预约管理。 预约管理有别于医疗结构传统的挂号模式，社区居民和社区医护人员实际上是一个相互连通的过程，社区居民制定了相应的诊疗时间，相应的医护人员也要根据诊疗时间来排开自己的诊疗时间，这实际上正是社区医疗的特点所在。

（5）查询管理。无纸化的社区医疗管理系统区别于传统的有纸化社区医疗系统的标志就是通过输入关键词来对居民的健康档案进行查询，传统的有纸化社区医疗管系统在查询健康档案时效率十分低下，所以在当今这个无纸化办公的时代，如何设计出合理且高效的健康档案查询方式是本系统的重点。

（6）权限设置管理。在社区医疗管理系统中的权限设置功能也是十分必要的，如果在系统中没有权限设置相应的功能模块，那么社区医护人员和居民将会出现功能没有区分度等缺点，因此在设计过程中，将全线设置功能加入到了整个系统中。

通过需求分析我们得出了社区医疗管理系统因该具备以上六点功能，其中商品登录功能是系统最基础的功能，相当于所有功能的地基。健康档案管理模块则是整个软件支撑的重中之重，这部分相应功能对系统整体的运行起到了决定性作用。添加医学信息管理是小型社区医疗登记管理系统的新增点，能够更好地对社区居民进行慢性病常识的普及。预约管理是系统中显示与传统医疗系统的关键所在，也是最能够体现社区医疗管理系统特点的功能模块。查询管理是区别传统的有纸化办公和无纸化办公的功能模块，这部分模块设计好将会大大提升整个医疗系统的效率。权限设置功能是社区医疗管理系统中区别不同用户身份的模块，这部分也是必不可少的[3]。

3 总结

对相应的社区医疗工作人员做了需求分析，并了解到他们对于系统的实际需要，通过对系统的实际需要初步设定了系统所要设计的一个基本方向，为系统设计打下了一个坚实的地基。

参考文献：

[1]汪东芳，杨晋霞.社区医疗管理系统的设计与实现[J].江苏科技信息，2016：62-63.

篇6

[关键词]医疗设备维修；管理系统；方案设计；需求分析

医疗设备的维修管理是其生命周期管理中最为重要的环节，其不仅是保证设备完好的关键，也与临床应用是否安全有效密切相关，是医院医疗质量与安全的重要组成部分[1-2]。近年来，随着医疗设备种类和数量的大幅度增加，医疗设备维护及管理工作繁重，对医院的医疗设备维修管理水平也提出了更高要求[3]。加强医疗设备维修管理，不仅可以提高医疗设备完好率，使其更好的为临床服务，还可促进医院设备管理向精细化和信息化方向发展，从而使医院能够利用最优的医疗设备资源创造更大的经济效益和社会效益[4]。

1医疗设备维修管理系统总体方案设计背景

近年来，随着医院的不断发展，医疗设备种类和数量在不断增加，传统的维修管理模式已经不能适应现代化医院的发展，只有通过多元化的科学管理才能获得更大的效益[5]。通过对如东县人民医院医疗设备维修管理工作的深入了解，发现需要亟待解决的相关问题。(1)医疗设备维修时间长[6]。一方面由于医疗设备技术专业性强，技术含量高，导致维修人员检修时间过长；另一方面是由于无专门的配件管理，工程师在遇到需要更换配件时，一般采用现购置方法，且产生费用的维修报批时间长，从而延长了维修时间。(2)维修管理项目种类繁多，内容琐碎。医疗设备相关记录需要使用大量的纸张，且以手工记录为主，记录的文档不便于查询和保存，给设备维修管理和总结分析带来了不便。(3)医疗设备的日常保养维护缺乏计划性，预防性维修工作盲目[7]。(4)各医院普遍存在“重医轻工的思想”，维修工具简陋，导致工程师只能做一些简单维修，遇到有难度的维修只能求助厂商工程师[8]。而长期依赖厂商工程师又会导致医院处于被动地位，出现维修响应不及时，维修费用高等问题。(5)使用科室无法实时监督设备维修状况，各科室之间得不到良好沟通，影响临床科室正常使用[9]。医院需要一个医疗设备维修管理系统，用于管理相关记录信息，合理分配现有工程师，制定日常维修保养周期，使设备维修管理工作规范化和科学化[10]。

2医疗设备维修管理系统总体需求分析

医疗设备维修管理系统主要涉及临床使用科室、医疗设备维修组以及医疗设备管理办公室3个使用部门，只有将3个部门工作相辅相成，才能不断提高医疗设备完好率，确保临床诊疗工作有序进行。

2.1临床使用科室系统需求分析

临床科室护理人员的主要职责是管好本科室的所有医疗设备，如设备的使用和保养、设备故障报修及设备报废申请等，故其主要系统需求分析有故障报修与维修状态查询、设备日常保养与保养状况查询以及设备报废申请与报废状态查询。

2.2医疗设备维修组系统需求分析

医疗设备维修组的主要职责是接收临床科室的故障报修信息、及时派工维修、反馈设备的故障现象、合理使用维修配件、参与报废设备的检验及处置工作、制定周期保养计划以及进行预防性维护保养等。其主要系统需求分析如图1所示。

2.3医疗设备管理办公室系统需求分析

医疗设备管理办公室主要运用系统完成查询与统计工作，查询操作贯穿于系统的各项业务中，主要包括注册用户信息、医疗设备信息和设备配件信息查询，其可以帮助各科室及时掌握设备维修情况。统计操作不仅能实现维修工作量、设备故障率、维修服务费和设备配件费的统计，也是科室管理的重要依据。

3医疗设备维修管理系统设计

3.1逻辑功能设计

在上述需求分析的基础上，将医疗设备维修管理系统归纳为基础业务和核心业务两大模块。①基础业务模块，分为系统管理和基础数据管理2个功能模块，系统管理主要面向于系统管理员，完成系统维护及数据初始化等工作，基础数据管理是临床使用科室与设备科工作的实体，可完成各项数据的建模工作；②核心业务模块，涵盖设备维修管理中的所有业务，即故障报修、派工维修、预防性保养、配件管理和设备报废5个功能模块。

3.2整体方案设计

使用医疗设备维系管理系统不仅可适应医院的信息化管理，而且能够完善医学装备科的日常业务，使医疗设备的维修、费用支出和报废处置等工作更加透明。本研究在系统逻辑功能设计的基础上进行整体方案设计，其整体设计如图2所示。

3.3数据库设计

经过对医疗设备维修管理系统的逻辑功能及总体方案设计的详细分析，建立满足医疗设备维修管理系统的数据库模型，模型可直观了解系统中的关系类与实体类。该系统的数据库实体-联系模型如图3所示。

4医疗设备维修管理系统优势

4.1实现医疗设备维修管理信息化

系统主要用于实现医疗设备的故障报修、派工维修、预防性保养、配件管理、设备报废、信息查询和工作量统计的自动化管理。采用信息化管理不仅可优化故障报修流程，缩短维修响应时间，记录设备不同时期的故障原因及检修方法，还能科学安排医疗设备的保养计划，延长设备使用寿命，实现医疗设备报废透明化。此外，维修工程师能够应用该系统对医疗设备出现的故障进行统计分析，从而做到早预防和早检修[11]。

4.2提升医疗设备维修档案管理质量

随着医疗设备的不断增多，随机带来的资料也日益增多，因此传统的档案管理均难达到要求，故医疗设备维修档案无纸化管理势在必行[12]。使用医疗设备维修管理系统可将医疗设备购置、维修保养、质量安全检查、培训考核、设备巡检、更新和报废申请等方面的资料进行无纸化管理，减少资源浪费。设备使用科室和管理科室也能及时查看该资料，掌握设备的使用技术状况，通过分析其使用率、完好率、维修率和报废率等资料，为医院更新和购置新设备提供有效的依据。

4.3提高医疗设备经济效益

医疗设备的效益分析贯穿其整个生命周期，使用维修管理系统不仅可以从设备完好率、使用率及报废折旧费等多个方面对其进行经济效益分析，还能反映医疗设备管理人员、使用人员及维修人员的工作效率，便于医院进行资金质量控制[13]。

5结论

篇7

本文在对I框架和UML建模机制深入研究的基础上，提出了一种全新的面向Agent的需求建模方法，并通过对图书馆管理系统应用实例的分析来验证该方法在面向Agent系统建模中的可行性。

【关键词】

需求工程；Agent；I框架；UML；AUML；图书馆管理系统

当前人们习惯地将软件的需求工程划分为早期和后期两个阶段，在早期阶段主要是通过非形式化的的方式来实现整个系统的非功能性需求描述，详细的功能性描述往往是在后期阶段进行的。然而目前大多数需求建模技术都过度强调后期需求分析，忽略了早期需求分析，造成了整个软件开发工作的失败。基于此，本文在对I框架和UML建模机制深入研究的基础上，提出了一种面向Agent的建模框架，即在早期和后期两个阶段，分别采用I框架模型和UML建模技术来对系统进行建模。同时，为了保证前后两个阶段的一致性，分别建立了相应的映射规则，实现了两阶段之间的平滑过渡。

1．Agent定义

Agent理论自诞生以来，被广泛地应用于诸多不同领域，在软件需求建模范畴，Agent经常被看成是对象的扩展。然目前学术界对Agent尚未有一个统一的定义，一般认为Agent系统应具备自主性、反应性、主动性、社会性四个基本属性[1][2]。为了在I模型和扩展UML模型之间建立相应的映射规则，首先，本文认为Agent具有目标、能力、信念、资源、服务和行为规则六个方面的基本属性。

2.基于I框架和扩展UML需求建模方法

2.1I框架的基本概念I框架[4]是由多伦多大学EricYU教授等人提出来的，是一种根据策略依赖关系及其原理来理解和重新设计业务处理过程的面向目标的需求建模方法。其基本概念包括三种，分别是行为者、意图元素和意图关系。通过对这三类概念的描述，建立系统策略依赖模型（StrategicDependencyModel,简称SD模型）和系统策略原理模型（StrategicRationaleModel，简称SR模型），将系统中的风险承担者的意图转化成目标系统的功能需求和非功能需求。I框架基本元素的图形化表示方式如图1所示。

2.2基于I框架和扩展UML需求建模方法

2．2．1需求建模框架和需求建模过程需求建模是要明确系统的“what”和“why”方面的问题。本文将建模框架分成两层考虑（如图2所示），在早期需求获取层，我们通过I框架对系统的组织背景、动机和基本原理进行宏观上的描述。在后期需求说明层，我们通过UML来描述系统的功能需求和非功能需求。在此，通过将I框架和UML建模语言的有效结合，形成了更适合于面向Agent系统的建模框架。统一建模语言UML是一种非常成熟的后期需求建模工具，因此我们完全可以使用UML及其扩展机制来实现面向Agent的软件建模，需求建模过程如图3所示。

2．2．2建立系统用例模型和类模型本文分别建立了三条规则来实现从SR模型到用例模型的映射规则（如表1所示）和十条规则实现从I框架模型到类模型的映射。

3．实例分析

下面我们通过对图书馆管理系统应用实例的分析来验证本文提出的基于I框架和扩展UML方法在面向Agent系统建模中的可行性。

3.1建立早期需求模型图书馆自动化管理系统最终目标是要实现图书采访、编目、流通、OPAC查询、管理等等业务环节的自动化。图书馆主要的业务部门包括采编部（负责图书的采访和编目）、流通部（负责面向读者的图书借阅和归还工作）、技术部（负责系统数据库的管理和系统的维护等工作）。系统需要实现的功能可以概括成以下五个方面：（1）OPAC查询功能（读者可以通过网络对借阅信息和馆藏信息进行查询）；（2）读者能够借阅和归还图书；（3）流通部处理读者的借阅和归还图书的功能和权限；（4）系统管理员能够实现书目信息的添加、修改和删除（即采购与编目）；（5）系统管理员对读者信息进行添加、修改、删除等管理功能。

针对以上描述，我们在早期需求建模阶段可以识别出四个主要行为者：读者、流通部、图书馆管理系统、系统管理员。他们之间的策略依赖模型如图4所示：如图4所示，读者角色要想通过网络查询书籍信息和自己的借阅信息，首先要登录系统，因此读者和图书馆管理系统存在三个任务依赖关系（登录系统、查询书目信息、查询借阅信息）。读者需要通过流通部图书管理员的处理来实现借阅和归还图书的目标，因此，读者与流通部之间存在任务依赖（借书、还书），同时，要想成功借阅图书，依赖的是图书馆的图书资源同时要保证所要借阅的图书处于可借阅状态，因此读者与流通部之间存在软目标依赖（图书可借）和资源依赖（图书资源）。而流通部与图书馆管理系统之间存在着任务依赖（登录系统、更新库存）和目标依赖（图书流通）。书目信息的添加、修改和删除与读者信息添加、修改、删除等业务功能统一概括为数据库管理和维护，由系统管理员来完成。因此系统管理员与图书馆管理系统之间存在着软目标依赖（可靠性、安全性）和目标依赖（数据库管理）。我们通过I框架的策略依赖模型对图书馆管理系统各角色（图书馆管理系统、读者、流通部和系统管理员）之间的依赖关系进行了描述，却并没有涉及到角色内部的意图关系。要想对系统依赖原理作出更加详细的描述需要借助策略原理模型来完成。I建模框架的策略原理模型由I节点和I链组成。在识别出系统的行为者和它们的目标后，我们就可以通过I链来分析这些目标是怎样被满足的。在对读者、流通部、图书馆管理系统和系统管理员四个系统角色分别进行分析推理的基础上，建立图书馆管理系统的策略原理模型。

如图5所示，图书馆管理系统角色被细分为流通、书目、数据库管理和读者信息四个子角色。其中流通与书目之间存在着查询书目和更新库存两个任务依赖；流通与读者信息之间存在着更新借阅信息和查询借阅信息两个任务依赖；数据库管理与书目之间存在着添加书目、删除书目和修改书目三个任务依赖；数据库管理与读者信息之间存在着添加读者信息、删除读者信息和修改读者信息三个任务依赖。而对于流通部角色，其主要任务就是流通处理，流通处理任务又被分解为借书处理、还书处理和维护库存三个子任务，通过任务分解关系来连接，其中借书处理是针对读者的借书请求的响应操作，而对于还书处理任务，在作出响应之前，必须满足软目标（缴清超期罚款），通过方式-目的关系来连接。

篇8

关键词：工资管理系统；数据库；用户环境；性能需求

中图分类号：TP311

文献标识码：A

文章编号：1009-2374（2012）23-0134-03

随着人事制度改革的深入和劳资关系的改善，薪酬问题日益成为企业所关注的问题。加之社会经济制度的改革，使得企业工资管理工作也变得越来越复杂。建立一套适合于企业自身特点发展的薪酬管理系统日益提上了企业人力资源的工作日程。一套行之有效地工资管理系统有利于减少企业的薪酬错误，避免矛盾，同时减轻人事部门的任务，提高效率，节约人力资源，降低企业成本。

1　企业工资管理系统功能需求简介

系统数据流程图如下：

就企业而言，工资管理系统的设计需要简洁、实用，同时能满足人事、财务部门及其他相关部门或单位的多方对工资管理需求的系统即可。大型的数据库系统反而容易出现操作不便、浪费人力、不易解释的问题出现。就一般的大、中型企业而言，它的设计内容应包括员工信息管理功能、工资管理功能、工资查询功能、工资报表输出功能、相应的模块也增加，例如报表设计模块、打印输出模块、模糊查询模块等。

系统的设计应首先对企业的员工工资管理业务进行分析。经过笔者多方面调研，一般企业员工工资系统主要涉及的参与者包括员工、系统管理员、上级主管部门、总经理。

2　企业的工资管理系统功能描述

2.1　员工信息管理

员工基本信息模块具有员工信息输入、员工增删和员工信息查询三个功能。员工基本信息包括员工号、员工姓名、员工性别、所在部门、所在岗位、工龄和工资等级等信息。员工增删实现了对数据库中员工信息的增加和删除。员工信息查询可以通过员工号或员工姓名对员工信息进行查询。

2.2　工资管理

结合各个公司的工资管理实际情况和人力资源保障部门的劳资规定将工资、结构分为基础工资、岗位工资和工龄工资、绩效工资等标准完成对基础数据条目的设定，增加相应的模块例如工资统计和发放、打印工资条及员工奖励和惩罚等内容。

2.3　工资查询

可根据条件查询员工历史工资数据（如按月份查询、按姓名查询、按部门查询等）。

2.4　汇总打印

提供报表打印输出功能，可以报表的形式打印员工信息、工资发放报表、工资历史报表、员工奖励和员工惩罚报表。

2.5　系统维护

可对数据进行备份和恢复，并可实现数据导入导出功能。

2.6　管理员设置

实现系统用户及密码的设置操作，可以增加和删除系统用户（仅系统管理员才有权限），对系统当前用户修改密码。

3　用户环境选择

选择操作系统最好为Windows XP，因为越来越多的企业在规划内网时，将微软平台作为首选方案；从技术角度而言，微软平台上的应用和开发也是其他平台无法比拟的。绘制UML所需要的Rational ROSE或office VISIO。

4　数据库介绍

功能的实现应尽可能由数据库管理系统完成，这样才能充分发挥数据库管理系统高效、安全、可靠、便捷的性能，减少编程人员的工作量。工资管理系统具有大多数数据库应用系统的特征，在进行设计时，应尽可能使用SQL Server的功能完成下列功能设计的各项操作。

4.1　数据表设计

设计者应根据功能要求中所提到的要求设计数据表，力求数据结构科学合理。设计时要充分考虑如何保证并实施数据完整性，合理建立表与表之间的关系，设计各种数据库对象。

4.1.1　员工信息。员工基本信息应包含员工编号、姓名、性别、出生年月、参加工作时间、地址、电话号码、所属部门、职务、职称、政治面貌、婚姻状况等字段，并预留空白字段若干。

4.1.2　员工工资。员工工资应包含员工编号、基本工资、岗位工资、住房补贴、津贴、住房公积金、养老保险、应发金额、应扣金额及实发金额。应发金额、应扣金额及实发金额使用计算列，并预留空白字段若干。

4.1.3　部门信息。部门信息应包含部门编号、部门名称、部门负责人、部门人数等字段。

例如：

字段 字段名 类型 宽度 说明

1 员 工 号 字符型 3 数字

2 员工姓名 字符型 10 小于等于15个汉字

3 员工性别 字符型 2 “男”或“女”

4 岗位名称 字符型 14 小于等于25个汉字

……

4.2　数据完整性设计

为了保证数据库系统的正确性、完备性和一致性，就必须进行数据完整性设计。可考虑如下数据完整性：给表设置主键及外键约束；设定缺省约束；设置非空约束；实施CHECK约束。

4.3　数据库对象的设计

为充分发挥数据库的效能，保证数据库的安全性，提高数据库管理系统的执行效率，可以考虑使用视图、存储过程及表的触发器来实现某些功能。

4.3.1　指定部门信息查询。设计一个存储过程，以部门编号为参数查询该部门的所有员工的相

关信息，同时统计出此部门的工资总额和平均工资。

4.3.2　设计一个视图，返回所有员工的工资信息。

4.3.3　为提高检索性能，为表创建相关的索引。

4.3.4　为调入、调出人员创建INSERT、DELETE触发器，实现部门人数的自动更新，员工调离本单位时，应当从员工信息表中删除这个员工的信息，并将其工资信息的数据删除。

5　系统性能需求分析

5.1　运行需求

系统在进行数据的录入、计算、统计的时候，能将数据精确到小数点后三位小数。系统接收到用户的操作命令后（如计算处理、查询等），能迅速地响应其操作请求，响应时间不超过1秒。在同一时间，系统还提供支持至少10个客户端进行同一个操作请求的响应。

系统可移植较强，在不同的平台下运行，均不会影响系统的稳定性。同时，支持在客户端安装不同

操作系统、浏览器版本，均不会影响系统的运行。

5.2　安全需求

为保障系统数据的安全性，系统采用访问控制策略，未授权者不能进入系统。同时，对不同级别的用户授予不同的使用权限。在系统运行期间，如发生掉电尚未保存数据或由于操作不当等原因导致系统重启等，为保证数据的易恢复性，系统提供每隔30秒自动保存数据的机制，让用户的数据在发生意外时能最大程度上得到恢复。同时，系统提供强大的容错性能，当一台服务器发生故障时，系统能自动切换到另外一台服务器上，从而保障服务器能长时间地提供系统的运行支持。

5.3　系统界面需求

系统开发基于B/S的开发模式，界面直观、简洁，人机交互性强。基于表单和弹出式窗口的数据录入方式，菜单电击的方式操作。用户使用时，只要是按照格式和要求填入信息，系统在后台响应用户操作过程。让用户在最短时间里，不需要经过专门培训，就可以轻松上手使用。

5.4　其他需求

数据不管是在企业内部之间传输，还是公司与分公司之间进行远程数据传输时，防止数据被不法分子任意地修改和破坏，对所有的敏感数据均进行基于SSL协议的加密操作，只有对信息解密的人员才能最终读取数据信息。这样，能最大程度地提高数据在传输过程的安全保密性。

6　结语

篇9

 

0引言

 

在系统工程及软件工程中，需求分析指在创建一个新的或改变一个现存的系统或产品时，确定新系统的目的、范围、定义和功能时所要做的所有工作。需求分析是软件工程中的一个关键过程[1]，是整个系统开发的基础。需求分析的结果将直接影响到整个软件工程的成功与失败[2]，需求分析阶段的任务是确定软件系统功能。

 

在UML中，需求模型又称为用例模型，主要用于描述系统的功能性需求，即软件可以实现的功能。将UML的用例模型应用到医学院校临床毕业实习管理系统的需求分析中可以更有效地获取系统功能需求，并清晰描绘出系统功能。

 

1医学院校临床毕业实习管理系统需求分析

 

医学院校临床毕业实习根据专业性质不同一般为36～52周，通常安排在第五学年进行。临床医学毕业实习工作主要包括：实习计划制订、实习医院落实、实习生分配、各实习医院学生名单公布，实习日期确定;学生分赴实习医院、确定实习科室轮转日程、确定实习指导教师、分配实习分管床位、按计划进入各实习科室、出科考试。参与这些工作的用户有管理员、教师、学生、系统管理员，不同的用户对系统有不同的功能需求。

 

学生用户的功能需求为：查询和修改个人信息，填报实习医院，查询实习医院，查看、下载、上传作业，查看各种公共信息，查询学生成绩等;教师用户的功能需求为：查询及维护个人信息，添加、修改、删除实习科目，查看、添加、删除、修改公告，查看、添加、修改、删除作业，查询学生记录、录入学生成绩;管理员用户的功能需求为：查询、添加、删除、修改、审核或导入医院信息、专业信息、实习科目信息和教师信息，、查看、修改公告审核和调整学生实习医院等;系统管理员用户的功能需求为：管理整个临床毕业实习管理系统，负责不同用户组的权限定义，进行整个系统的信息初始化及数据维护备份，注册系统用户，负责系统安全管理，硬件环境及网络的管理与维护。

 

根据上述各种用户的功能需求描述，可以将临床毕业实习管理业务功能归纳为：用户管理、公用信息管理、作业管理、实习成绩管理、公告管理、实习医院管理，如图1所示。

 

2基于UML用例建模的系统用户功能需求描述

 

用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早由Iva Jackboson博士[3]提出，后来被综合到UML规范之中，成为一种标准化的需求表述体系。UML 是目前最常用的一种面向对象建模语言， 主要包括7种常见类型，即用例图、类图、序列图、状态图、活动图、组件图和部署图，分别用于不同的建模用途。 用例图主要用于对系统、子系统或类的行为进行建模。它只说明系统实现什么功能，而不必说明如何实现。用例图包括系统的执行者和若干个执行用例[4]，以图形化的方式表示系统内部用例、系统外部参考者以及它们之间的交互[5]，从系统外部用户的观点看系统所具功能的高级视图[6]。

 

医学院校临床毕业实习管理系统中的主要执行者有系统管理员、普通管理员、带教教师及实习学生等，常见的执行用例为数据备份与恢复、用户管理、公用信息管理、公告管理、作业管理、实习成绩管理、实习医院申报和审核管理，由此可以得到系统顶层用例如图2所示。

 

2.1用户管理用例建模

 

在医学院校临床实习毕业系统中，为了保证系统数据的安全，建立用户管理。用户管理实现系统中所有用户使用系统资源的权限管理。用户管理的执行者是系统管理员，执行用例为添加用户、修改和查询用户、删除用户、权限定义。具体用例如图3所示。

 

2.2公用信息管理用例建模

 

公用信息是维护整个系统正常运行所需的基础数据集，公用信息管理的执行者是各院系管理员，执行用例包括专业信息管理、班级信息管理、学生信息管理、管理员信息管理、部门信息管理、公告类型信息管理、实习科目信息管理、成绩系数管理，具体用例如图4所示。

 

2.3作业管理用例建模

 

为巩固学生实习所学知识，检测学生实习效果，并使所学知识转化为技能技巧，在实习过程中，带教教师常常布置相应的作业，教师通过批改学生作业，检查实习效果，因此在医学院校临床毕业实习管理系统中设置作业管理用例图。作业管理的执行者是带教教师和实习生，执行用例包括添加作业、管理作业、批改作业、做作业。具体用例如图5所示。

 

2.4成绩管理用例建模

 

医学院校临床毕业考试成绩通常由毕业实习成绩、毕业实践技能考核成绩、毕业理论考核成绩按一定比例构成。专业不同，实习科目不同，毕业实习成绩计算方法也不同。例如临床医学专业实习科目为内科、外科、妇产科、儿科，每个科目的出科考试成绩通常由医德医风考核、病历书写考核、临床实践技能考核、理论考试按一定比例构成，内科、外科、妇产科、儿科的出科考试的平均分构成毕业实习成绩。录入成绩后，学生可查询成绩，各院系(或者医院)的管理员将学生每门实习科目的出科考试成绩按一定系数比例汇总成毕业实习成绩，各院系管理员将毕业实习成绩、毕业实践技能考核成绩、毕业理论考核成绩按一定比例汇总成毕业考试成绩上交给教务处。成绩管理的执行者有教师、院系管理员和实习生，执行用例包括录入成绩系数、录入成绩、查询成绩、汇总成绩。具体用例如图6所示。2.5公告管理用例建模

 

公告管理的执行者为系统管理员、管理员和实习生，管理员又可分为教师、教务处管理员、院系管理员、医院管理员，执行用例包括添加公告、上传公告、查看公告、修改公告、删除公告。公告管理用例如图7所示。

 

公告管理系统内的任何用户都可以查看系统内所有已的公告。系统管理员、各院系临床实习教学管理员、医院临床实习管理员、教师都可以添加公告，在公告没有前可以修改自己添加的公告，各用户可以删除自己已的和未的公告。

 

2.6实习医院申报和审核管理用例建模

 

实习生在实习前首先要进行实习医院的申报，各院系管理员根据实习生的申报情况进行实习医院的调整，调整完后，学生可以查询具体实习医院信息。各医院管理员根据实习生分配情况，对每一实习科目指派带教教师。实习医院申报和审核管理的执行者为实习生和院系管理员，执行用例包括填报实习医院、查询实习医院(扩展用例包括查询实习科目、查看带教教师)、调整实习医院、管理带教教师。具体用例如图8所示。

 

3系统模块设计

 

综合上述需求分析和用例模型分析，采用结构化设计的方法设计出临床毕业实习管理系统功能模块，包括用户管理、公用信息管理、作业管理、实习成绩管理、公告管理、实习医院管理共6个子系统，这些子系统又包含了若干子模块，如图9所示。

 

4结语

 

UML提供了一套标准、规范、直观、易懂的，描述客户需求的Use Case元素。正确规范地使用这些元素能够高效地建立起一个可视化的客户业务模型，通过该业务模型可以使软件系统的需求分析人员和客户之间建立起一个高效、便捷、良好的沟通渠道，这对建立一个详尽、准确的客户需求分析文档极为重要。本文根据各类需求通过UML用例建模法详细概述了医学院校临床毕业实习管理系统各类用户的功能需求，然后按照用例建模的一般步骤，进行了活动者、用例的定义，设计了医学院校临床毕业实习管理系统用例模型，完成了系统的初步设计工作。

篇10

1. 引言 ................................................................. 1

1.1编写目的 ........................................................ 1 1.2项目背景 ........................................................ 1 1.3定义 ............................................................ 2 1.4参考资料 ........................................................ 2 2．任务概述 ............................................................ 2

2.1目标 ............................................................ 2 2.2运行环境 ........................................................ 3 2.3条件与限制 ...................................................... 3 3．数据描述 ............................................................ 3

3.1静态数据 ........................................................ 3 3.2动态数据 ........................................................ 4 3.3数据库介绍 ...................................................... 5 3.4数据词典 ........................................................ 6 3.5数据采集 ........................................................ 7 4．功能需求 ............................................................ 8

4.1功能划分 ........................................................ 8 4.2功能描述 ....................................................... 21 5．性能需求 ........................................................... 22

5.1数据精确度 ..................................................... 22 5.2时间特性 ....................................................... 22 5.3适应性 ......................................................... 22 6．运行需求 ........................................................... 23

6.1用户界面 ....................................................... 23 6.2硬件接口 ....................................................... 28 6.3软件接口 ....................................................... 28 6.4故障处理 ....................................................... 28 7．其它需求 ........................................................... 29 8. 附录 .............................................................. 29

1. 引言

1.1编写目的

随着计算机技术的发展，人类生活速度的加快，单一的人工售票方式已经不能满足人们出行的要求。每逢出行高峰都会造成火车站售票的拥挤，因此售票自动化应运而生。车站售票管理系统就是这样的一个产物。经过我开发小组的调研与讨论研究，基本上明确了该系统的需求，并在此基础上完成软件需求规格说明书。该文档旨在对该系统的需求做出综合的分析，对各个模块的功能做出具体的说明。

《车站售票管理系统需求规格说明书》的目的是明确《车站售票管理系统》中各项功能和非功能需求，确定系统功能模块，同时为概要设计和详细设计人员提供设计依据，也可供本项目的其他开发人员参阅。本需求分析报告的目的是规范化本软件的编写，旨在于提高软件开发过程中的能见度，便于对软件开发过程中的控制与管理，同时提出了本火车售票系统的软件开发过程，便于程序员与客户之间的交流、协作，并作为工作成果的原始依据，同时也表明了本软件的共性，以期能够获得更大范围的应用。。

本文档需要交于论证人员进行论证修改，无误后供软件开发人员进行后期的软件设计

1.2项目背景

委托单位：呼和浩特火车站 开发单位：内蒙古工业大学软件工程 主管部门：内蒙古工业大学计算机系 项目开发者： 周伟，马星，张玲燕，苗欣宇 用户：呼和浩特火车站 产品的所有权：呼和浩特火车站

项目背景：火车票出售管理系统是典型的信息管理系统(MIS),其开发主要包括后

台数据库的建立和维护以及前端应用程序的开发两个方面。本项目适用于Windows 操作系统，使用SQL Server 2005数据库，利用C++,JAVA

开发平台开发系统。

1.3定义

静态数据：主要是由表和视图组成，应该注意的是，数据字典中的表是不能直接

被访问的，但是可以访问数据字典中的视图。

动态数据：SQL 包含了一些潜在的由系统管理员如SYS 维护的表和视图，由于当

数据库运行的时候它们会不断进行更新，所以称它们为动态数据字典（或者是动态性能视图）。这些视图提供了关于内存和磁盘的运行情况，所以我们只能对其进行只读访问而不能修改它们。

数据字典：数据字典是SQL 存放有关数据库信息的地方，其用途是用来描述数据

的。比如一个表的创建者信息，创建时间信息，所属表空间信息，用户访问权限信息等。当用户在对数据库中的数据进行操作时遇到困难就可以访问数据字典来查看详细的信息。

需求：用户解决问题或达到目标所需的条件或功能；系统或系统部件要满足合同、

标准，规范或其它正式规定文档所需具有的条件或权能。

需求分析：包括提炼，分析和仔细审查已收集到的需求，以确保所有的风险承担

者都明其含义并找出其中的错误，遗憾或其它不足的地方。

1.4参考资料

[1] 刘利民、田宝军 .软件工程综合设计指导书,2011

[2] 张海藩. 软件工程导论（第五版）. 北京清华大学出版社,2003 [3] 黄国兴、周勇著 .软件需求工程. 清华大学出版社,2008-05 [4] 车站售票管理系统——项目开发计划书 [5] 车站售票管理系统——可行性分析报告

2．任务概述

2.1目标

利用信息化手段缓解火车站售票压力，满足广大人民群众的购票需求，使管理人员能够方便进行售票管理工作，包括修改、维护、统计等，使广大人民用户能够利用该系统进行信息的查询，购票，退票等。

用自然语言或者形式化语言与图形等完整、准确、具体地描述系统的数据需求、功能需求、性能需求、可靠性需求和可用性需求、接口需求、约束、逆向需求以及将来可能提出的要求。

（1) 完善目前火车售票系统，使之能跟上时代的发展。同时通过实践来提高自

己的动手能

（2）应用范围：理论上能够实现于铁路部门的售票系统，其目的在于在原有的

系统基础使得火车售票便捷化，以期实现完善日常生活中火车售票的各种缺陷。

（3）可实现旅客对于火车票的查询与购买功能，售票员则可实现查询、添加和

删除等功能；对于所查询的车次结果提供列表显示输出；有一定的安全机制，普通旅客不能对车次信息随意删改，只有系统管理员可通过密码识别进行维护。

2.2运行环境

操作系统：Microsoft Windows 2007或Microsoft Windows XP 支持环境：IIS 5.0

数 据 库：Microsoft SQL Server 2005

2.3条件与限制

应具备的设备：计算机4台，打印机1台 应具备的人员：软件专业学生4人

其他条件：保证相关开发人员全部到位，不缺勤；资金全部到位

3．数据描述

3.1静态数据

列车信息：列车车号 (int SerialNumber) 列车始发时间 (struct time SetOut) 列车始发站(char DeparturePoint) 列车终点站(char TerminalPoint) 额定载量（int FixNumber ）

票务：列车车号 (int SerialNumber) 发车时间 票价 发出车站

售票员：用户名 （char name） 密码(char password)

3.2动态数据

输入数据：（根据界面提示，键盘输入操作） 输出数据：

输出信息：查询车次确定的数据库记录的子集；

3.3数据库介绍

名称：Microsoft SQL Server 2005

介绍：微软SQL Server 2005 SP1加入数据库镜像功能，为SQL Server 2005

Express Edition提供新管理工具，并且加强了SAP NetWeaver智能商务系统的报告反馈支持功能。

管理：SQL Server Management Studio 集成了对 SQL Server 2005 所有组件的

管理。Business Intelligence 从业者都将得益于 Microsoft 服务器“能力”扩展这一用户盼望已久的功能增强，即从关系引擎（伸缩性、可靠性、可用性、可编程性，等等）扩展为全套的 BI 平台组件。 支持的操作系统： Windows 2000 Service Pack 4;

Windows Server 2003 Service Pack 1; Windows XP Service Pack 2

硬件要求：具有 Intel Pentium III 600 MHz（或同等性能的兼容处理器）或速

度更快处理器（建议使用 1 GHz 或速度更快的处理器。）的计算机 最低 192 MB 的 RAM（建议使用 512 MB 或更高的 RAM。） 100 MB 的可用硬盘空间

注意事项：安装此包之前，必须从系统中删除 SQL Server Management Studio

Express 的任何 Beta 版本或 Community Technology Preview (CTP) 版本。如果不执行此操作，则将导致此包安装 失败。

安装条件：您必须在计算机上具有管理权限才能安装SQL Server 2005。

3.4数据词典

3.5数据采集

（1） 车票信息由数据库设计人员加入录入数据库中

（2） 用户账户及密码由登陆人员自行设计有数据库设计人员设计的系统方

式录入数据库中。

（3） 其他数据如票务信息由系统自动生成

4．功能需求

4.1功能划分

图 3.1 系统管理用例图

表3-1 登录系统用例规约

表3-6 维护数据管理规约

图 3.2 售票用例

表3-7登录系统用例规约

表3-8 退票规约

表3-9 统计信息用例规约

表3-10 售票规约

表3-11查询信息规约

表3-12 购票规约

4.2功能描述

售票：根据旅客的需求如发车日期、发车时间、车厢类型、车票类型（学生票、

军人票„）、旅客终点站等选择用户所需要的车次，然后结算并打印车票给旅客。

订票：由售票点授权或是有一定信誉的售票商替代旅客进行预订车票，售票

商通过电话或是亲自到售票点预订的方式进行预订车票。

退票：处理用户由于某种情况需要退回车票的情况，旅客要在车站指定的时间内

进行退票，此外车站售票点还要扣除一定的手续费。如若改签则由售票员改签到旅客所要的车次、时间、地点。

查询：查询分为车次查询、站点查询、时刻表查询、票价查询、剩余票数查询。

车次查询提供了所有车次浏览、按车次查询、和站站查询，用户可以通过查询来了解列车所经车站以及发车时间等信息。时刻表查询可以查询每一车次在每一站的发车时间和到站时间。票价查询可以让用户按自己的需求来查询所有车次的车票价格；余票查询可以查询到所有车次的剩余车票的

情况；

统计：售票统计分别可以按日期统计、按车次统计、按客流方向统计等统计方式，

通过察看车票的流向可以得知旅客的大致流向，列车管理人员可以根据客流的流向随时调整列车运行车次，达到列车的合理调度，使列车最大限度的投入使用中，实现资源的合理利用。

信息修改：包括车次修改、票价修改、站点修改。车次修改包括增加车次，减少

车次，车次的临时调度和由于自然灾害造成的临时路线更改。票价修改为节假日、春运等特殊时段或某些特殊地域需要适量增加或减少票价，具体数字有铁路管理定。站点修改可是某些车次增加或减少一些站点。 系统管理：管理员通过系统添加用户或者删除用户，并且授予权限，同时维护数

据库，保证系统正确运行。

5．性能需求

5.1数据精确度

由于采用数据库技术并且用户的应用领域对数据精确度的要求不是太高，所以这点在系统中表现得比较少，但是用户数据的安全性与正确性是完全保证的，所以对用户的使用没有多大的障碍。输入数据精度要求不高，但用户输入不精确时有提示。

5.2时间特性

对于用户的输入应该在较短的时间里给出回应。若出错，应有出错报告。由于该系统要求36台机器能够同时运行，要求较高的并发处理功能。当增加多台机器后，要求系统的响应时间不会有过大的延时。

5.3适应性

该软件只能在Windows 系统下运行，所以兼容性不高，但应用户特殊需求在维护阶段会保持一个与其它类软件接口，随时满足客户的使用需求。

6．运行需求

6.1用户界面

图3.3 系统登录界面

图 3.4 旅客及售票员查询界面

图 3.5 管理员功能界面

图 3.6 列车信息

图 3.7售票员功能

图 3.8 退票界面

图 3.9 人员管理

图 3.10 权限管理

图 3.11 售票管理

图 3.12 列车管理

图 3.12 维护后台

6.2硬件接口

（1）硬件接口：支持x86系列PC 机

（2）网络硬件接口要求：现实中要求具有高速以太网组网一实现联网销售，但是在理论实验验证软件本身的目的来看，无需网络通讯接口。

软件除较小硬盘和显示器，鼠标外，服务器，基本没有与外界硬件的联系，不过考虑到数据库大量数据的备份等要求可以保持与磁带机和光盘刻录机的接口。

6.3软件接口

在这里主要考虑软件与操作系统的接口，考虑到文档处理的需要有可能需要与常用的办公软件的接口。例如Microsoft 的office 系列。另外查询模块需要与互联网相连，以实现乘客的网上查询。运行于Windows2000及更高版本并装有JAVA 虚拟机的操作系统之上。

6.4故障处理

鉴于火车售票系统涉及的数据对于火车站日常管理的重要性，必须建立数据库严格有效的恢复机制：数据必须每天进行一次备份，由于本信息涉及信息量巨大，应以天为周期进行增量转储，一般半个季度为周期进行删除。

正常使用时不用出错，对于用户的输入错误应及时给出适当的改正信息提

示，若运行遇到不可恢复的系统错误，也必须保证数据库完好无损。

7．其它需求

本系统中对系统各个模块功能，以分级菜单的形式给出；所有的提交，确认，删除等操作以按钮的形式给出，且名称一律取为“提交”、“确认”、“删除”等易于理解的形式；根据用户统计信息计算，统计在正常情况下应该支持一定人数的并行操作能力，春运高峰期间人们要集中买票和查询，应支持更多人数的并行操作能力；高峰期间服务器应支持几十万以上的日访问量。 （1）可用性：该软件也可以通过单步跟踪的操作进行检查处理。

（2）安全性：由于软件运行数据放在数据库中，所以参数不容易被错改、破坏，万一参数受到破坏也不会影响源程序。

（3）可维护性：该软件利用数据库进行编程，系统结构由程序基本确定，大量的参数及文本内容全部放于数据库中。修改、更新数据只要在数据库进行修改添加，而不需要对系统结构进行修改，这样系统维护性、升级都十分方便。 （4）兼容性：由于尚未测试，故无法对兼容性进行评析。

8. 附录

1. 车辆类型

篇11

关键词：基本农田 ；信息系统； mapgis

基本农田划定是依据土地利用总体规划将基本农田落实到地块，确定基本农田空间位置、数量、质量等级、地类等信息的全过程。将基本农田划定成果包括基本农田保护图件、基本农田责任状、保护标志牌、统计表等图表册全部放入数据库进行统一管理、更新，可以全面掌握基本农田的数量、分布、等级，为基本农田管理提供评价、统计、查询和预测等服务，提高管理者的管理水平和决策效率。

一、基础平台的选择

本次开发地理信息系统主要是基于mapgis为平台，采用.net技术开发，C/S体系结构。

当今计算机技术和信息技术蓬勃发展，形成了诸多关于土地管理方面的软件，基本农田信息是一个相当庞大的数据库，不仅包含基本农田的属性信息，充分借助GIS空间分析与属性查询的交互式操作进行数据变更和统计，是一般软件所不能及的，利用GIS软件管理地理信息数据是未来发展的一大趋势。另一方面，在运行环境上，Internet技术飞速发展，使得基于b/s体系结构的方式取代了c/s体系结构，用于无序下载客户端软件即可浏览并进行基本的GIS操作，提高了系统升级维护的便捷性。

广西开展的第二次土地调查数据库、乡镇级土地利用规划数据库均采用MapGIS软件系统，因此，以此为基础，设计开发基本农田管理系统可以满足基本农田数据库建库需求同时具备广泛试用性。

二、县级基本农田管理系统的需求分析

基本农田管理信息系统的建设要以实现基本农田精细化监管为总体目标，以基本农田“管理信息化”为建设目标，主要实现如下6个方面的主要功能需求。

(一)占用预警

实现图形与属性数据的互动。通过导入新增建设用地项目范围线，分析项目范围内占用基本农田和土地利用现状地块情况，统计占用的基本农田总面积及各地类面积的细化情况，在地图上标出预警区域，建立预警档案，为新增建设用地项目报批提供参考依据。

(二)基本农田动态监测

一是实现图形与属性数据的互动。采用卫星或航拍影像数据监测基本农田变化。根据影像特征，对比基本农田保护区范围内各地类的变化情况。二是及时分析。巡查人员在巡查项目过程中如果发现了基本农田占用情况，通过拍照片、用GPS采集坐标信息，上传到土地部门。数据库管理员把巡查员传回的坐标数据导到基本农田数据库，利用占用预警分析功能，分析出该项目占用基本农田情况是否合法，如占用合法，则进行基本农田补划；如占用非法，则移交执法部门执法

(三)智能补划

在土地利用现状图斑中自动选取不在基本农田保护地块范围内的满足补划条件的耕地地块(或可调整地类地块)，显示补划地块信息和位置。在查找结果中，根据实际补划面积，提供最优补划方案，保证基本农田的占补平衡.

(四)数据变更管理

通过对基本农田图斑、保护块等的新增、分割、合并等变更操作，根据日常的业务需求，可以实现对基本农田占用补划、灾毁等实时变更。

(五)数据入库检查、综合统计分析与图表输出

数据入库：衔接好土地利用现状数据库、基本农田规划数据库、基本农田划定数据库、基本农田占、补划数据库等的录入。

数据检查：要求系统具有强大的检查功能，对入库的数据建立数据入库核查、检查机制，检测数据的数据结构、数据属性、图形拓扑(包括单个图层内和图层间)、逻辑关系等。对于检查出来的错误可以直接在图上定位，并能形成检查报表。

汇总统计：对基本农田现状面积以及变化，数量、地类、质量等信息进行分类统计、制图、制表。同时要求在指定区域、指定时间点统计分析。

图表输出：输出相关表格图件。土地利用地类面积表、土地利用现状图和基本农田保护图专题图等。

(六)数据共享、安全和维护

数据共享要求：建立健全与各级数据信息管理相一致的基本农田数据标准体系和成果规范体系，要实现耕地保护系统其他相关业务职能部门数据信息的无缝对接，保证各级数据的一致性、格式的通用性。建立数据的多级访问权限机制和数据保密机制，保证数据访问、的安全性。

数据维护要求：要求系统接口开放，能根据各类规程及政策文件要求变化，对系统功能和算法进行调整 ，及时调整维护各数据库数据。

三、系统总体架构

此总体框架由三大体系：安全体系、运行管理体系、保障体系；四个层面：基础层、数据层、支撑层、应用层构成。

基础层是系统的运行保障层，包括网络基础设施和相应的硬件设施。硬件层为系统提供通信、安全等基础设施。

数据层主要是系统的数据支撑层，包括了系统的数据资源及数据资源管理功能。系统的数据包括：基础地理数据、二调基本农田调查数据、土地利用总体规划基本农田数据、土地利用分等定级数据、建设用地审批数据、基本农田数据数据库数据。数据层为系统提供真实的基础数据支持。

支撑层主要是系统业务应用系统的支撑平台，由各种中间件、服务组件和接口组成，主要包括工作流中间件、GIS服务组件、位置服务中间件、消息中间件和安全中间件等组成。

应用层主要是系统的业务应用系统,包括基本农田业务管理、基础数据管理、数据更新、维护管理等。

四、系统功能设计

基本农田信息系统分为建库子系统、成果监管子系统和WEB子系统。

建库子系统：提供了建库工具和数据检查功能，辅助用户快速建立信息齐全、图属无误的基本农田划定数据库；同时提供初步的统计汇总功能，满足建库单位上报成果进行检核的要求。

监管子系统：结合国土资源管理部门对基本农田划定数据库的日常管理要求，提供了信息查询浏览、建设占用地块范围统计分析、基本农田保护责任书责任卡的输出和管理、以及调整补划等功能，使相关人员能够对 数据库进行全局把握并维护现势性，达到长效更新和永久保护的目的。

WEB子系统：在同一局域网内，实现基本农田数据库的图属和信息的有效共享。由数据库管理员统一维护，针对不同用户设定不同的职能权限，使客户端人员只能在分配的功能范围内调用自己辖区的数据，做到互不侵犯，有效保证数据安全。

五、应用前景

目前以广西第二次土地调查形成的全区土地利用现状图、遥感影像图、农村土地权属和基本农田四个数据信息成果为基础，集成了土地、矿产、海洋等数据库，与电子政务系统紧密结合，完成了“一张图”工程构建，解决了办公信息系统与GIS的无缝连接。因此在广西建设开发基本农田信息管理系统，具备十分优越的基础条件。采用信息系统管理也是今后发展必然趋势，使用该系统可以更好的服务于国土系统，实现基本农田的动态高效管理。本系统设计思路符合实际运用需求，可为各地区基本农田信息系统的构建提供参考依据。

参考文献：

[1] 杜小娅，陆跃进.浅谈基本农田保护管理信息系统需求设计分析(J).信息资源建设与管理.2012，2：35-37.

篇12

关键词 ：基本农田 ，信息系统，mapgis

Abstract: the cultivated land protection, especially the protection of basic farmland has always been a national priority, the country at present general land use planning work has been basically end, now into the basic farmland demarcated work stage. According to the requirements of land and resources, the basic farmland demarcated work a important task is to establish the basic farmland management information system at all levels, through the routine information supervision, implement the strictest arable land protection system. This paper based on the actual work, in the existing software and hardware, and on the basis of research really feasible management system, and combined with the use of software in guangxi universality and broad, at the county level of protection of basic farmland management system function demand and put forward the design development train of thought, so as to provide the guidance system development each county.省略技术开发，C/S体系结构。

当今计算机技术和信息技术蓬勃发展，形成了诸多关于土地管理方面的软件，基本农田信息是一个相当庞大的数据库，不仅包含基本农田的属性信息，充分借助GIS空间分析与属性查询的交互式操作进行数据变更和统计，是一般软件所不能及的，利用GIS软件管理地理信息数据是未来发展的一大趋势。另一方面，在运行环境上，Internet技术飞速发展，使得基于b/s体系结构的方式取代了c/s体系结构，用于无序下载客户端软件即可浏览并进行基本的GIS操作，提高了系统升级维护的便捷性。

广西开展的第二次土地调查数据库、乡镇级土地利用规划数据库均采用MapGIS软件系统，因此，以此为基础，设计开发基本农田管理系统可以满足基本农田数据库建库需求同时具备广泛试用性。

二、县级基本农田管理系统的需求分析

基本农田管理信息系统的建设要以实现基本农田精细化监管为总体目标，以基本农田“管理信息化”为建设目标，主要实现如下6个方面的主要功能需求。

（一）占用预警

实现图形与属性数据的互动。通过导入新增建设用地项目范围线，分析项目范围内占用基本农田和土地利用现状地块情况，统计占用的基本农田总面积及各地类面积的细化情况，在地图上标出预警区域，建立预警档案，为新增建设用地项目报批提供参考依据。

（二）基本农田动态监测

一是实现图形与属性数据的互动。采用卫星或航拍影像数据监测基本农田变化。根据影像特征，对比基本农田保护区范围内各地类的变化情况。二是及时分析。巡查人员在巡查项目过程中如果发现了基本农田占用情况，通过拍照片、用GPS采集坐标信息，上传到土地部门。数据库管理员把巡查员传回的坐标数据导到基本农田数据库，利用占用预警分析功能，分析出该项目占用基本农田情况是否合法，如占用合法，则进行基本农田补划；如占用非法，则移交执法部门执法

（三）智能补划

在土地利用现状图斑中自动选取不在基本农田保护地块范围内的满足补划条件的耕地地块（或可调整地类地块），显示补划地块信息和位置。在查找结果中，根据实际补划面积，提供最优补划方案，保证基本农田的占补平衡.

（四）数据变更管理

通过对基本农田图斑、保护块等的新增、分割、合并等变更操作，根据日常的业务需求，可以实现对基本农田占用补划、灾毁等实时变更。

（五）数据入库检查、综合统计分析与图表输出

数据入库：衔接好土地利用现状数据库、基本农田规划数据库、基本农田划定数据库、基本农田占、补划数据库等的录入。

数据检查：要求系统具有强大的检查功能，对入库的数据建立数据入库核查、检查机制，检测数据的数据结构、数据属性、图形拓扑（包括单个图层内和图层间）、逻辑关系等。对于检查出来的错误可以直接在图上定位，并能形成检查报表。

汇总统计：对基本农田现状面积以及变化，数量、地类、质量等信息进行分类统计、制图、制表。同时要求在指定区域、指定时间点统计分析。

图表输出：输出相关表格图件。土地利用地类面积表、土地利用现状图和基本农田保护图专题图等。

（六）数据共享、安全和维护

数据共享要求：建立健全与各级数据信息管理相一致的基本农田数据标准体系和成果规范体系，要实现耕地保护系统其他相关业务职能部门数据信息的无缝对接，保证各级数据的一致性、格式的通用性。建立数据的多级访问权限机制和数据保密机制，保证数据访问、的安全性。

数据维护要求：要求系统接口开放，能根据各类规程及政策文件要求变化，对系统功能和算法进行调整 ，及时调整维护各数据库数据。

篇13

关键词：需求侧 管理系统

1 引言

电力需求侧管理系统的首要功能任务就是解决电网缺电时如何做到电力需平衡。但不局限于当电网电力供应不足时做到供需动态平衡，通过研究负荷侧实时的用电负荷变化和发展趋势，为供电和发电两侧的5年发展规划提供更加详细的电网运行原始数据，使供需平衡点由静态平衡达到一个动态平衡过程。

2 电力需求侧管理系统的需求分析及总体设计

2.1 系统需求分析 电力需求侧管理系统是在营销运行的基础上，将系统的用电监控与负荷需求侧综合分析综合为一体化的综合应用平台。要求保证供电局其他系统上线的基础性业务正常运行上线的前提下，为营销部决策提供准确详实的依据；并且通过将供电局众多独立的单个子系统整合成系统，达到数据资源最大程度优化和数据共享；制定统一标准的营销业务流程。

2.2 系统的功能需求 电力需求侧管理系统能够实现主动采集负荷侧电能参数、实时抄表、准确掌握用户负荷侧的数据变化趋势、用户负荷管理和控制、用电负荷侧数据突变和实时监测分析、多线路线损并行计算分析等多种功能。因此系统要求具有高冗余度和可靠性，确保收集到监测数据的准确可靠和完整。从系统的硬件角度上，系统在CPU、RAM和硬盘存储硬件设备等主要硬件方面留有足够的发展升级空间。从软件设计方面，电力需求侧管理系统所要完成的主要功能可归纳为原始数据的收集、数据传输和实时监控、用户负荷控制管理、用电数据突变异常、多路线损计算与综合分析、电能数据报表的及时生成和打印、系统本身管理等几大模块。

2.3 总体设计 系统框架结构如下图：

如图2-1电网的需求侧管理系统整体框架结构所示系统主要建立在地市电厂、关口电表、主要枢纽配电所、配变终端和用户负荷侧等关键电能量采集点的基础之上的，在供、售、购电三个关键环节点上实现一体化管理，将用电负荷终端数据集中存储分析；并且构建出电能量采集一体化系统，对电厂、各级配变终端、用户负荷侧等电能量数据实现实时采集。

3 电力需求侧管理系统的研究与实现

3.1 主机系统设计 在建设思路上，这次电力需求侧管理的规划将数据库的服务器与应用程序的服务器进行了一体化，但是有两台PC的配置。

3.2 数据库/应用服务器设计 采用三层分层分布式数据结构后，底层数据库及应用层数据库服务器承担着相应电力系统企业营销业务线数据逻辑处理分析及运算的主要任务。

3.3 前置服务器设计 前置服务器主要完成整个需求侧管理系统的通信、逻辑数据解析，实现用户侧终端数据及配变电能数据采集与系统终端数据联系控制管理功能，应采用两台主备服务器，操作系统采用Linux系统构成双机主备结构，提高系统可靠性。

3.4 备份系统设计

3.4.1 备份系统需求分析。首先，我们分析由于硬件故障、应用程序出错、病毒入侵等多种可能导致业务系统功能中断的原因，因此需要做好多种预防和解决各类系统缺陷故障的手段。对于系统硬件的故障，我们采用硬件备份的设计来解决这些问题。对于应用程序故障，采用三层分布式数据结构和多线程处理应用解决应用程序上的故障。但是对于自然灾害导致的需求侧管理系统瘫痪，为了在故障来临时恢复原始数据，需要构建统一的备份中心来保护这些系统的数据，可通过异地数据恢复，将因系统无法自动恢复所带来的损失减到最低程度。

3.4.2 备份系统组成。备份系统是由备份系统管理软件，备份管理后备服务器以及硬件构成的。

4 总结

本文对整个电力需求侧管理系统进行了全面的研究和开发。构建出电力需求侧管理系统的需求分析及总体设计。对硬件平台及软件平台设计及开发详细的介绍。电力需求侧系统将在电力企业与用电客户之间架起沟通的桥梁，直接为电力部门产生良好的社会、经济效益，因此本文研究具有良好的市场推广应用前景。

参考文献：

[1]刘磊.新型需求侧管理系统特点解析[J].华北电力技术，2009（01）.

[2]郑峰崖.当前实施电力需求侧管理存在的问题和思考[J].广东电力，2007（06）.

[3]胡江溢，王鹤，周昭茂.电力需求侧管理的国际经验及对我国的启示[J].电网技术，2007（18）.

[4]杨林.电力需求侧管理综述[J].中国电力教育，2008（04）.

篇14

1 总体业务描述

本文设计的人事管理信息系统是一个针对单位人事管理单位管理职工档案信息和管理职工的实际工作情况，并结合单位人事管理通用的管理功能和操作习惯等特点开发设计的一个基于WEB的人事管理信息系统。

单位职工可以通过该系统变更、调整、申请等业务。人事管理员可以对档案信息进行查询，财务可以对工资信息发放，单位领导可查询职工具体情况。

1.1 系统业务流程

根据需求分析得到的现行业务处理流程，一是公司员工登录和查询信息业务流程：登录、进入查询模块、查询信息；二是系统操作员登录和后续相关操作的业务流程：登录，进入处理模块，查询处理信息。其次进入修改和添加模块，进行修改、添加和删除相关信息。

1.2 系统数据流程

数据流程表示求解某一问题的数据通路。在人事管理信息系统的需求分析过中，还将使用结构化的分析方法。所谓结构化的分析方法就是通过自顶向下、逐层分解的方法，把大问题分解成小问题，然后分别解决。

人事管理系统的数据流。分为员工和操作员登录的两大部分，员工可以在系统中进行注册，注册信息后可登录界面，进而进行查询。对于操作员登录后能对登记的信息进行修改和维护等操作。

2 系统数据字典

数据字典是配合数据流程使用的工具之一。在结构化分析时所定义的数据字典，主要用来描述数据流程中的数据流、数据存储、处理过程、数据源点和终点。

2.1 系统的主要数据流

1. 流 名： 登陆验证

位 置： 操作员"登陆处理

定 义： 登陆验证=操作员姓名+密码

2. 流 名： 验证结果

位 置： 登陆处理"操作员

定 义： 验证结果=[登陆成功|用户未注册|密码错误]

3. 流 名： 登记信息

位 置： 登记处理"人事管理基本信息

定 义： 登记信息=人事管理基本信息

4. 流 名： 登记结果

位 置： 人事管理基本信息"登陆处理

定 义： 登陆结果=[成功|失败]

5. 流 名： 员工注册

位 置： 员工"登陆处理

定 义： 员工注册=员工基本信息+密码

6. 流 名： 注册结果

位 置： 登陆处理"员工

定 义： 注册结果=[注册成功|注册失败]

7. 流 名： 员工登陆

位 置： 员工"登陆处理

定 义： 登陆验证=员工姓名+密码

8. 流 名： 登记结果

位 置： 登记处理"员工处理

定 义： 登陆结果=[成功|失败]

9. 流 名： 查询要求

位 置： 员工处理"人事管理基本信息

定 义： 查询要求=员工姓名

10. 流 名： 查询结果

位 置： 人事管理基本信息"员工处理

定 义： 查询结果=[人事管理基本信息|失败]

11. 流 名： 系统维护

位 置： 登记处理"人事管理基本信息

定 义： 登记新到员工的基本信息、人员调动、福利、出勤、请假、基本工资、操作员授权等

12. 流 名： 维护结果

位 置： 人事管理基本信息"登记处理

定 义： 把登记的员工的基本信息、人员调动、福利、出勤、请假、基本工资、操作员授权信息等反馈给操作员。

2.2 系统的主要数据存储

1.数据存储名称： 操作员授权

输 出： P1

数据结构： 操作员姓名+密码

2. 数据存储名称： 人事管理基本信息

输 入： P1

输 出： P3

数据结构： 员工的基本信息、人员调动、福利、出勤、请假、基本工资信息等

3 数据存储名称： 员工信息

输 出： P2

数据结构： 员工姓名+密码

3.系统的功能性需求

从功能上看，该人事管理系统可以分为七个子功能模块：人员基本信息管理、人员档案信息管理、工资管理、考勤管理、休假管理、统计查询和系统维护。

人员基本信息管理子功能模块与系统权限管理模块相结合，将人员权限落实到每一个人，在系统中授予相应的权限，体现出以人为本的管理理念。

人员档案信息管理子功能模块：主要包括姓名、性别、出生日期、年龄、照片、户籍、地址、电话、身份证号码、最高学历、家庭状况、主要简历等。

工资管理子功能模块：工资帐套管理、工资档案结算等。

考勤管理模块：该模块分为基本考勤、加班考勤和出差考勤三部分

统计查询模块：包括人事档案查询、职工调整查询、合同续签查询、职工培训、奖惩、考核查询、工资档案查询。

系统维护模块：模块包含单位设置、数据字典、自定界面、编号设置、提醒设置等。

每个包一个子功能模块，分别对相应的事务进行管理。用例中包括5个用例：领导、人事档案管理员、财务管理员、系统管理员和职员。

人事档案系统：人事档案系统是劳动人事管理系统中的核心模块之一。人事档案管理员可以管理人员档案信息，进行人员相关信息职评定修改、调动管理。

系统管理：系统管理员可以根据系统需要，添加部门，删除、更新部门，管理系统基本资料。

财务管理：财务管理员的职责尤为重要，该财务管理主要是针对人才培养投入的各种经费管理，包括工资等等多种经费的管理。

综合查询：此模块功能简单明确。领导登陆后可以查阅任何信息。

4 系统非功能性需求

非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。

（1）系统的完整性

系统的完整性指为完成业务需求和系统正常运行本身要求而必须具有的功能，这些功能往往是用户不能提出的，典型的功能包括联机帮助、数据管理、用户管理、软件管理和在线升级等。

（2）技术适应性与应用适应性

系统的适应性与系统的可扩充性和可维护性的概念相似，也表现产品的一种应变能力，但适应性强调的是在不进行系统设计修改的前提下对技术与应用需求的适应能力，软件产品的适应性通常表现为产品的可配置能力。

（3）系统的可扩展性与可维护性

指系统对业务和技术需求变化的支持能力。当技术变化或业务变化时，不可避免将带来系统的改变。因此不仅要进行设计实现的修改，甚至要进行产品定义的修改。