系统需求分析报告

时间:2019-05-14 01:28:37下载本文作者:会员上传
简介:写写帮文库小编为你整理了多篇相关的《系统需求分析报告》,但愿对你工作学习有帮助,当然你在写写帮文库还可以找到更多《系统需求分析报告》。

第一篇:系统需求分析报告

系统需求分析报告

目录

目录.............................................................................................................I

1、项目描述...............................................................................................1 1.1 背景................................................................................................1 1.2研究意义........................................................................................1

2、需求分析...............................................................................................1 2.1功能需求分析................................................................................2 2.1.1 系统管理功能......................................................................2 2.1.2 流量劫持功能....................................................................2 2.2性能需求分析................................................................................2

I

1、项目描述

1.1 背景

随着网络的普及,网络业务应用向深度和广度不断发展,方便用户的同时,也因用户终端存在网络安全漏洞或用户网络安全意识的疏忽,使得网络上涉及如:电子商务、在线游戏、DNS授权服务、网银支付系统、社交网站、论坛、博客、门户网站等在线业务受到黑客及网络犯罪份子的攻击,对个人用户信息(网银、支付钱包账号密码等)的保密和对国家互联网信息管理与审计构成严重威胁。

1.2研究意义

本项目针对以上问题,主要利用了以下两种技术:僵尸网络反制技术及HTTP/HTTPS协议通信的监控技术。

网络攻击已严重威胁着网络的安全,及时的发现网络攻击并在必要的时候劫持与反制网络攻击,成为保障互联网正常运行、保障在线业务系统正常访问的重要方法。

2、需求分析

经过与项目委托方多次讨论,设计系统的目的是为实现对特定非法用户Web(HTTP/HTTPS协议)通信进行监控及反制,具体要求实现的功能有:监控系统远程控制、针对特定非法用户上网流量劫持、针对特定非法用户Web通信进行JS脚本注入、获取非法用户账号和密码、获取非法用户访问某些网站的Cookie。

第 1 页 2.1功能需求分析

根据监控系统的要求对系统的功能进行分析,明确了系统需要实现的功能。系统的功能结构模块:系统管理功能、流量劫持功能、监控与反制功能。

2.1.1 系统管理功能

系统管理模块主要负责系统登录、系统远程控制、黑名单库配置、数据存储和展示。数据展示包含数据存储和数据展示,数据存储负责接收后端和前端JS探针采集的数据并存储到数据库,数据展示负责提取数据库数据并显示。

2.1.2 流量劫持功能

本文流量劫持指DNS协议劫持,主要由四个部分组成:报文捕获、协议解析、IP及域名查找匹配、DNS协议欺骗。

2.2性能需求分析

1.DNS流量劫持成功率

为了达到项目委托单位的要求,需要对特定用户访问特定网站的流量进行准确监控,同时保证流量劫持的成功率(90%以上)。

2.监控与反制系统并发量

监控与反制系统服务器的并发性能直接决定同时能够监听的用户数。当被监控用户数过大,监控与反制系统并发处理能力到极大挑战。

3.系统运行稳定性

第 2 页 系统稳定性是系统最基本也是最重要的要求,运行稳定性关系到系统能否长时间稳定运行。系统的稳定性体现在:随着运行时间的增加,系统并不会出现内存泄露、甚至系统崩溃等情况。其中内存泄露可通过内存消耗、CPU使用率指标度量。

第 3 页

第二篇:工资管理系统需求分析报告

工资管理系统需求分析报告

引言

1.编写目的

编写该文档是为了分析人工管理企业工资的流程,把人工模式抽象为可在计算机上处理的自动模式,对企业工资的科学管理进行分析与总结,便于开发小组成员对系统整体功能的认识,通过该文档,确定了系统的目的和功能,以及管理的流程和方法,同时也为使用者提供参考。

2.背景

随着企业的快速发展,企业规模越来越大,在职员工的数量也越来越多,企业工资管理更加的复杂,而工资管理是一项琐碎、复杂而又十分细致的工作,工资计算、发放、核算的工作量很大,一般不允许出错,如果实行手工操作,每月发放工资须手工填制大量的表格,这就会耗费工作人员大量的时间和精力,计算机进行工资发放工作,不仅能够保证工资核算准确无误、快速输出,而且还可以利用计算机对有关工资的各种信息进行统计,服务于财务部门其他方面的核算和财务处理,同时计算机具有着手工管理所无法比拟的优点.例如:检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。这些优点能够极大地提高人事工资资管理的效率,也是企业的科学化、正规化管理,与世界接轨的重要条件。这就对企业工资管理提出了新的要求,用计算机管理系统来管理企业工资已经成为目前的趋势,使用计算机可以高速,快捷地完成以上工作。在计算机联网后,数据在网上传递,可以实现数据共享,避免重复劳动,规范数据管理行为,从而提高了管理效率和水平。企业工资管理系统便是以计算机为工具,通过对工资管理所需的信息管理,不仅把管理人员从繁琐的数据计算处理中解脱出来,而且优化了管理体系,使其高效化,简易化,智能化,也提高了透明度和互动性。

