1软件需求规格说明书

1软件需求规格说明书（共8篇）

篇1：1软件需求规格说明书

中 国 矿 业 大 学

China University of Mining and Technology

GIS软件需求规格说明

姓

名：

周 瑶

学

号：07122995 学

院：环测学院

班

级：地理信息系统12-1班

老师：张海荣老师

1．引言

1.1编写目的

由于高校教师带领学生去野外实习中，经常出现学生掉队、旷课、自行离队或走散等现象，为了学生的安全和实习的顺利进行，减轻教师传统的管理学生的方法的负担，急需一些有效措施来解决这些问题，帮助教师在野外实习期间充分了解每个学生的位置信息，进行有效管理，保障学生人员安全，实现安全有效的野外实习，并明确其中的经济效益。1.2GIS项目背景

项目由中国矿业大学团队开发。为了满足实际野外实习的需求，采取相关措施来解决野外实习中出现的问题，开发野外实习管理信息系统。1.3定义

GPS室外定位：全球定位系统

数据库SQL Server：由微软退出的关系型数据库管理系统，具有使用方便可 伸缩性好与相关软件集成程度高等优点。

服务器Tomcat：是一个免费的开放源代码的Web应用服务器，属于轻量级 应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用。1.4参考资料

项目经审核的计划任务书 项目开发计划 论文：

[1]李刚.GPS导航系统的工作原理，2012 [2]胡旭科.融合GPS与Wi-Fi的室内外无缝定位原型系统研制，2014 [3]曹科.基于智能手机的GPS定位技术的研究与实现，2006 [4]刘前刚.GPS定位算法，2009 书籍：

《Android应用开发揭秘》杨丰盛著 《Android优化技术详解》陈德春编著 《IOS开发指南》关东升编

《Tomcat与Java Web开发技术详解》电子工业出版社

《Tomcat权威指南》中国电力出版社

2．GIS项目概述

2.1 GIS项目目标、内容、现行系统的调查情况

项目目标主要是开发出一款手机APP，针对野外实习的场景，方便教师更好地管理学生，保障学生安全。

项目内容主要包括教师客户端通过读取学生客户端的数据，掌握学生的地理位置，方便野外实习管理。

现行系统调查情况如下：现行系统的主要功能和目标是满足高校教师带领学生外出实现的管理需求，确保学生的安全。2.2 GIS运行环境

软件为手机APP，运行在手机端，即现在主流的智能机。当用户把手机软件打开时，软件会默认读取用户的地址位置，并返回。即当学生打开手机软件或将手机软件运行在后台时，软件会自动读取学生的地理位置信息，并将信息返回给教师的客户端上。2.3条件与限制

GPS的室外定位精度约为5米左右，由于在室内是无法使用GPS定位的，所以该软件适用于户外定位；当在野外实习处于交通闭塞信号差的山区时，通信差，可能会导致手机接收不到信号，导致定位出现阻碍，学生的地理位置信息读取出现错误、地理信息返回给教师客户端出现故障等，这样一来，教师不能完全掌握学生的位置信息。

3．GIS数据描述 3.1 GIS静态数据 学生和教师的基本信息。3.2 GIS动态数据

输入数据：学生与教师的个人信息。输出数据：学生和教师的地理位置信息。3.3 GIS数据库描述

使用SQL Server数据库，数据类型分为基本数据和地理数据。3.4 GIS数据字典

数据流名：地理位置信息 简述：学生的地理位置信息 来源：学生 去向：教师

组成：学生学号+姓名+地理位置信息 数量流量：教师可随时查看

4．GIS功能需求 4.1功能划分 4.1.1流程图

4.1.2数据与功能的对应关系

数据是功能的基础，该软件功能的实现是依靠数据的。教师之所以能掌握学生的实时动态，是因为学生的客户端后台通过手机上的GPS读取学生的地理位置信息数据，将该数据实时传输给教师的客户端。4.2功能描述

（1）打开软件，进行注册，登录。教师用学校工号进行注册登录，学生用学校学号进行注册登录，登录后教师和学生分别有不同的界面，分别有教师和学生学校教务系统统计的基本个人信息，也可在此基础上完善个人信息。

（2）先介绍学生界面。学生界面的功能选择主要有：查看和完善个人基本信息、查看同伴的地理位置、查看自己的地理位置。软件系统默认读取用户的地理位置信息等。

（3）教师界面。教师先将学生的名册添加进入自己的系统中，也可手动输入添加。教师界面的功能选择主要有：查看和完善个人信息、查看学生所有信息、查看所有学生现时地理位置、查看学生一段时间内的路线、查看单个学生个人信息、查看单个学生现时地理位置、查看教师自己的地理位置等。（4）教师与学生均可查询自己在一定时间内走过的路线。

5．GIS性能需求 5.1数据精确度

GPS的室外定位精度约为5米左右，由于在室内是无法使用GPS定位的，所以该软件适用于户外定位；而在野外实习的过程中可能会去一些信号弱的山区，这样可能导致手机接收不到信号，导致定位出现阻碍，教师不能完全掌握学生的位置信息。5.2时间特性

相应时间较短，只需要在联网状态下，打开软件，会自动进行更新地理位置。5.3适应性

操作方式简单，运行环境是当下热门的智能机，系统是基于Android 4.0以上或者ISO系统，具有良好的兼容性当开发计划改变时具有良好的适应性。

6．GIS运行需求 6.1用户界面

屏幕格式设计为适合所有的手机屏幕 6.2硬件接口

开发环境为基于Windows 7操作系统下的PC。运行环境为当下流行的基于Android 4.0以上或者IOS的智能手机。6.3软件接口

开发环境为Windows 7 系统下的eclipse 的Android开发环境或者X-code的IOS开发环境，调用百度地图的API，数据库选用SQL Server，服务器选用Apache的tomcat。6.4故障处理

在软件发布前，进行大量全面的测试。

当出现严重故障时，应在第一时间内解决掉，要正对用户的描述来评估问题的大致问题，然后针对该问题进行修改；当出现一般故障时，需要尽快解决，不要任其发展演变成软件严重故障；当出现轻微故障时，在不影响总体使用的前提下，将故障原因记下，根据实际情况，灵活的解决问题。

7．质量保证

发布前采用软件测试，依次进行单元测试、集成测试、组装测试、确认测试、系统测试、验收测试、回归测试。客观的验证软件项目产品和工作是否遵循恰当的标准、步骤和需求等。并写清楚相关使用文档。

8．其他需求

软件的可使用性强，将用户信息加强安全保密性，教师和学生的信息加强了保密，并对地理位置数据也加强保密性，后期的可维护性强，可移植性强。

