第一篇:博客系统需求分析报告
博客管理系统
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,、写一个允许用户一次只删除一条员工记录的触发器。
第二篇:个人博客系统需求分析
[个人博客系统]
需求说明书
[V1.0(版本号)]
拟 制 人朱金国审 核 人潘欣批 准 人潘欣
[二零一零年五月九日]
需求说明书
1.引言
1.1编写的目的a.为明确软件需求、安排项目规划与进度、组织软件开发与测试,撰写本文档。
b.本文档供项目经理、设计人员、开发人员参考。
1.2背景
a.系统名称:个人博客系统;
b.用户:广大普通用户包括高级知识分子;
C.市场背景:全球上网的10亿人中,有1亿人正通过博客改变他们的生活,不同国家、地区、年龄的人群通过博客建立了一个充满个性的交流空间,人们通过自己的文字传递着不同的信息。作为一个新兴、发展、甚至迅速膨胀的网络空间,博客向我们透露着这个信息传递和情感交流的平台将影响接下来的几代人。
1.3定义
Blog:博客
1.4参考资料
《软件文档国家标准》
《计算机软件开发文档编写指南》
2.任务概述
2.1目标
本系统所实现的功能将是利用程序的智能算法,利用各种数据,将各个Blog的最新内容整合到一起。
(1)建立查询网站,支持并发访问
(2)可提供面向所有客户的基于HTML和RSS等格式的实用信息
(3)提高数据读取效率
(4)建立多个发布点,规避网络风险,保证数据传输稳定
(5)能随时根据站点数量和内容的变化实现更新和扩展
(6)发布的信息能够鼓励Blog作者经常更新自己的站点,能够产生实际的宣传效果
2.2.运行模式:
面向用户,在浏览器中直接返回相关数据,包括最新日志和站点信息。
本系统被期望布署为一个数据发布系统和多个数据镜像发布系统,要求有较高可靠性和稳定性。
2.3 用户的特点
管理员:可以对普通用户进行授权,对会员信息进行部分更改,主要包括用户角色调
整,版主调整,删除会员等;
注册用户:可以加好友,关注好友,转载博文,上传图片,留言等;
游客:可以进行匿名留言等。
3.需求规定
3.1系统功能模块
1.会员注册
新会员注册,提供会员信息,检验新会员信息的有效性;
2.会员登陆
输入用户名和密码,检验用户信息;
3.会员管理
管理员由程序员设置一个,管理员可以对会员信息进行部分更改,主要包括用户角色调整,版主调整,删除会员等;
4.Blog板块管理
用户可以添加,删除,调整博客板块;
5.留言管理
用户可以对所有帖子进行转移,删除等操作;
6.留言回复
注册用户可以回复好友;
7.博文发表
注册用户可以在板块中发表新博文;
8.博文搜索
用户或者游客可以提供关键字查找博主的相关博文,注册用户可以查看自己发表的博文;
9.博友
注册用户可以添加好友,便于查看好友的博文和评论好友博文,以及给好友发送消息,留言等
10.聊天室
注册用户可以在聊天室和Blog成员会话
聊天室的名称,人数限制等由管理员设置,聊天室可以由管理员创建,删除。
13.意见反馈
用户可以给管理员联系,并欢迎提成各种意见和建议;
3.2系统操作
1.会员注册
填写个人信息---信息检验---保存会员信息
2.会员登陆
输入用户名和密码---信息验证
3.会员管理
持有管理员角色---角色调整或分配版主或删除用户
4.博客板块管理
注册用户角色---添加,删除,调整,隐藏板块
5.博文发表
注册用户---选择板块发表主题---主题持久化
6.留言回复
注册用户---针对主题发表回复---回复持久化
7.留言管理
持有版主角色---转移,删除等操作
8.博文搜索
注册用户---按检索条件返回相关博文
9.好友
注册用户---添加好友用户名---验证信息---添加成功
3.3 对性能的规定
3.3.1精度
输入数据除了非法字符均可。
3.3.2时间特性要求
无具体要求(或者一天24小时)。
3.3.3灵活性
当系统遇到偶然或者非人为的故障时,本系统将自动保存未完成的任务。
4.运行环境规定
4.1设备
Win98以上操作系统
内存:128M以上
硬盘:20G以上
(因为本系统对硬件要求不高,所以以上数据仅供参考)
4.2支持软件
大部分浏览器均可;
装了flash播放器
4.3接口
第三篇:系统需求分析报告
系统需求分析报告
目录
目录.............................................................................................................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 页
第四篇:儿童博客网站需求分析报告
儿童博客网站需求分析报告
通过中国互联网络发展状况统计报告,发现网民对博客的需求增长迅速,同比增长超过10%,相比对网络聊天室以及个人主页空间的需求要高近5%。显示出了网民对博客的极度追捧。
博客永远是共享与分享精神的体现
儿童博客网站是一款以静、与细腻的宝贝博客,网站鲜明的色调,可以充分的展示出儿童博客的风格,记录下宝宝成长过程中的点点滴滴,此儿童博客网站主要是为妈妈们提供交流、分享的一个平台。
博客的用处:
1、作为网络个人日记
2、个人展示自己某个方面的空间
3、网络交友的地方
4、学习交流的地方
系统软件要求与选型
具体要求:
1)功能强的数据库管理系统,以对信息进行有效的管理
2)支持数据库管理系统的操作系统
3)丰富的程序设计语言
4)灵活的网络通讯软件,为以后联网提供软件保证
5)数据管理支持软件
6)丰富的应用软件
个人博客网页:
1.首页:点此标签可以回到刚进入博客的界面。
2.成长历程:点此标签进入日志网页,在此网页中我们不但可以显示自己以前所写的日志,也可以发表新的日志,同样博友也可以对你的日志进行评论。
3.宝贝相册:点此标签进入相册网页,在此网页中可以上传自己的照片,也可以对自己的相册进行编辑。
4.童声童语:点此标签进入音乐网页,在此网页中我们可以上传自己喜欢的音乐,同样也可以将他们设成博客的背景音乐,是博客丰富化。而博友也可以对我们上传的歌曲进行评论。
5.给我留言:点此标签进入留言网页,在此页面中我们可以看到博友给我们的留言信息,我们同样也可以回复他们。
6.宝贝资料:点此标签进入个人信息网页,这个网页中有关于我们的大部分信息。
第五篇:办公自动化系统需求分析报告
办公自动化系统 需求规格说明书
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 可维护性:新功能的实现仅涉及局部。