3.功能定义

(1)员工基本信息的添加,修改,删除,查找和辅助查询。

(2)工资标准设定功能。具体包括工资,出行费,医疗保险,养老金,水电费,其他费用,补贴,奖金标准的设定。

(3)工资信息浏览。

(4)员工工资表创建。

(5)工资调整管理。

(6)工资统计。

为完善系统管理功能,增加工资系统用户管理功能,包括系统用户数据的添加,修改和删除。教职员工为系统普通用户,只能运行系统个人工资查询功能;系统管理员则能运行系统所有功能,从而有效保证系统数据的安全性。

4.功能描述

用例模型

顺序模型(管理员查询工资)

活动模型(登陆)

4.1员工基本档案信息管理功能描述:

凡属于本部门的员工,都需要对其基本的档案信息做好记录存储处理。以方便高级管理人员时时的了解或查阅其员工基本信息。对员工基本信息的操作包括添加信息、修改信息、查询信息,同时在数据库中要形成员工基本信息表。

4.2工资管理功能描述: 工资计算:

在进行工资计算之前,管理员首先应该根据部门的实际业务情况确定好各个部门中所需要的工资项目及分别对工资项目进行计算的方式,然后按照系统工资种类的设定,对每个员工分别依次实际工资项目构成情况,如考勤情况工资、底薪工资、奖惩工资、提成工资、应交所得税等等项目,录入相应的工资金额数,再计算出总的应得工资、实得工资的工资项目。在数据的录入过程中系统会根据用户 3

误输、错误输入智能提示引导用户录入数据的正确性。要形成的数据库中的表为员工工资信息表。

工资统计分析:

对员工工资数据计算完后,同时要将工资信息统计分析,如汇总统计,工资项目明细数据的汇总等,又分为对员工个人工资统计分析、部门工资统计分析、月份工资统计分析、季度工资统计分析、年工资分析统计。

4.3工资查询功能描述:

在查询这个模块里,系统能支持用户在客户端按照各种不同的字段名称进行工资信息的查询。同时,迅速的响应用户的查询请求,不同级别的人系统会根据其权限级别的大小享有不同程度的功能。不同级别的人不能越权进行操作。在查询过程中,为避免由于在同一时刻里访问人数过多造成响应缓慢时,每登录的一个用户,系统记数器自动加一,当记数大于峰值时,系统弹出对话框提示用户进行等待,从而有效的避免了系统在查询过程中快速响应的优点。

4.4系统维护:

用户在第一次使用系统时,在服务器端需要用户做系统初始化的处理,包括; 1. 设置工资项目种类、相应工资项目的计算

2.设置系统使用用户及口令、权限的级别,对公司不同要求用户授不同权限,可限制一次性访问数据库用户数量。对每个访问数据库的登陆用户有日志记录。由系统管理员维护。在系统运行过程中,数据库管理员在系统运行过程中,还可以即使的进行系统数据的更改,如:对员工工资数据的更改,对工资项目计算方式的更改,定期做好系统数据的备份操作、还原、清理等。

5.非功能性需求: 5.1可靠性

1. 可恢复性

如果正在使用时出现故障,为了完成做好的工资记录,需要尝试采用本地方案(如存储和转发)加以解决。对此需要更深入的分析 2. 长时间运行

每月都要对工资结算,要求系统能够持续可靠运行,3. 容错性

当员工不能识别,应能够给予提示。

5.2可支持性

1.可适应性

不同型号的票据打印机打印的效果可能存在差异,软件能够支持市场上主流的票据打印机。2.可配置型

人员的权限会根据企业的变化而调整,系统应该能够方便配置调整。还存在一些其他的配置要求,如打印格式、查询项目等,对此需要进一步分析。

5.3可行性

1.评价标准

A.是否消耗太多经费,耗时太长; B.是否功能齐全,运行稳定; C.是否方便管理; D.设置是否灵活;

E.是否具有界面灵活,操作简单的特点。

6.用例说明