篇2：1软件需求规格说明书

文档组织与完整性

1.所有对其它需求的内部交叉引用是否正确？

2.需求为设计提供了充足的基础么？

3.是否所有需求的书写详细程度都是一致的、合适的？

4.是否包括了每个需求的实现优先级？

5.是否定义了所有与外部硬件、软件和通讯的接口？

6.是否定义了功能性需求内在的算法？

7.软件规格说明书是否包含了所有已知的业务需求？

8.是否记录了所有可能的错误条件所产生的系统行为？

9.对所有内部和外部接口的描述，是否都符合模板的要求，即包括来源、目的、输入、输出和激发条件？

正确性

10.是否没有需求间的冲突或重复的需求？

11.是否每个需求都是无二义性的？

12.是否每个需求的描述都是简洁、清晰的？

13.是否每个需求都可以用测试或同级评审来进行验证？

14.是否每个需求都在项目的范围内？

15.是否每个需求都没有内容或语法上的错误？

16.是否需求中必需的信息都没有遗漏？如果有的话，是否标记为“待决定”了？

17.在已知的约束条件下，是否可以实现所有的需求？

18.是否任一个特定的错误信息都具有唯一性和明确的意义？

质量属性

19.对所有性能目标都作了适当的说明么？

20.对所有安全和防护性的考虑作了适当的说明么？

21.对其它相关的质量属性目标是否明确地文档化和量化，且进行了可接受的权衡也被详细说明了？

可追溯性

22.每个需求的标识都是唯一和正确的么？

23.每个软件功能需求都可追溯到客户需求么？

特殊问题

24.是否所有需求都是名副其实的需求，而不是设计或实现方案？

篇3：1软件需求规格说明书

一、软件服务外包人才需求规格

目前, 软件服务外包企业需求的工作岗位多样, 主要包括软件开发工程师、软件测试工程师、项目管理工程师等, 这些岗位人才应具备以下技能和素质:

1、熟悉软件的开发流程及企业的工作流程。

2、在项目开发过程中, 注重工作经验的积累。

3、较强的外语能力以及对海外文化具备必要的了解。

4、具有职业道德意识及按照职业规范开展工作的习惯。

5、具有较强的法律意识和知识产权和信息安全保护意识。

6、良好的沟通表达能力和团队合作精神。

二、软件服务外包人才缺乏的原因

高等教育是服务外包人才培养的主要途径, 然而, 高等教育周期长、偏于理论、实践能力不足, 导致学生在学校所学的知识及形成的专业能力与用人单位的实际需要形成较大的差距, 造成用人单位无合适人才可用, 究其原因, 主要有如下几方面。

1、普适性教育问题

软件服务外包行业对于人力资源结构的需求呈现“橄榄球”形状, 对中间掌握专门技能的技术人才需求巨大, 但是, 当前各高校普遍采取的是一种普适性教育, 课程体系更注重对软件行业的全覆盖, 人才结构呈现“金字塔”形状, 即高端人才缺乏, 中间技术人才也相对不足, 而处于金字塔底端、对技术要求不高的低端人才数量充足。

2、教学实践问题

高校和企业由于体制和模式的不同, 高校的课程安排注重理论的学习, 实践性较少, 按照教学大纲规定培养人才, 到了企业, 还需要几个月的时间去适应和“补课”。

目前, 在已形成的校企合作中, 多数企业跟学校的合作只是停留在实习基地的提供、安排学生实习等方面, 不够深入。导致专业教育和生产实践联系不够紧密, 产学研合作的目标与短期行为相互矛盾。

3、专业缺位的问题

目前, 我国软件从业人员3/4以上来自于全国各大高校和科研机构的计算机科学与技术、软件工程、信息管理等计算机与软件相关专业, 不同专业方向的学生在同一人才培养模式下接受教育, 软件人才的差异性、梯度性不强, 人才技能单一, 远远不能满足软件服务外包企业多样化的工作需求, 导致一边是大量找不着工作的毕业生, 一边是众多找不到合适人才的软件企业的现象。

三、构建良好的软件服务外包人才培养模式

软件服务外包业务属知识密集型产业, 需要有素质较全面、符合实际需求的软件专业人才。对于为其服务的相关专业, 必须根据软件服务外包特点和人才需求来采用新的人才培养模式, 这就要求高校和软件外包企业发挥各自的优势, 共同培养软件外包人才。

1、校企共同参与

良性校企合作的软件服务外包人才培养模式是基于软件服务外包产业发展目标导向型的高校和行业企业共同培养软件人才的双赢驱动方式, 核心是解决学校育人和企业用人的问题, 从合作机制和运行模式两个核心层面促使高校和软件企业充分实现优势互补全方位的合作。

一方面, 高校必须破除落后的、封闭的办学观念, 主动与企业联系, 根据企业生产任务的特点和企业岗位需求增设或变更课程, 形成符合市场经济和现代高等教育发展要求的办学理念, 按企业需求设置专业、共同制定培养计划和课程体系、联合教材开发、联合建设实训基地、软件类教师和软件服务外包专家的互聘、确保高校的教学实施和企业生产经营的无缝对接。

另一方面, 企业也要认识到高校在科研和人才综合能力、人才素质培养上的优势, 从企业发展的长远利益出发, 尽心尽力为培养企业“准员工”而努力, 让高校在技术升级、人才储备、提高竞争力方面为企业源源不断地输入动力。

2、落实实训环节

培养软件外包服务人才职业能力的有效手段就是实训, 强化在校期间的动手实践能力训练, 接受企业提供的真实的项目、真实的目标管理、真实的绩效考核实训, 是培养合格“实用型”人才不可或缺的程序。学生实训期间, 学校安排专职教师做好学生的管理和校企之间沟通与协调, 保证实训有序进行;企业用实训成绩替换教学计划中相应实践性教学环节的成绩。校企共同管理学生, 在提高学生的专业技能, 文化素养的同时, 提升学生的职业素养和职业道德, 打造“一专多能”的软件服务外包人才。

3、开设服务外包行业语言课程

目前, 发达国家是外包业务的主要发包国, 其中美国约占全球市场份额的三分之二, 欧盟和日本占三分之一, 要想了解国际上软件技术的发展趋势, 掌握最新的研究成果, 或者与国外同行进行技术交流, 就必须掌握共通的语言。

这种外语培训有别于传统的公共英语, 更加注重模拟学生在外国软件企业中会遇到的各种工作场景, 加强学生在软件专业领域和商务领域中的听、说、读、写的能力。可能的话, 专业课程在讲解时也可用双语教学。这样, 一方面可以缓解社会上“专业+语言”的综合性软件人才奇缺的现状, 另一方面也拓展了高校人才的就业渠道, 提升了人才的就业层次。