本系统的设计目标是能够对大型企业员工的基本信息和工资信息进行添加和修改,根据个人信息将工资分为职务工资,职称工资和其他工资。能够调整工资标准和员工信息,也能够调整其他工资项目,根据需要对教职员工基本信息和工资信息的查询,本系统能够生成各个月的工资表,能够打印报表方便保存和管理,还包括对系统的一些基本操作功能,比如为完善系统管理功能,增加工资系统用户管理功能,系统应该包括系统用户数据的添加,修改和删除。员工为系统普通用户,只能运行系统个人工资查询功能;系统管理员则能运行系统所有功能,从而有效保证系统数据的安全性,系统应该具有简单,易用,小巧,经典的特色,应该能够对企业工资管理进行优化,使其系统化,高效化,智能化。并保证工资管理的准确性,简易性,为企业财务人员提供便利。

7.系统性能需求分析:

7.1 性能需求

此工资管理系统对工资数据精度的计算能在默认情况之下精确到小数点后3位小数,即是精确到分的计算。但在用户使用过程中,能自行根据实际情况进行小数计算精度的设定,最大能允许保留小数点后5位的精度。在时间特性上,当用户发出命令请求时的服务器的响应时间、对数据更新处理、工资数据的查询检索等上,同样要求系统响应时间不会超过0.5秒时间。系统支持多种操作系统的运行环境,多不同操作系统,不同文件格式的磁盘

上的数据均能实现信息的互通,及共享。当服务器移植到其他的系统平台,如:Linux平台下时,同样能和其他的系统进行数据存取同步,不会出现系统之间互不兼容的情况,系统支持多系统之间的互连互通,系统有巨大的强健性。

7.2 运行需求

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

系统可移植较强,在不同的平台下运行,均不会影响系统的稳定性。同时,支持在客户端安装不同操作系统、浏览器版本,均不会影响系统的运行。

7.3安全需求

为保障系统数据的安全性,系统采用访问控制策略,未授权者不能进入系统。同时,对不同级别的用户授予不同的使用权限。在系统运行期间,如发生掉电尚未保存数据,或由于操作不当等原因导致系统重启等,为保证数据的易恢复性,系统提供每隔30秒自动保存数据的机制,让用户的数据在发生意外时能最大程度上

得到恢复。同时,系统提供强大的容错性能,当一台服务器发生故障时,系统能自动切换到另外一台服务器上,从而保障服务器能长时间的提供系统的运行支持。在输入数据时,如果用户输入的数据不符合系统的要求,则系统自动提示错误信息,并要求用户重新输入,直到输入完全正确时才允许进行下一步的操作。

7.4 系统界面需求

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

7.5 其他需求

数据不管是在企业内部之间传输,还是公司与分公司之间进行远程数据传输时,防止数据被不法分析任意的修改和破坏,只有对信息解密的人员才能最终读取数据信息。这样,能 最大程度的防止数据在传输过程的安全保密性。

8.总结

在第一阶段总体分析的基础之上,我们小组进在系统需求过程中,主要是围绕着系统数据流程图和数据字典这两个方面展开文档的编辑工作。当然,在需求分析过程中,我们对系统的功能需求、性能需求、可靠性等方面做了进一步的描述,这为我们进行下一步设计阶段的顺利进行做好铺垫的工作。

第三篇:博客系统需求分析报告

博客管理系统

1.系统需求分析

博客系统分前台功能和后台功能两大部分。前台主要供用户注册,浏览,后台主要供管理员使用,管理员可以对用户进行管理。

1.1前台功能分析

博客系统前台的用户共分两类:一类是注册用户(正式用户),这类用户有基本的信息,可以对自己的信息进行查看与修改,;另一类用户是游客(未注册用户),他们只能查看、浏览注册用户的信息。

游客:可以查看注册用户的信息。经过注册可以成为注册用户。

注册用户:

1、登录后对可以对个人信息进行查看和修改。

2)博客用户通过前台登录后,对自己的空间进行管理,包括发布自己的网络日志,分享视频,分享音乐,邀请好友玩游戏,上传照片,与相关人员进行交流和沟通以及删除访客发表的评论

3)博客用户登录后对自己的信息进行修改

非注册用户

1)游客通过注册,登录进入博客空间发表评论

2)游客不注册,通过匿名方式对博客空间浏览文章,发表评论,查看文章发表人的所有文章

1.2后台功能分析

博客系统后台主要是供管理员使用的,管理员可对用户进行添加、删除、查询及修改;对网站的新闻、公告进行管理。

管理员也可以具有不同的权限分为超级管理员和普通管理员,普通管理员具有以上权限,超级管理员除了可以具有以上所有功能外,还可以添加、删除普通管理员。

2.数据库设计

2.1数据库概念结构设计

对博客系统进行分析后,抽象出有关的数据,按照现实世界的事物能作为属性对待的,尽量作为属性对待的原则。作为“属性”,不能再具有需要描述的性质,“属性”必须是不可分的数据项,不能包含其它的属性;“属性”不能与其它实体具有联系,E-R图中所表示的联系是实体与实体的联系。依照以上准则,可以确定哪些为实体,哪些为属性,每个实体具有哪些属性,实体之间存在何种联系。经分析之后,该系统中包含的实体以及实体之间的联系如下所示:

实体:管理员实体,用户实体,文章类型实体、链接实体、留言实体、文章实体和评论实体,回复实体,视频,照片,音乐、游客。

实体间存在的联系

管理员和用户实体之间存在多对多的联系

博客用户与链接之间存在多对多的消息联系

博客用户与留言之间多对多的回复联系

文章类型与文章之间存在一对多的消息联系

文章与评论之间存在一对多的消息联系

用户和游客之间存在一对多的联系

用户和视频之间存在一对多的联系

用户和音乐之间存在一对多的联系

用户和照片之间存在一对多的联系

实体的属性:

留言(留言编号,网友昵称,日期,标题,内容,个人主页,回复)管理员(管理员,密码,权限)博客用户(用户号,用户名,密码,真实姓名,性别,出生年月,邮箱,电话,单位,城市,地址,注册时间,积分,用户等级,安全问题,安全答案)

文章(文章编号,作者,标题,摘要,内容,发表日期,人气,回复,类型编号,类型名称,回复数)

文章类型(类型编号,类型名称)

评论(编号,用户昵称,标题,内容,发表时间,文章编号)链接(链接编号,名称,地址)

新闻(新闻号,标题,内容,时间)公告(公告号,标题,内容,时间)

视频(视频编号,标题,内容,时间)

音乐(音乐编号,标题,内容,时间,歌手名)

照片(照片编号,标题,内容,时间,大小)

游客(游客号,游客名)回复(用户号,留言号,主题,内容,回复时间)

联系的属性:

实体之间关系的E-R图如图7-7所示。

2.2数据库逻辑结构设计

根据系统E-R图,把实体与实体之间的联系转换成关系模型,E-R图中的每个实体转换成一个关系模型,实体之间一对多的联系合并到多方实体对应的关系模型中,把一方的码与联系的属性纳入到多方实体对应的关系模型中,为实体之间多对多的联系创建一个新的关系模型,它包含双方的码以及联系的属性。具有相同码的关系模型有些情况下可以考虑把它们合并。在转换过程中应该按照关系规范化的理论,对关系模型进行优化,减少冗余和数据操作异常,提高查询速度,在性能与范式之间作出权衡,一般所设计出的关系数据库达到3NF就基本符合要求。按照

评论(编号,用户昵称,标题,内容,发表时间,文章编号)

文章(文章编号,作者,标题,摘要,内容,发表日期,人气,回复,类型编号,类型名称,回复数)

文章类型(类型编号,类型名称)

博客用户(用户号,用户名,密码,真实姓名,性别,出生年月,邮箱,电话,单位,城市,地址,注册时间,积分,用户等级,安全问题,安全答案)

发表(用户号,文章编号,发表日期)管理(管理员,用户号,注册号)留言(留言编号,用户号,网友昵称,日期,标题,内容,个人主页,回复)回复(用户号,留言编号,主题,内容,回复时间)

链接(链接编号,名称,地址)

访问(用户号,游客号,访问量,访问时间)

公告(公告号,标题,内容,时间)

视频(视频编号,用户号,标题,内容,时间)

音乐(音乐编号,用户号,标题,内容,时间,歌手名)

照片(照片编号,用户号,标题,内容,时间,大小)

游客(游客号,游客名)

3功能分析

在其博客管理系统上建立适当的视图,索引,存储过程和触发器,因此我们主要从这四个方面来分析它的功能

A 视图:视图是一个虚拟表,其内容由查询定义。同真实的表一样,视图包含一系列带有名 称的列和行数据。但是,视图并不在数据库中以存储的数据集合形式存在。.创建某某表的视图

2、利用cust_view视图添加一条记录数据

3、创建视图sale_item_view,该视图中包含订单编号、订货日期、产品编号及数量。然后利用该视图向表中插入数据

4删除视图中所有姓“王”的客户数据

5有两个基本表employee和sales,创建一个视图,该视图包含相同业务员的编号、姓名、订单号、销售总金额。