四、结论

依靠高等院校的教育资源和企业的一线资源, 针对企业用人需求, 把产业人才需求与高等职业教育相衔接, 在加强学生专业知识积累的同时, 提高学生服务外包的职业技能, 解决软件服务外包人才供给的失衡问题, 可以为我国软件外包快速地发展打好坚实的基础。

参考文献

[1]王秀平:《产业转型背景下的高职软件人才培养模式的探索与实践》, 《计算机教育》, 2010 (6) 。

[2]卢建平:《服务外包转变经济增长方式的绿色引擎》, 《开发研究》, 2010 (1) :22-26。

[3]惠学东:《高职教育与服务外包产业无缝连接的扁平化视野》, 《辽宁高职学报》, 2009 (9) :15-16。

篇4：需求规格说明书编写心得

以下是本人总结的《需求规格说明书》编写心得，由于人个水平有限，欢迎大家补充。

1.需求编写依据

合同、招投标文件、调研记录以及项目经理提供的已确定的需求规格说明书（内部）等。

2.主动与项目经理的沟通

反复的沟通，才能深入把握项目的实际需求，获得更多的资讯和资料。

3.项目背景

1)阐述目前遇到了什么样的问题，并充分说明该问题的严重性和紧迫性，若能提供一些数据或运用一些真实、典型的案例，不仅可以充分的说明该问题同时还能表明你对该项目的了解；

2)如何解决该问题；

3)为什么要提出这样一个系统；

4)最后扼要概述该系统的长远战略意义。

这样从逻辑上层层递进，不仅可以让自己的思维严谨起来，也使自己写出来的东西变得专业些。

4.系统总体概述

简单介绍系统的基本情况、特点、展示功能框架及阐述其优势。主要围绕是什么，有什么样的功能特点，能起到什么样的作用。

5.术语与用词

列出与系统有关的在文档中一定会提到的专业术语，没有提到的术语则不需要列出，否则会给读者带来一定的负担。还有要统一表达方式，如“修改”，“编辑”，“用户”，“员工”等等，以避免引发歧义。

另外，需求文档不需要华丽的词语，以客观事实的原则，切忌掺和主观思想，注意用词准确，精简表达其业务就可以。同时还需注意几点：等等、很多等抽象词尽量不使用；我认为、以为等主观词语切忌出现，尽量避免口语化。

6.描述模块

在编写模块时，通常包括模块描述、重要业务及流程、功能需求定义、业务数据字典、原型界面图等。

 模块描述

要明确指出建设了哪些功能，帮助用户实现什么、目标、基础等

 重要业务及流程

对该业务进行认真分析，得出该功能事项的有效规则，以激发该功能。可以通过画流程图，快速帮助阅读者理解，但一定要注意质量，避免产生误导。

 功能需求定义

需求中每个功能点力求写的清楚，一个需求文档下来能清楚统计出功能有多少个，并指明什么用户使用。一般情况下，要先写简单的，权限少的角色。此文档是设计的基础，是系统验收的依据。

 数据字典

写出实体类的中英文属性名称、类型和说明（如是否为表主键）。

 重要界面原型图

篇5：返利APP需求规格说明书

1.1 登录

1.1.1 功能说明

使用帐号（手机号码）和密码登录

1.1.2 注意事项

1.判断账号和密码是否合法，合法的话，直接登录；不合法的话给出对应提示

1.2 注册

1.2.1 功能说明

用户：使用手机号、验证码、邀请码（选填）、密码注册 一级代理：后台确定身份，在大后台设置账号和密码 二级代理：一级代理在其个人中心中进行绑定

1.2.2 注意事项

1：用户注册页面：推荐码可以进行选填，也可以获取系统默认的验证码，一旦输入有效的推荐码则上下级关系绑定

2：一级代理注册：超级管理员为其添加登录账号和密码，并且可以进行修改

3：二级代理注册：二级代理需要一级代理在个人中心处添加，添加成功则代表着关系绑定

4：每个手机号只可以注册一个身份，如果需要切换身份，则需要重新注册账号，同时之前的账号逻辑和账号信息保持不变

5：注册之后需要绑定支付宝，绑定的支付宝在个人中心可以编辑修改

1.3 忘记密码

1.3.1 功能说明

使用手机号、验证码、密码找回密码

1.3.2 注意事项

1：使用手机号和验证码找回密码，无论哪种身份，在APP里面都可以找到密码

1.4 首页

1.4.1 功能说明

首页包含搜索框、banner图、推荐商品

1.4.2 注意事项

安徽木子林科技有限公司 返利APP需求规格说明书

1：搜索框：输入商品名称中的关键字，搜索全平台商品

2：banner图片：可以设置跳转链接，点击进行跳转，同时不限制张数 3：推荐商品：首页推荐商品样式，首页可以利用不同的页面布局或者排版展示推荐商品，可以只是部分商品推荐，也可以是每个分类推荐同时推荐该分类下的个别商品，具体请在原型图阶段确定

4：推荐商品：点击进入到对应的列表页面或者商品详情页面

1.5 商品

1.5.1 功能说明

商品页面主要是展示各个商品列表，包括商品分类和商品详情

1.5.2 注意事项

1：商品分类、商品列表和商品详情中的字段都是从淘宝中获取，关于页面商品分类和商品列表需要重新出，商品详情页面可以使用原生（和淘宝的详情页面一模一样）也可以另外出图（可以自定义布局和样式）

2：点击商品分类可以对商品进行筛选

3：点击商品列表可以查看商品详情，在商品详情页面可以加入购物车、分享、收藏、立即购买

1.6 积分商城

1.6.1 功能说明

在积分商城页面展示后台添加的所有的积分商城商品，用户可以利用账户中的积分进行购买，购买之后按照正常流程进行发货

1.6.2 注意事项

1：积分商城商品列表展示信息包括：商品的缩略图、商品积分价格、商品名称，点击可以查看详情

1.7 购物车

1.7.1 功能说明

购物车内显示用户选中的商品列表

1.7.2 注意事项

1：购物车页面：已加购物车的商品列表，根据加入购物车的时间排列，时间越近越靠前。列表中显示商品缩略图、商品名称、用户选中的商品规格（尺码、分类）、商品价格（根据会员的身份显示，会员显示会员价，代销身份也显示会员价）、购买数量，购买数量可直接加/减，如下图：

2：购物车页面：用户可以直接勾选列表中的商品，在底部合计栏显示所选中商品的价格总和，结算栏显示选中列表商品的个数。点击结算，进入确认订单页面