6将上述视图中订单号为10001的记录的销售金额改为60000。

B 索引:索引用来快速地寻找那些具有特定值的记录。

普通索引,这是最基本的索引类型,而且它没有唯一性之类的限制。普通索引可以通过以下几种方式创建:

创建索引,例如CREATE INDEX <索引的名字> ON tablename(列的列表);

修改表,例如ALTER TABLE tablename ADD INDEX [索引的名字](列的列表);

创建表的时候指定索引,例如CREATE TABLE tablename([...], INDEX [索引的名字](列的列表));

唯一性索引,这种索引和前面的“普通索引”基本相同,但有一个区别:索引列的所有值都只能出现一次,即必须唯一。唯一性索引可以用以下几种方式创建:

创建索引,例如CREATE UNIQUE INDEX <索引的名字> ON tablename(列的列表);修改表,例如ALTER TABLE tablename ADD UNIQUE [索引的名字](列的列表);

创建表的时候指定索引,例如CREATE TABLE tablename([...], UNIQUE [索引的名字](列的列表));

主键:主键是一种唯一性索引,但它必须指定为“PRIMARY KEY”。如果你曾经用过AUTO_INCREMENT类型的列,你可能已经熟悉主键之类的概念了。

主键一般在创建表的时候指定,例如“CREATE TABLE tablename([...], PRIMARY KEY(列的列表));”。但是,我们也可以通过修改表的方式加入主键,例如“ALTER TABLE tablename ADD PRIMARY KEY(列的列表);”。每个表只能有一个主键。

3存储过程: 一组为了完成特定功能的SQL 语句集,经编译后存储在数据库中,用户通过指定存储过程的名字并给出参数(如果该存储过程带有参数)来执行它。

1、利用存储过程,给employee表添加一条业务部门员工的信息。

2、利用存储过程从employee、sales、customer表的连接中返回所有业务员的姓名、客户姓名、销售金额。

3、创建带一个输入参数的存储过程,实现按员工姓名进行模糊查找,查找员工编号、订单编号、销售金额。

4、创建带两个输入参数的存储过程,查找姓“李”并且职称为“职员”的员工的员工编号、订单编号、销售金额。

3、利用存储过程计算出订单编号为10003的订单的销售金额。(带一输入参数和一输出参

数)(提示:sales表中的tot_amt应该等于sale_item表中的同一张订单的不同销售产品的qty*unit_price之和)

4、创建一存储过程,根据给出的职称,返回该职称的所有员工的平均工资。(带一输入参

数和返回值)

4触发器触发器对表进行插入、更新、删除的时候会自动执行的特殊存储过程。触发器一般用在check约束更加复杂的约束上面。触发器和普通的存储过程的区别是:触发器是当对某一个表进行操作。诸如:update、insert、delete这些操作的时候,系统会自动调用执行该表上对应的触发器。SQL Server 2005中触发器可以分为两类:DML触发器和DDL触发器,其中DDL触发器它们会影响多种数据定义语言语句而激发,这些语句有create、alter、drop语句。

1、针对employee表写一个DELETE触发器,显示删除的员工人数。

2、针对employee表写一个UPDATE触发器,限制每次工资额的变动不能超过原工资的20%。

3、定义一个触发器,保证新添加的员工的工资不能超过5000元

4、对sale_item表创建一个触发器,当插入一条销售明细记录时,如果该记录的产品数量超过5,则显示“欢迎成为本公司的VIP会员!”

5、针对customer表,定义一触发器用来保证参照完整性

6、针对sales表,定义一触发器保证参照完整性(参照customer表)

7.针对employee表,定义一触发器用来保证实体完整性

8,在customer表上创建一触发器,用来实现级联删除

9、定义一触发器,保证新添加的员工的工资不能超过5000元

10、创建一个触发器,只能接受女员工

11,、写一个允许用户一次只删除一条员工记录的触发器。

第四篇:监控系统需求分析报告

需求分析报告概述

高陵县地处陕西省关中平原腹地,位于西安市辖域北部。地势平坦,土壤肥沃,是西北首个吨粮县。高陵县始建于秦孝公十二年(公元前350年),是中国建县历史最早的县份之一。1949年划属三原分区,1950年5月划属咸阳专区,1953年1月改属渭南专区,1956年10月由省直辖,1961年改属咸阳专区,1983年10月5日划归西安市管辖区域。全县辖4镇4乡,88个行政村,740个村民小组。耕地2万公顷。地区总面积290平方千米,每平方千米人口密度约950人。总人口29万人,其中非农业人口11.9万。县人民政府驻鹿苑镇。名胜古迹有昭慧寺塔等。

2011年全省公安机关还将全力推进技防视频监控网建设,建成覆盖全省城镇社会面、城乡社区、单位内部、重要部位以及复杂公共场所、公共服务娱乐场所视频监控网络。2011年底,全省完成了28万个视频监控摄像点的建设任务,2012年底前,消除城镇社会面、城乡社区、村居、单位内部的治安视频监控盲点,重要部位视频监控覆盖率达到100%,农村社区、村居覆盖率达到60%的目标。据悉,除以上各项内容外,陕西还将在交通智能化、公安信息化建设、电子警察、综合执法平台建设、科技强警、公共安全科技研发等相关项目迎来了历史发展的新机遇。需求分析

高陵县原有平安城市系统,投入使用多年来,在震慑犯罪、取证服务、掌握社会治安动态、有效控制社会面、应急处置突发事件等方面发挥了很大的作用。但因规划建设早,视频监控设备已落后,亟待进行升级改造。

随着平安城市工程在全国范围内的快速推进,视频监控系统的基础建设已经初具规模,并取得了显著成效,正逐步能够满足城市视频监控的一些基本要求,但是也存在着多种矛盾,主要体现在以下几点:

图像清晰度不够:已建的系统大多为模拟系统,图像分辨率最高达到D1格

式(40万像素),只能满足“看的见”需求却不能满足“看的清”需求;

系统扩容性差:视频监控的趋势逐步从模拟系统向数字化系统方向发展,很多平安城市项目建设当初未充分考虑系统扩容,后期建设不能充分整合现有资源,存在资源浪费的情况。

系统稳定性差:视频监控系统是一个涵盖了视频采集、传输、控制、存储、显示等方方面面的功能,每一个环节都需要采用大量的设备,系统集成化程度不高,系统的每个硬件设备都可能成为故障点,导致系统的稳定性下降。

重建设、轻维护:平安城市项目是一个大规模的视频监控系统,随着系统建成投入使用,系统的运营维护工作一般由人工完成,由于维护成本过高,一些损坏的设备未能得到及时修理或更新,在关键时刻系统宏机导致不能正常运行,未能达到“科技强警”目的。

因此,建设满足各个专业管理部门多级多领域城市管理的应用需求,建立一套统一的应急联动指挥与数字化城市管理监控系统平台,对各单位现有资源有效整合,达到资源共享,不仅节省大笔资金,而且可以大幅度提高监控系统的使用率和工作效率,实现整个城市的扁平化管理。在此基础上,利用市公安局现有的三台合一指挥系统、平安城市监控系统,扩建改造为涵盖各个职能部门的数字延安,是科学合理、安全可行的。针对当前平安城市视频监控系统的主要矛盾,后期系统的建设应着重从以下几方面考虑:

全网络化:数字监控远比模拟监控具有优势,平安城市从模拟走向数字一个必然趋势,由于部分区域网络基础建设的限制,当前视频监控系统建设过程中将存在模数并存的现象,这就要求系统的设计必须能够接入模拟信号同时可以有效兼容原有模拟系统。

高清化:高清能够提供更好的图像清晰度、更流畅的画面、更宽广的浏览画面、更精确的图像信息,特别是对于公安重大案件侦破、交通违法抓拍来说,高清图像更显得举足轻重。

高集成化:视频监控系统的后期维护在很大程度上将成为系统长期稳定运行的关键因素,每个硬件设备都将是隐藏的故障,采用集编码、传输、控制、显示于一体的设备,降低单位硬件数量,从而保障系统的稳定性。

智能化:传统的视频监控系统往往依靠人力,维护人员往往在一个监视屏同

时监控多个画面或随即抽取某一画面,造成部分监控点被漏看或被忽视;另外,维护人员存在一定的不稳定性、随意性和局限性,加上人的注意力有限,图像出现异常后,往往不能及时被发现。这就要求系统具有一定的智能视频分析功能,把人力从视频监控系统中大大解放出来,又能提高视频监控效率。

整合应用:平安城市有两大关键点,一是监控点的覆盖,二是应用,没有上层应用,平安城市就失去了应有的意义,这些应用包括调度指挥、GIS整合、视频报警、警视联动等等。当前已建平安城市各子系统仍属于独立工作,互补相连的状态,实现各子系统的整合应用将是今后建设的重点,也是平安城市的建设具有更深远的意义。

第五篇:办公自动化系统需求分析报告

办公自动化系统 需求规格说明书

1.引言 1.1 目标