3：购物车页面-编辑：点击编辑，可删除选中的商品

4：用户将商品加入购物车后，如果后台此时重新编辑了商品信息，则购物车中的信息也要更新

（1）如果用户选中的商品规格被更改，则显示商品状态为已失效，点击商品进入商品详情页面，显示已更新的数据，用户可以选择其他规格商品重新加入购物车，但购物车中仍保留之前的失效商品数据，用户清空失效商品后，失效商安徽木子林科技有限公司 返利APP需求规格说明书 品不再显示

（2）如果已加入购物车的商品在后台被删除，则此商品在购物车中显示的商品状态为已失效，仍显示在购物车列表中；在用户端商品列表中消失，也不再显示在后台商品列表中，只存在数据库中

（3）如果购物车里的商品在后台被下架，则该商品在购物车中的状态为已失效，在用户端商品列表中消失，但仍显示在后台普通商品管理的列表中

（4）已失效商品，点击商品名称/缩略图进入商品详情页面，只更改了规格的商品可以显示商品详情，可以选择其他规格加入购物车/直接购买；已经被删除/下架的商品提示“该商品已被下架或删除”

（5）已失效商品不显示购买数量

（6）点击清空失效商品将删除所有失效商品

1.8 个人中心

1.8.1 功能说明

个人中心包括：个人信息、积分收入、我的推广、我的订单、我的收藏、支付宝设置

1.8.2 注意事项 1.个人信息：

1）个人信息包括个人头像、推荐码、姓名/昵称、性别、手机号，在个人中心首页，点击头像/昵称进入到个人信息编辑页面

（1）个人头像：可编辑，从相册中选择/拍照，图片大小不能超过2M（2）推荐码：系统自动生成，不可更改（3）姓名/昵称：可以更改

（4）性别：可编辑，选择男或者女

（5）手机号：点击手机号进入到手机号修改页面，利用手机号和验证码进行更改，更改成功之后本次不重新登录，下次登录账号使用新手机号登录

（6）点击保存，保存信息同时跳转到个人中心 2.积分收入

1）包括：总收入、即将到账、已到账、可提现和返利订单 2）返利订单包括：即将到账订单、已到账订单、无效订单

3）积分收入来源：作为一级或者二级代理，下级的用户在APP中购买商品，确认收货之后可以获得一定积分，或者本人在APP内购买商品确认收货之后可以获得一定积分

4）积分提现：每个月的20号，用户可以提交提现申请，申请提现的支付宝账号是在注册或者在个人中心编辑设置的，后台收到申请，审核通过之后会把对应的返利打到用户的支付宝账户

3.我的订单：

1）点击我的订单进入我的订单主页面

2）我的订单：订单排列顺序按照订单创建时间排列，最新订单显示在首位

3）我的订单（具体的按照淘宝提供的接口为准）：显示订单编号、订单状态、商品列表（商品缩略图、商品名称、商品价格、商品规格、购买数量）、订单内商品数量、合计金额、订单操作等

安徽木子林科技有限公司 返利APP需求规格说明书 4）订单状态（具体的按照淘宝提供的接口为准）：

待付款、待发货、待收货、待评价、取消订单、退款订单、退货订单 4.我的推广：

1）如果用户身份是一级代理，则该用户可以在我的推广中添加二级代理，添加成功的二级代理有登录账号和登录密码，同时有一个唯一的推荐码

2）在我的推广中，可以查看到我的一级好友和我的二级好友 5.我的提现：

1）提现明细：显示出申请时间、申请的金额、申请的状态、提现账号、提现流水号，点击账号可以查看以弹窗显示 6.收藏宝贝：

1）收藏的商品列表，按时间排列，最新的收藏在首位 2）收藏列表中的商品，可以删除，删除的方式后期确定 3）收藏的商品不显示规格参数

4）收藏的商品被删除/下架，收藏页面显示商品状态为已失效，点击商品名称提示“该商品已被下架或删除”

5）点击清空失效商品将清空所有已失效商品 7.支付宝设置

1）注册时绑定的支付宝账号可以编辑修改 8．系统设置

包括版本检测、退出登录

1）版本检测：默认显示当前版本，点击可以查看是否是最新版本 2）退出登录：点击进入到商城首页

安徽木子林科技有限公司 返利APP需求规格说明书 2 后台

2.1 登录

2.1.1 功能说明 登录使用内置帐号密码登录

2.1.2 注意事项

1.判断账号是否存在，不存在的话文字提示用户“当前账号不存在，请重新输入”

2.判断账号是否合法，不合法的话给出对应提示

3.判断账号密码的一致性，不一致或者有错的话给出提示

2.2 控制台

2.2.1 功能说明 展示统计数据

2.2.2 注意事项

1.控制台：包括总注册人员、一级代理人员、二级代理人员、用户人数等

2.3 用户管理

2.3.1 功能说明

包括一级代理添加、用户管理

2.3.2 注意事项

1：一级代理的添加：添加的主要内容是一级代理的登录账号、登录密码、支付宝信息

2：用户管理：列表显示用户基本信息，并且可以查看对应用户的上下级，比如，用户A的父级，以及用户A的二级和三级

3：用户管理：在用户列表中可以对用户账号删除、禁用并且可以对大代理进行编辑

2.4 积分商城商品管理

2.4.1 功能说明

积分商城商品管理在后台进行积分商城商品管理处添加

2.4.2 注意事项 1.积分商城商品管理：

1）显示商品总数、上架个数、下架个数，显示商品列表，内容包括商品名称、商品价格、上下架、操作，如下图：

2）查询条件：商品名称

3）上下架：点击上架，商品将在用户端-商品区域对应的分类中显示；对已上架的商品点击下架，商品将不在用户端-商品区域对应的分类中显示，只显示在后台

5）操作：添加/编辑/删除：

2.5 订单管理

2.5.1 功能说明

安徽木子林科技有限公司 返利APP需求规格说明书 包括：订单管理（具体的展示数据以淘宝接口为准）

2.5.2 注意事项

1.显示内容包括：总订单、待支付订单、代发货订单、已发货订单、已收货订单、已评价订单、退款订单、已完成订单、退货订单

2.查询订单条件：时间段、订单号、订单状态等

3.订单内容包括：订单编号、下单时间、购买账号、商品名称、规格、单个商品价格、购买数量、订单状态、付款总金额、收货人信息

2.6 财务管理

2.6.1 功能说明

包括：财务管理、提现管理、分销体系设置

2.6.2 注意事项

1.财务管理：收入统计：总收入、已提现等 1）收入统计

可以显示出平台内所有的收入订单，并且可以通过查询条件查询 2.提现管理

显示APP用户提交到所有提现申请，申请的金额可以查看到对应的订单以及订单状态，后台给出审核，如果同意申请，则直接打款至支付宝账号，否则直接拒绝

3：分销体系设置

主要是设置每个等级用户获得返利比例

2.7 广告图管理

2.7.1 功能说明

目前设置在APP首页，如果特殊要求请提出

2.7.2 注意事项

1.banner图显示在用户端首页

3.banner图列表：展示：banner图片、链接、名称和操作等

2.8 系统设置

2.8.1 功能说明

包括：启动图管理、服务协议管理、账号设置

2.8.2 注意事项 1.启动图管理：

1）启动图为用户打开APP，未进入首页时出现的图片 2）上传启动图图片，图片尺寸：480×800，图片类型：png, gif, jpg, jpeg，图片的质量不能大于2M

4、服务协议

服务协议：富文本编辑框 操作：保存 6.账号设置

安徽木子林科技有限公司 返利APP需求规格说明书 1）超级管理员账号为内置账号，只能修改密码 2）帐号列表如下图： 3）操作：添加/编辑/删除

（1）添加/编辑：添加/编辑管理员名称、帐号，输入密码、确认密码，点击确定即可添加/编辑成功

安徽木子林科技有限公司

篇6：宿舍管理系统需求规格说明书

1.引言 1.1编写目的

本学生宿舍分配系统以公寓房间、入住学生为基础信息源，可以对房间和床位分配，可以使教务处、学生处、保卫处、公寓管理中心、财务处等学校职能部门及学校学院领导随时获得全方位的公寓管理信息，实现信息共享，提高工作效率。

本文档从用户、功能、性能、运行环境等各方面对系统进行了分析，以确保在系统开发过程中，确定好具体目标，使工作能有条不紊的进行，提高工作效率。

1.2背景

很多学校特别是中等及高等院校中，学生在校住宿的情况极其普遍。随着高校的扩招，需要住宿的学生人数和学生公寓楼房越来越多，宿舍管理人员的需求量也相应地增加。许多高校后勤实施社会化改革，学生住宿条件得到了很大改善，宿舍安排上打破了原来按专业班级强制集中住宿的限制，可供学生选择的余地也越来越大，相关部门对公寓管理的要求越来越高，导致公寓管理的难度越来越大，原来的手工管理已经无法适应，需要用信息化手段来实现。因此，开发一个学生宿舍分配软件是十分必要的，希望能够为广大教师、校院领导、宿舍管理员和学生提供便利，加强学生住宿管理、规范高校公寓日常工作、提高公寓管理效能的有效工具。

1.3 定义

用例图(Use Case)：是指由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图。呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

顺序图：是将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。

类图(Class diagram)：是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性信息。

状态图(Statechart Diagram)：是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的。

活动图（activity diagram）：是阐明了业务用例实现的工作流程。工作流程通常包括一个基本工作流程和一个或多个备选工作流程。工作流程的结构使用活动图来进行说明。

协作图/通信图(Communication Diagram)：而“协作”作为一个结构事物用于表达静态结构和动态行为的概念组合，表达不同事物相互协作完成一个复杂功能。

1.4参考资料

（1）殷建民 主编，《软件系统分析与设计》，中国水利水电出版社，2008（2）《学生宿舍基本需求》（3）《2012级软件系统分析与设计实验指导书（16学时宿舍分配系统）》

2．任务概述

2.1 目标

本学生宿舍分配系统以公寓房间、入住学生为基础信息源，可以对房间和床位分配，可以使教务处、学生处、保卫处、公寓管理中心、财务处等学校职能部门及学校学院领导随时获得全方位的公寓管理信息，实现信息共享

2.2 用户特点

学生：若要住宿需提交住宿申请，然后等待分配。如有特殊要求，务必专门说明。一旦得到批准通知，可以查询个人宿舍安排。住宿后若有特殊原因，可以申请调整宿舍或床位，但依然要经过审核、批准。一旦调换了宿舍，其所使用的设备也要随之变更记录。

教师：分为班主任和辅导员。辅导员负责查看、初审学生提交的住宿申请，对基本符合要求的，转交给宿舍负责人。班主任和辅导员可以随时查看、了解所负责班级住宿学生的情况。

宿舍负责人：负责对住宿申请进行综合审查，通过的则以班为单位分配床位。可以随时查看和了解宿舍的基本情况、所有住宿情况和设备使用情况，对特殊情况及时进行统计，并报送相关领导。学生一旦毕业或提出退宿，其宿舍和床位会立即变空，等待重新分配使用。

宿舍管理员：负责宿舍设备情况的记录（购入登记、各建宿舍配置、损坏和修理登记、报废登记）、每日查房结果记录、学生晚归记录、宿舍具体情况管理（新房间登记、房间撤消、格局调整）。

校院领导：可以随时查看、了解学校和学院宿舍的详细信息、学生住宿状况和宿舍管理员的基本情况以及每日查房的情况。

2.3 假定与约束

经费限制：由于是学习之作，资金的不足限制了本软件的研发。

开发期限;在时间方面，只能在课余时间完成本软件，对时间的安排需做到合理，恰当才能很好的完成本工程。

3.需求分析建模

3.1功能需求

3.1.1系统需求描述

本学生宿舍分配系统以公寓房间、入住学生为基础信息源，可以对房间和床位分配，可以使教务处、学生处、保卫处、公寓管理中心、财务处等学校职能部门及学校学院领导随时获得全方位的公寓管理信息，实现信息共享。

基本流程图如下:

宿舍学生提交住宿申请返回不同意返回同意结束N查看住宿申请初审Y判断宿舍负责人是否同意NYN复审负宿人责舍教师查看申请Y分配床位领校导院管宿员理舍

3.1.2 总体功能分析

各类角色的大体功能分析：

学生:填写申请表、提交住宿申请、查看申请结果、申请宿舍调整 辅导员:查看学生住宿情况、查看住宿申请、初审、返回申请结果给学生 班主任：查看本班学生住宿情况