开发网络办公系统的市场前景是广阔的。大型企业需要高层次的网络办公自动化,他们往往会选择大型的软件公司合作开发,所需的开发费用和维护费用也是非常高的。这些高额的费用并非大多数中小企业所能承受得起的。本系统就是为这些公司制定的。

1.2 参考文献

《软件工程导论》,张海藩,清华大学出版社。《实用软件工程》,郑人杰等,清华大学出版社。

2.总体描述

2.1 用户类和用户特性

本OA办公系统软件的最终用户是面向中大型企业的员工和相关管理人员一套软件,操作人员需要有一定的计算机操作基础,对于系统管理员不仅要有一定的计算机基础,还要求有一定的网络管理经验。

2.2 运行环境(Operation Environment, OE)OE-1:“办公自动化系统”的操作将通过如下的Web浏览器来完成:Microsoft Internet Explorer版本10.0和11.0,Netspcape Communication版本4.7和Netscape版本8和9。OE-2:“办公自动化系统”将运行在一个服务器中,该服务器运行当前由公司批准的Red Hat Linux版本和Apache HTTP Server。OE-3:“办公自动化系统”将允许用户通过公司内联网来访问,如果用户将被授权在公司的外部穿过防火墙来访问,那么用户也可以在家通过Internet来访问该系统。

2.4 设计和实现的约束条件(constriant)

CO-1:系统的设计、编码和维护文档将遵照Process Import Intranet Development Standard(Process Import公司内联网开发标准)版本1.3。CO-2:系统将采用公司标准的当期Oracle数据库引擎。CO-3:所有HTML代码将遵照HTML4.0版本。C0-4:所有脚本都用Perl语言来编写。

2.5 用户文档(User Documentation, UD)

UD-1:系统将提供一个分层的跨链接的HTML联机帮助系统,它描述并演示了所有系统功能。

UD-2:如果是一个新用户第一次使用该系统,系统可以根据用户的要求,提供一个联机帮助,这样用户可以使用静态教程菜单来具体实践一下如何使用。系统不会将采用这一模板的管理案例存储到数据库。

UD-3: 开发期限十一至十二周。

3.系统特性

3.1 员工名录管理

本系统会将员工的信息录入到系统数据库中。其中包括人员履历、转正申请、离职申请以及员工一些重大事情的记录。

3.2 部门管理 上级部门有权对下级部门进行管理,并查看该下级部门人员的信息,以及上级部门对下级部门发布任务、取消任务、撤销部门、创建部门。

3.3 综合邮件管理

管理员有权对已经超过规定时限的数据库中的邮件进行管理,如进行邮件的删除;对于一些已经删除的邮件进行恢复等。员工可以对自己写的邮件进行发送、修改、删除、保存操作;对收到的邮件进行保存、删除操作。

3.4 综合事务管理

综合事务管理包括行政管理、信息管理、人事管理、车辆管理进行全面的管理。

3.5 工作流管理

几乎所有的业务过程都是工作流,特别是办公公文审批流转处理。每一项工作以流程的形式,由发起者(如文件起草人)发起流程,经过本部门以及其他部门的处理(如签署、会签),最终到达流程的终点(如发出文件、归档入库)。

3.6 个人日程管理

个人日程管理中有工作日志、工作计划、消息提醒、通讯录。工作日志:基于网络的工作日志系统,可设为私有,限制,公共三类级别分别供自己,部门领导,全部人员查看。便于个人总结,便于上级检查工作,便于和同事分享工作经验,是知识管理挖掘隐性知识的一种手段;用户可以随意添加、删除、修改多个日志,通过翻阅日历查看任一天的日志也可通过日期,关键字等检索日志。工作计划:针对自己和领导下达的任务进行布置;布置的具体任务涉及时间、任务查看人、任务完成的标准、任务附件、提醒日期、汇报时限等内容。消息提醒:设置消息提醒功能每当用户登录系统时提示窗口。通讯录:记录联系人具体通讯信息,包括我的通讯录、公共联系人和内部通讯录三种类型。

3.7 内部消息服务

内部消息服务将消息在公司内部传递,管理员有权对消息进行添加、修改、删除操作。

3.8 文件档案管理

对现有档案进行管理,可以直接增加新的档案,并对档案实现添加、删除和分发查询、分类存储等操作。

3.9 云存储管理

云存储管理是对云数据库中内容进行存储、删除、备份、修改操作。

4.用例图

4.1 邮件管理用例图

4.2 个人日程安排

5.外部接口需求

5.1 用户界面(User Interfaces, UI)