宿舍负责人：复审、分配床位、查看住宿信息、宿舍住退更新、特殊情况报送领导 宿舍管理员:宿舍查房记录、宿舍设备情况记录、晚归记录、宿舍集体情况 校院领导：查看宿舍详细信息、查看住宿情况、宿舍管理员情况、每日查房情况 具体用例图如下： 填写申请表查看学生住宿情况提交住宿申请查看住宿申请初审查看申请结果学生辅导员返回申请结果给学生班主任申请宿舍调整复审宿舍查房记录查看宿舍详细信息分配床位宿舍设备情况记录查看住宿情况查看住宿信息晚归记录院校领导宿舍管理员情况宿舍管理员宿舍负责人宿舍住退更新特殊情况报送领导宿舍集体情况每日查房情况3.1.3 功能模块分析(详述 学生申请)☆由学生申请住宿用例：当学生登录后，进入申请界面，填写申请报告，出现两种情况，即填写正确或错误/部分错误，对应的成功提交申请或返回重新填写申请...构建活动图、协作图、顺序图等来完成功能的具体分析。

活动图：

学生登陆进入申请界面填写申请表还有未审核的申请填写正确保存新申请表填写错误返回主界面重新填写提交申请等待申请结果回到主界面

状态图：

学生申请这一事件对应的状态：首先是要进行申请表的填写预准备工作，即新建一张空白申请表，进行填写，完成后进行提交，即等同于进入等待审核状态；等待后台审核完成后，学生进行查看可以找到‘审核通过’‘不通过’以及‘不通过（部分不符合要求）’三种状态，一次审核通过后二审，产生‘批准’‘不批准’两种状态，批准通过，进入入住状态。

新建批准保存已入住审核通过不批准提交审核不通过部分通过顺序图: 根据流程图和活动图，可以建立学生申请的工作顺序图，首先是登陆到首页>进入申请界面，申请表的填写与是否可以成功提交由提交控制检测并返回可申请/不可申请/有错重新填写，提交成功则学生等待来自辅导员以及宿舍管理员的的审核结果以及宿舍分配结果。

学生首页申请界面提交控制辅导员宿舍负责人登陆登陆成功退出不可以申请可以申请填写申请提交给辅导员有错重新填写反馈同意请求复审同意驳回不同意 协作图：

学生功能界面申请表审核控制辅导员返回不同意返回同意及宿舍分配 3.2性能需求

3.2.1精度

在进行向数据库文件提取数据时，要求数据记录定位准确，在往数据库文件数组中添加数据（如申请表，住宿信息等）时，要求输入准确学生姓名，身份证，学号，班级，宿舍号等，按需求设定字符数。

3.2.2时间特性要求

（1）查询类页面响应时间<=3s（2）更新处理时间，如新建、提交等最长时间不超过2s。（3）数据的转换和传送时间，如远程数据传输不超过5s。

3.3数据需求

3.3.1 输入输出数据要求

1）宿舍的详细数据、学生住宿的情况以及宿管人员的具体数据要完整保管，且一旦发生变化，必须及时变更记录。

2）上述数据要能够导出到excel文件中，或从excel文件导入。3）分配床位时可以采取二种方法：

● 第1是按照一定的算法进行自动分配，● 第2是针对特殊要求进行手工分配 4）学生住宿需要记录的内容主要包括：

学号、姓名、所属学院、所属系、宿舍房间号、床铺号、柜子号、入住时间、联系电话等。5）每个房间需要记录的内容主要包括：

宿舍房间号、面积、可容纳人数、目前空床数、6）为简化宿舍分配过程中学生信息的重复录入，保证数据的一致性和统一性，最好可利用现行的学籍管理系统中的信息。

3.3.2数据分析模型(类图)

people-memberName-memberName学生-memberName-memberName职工-memberName-memberName教师-memberName-memberName院校领导-memberName-memberName宿舍负责人-memberName宿舍管理员-memberName-memberName-memberName辅导员-memberName班主任-memberName-memberName-memberNamec各种记录学生住宿信息班级-memberName-memberName-memberName-memberName-memberName-memberName住宿申请-memberName-memberName住宿登记表-memberName-memberName床位-memberName宿舍-memberName-memberName设备-memberName-memberName-memberName

类图分析：用户主要分为学生和职工两大类，学生类和职工类继承于people类，而教师类、领导类、宿舍负责人类和宿舍管理员类继承于职工类，辅导员和班主任类继承于教师类；学生与辅导员、班级、住宿登记表、床位、宿舍、住宿申请等都是关联关系。

3.4故障处理要求

正常使用时不应出错，对于用户的输入错误应给出适当的改正提示。若运行时遇到不可恢复的系统错误，也必须保证数据库完好无损，可以通过日志来了解故障现象、发生时间。

3.5其他专门要求

（1）进度需求：系统开发的阶段进度要求。（2）运行环境需求：平台、体系结构、设备要求。

（3）培训需求：无实体培训，系统配备《用户使用手册》，提供多媒体教学光盘。

4.运行环境规定 4.1设备

服务器

PC机（建议配置：操作系统 windows 2000/XP/Vista CPU PentiumⅣ以上 内存 128M以上 硬盘空间 100M以上）DVD光驱，打印机等。

4.2支持软件

软件运行基于windows平台上的2000，NT，XP,Vista等。数据库：MySQL 4.3接口

篇7：机票预订系统需求规格说明书

1． 引言

1.1 编写目的本机票预定系统在可行性研究的基础上，是为了进一步明确机票预订系统的软件需求，以便安排项目规划和进度，组织软件开发与测试，撰写本文档。

本文档供项目经理、设计人员、开发人员参考。

1.2 项目背景

开发软件名称：机票预订系统

项目任务提出者：国际教育学院电子商务专业

项目开发者：无敌小分队

用户：航空公司

实现软件单位：国际教育学院电子商务专业

1.3 参考资料

《信息系统分析与设计（第三版）》邝孔武，王晓敏 编著清华大学出版社

《UML基础与Rose建模教程》蔡敏 徐慧慧 黄炳强 编著机票预订系统可行性研究报告无敌小分队

2． 任务概述

2.1 目标

当旅客交付了预订金后，系统打印出取票通知和帐单给旅客，旅客在飞

机起飞前一天凭取票通知和帐单交款取票，系统核对无误即打印出机票给旅客。此外航空公司为随时掌握各个航班飞机的乘载情况，需要定期进行查询统计，以便适当调整。

2.2 假定和约束

在分析系统功能时要考虑有关证件的合法性验证（如身份证、取票通知和交款发票）等。

3． 需求规定

3.1 对功能的规定

1． 航空公司工作人员登录及注销

要求合法的管理员才可以登录系统，防止系统被无关人员动用，使用字符串匹配对用户名和密码进行判断。在不使用时进行注销，下次使用时需要重新登陆，由于目标客户的层次较低，建议用输入检测确保输入准确无误。

2． 机票信息输入和查询

在系统中，要求可以输入每日航班次数。可以通过航班号、目的地、起飞日期、起飞地点查询航班，输出该次航班的起飞时间和所剩票

数和票的价格等信息。