在用户界面部分,根据需求分析的结果,用户需要一个用户友善界面。在界面设计上,应做到简单明了、易于操作,并且要注意到界面的布局,应突出的显示重要以及错误信息。外观上也要做到合理;合理化,考虑到用户多对Windows风格较熟悉,应尽量向这一方向靠拢。在设计语言上,已决定使用Delphi所提供的可视化组件,向Windows风格靠近。其中服务器程序界面要做到操作简单,易于管理。在设计上采用下拉式菜单方式,在出错显示上可调用Delphi库中错误提示函数。总的来说,系统的用户界面应做到可靠性、简单性、易学习和使用。

5.2 硬件接口(Hardware Interfaces, HI)

处理器型号及内存容量;

外存容量、联机或脱机、媒体及其存储格式。设备的型号及数量 数据通信设备的型号和数量 ④输入及输出设备的型号和数量 ⑤功能及其他专用硬件

5.3软件接口(Software Interfaces, SI)

服务器程序可使用Delphi提供的对SQL SERVER 的接口,进行对数据库的所有访问。服务器程序上可使用SQL SERVER对数据库的备份命令,以做到对数据的保存。在网络软件接口方面,使用一种无差错的传输协议,采用滑动窗口方式对数据进行网络传输及接受。

6.其他非功能性需求 6.1 性能(PErformance)需求

本项目软件性能要求如下:

告警信息从产生到显示出来的时延不应该大于15秒。配置信息的更新最大时延为24小时。性能监控数据时间间隔不超过15分钟。

④对本软件系统用户经常使用的90%操作响应时间小于20秒,对于极少使用的10%操作响应时间应不小于120秒。

⑤ 保证系统并发访问用户数>30。

⑥系统数据库容量应能够满足各功能模块的需要。能满足告警和性能原始数据、日志信息等半年的存储容量;告警统计和性能数据一年的存储容量。

6.2 安全性(SEcurity)需求

系统应该具有对系统自身的管理功能,应实现网管系统自身的完善的维护和管理,需提交标准安装程序。提供必要的操作维护手册及技术手册。当进行版本升级时,提供版本差异的详细说明。

7.其他需求

7.1 系统的封闭性:用户的封闭性较好,用户基本上在提示信息下输数据。7.2 系统的容错性:用户数错数据都有提示信息,具有较好的容错性能。7.3 可维护性:新功能的实现仅涉及局部。

下载系统需求分析报告word格式文档
下载系统需求分析报告.doc
将本文档下载到自己电脑,方便修改和收藏,请勿使用迅雷等下载。
点此处下载文档

文档为doc格式


声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎发送邮件至:645879355@qq.com 进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。

相关范文推荐

    图书管理系统需求分析报告

    图书管理系统 1引言 1. 1编写目的 本项目为图书管理系统;书写此文档是为了确定客户的真正需求,因此我们在可行性分析的基础上进一步了解、调查、明确用户对系统的综合要求、数......

    订单管理系统需求报告分析

    1、订单管理系统 1.1、系统总体介绍 1、采购基础数据功能包括:物料数据维护、订/交货方式维护、来源类别维护、采购员维护、采购系统维护。 2、采购计划管理功能包括:请购计划......

    酒店管理系统需求分析报告

    目录 酒店管理系统需求分析 ................................................................................................................... 1 1 2 引言..............

    图书管理系统需求分析报告

    目录 一.概述 1.编写目的 2.项目背景 3.定义 4.参考资料 5.开发环境 二.需求分析 1.问题提出 2.系统的业务功能分析 3.需完成的功能 三.系统需求说明 1.对功能的规定......

    教务管理系统需求分析报告[范文模版]

    教务管理系统需求分析报告 一、导言 现在是信息化的社会,传统的教务管理模式,已经不适应信息时代的要求,迫使人们起用新的管理方法来管理。 计算机技术的飞速发展,使各行各业在......

    图书馆管理系统需求分析报告

    图书馆管理系统需求分析报告 一、 概述 1、编写目的 在对系统计划阶段的确定的工作范围内进一步对目标对象和环境作细致、深入的调查分析。 2、项目背景 a.所建设开发软件系......

    银行排队系统需求分析报告

    银行排队系统需求分析报告 1. 引言 编写目的 随着时代的发展,信息技术在各服务行业中的重要作用得到充分体现,通过服务模式的信息化,可以极大提高服务质量,节约人力成本,提高工......

    图书馆管理系统需求分析报告

    图书馆管理系统需求分析报告 1.1编写目的 将计算机技术运用于图书信息管理,使图书管理更加方便、快捷,为用户提供最舒适最人性化的服务。 1.2项目背景 图书管理系统是各所......