3． 订票，取票和退票

把预定机票的旅客信息（姓名、性别、工作单位、身份证号码（护照号码）、旅行时间、旅行始发地和目的地，航班舱位要求等）输入

到系统中，系统为旅客安排航班。当旅客交付了预订金后，系统打

印出取票通知和帐单给旅客。，旅客在飞机起飞前一天凭取票通知和

帐单交款取票，系统对旅客有关证件合法性（如身份证、取票通知

和交款发票）等进行验证，系统核对无误即打印出机票给旅客。对

于已去机票应在未售出机票中减去。对于以下情况要求退票者，给

予50%金额退款：（1）旅客延误取票时间；（2）旅客临时更改航班

处理；（3）因私人原因需要退票。对于因特殊情况下（如天气不适

合飞机起降、飞机延误超过30分钟）等给予全额退票。对于退订机

票要在未售出机票中重新体现。

3.2 对性能的规定

为了确保系统能够稳定、安全、可靠的运行，机票预定系统应该满足一下性能要求：

3.2.1 系统处理的准确性和及时性

系统处理的准确性和及时性是系统的必要性能。在系统设计和

开发过程中，要充分考虑系统当前和将来可能承受的工作量，使系

统的处理能力和响应时间能够满足航空公司对信息处理的需求。在系统开发过程中，必须采用一定的方法保证系统的准确性。由于机

票预定系统查询功能对于整个系统的功能和性能完成举足轻重。作

为系统的很多数据来源，机票数量和时间有影响决策活动，其准确

性很大程度上决定机票系统的成败。在系统开发过程中，必须采取

一定的方法保证系统的准确性。

3.2.2 系统的开放性和可扩展性

机票预订系统在开发过程中，应充分考虑以后的可扩充性。要

求系统提供足够的手段进行功能的调整和扩充。

3.2.3系统的易用性和易维护性

机票预订系统直接面对使用人员的，而使用人员往往对计算机

并不是非常熟悉，这就要求系统能够提供良好的用户接口，易用的人机交互界面。

3.2.4 系统的标准性

系统在设计开发使用过程中要涉及到很多计算机硬件、软件。

所有这些都要符合主流的行业标准。同时，在自主开发本系统时，要进行良好的设计工作，制定行之有效的软件工程规范，保护代码的易读性，可操作性和可移植性。

3.2.5 系统的先进性

目前计算机系统的技术发展相当快，作为机票预订系统工程，应该保证系统是先进的，在系统的生命周期尽量做到系统的先进，充分完成信息处理的要求而不至于落后。这一方面通过系统的开放

性和可扩展性，不断改善系统的功能完成。另一方面，在系统设计

和开发过程中，应在考虑成本的基础上尽量采用当前主流并先进且

有良好发展前途的产品。

3.3 输入输出要求

各个旅行社把预定机票的旅客信息（姓名、性别、工作单位、身份证

号码（护照号码）、旅行时间、旅行始发地和目的地，航班舱位要求等）输入到系统中，系统为旅客安排航班。当旅客交付了预订金后，系统打印出取票通知和帐单给旅客，旅客在飞机起飞前一天凭取票通知和帐单交款取票，系统核对无误即打印出机票给旅客。

3.4 数据管理能力的要求

后台数据库需实时更新机票预订情况，以供航空公司随时掌握各个航班飞机的乘载情况，定期进行查询统计，以便适当调整。

3.5 故障处理

本系统能自动修复故障，保证回退，可以在固定时间对系统进行备份操作，而且本系统有日志记录记载故障原因，便于调查取证。当数据操作失败时，与之相关的一些操作可以取消。如果在操作过程中出现意外，只需要退出系统在重新登陆即可消除故障。

3.6 运行环境规定

系统软件：windows xp/vista/7

数据库管理系统：SQL SERVER 2005

硬件要求：奔四 1.6GHz512M RAM10G HD

篇8：图书馆管理系统需求规格说明书

图书馆管理系统需求规格说明书

1．导言 1.1编写目的

图书管理信息系统的前阶段，对本系统的需求做了详细的阐述，并提出了这份软件需求规格说明书。

此需求规格说明书对图书管理信息系统软件做了全面细致的用户需求分析，明确所要开发的软件应具有的数据库、功能、性能等，使系统分析人员及软件开发人员都能清楚地了解用户的需求，并在此基础上进一步提出概要设计说明书和完成后续设计与开发工作。本说明书的预期读者为用户、需求分析人员、代码编写人员、测试人员、用户文档编写者、项目管理人员。

在下一段的设计中，程序设计员可参考此需求分析规格说明书，在需求分析说明书对图书馆管理信息系统所做的模块结构设计的基础上进行详细设计。在以后的软件测试以及软件维护阶段也可参考此说明书，以便于了解在概要设计过程中所完成的各模块设计结构，或在修改或发现错误时找出在本阶段的不足或错误。1.2项目背景

由于图书馆书籍多，查找、增加、借阅、归还极为不便，要浪费许多的人力、脑力、物力。图书的管理不当会严重导致图书馆书籍的遗失等问题。于是我们希望能找到解决的方法。

为了解决以上的问题，让图书馆能够有效的管理图书馆书籍，有效的利用软件的便捷，保护好书籍，促进图书馆管理的信息化和规范化。我们多方听取意见、分组讨论、查阅资料，进而了解图书馆管理的流程，开发出一套适合于图书馆书籍多而复杂的管理系统。1.3缩写说明

系统：若未特别指出，统指本图书信息管理系统。SQL：Structured Query Language（结构化查询语言）。

1.4术语定义SQL SERVER：系统服务器所使用的数据库管理系统（DBMS）。

SQL：一种用于访问查询数据库的语言。主键：数据库表中与其他表主键关联的域。外部主键：数据库表中的关联域。值互不相同。

需求：用户解决问题或达到目标所需的条件或功能；系统或系统部件要满足合同、标准，规范或其它正式规定文档所需具有的条件或权能。

软件需求规格说明书

1.5参考资料

《软件工程实务》罗先文、徐军，重庆大学出版社，2005年3月

《UML 用例驱动对象建模》Doug Rosenberg、Kendall Scott著，徐海、周靖、陈华伟译，清华大学出版社，2003年5月

《UML 系统分析设计应用案例》 冀振燕，人民邮电出版社，2003年6月 《NET语言程序设计》 陈炜，人民邮电出版社，2005年1月 《SQL Server数据库》吕凤顺，清华大学出版社，2006年9月 《网页设计与制作》于巧娥、何金奎，北京大学出版社，2006年1月 2．任务概述 2.1系统定义

实现图书管理信息系统的基本需求。让图书馆能够有效的管理图书的查询、借阅、增加、归还等操作，保护好文件，促进图书管理的信息化、规范化，实现图书馆的智能化管理，以提高图书馆的的工作效率。2.2应用环境

硬件环境：一台586 以上的微机及兼容内存16MB（最好32MB内存）

软件环境：windows 98 以上的操作系统 ；Office 2000应用软件 操作系统：Microsoft Windows 2000 Advanced Server 支持环境：IIS 5.0 数 据 库：Microsoft SQL Server 2000 2.3假定条件与限制

本图书管理信息系统软件是应用于中小型的图书馆。在功能上还不是很健全，还需要进一步完善，还可进一步实现与E-Mail和Internet电话连接起来，成为网络图书管理信息系统软件。3．需求规定 3.1对功能的规定

(1)图书信息表(book)：数据结构（自动编号ID,图书编号（BookID），书号（ISBN），价格（Price），类别名（Kind），图书名（BookName），出版社（Publish），借出日期（BorrowDate），是否借出（IsBorrowed））

(2)借出图书信息表（bookoff）：数据结构(自动编号ID,借书证号（LoanNum），姓名（Name），图书编号（BookID），书名（BookName），价格（Price），类别（Kind），出版社（Publish），借出日期（BorowDate）)

软件需求规格说明书

(3)管理员信息表（Librarian）：数据结构（自动编号ID,名称（LibName），密码（Password））

(4)读者信息表（personal）：数据结构（自动编号ID,读者编号（ReaderNum），借书证号（BorrowNum），姓名（Name），班级(Class)，部门(Depart)，职称(Tittle)，罚款（Fine））

(5)图书类型信息表(type)： 数据结构（自动编号ID，类别名(Kind)，借出天数(BorrowedDay)）3.2对性能的定义 3.2.1 精度

（1）要按照严格的数据格式输入，否则系统不给予响应进行处理。

（2）查询时要保证查全率，所有相应域包含查询关键字的记录都应能查到。（3）添加记录时必须写入正确的记录字段。3.2.2时间特性要求

一般操作的响应时间应在1~2秒内，对软磁盘和打印机等的操作也应在可接受的时间内完成。3.2.3灵活性说明

满足图书馆使用的需求（记录量控制在100项内）；对前面提到的运行环境要求不应存在困难。3.3输入输出的要求

输入数据：菜单选项，查找关键字，新建记录项。

输出数据：由查询关键字确定的数据库记录集合。（1）系统管理

1)用户登录：用于管理员或读者登录，进行图书馆书籍及资料的查询。2)用户注册：用于用户及管理员的注册，当数据库中有了用户资料之后此用户才有权限登录系统。

3)修改密码:只限于已经注册的用户或管理员的操作。以便于个人登录的识别。

（2）图书管理

1)图书的分类：主要是适合于管理员的操作，对图书进行分类以便读者查询、借阅书籍。

2)查询书籍：主要给借阅者使用，是为了方便借阅者查询自己想要的图书，

软件需求规格说明书

借阅者输入图书的相关关键字，按下按钮即可查询到于此相关的书籍。

3)图书的添加：是给管理员用的功能，如有新增书籍，可通过这项功能，在数据库中添加一项纪录，让读者预留、借阅等。

4)图书的删除：是给管理员用的功能，当图书馆没有此书籍时，在数据库中删除此图书的信息。（3）借书证管理

1)借书证的添加:仅图书管理员可以使用的功能，在数据库中添加读者的借书证信息，方便读者借阅图书。

2)借书证信息的修改：修改读者的图书证信息记录

3)借书证的删除：删除读者的图书证信息记录

4)借书证的借书上限和逾期罚金： 根据等级或其他信息规定该读者最多能借阅几本书籍，归还书籍时如果超过期限，规定超过一天罚多少钱（4）借书和还书操作管理

1)借书操作：用户借书后在借出图书信息表中添加用户信息及书籍信息等 2)还书操作：用户归还书籍后在表中删除借出信息便于他人借阅。3)续借操作：当用户图书到期后，如需再借阅则可使用此功能。（5）打印报表

1)打印单条图书记录:主要适用于一般浏览者和一般用户。他们只能打印在他们的权限和级别范围内所能查看的图书馆信息资料。

2)打印全部档案:是为管理员设置的，管理员可以根据需要设置打印。也可以让档案以报表或其它形式生成文本文件或HTML文件输出。打印操作人员的信息只限管理员使用。

3.4数据管理能力的需求（五个基本数据表单）

图书信息表(book)借出图书信息表（bookoff）图书编号 BookID 借书证号 BorrowNum 书号 ISBN 图书编号 BookID 价格 Price 借出日期 BorowDate 类别名 Kind 是否借出 IsBorrowed 图书名 BookName 出版社 Publish 数量 Amount 作者 Author

读者信息表（personal）管理员信息表（Librarian）姓名 ReaderName 名称 LibName

软件需求规格说明书

密码 Password 密码 Password 班级 Class 部门 Depart 图书类型信息表(type)职称 Tittle 图书编号 BookID 借书证号 BorrowNum 类别名 Kind 罚款 Fine 借出天数 BorrowedDay 3.5故障处理要求

正常使用时不应出错，若运行时遇到不可恢复的系统错误，也必须保证数据库完好无损。调试中遇到的问题及解决的方案：

（1）遇到跳出“数据库已经关闭”提示信息阻止程序运行时：可以查看一下进行此项操作时，操作的表是否已经被关闭了或者是在没有关闭此表的情况下又一次运用打开语句打开此表。

（2）关于空记录带来的麻烦：有些空记录往往会使程序无法运行。此时你可用“if not isnull”语句先判断一下是否为空记录，再操作。（3）有些运行错误也可用如下语句排除 On Error GoTo Erropoint

Erropoint :

Msgbox Err.Descripton

Exit sub

或用On Error resume Ｎext 等语句进行处理。3.6其他要求

（1）系统的功能实现情况: 用户可在本系统下实现各种用户要求的功能（2）系统的安全性: 对于系统的重要数据都有密码保护，具有一定的安全性（3）系统的容错性: 用户输错数据都有提示信息，具有较好的容错性能。（4）系统的封闭性: 用户的封闭性较好，用户基本上在提示信息下输数据 4．运行环境规定 4.1设备

本软件不需要特定的硬件或硬件接口进行支撑；486以上PC机均可运行此软件。4.2支持软件

运行于Windows95及更高版本具有WIN32 API的操作系统之上。开发软件：Dreamweaver、SQL Server、Microsoft web developer 4.3双方签字

软件需求规格说明书