网关软件需求文档
目录
1. 引言3
1.1编写目的 (3)
1.2文档约定 (3)
1.3产品范围 (3)
1.4参考文献 (3)
2. 综合描述 4
2.1产品的状况 (4)
2.2产品的功能 (4)
2.3用户类和特性 (4)
2.4运行环境 (4)
2.5设计和实现上的限制 (5)
2.6假设和约束(依赖) (5)
3. 外部接口需求5
3.1用户界面 ............................................................................................ 错误！未定义书签。
3.2硬件接口 (6)
3.3软件接口 (6)
3.4通讯接口 (6)
4. 系统功能需求7
4.1用户权限需求 (7)
4.2网络需求 (7)
4.2.1 网络设备的分类 (7)
4.2.2 采用的网络协议 (7)
4.2.3 获取信息的前提条件 (7)
4.2.4 获取信息的手段 (7)
4.2.5 获取的信息内容 (7)
4.2.6 获取的信息内容的存储方式 (8)
4.2.7 获取的信息内容的显示手段 (8)
4.2.8 获取信息的频率 (8)
4.3操作系统需求 (9)
4.3.1 操作系统分类 (9)
4.3.2 获取系统信息的前提条件 (9)
4.3.3 获取信息的手段 (9)
4.3.4 获取的信息内容分类 (9)
4.3.5 获取的信息内容的存储方式 (9)
4.3.6 获取的信息内容的显示手段 (9)
4.3.7 获取信息的频率 (9)
4.4数据库系统需求 (9)
4.4.1 数据库软件名称 (9)
4.4.2 数据库软件运行的操作系统 (10)
4.4.3 获取信息的方式 (10)
4.4.4 获取数据库的相关监控内容 (10)
4.4.5 获取的信息内容的存储方式 (10)
4.4.6 获取的信息内容的显示手段 (10)
4.4.7 获取信息的频率 (10)
4.5应用软件需求 (10)
4.5.1 应用软件名称 (10)
4.5.2 应用软件运行的环境 (10)
4.5.3 是否需要应用软件进行额外的开发，以支持网关软件的要求 (10)
4.5.4 支持的获取的方式或手段 (10)
4.5.5 获取的内容 (10)
4.5.6 获取的信息内容的存储方式 (12)
4.5.7 获取的信息内容的显示手段 (12)
4.5.8 获取信息的频率 (12)
4.6特殊设备需求 (12)
4.6.1 特殊设备的分类 (12)
4.6.2 获取信息的前提 (12)
4.6.3 获取信息的方式 (12)
4.6.4 获取的内容 (12)
4.6.5 获取的信息内容的存储方式 (12)
4.6.6 获取的信息内容的显示手段 (12)
4.6.7 获取信息的频率 (12)
4.7预警需求 (12)
4.7.1 预警的种类 (12)
4.7.2 预警等级分类 (13)
4.7.3 预警传送的方式 (13)
4.7.4 预警的阀值设定 (13)
4.7.5 预警信息的存储 (13)
4.8统计需求 (13)
4.8.1 报表的分类 (13)
4.8.2 形成的报表列表 (13)
5. 其它非功能需求13
5.1性能需求 (13)
5.2安全措施需求 (14)
5.3安全性需求 (14)
5.4软件质量属性 (14)
5.5业务规则 (14)
6. 数据定义 14
7. 分析模型 15
8. 待定问题列表15
1. 引言
网络管理监控软件的网络部分的功能及设计说明，供网络管理软件调用。
1.1 编写目的
本模块为联网中心网络管理监控件网络管理部分，本模块为实现网络管理监控软件的各网管功能提供接口及实现，通过对接口的规范，从而使网络管理软件通过调用即可实现各类网络监控。
1.2 文档约定
●正文风格：正文内容采用正常宋体5号字，小标题采用小四号黑体字，编号采用阿
拉伯数字和小圆点来表示；
●提示方式：暂无提示；
●重要符号：重要符号会以红色下划线显示；编号以“.”来分隔
1.3 产品范围
该模块为网关软件的获取网络设备方面的信息提供数据，以供设备管理人员随时监控网络设备性能以及各软件系统运行情况。
1.4 参考文献
●C#网络应用案例导航，黄承安，2003年02月第一版，超星电子图书；
●SNMP协议入门，作者：IT动力源，来源：华为3Com，更新时间：2004.11.26，网
址：https://www.doczj.com/doc/a1260151.html,/Article/Hardware_Area/Doc_hw_3com/200411/3271.html；
2. 综合描述
作用范围：由联网中心的服务器连接的局域网内。
2.1 产品的状况
网络管理软件产品的背景和起源：
●属于联网中心开发的自主型的产品。
●本软件系统与联网中心其他服务系统及应用系统存在基本的相互关系，通过局域网
管理软件能够把联网中心大部分应用系统有效管理起来，包括软硬件设备，及各类信息数据都能得到有效的监控。
2.2 产品的功能
产品功能包括：
2.2.1 整体网络拓朴功能；
2.2.2 远程主机监控功能；
2.2.3 数据库性能监测功能；
2.2.4 故障报警功能；
2.2.5 业务数据监测功能；
2.2.6 系统设置功能；
2.2.7 流量统计分析功能；
2.2.8 有效防止部分病毒功能；
2.2.9 设备系统信息获取功能。
2.3 用户类和特性
本软件系统由联网中心使用，但需要得到联网中心其他软件系统客户的配合，因为需要通过网络协议及接口管理和维护局域网内各客户的数据及计算机设备。
2.4 运行环境
本软件的运行环境，包括：
●赛扬2.4G CPU，512M内存；
●操作系统和版本：Windows XP\2003\2000；
●支撑环境(例如：数据库等)和版本：Oralce、SQL-Server；
●其它与该软件有关的软件组件：.net FrameWork1.1；
●与该软件共存的应用程序：联网中心的其他类软件。
2.5 设计和实现上的限制
设计实现上的限制：
●必须使用的特定技术、工具、编程语言和数据库：C#、Visual Studio2003、Oralce、
SQL-Server；（因为目前对这些工具比较熟）
●要求遵循的开发规范和标准：要遵循ASN.1的编码标准；（要使用SNMP的指令获
取MIB的信息就必须遵循ASN.1的编码标准）
●硬件的限制：必须保证局域网的网络联通；（如果局域网都不能通的话，我们的系
统也就检测不到任何一台主机，也就没有任何意义）
●数据转换格式标淮的限制（在SNMP协议中，发送数据包的时候，需要把标识符转
换成十六进制，因为在网络中传送的都是二进制信息，相比十进制，十六进制和二
进制转换更方便一些）。
2.6 假设和约束(依赖)
列举出对软件产品需求分析报告中，影响需求陈述的假设因素(与己知因素相对立)。如果这些假设因素不正确、不一致或者被修改，就会使软件产品开发项目受到影响。这些假设的因素可能包括：
●将会使用一些免费的网络工具：
Ping 工具：负责检测网络是否畅通；
Trace Route工具：路由跟踪工具，对路由的结构进行跟踪，并返回相应信息；
FTP工具：对局域网内的上传上下载进行管理等
●假定DBA管理员对Oracle非常熟练、假定系统管理员对网络各项协议有一些了解；
●有关本软件运行环境的一些问题：假定我们能够自己搭建一个测试用的局域网，并
假定测试用的局域网和真实的局域网性能一样；
此外，确定本软件开发项目对外部约束因素所存在的依赖。有关的约束包括：
●人员约束：假定局域网内受控设备的主体都同意我们的控制，其操作人员给予配合；
●设备约束：受控局域网的总节点由我们全权控制，其受控设备均属于这个局域网，
并且由当前总节点路由下传。
3. 外部接口需求
本软件系统需要跟联网中心其他软件系统连接，以方便维护客户数据和系统。
包括：售票系统、报表系统、结算系统、企业ERP业务、网上订票。本软件系统将获取这些系统的部分数据，包括：
售票系统：应用软件的版本信息、今日计划班次数、今日实际班次数、今日最大运量、今日出票量、今日检票量、目前班次计划的日期、执行计划的人员信息、执行日期、当前售票系统的客户端数、当前检票系统的客户端数、当天退票量；
报表系统：需要监测的数据包括报表的数量及名称、中间数据转换是否成功、是否人工
转换、转换人员、转换时间、当前连接报表服务器的IP地址、查看人员；
结算系统：当前从售票系统转入结算系统的信息（截止日期、结算信息、执行人、执行时间）、目前结算的周期、参与结算的单位数、参与结算的车辆数、当前已结算的结算单数、尚未结算的结算单数、失效的结算单数；
企业ERP系统：留一个接口作为以后扩展用。
网上订票系统：网站的注册会员数、日最大访问量、日平均访问量、当前在线人数、当日在线订票量、当日在线购票量、当日在线交易成功数、当日在线交易失败数、当日在线交易成功率。
3.1 硬件接口
本产品与系统硬件接口包括：
●支持的硬件类型：路由器、带地址的交换机、主机；
●软件和硬件之间交流的数据最主要是通过网际传输的PDU包，PDU包包括了局域
网内各硬件设备之间传输的协议及数据，数据包括硬件本身信息、运行信息及各软
件系统、进程的运行信息；
●使用的通讯协议：TCP\IP协议、UDP协议、SNMP协议、ICMP协议；
3.2 软件接口
外部组件包括：
●操作系统：Windows XP\2000\2003、Linux；
●数据库：Oracle（目前仅使用Oracle）；
●工具：Ping 工具、Trace Route、FTP工具；
●集成的商业组件：.net FrameWork1.1、Tomat服务程序、Oracle服务程序、SNMP
服务程序、异地售票服务、FTP服务等；
3.3 通讯接口
描述与软件产品所使用的通讯功能相关的需求，包括：
●电子邮件：因为需要使用自动发送电子邮件，所以需要支持SMTP协议；
电子邮件是在预警时候使用的，发送格式为：
XXX：（接收邮件的用户名）
现（设备名称）发生（故障内容），请你尽快处理解决。
设备名称和故障内容由我们的软件系统获取。
●WEB浏览器：服务器端采用IIS服务器，客户端使用IE浏览器进行访问；
●网络通讯标准或者协议：TCP/IP、UDP、SNMP、ICMP、SMTP协议；
4. 系统功能需求
相关的详细功能需求
4.1 用户权限需求
详细描述使用该系统的各个用户的分类及可以访问的资源等信息
4.1.1 权限模块设置
1. 网络连接模块：包括IP地址、MAC地址、网络流量的查询监控；
2. 服务器运行模块：包括CPU、硬盘、内存、系统运行时间；
3. 关键服务程序模块：Oracle服务，Tomcat服务，IIS服务，异地售票服务，双机服务，短信订票服务，网上订票服务；
4. 路由访问设置模块：通过路由的进出流量、地址转换列表、端口信息；
5. 数据库关键信息模块：表空间、连接数、进程数、当前游标数、归档文件、日志文件、控制文件、数据文件；
6. 关键业务模块：售票系统，结算系统，报表系统，大小屏接口数据，语音系统接口数据等；
7. 数据库系统表模块：数据库进程数、进程名称、数据库会话数、会话对象、数据库表空间及文件路径（已使用，未使用，使用百分比）、数据库的对象名的大小及状态（对象名包括表、存储过程、包、函数、索引、序列等，失效状态）、监控表空间的I/O 比例、表和索引的存储检查、日志文件的大小与路径、作业进程的状态（Job）下次执行时间，执行的频率；
8. 用户管理模块：负责用户的增加，角色设置。
4.1.2 角色管理
1. 普通管理员：具有对网络连接模块、服务器运行模块、关键服务程序模块的权限；
2. 系统管理员：具有对网络连接模块、服务器运行模块、关键服务程序模块、路由访问设置模块、数据库关键信息模块、关键业务模块、用户管理模块的权限；
3. DBA管理员：具有对网络连接模块、服务器运行模块、关键服务程序模块、路由访问设置模块、数据库关键信息模块、关键业务模块、数据库系统表模块的权限。
4.1.3 用户设置
4.2 网络需求
针对不同的路由器、服务器等网络设备分别进行如下内容的描述。同时描述针对不同的前提条件，能够获取不同的信息内容.
4.2.1 网络设备的分类：路由器、带地址的交换机、PC电脑；
4.2.2 采用的网络协议：SNMP协议、TCP\IP协议
4.2.3 获取信息的前提条件：网路通畅及各协议已经安装完的前提下（包括SNMP协议）。
4.2.4 获取信息的手段：通过SNMP协议发送接收MIB包，再解析MIB包。
4.2.5 获取的信息内容
1. 详细流量分析
2. 通讯端口信息
3. 网络是否畅通
4. IP地址绑定
5. 远程截屏
6. PC进程清单
8. 设备类型名称
9. 设备正常运行时间
10. PC安装文件清单
11. 应用程序使用控制
12. 远程登录
13. 设备的CPU、内存
14. 网络慢的原因
15. 监测伪造的IP
16. 监测整体网宽占用率
17. 监测每个节点网络带宽利用率
18. 网络数据包大小分布
19. 安全漏洞检测
20. 查看TCP数据流
21. IP的物理位置
22. 根据域名获取IP
23. 数据包解码
24. 网络流量利用率
4.2.6 获取的信息内容的存储方式
存储方式分为两种：
1. 日志方式存储：故障内信息采取日志方式存储
2. 数据库存储：需要一直保存及分析的数据采取数据库存储
4.2.7 获取的信息内容的显示手段
显示方式分为：
1. 报表方式显示：这种显示方式是所有信息通用的显示方式。
2. 柱形图方式显示：是历史流量使用的显示方式。
3. 曲线图显示：分析流量数据时使用。
4. 拓朴图显示：最主要是对局域网的网络结构进行描述。
4.2.8 获取信息的频率
获取信息的频率根据实时设置，默认为5分钟轮循一次，时间单位为分钟。
4.3 操作系统需求
按照不同的操作系统分别进行以下内容的描述。同时描述针对不同的前提条件，能够获取的信息内容
4.3.1 操作系统分类：Windows、Linux；
4.3.2 获取系统信息的前提条件：网络必须通畅，并且受控设备需要从服务器所管理的路由器连接出去；
当网络不畅通的时候，本软件处于无效状态；
如果需要控制的设备不是从服务器管理的路由连接的，本系统将搜索不到此设备。4.3.3 获取信息的手段：
1. 通过下载的工具获取；
2. 通过自己编写SNMP的操作类获取。
4.3.4 获取的信息内容分类：
1. 操作系统版本
2. 运行时间
3. 当前运行进程
4. 当前用户
5. 标识
6. 用户状态
7. 联网信息
8. CPU使用率
9. 内存使用率
10. 总数（名柄数、线程数、进程数）
11. 物理内存（总数、可用数、系统缓存）
12. 认可用量（总数、限制、峰值）
13. 核心内存（总数、分页数、未分页）
4.3.5 获取的信息内容的存储方式：根据用户设置，采取两种存储方式
1. 数据库表格存储方式
2. 日志存储方式
4.3.6 获取的信息内容的显示手段
1. 报表显示方式：根据设置显示需要的字段
2. 柱形图显示：最主要是针对性能分类信息类显示
3. 曲线图显示：针对不同时段类的信息进行比较显示
4.3.7 获取信息的频率
获取信息的频率根据用户需要进行调节，最小单位为分钟，建议不要使用太频繁，而额外增加系统负担及网络负担，每小时一次较佳。意外情况可手动进行捕获。
4.4 数据库系统需求
获取不同的数据库的运行状态等信息
数据库软件名称：Oracle、SQL-Server、DB2、MySQL；
4.4.1 数据库软件运行的操作系统：Windows、Linux；
4.4.2 获取信息的方式
1. Oracle的数据可以通过Oracle专业工具获得；
2. 可以通过截取传送的数据包进行解协获取。
4.4.3 获取数据库的相关监控内容
1. 数据库进程
2. 数据库连接数（会话）
3. 数据库文件的大小及路径
4. 表空间大小及使用率、剩余空间
5. 日志文件的大小及路径
6. 当前锁的信息
7. 当前会滚段信息
8. 当前Job的状态
9. 数据库对象名称及状态
10. 数据库分区状态
4.4.4 获取的信息内容的存储方式
使用数据库存储
4.4.5 获取的信息内容的显示手段
显示手段采用表格方式显示，需要显示的字段可根据用户设置进行显示和隐藏。
4.4.6 获取信息的频率
获取信息的频率建议不要太高，避免造成数据库性能的下降，每天一次比较合适。
4.5 应用软件需求
不同的应用软件，获取的信息的方式不一样，能够获取的信息也不一样。
4.5.1 应用软件名称：
1. 售票系统
2. 报表系统
3. 结算系统
4. 网上订票
4.5.2 应用软件运行的环境
1. 售票系统为Windows下的C/S程序，其中数据库为Linux下面的Oracle；
2. 报表系统为Windows下的C/S程序，其中数据库为Linux下面的Oracle；
3. 结算系统为Windows下的C/S程序，其中数据库为Linux下面的Oracle；
4. 网上订票为Windows的B/S程序，服务器为IIS，数据库为Linux下面的Oracle。
4.5.3 是否需要应用软件进行额外的开发，以支持网关软件的要求
正常情况下不需要考虑应用软件开发，因为相关信息都从数据库中获取，但如果对一些意外的数据需要作记录的话需要在应用软件中设置意外情况发送标志给网关软件。
4.5.4 支持的获取的方式或手段
获取数据需要知道数据库的用户名和密码，通过专业的数据库工具进行获取。
4.5.5 获取的内容
1. 售票系统：
应用软件的版本信息
今日计划班次数
今日实际班次数
今日最大运量
今日出票量
今日检票量
目前班次计划的日期
执行计划的人员信息
执行日期
当前售票系统的客户端数
当前检票系统的客户端数
当天退票量；
2. 报表系统
需要监测的数据包括报表的数量及名称
中间数据转换是否成功
是否人工转换
转换人员
转换时间
当前连接报表服务器的IP地址
查看人员；
3. 结算系统
当前从售票系统转入结算系统的信息：截止日期、结算信息、执行人、执行时间目前结算的周期
参与结算的单位数
参与结算的车辆数
当前已结算的结算单数
尚未结算的结算单数
失效的结算单数；
4. 网上订票
网站的注册会员数
日最大访问量
日平均访问量
当前在线人数
当日在线订票量
当日在线购票量
当日在线交易成功数
当日在线交易失败数
当日在线交易成功率。
4.5.6 获取的信息内容的存储方式：采用数据库存储
4.5.7 获取的信息内容的显示手段
1. 某一时间的采取表格显示
2. 某一段时间的采取图表方式显示
4.5.8 获取信息的频率
频率不宜太频繁，避免增加数据库的负担，建议一天一次，这样可以对数据进行比较。
4.6 特殊设备需求
4.6.1 特殊设备的分类：双机热备份系统、集群系统
4.6.2 获取信息的前提：设备均在网络内，并且具有可访问的IP
4.6.3 获取信息的方式：通过网络协议进行访问
4.6.4 获取的内容：
1. 主机运行状态（IP地址，数据库状态、操作系统状态）
2. 备机运行状态（IP地址，数据库状态、操作系统状态）
3. 集群服务器状态：各服务器的运行状态
4.6.5 获取的信息内容的存储方式
当运行正常时采取数据库记录，发生异常同时保存在本地以及发送警报标志，这样避免网络故障异常造成的无法准备监测设备。
4.6.6 获取的信息内容的显示手段：使用表格显示方案。
4.6.7 获取信息的频率：当设备处于运行比较稳定的状态下，可一天一次，如果有一些异常可根据需要进行实时设置，以解决异常问题。
4.7 预警需求
4.7.1 预警的种类：
硬件预警：指CPU利用率、内存使用率，剩余空间、硬盘使用率
软件预警：设置的服务程序是否正在运行，例如：Oracle服务程序，SNMP服务程序、FTP服务，异地售票服务，Tomcat服务等。
网络预警：网络故障报警主要是监测到网络连通时，能否通过这个网络设备，若不能通过网络设备则显示该网络设备存在故障。同时也监测一些通过网络设备的数据包，其中包括数据包的大小及数量，当这些数据包超过一定的值后，同样也显示报警状态。
数据库报警：主要显示在数据库中的关键的值达到了预先设定的报警的值，这些报警的值包括：数据库关键进程状态、数据库连接数、表空间使用率、日志文件大小等，当这些值达到一定的值后，就会产生报警信号，通过不同的方式通知系统管理员。同时在界面上也有相应的显示。
4.7.2 预警等级分类：可以由用户设置，系统默认设置三类：灾难性报警（指网络瘫痪或者服务器瘫痪类故障报警）、紧急报警（服务器重启或者关键服务程序中止类故障）、一般预警（性能问题、流量过大问题）。
4.7.3 预警传送的方式：方式分为三种，Email方式，手机短信方式，页面弹出。
4.7.4 预警的阀值设定：由系统管理员设定。
4.7.5 预警信息的存储：预警信息采用日志存储方式。
4.8 统计需求
4.8.1 报表的分类
1. 流量统计类报表
2. 业务数据统计报表
3. 局域网内设备统计报表
4. 故障类统计报表
5. 数据库类性能统计报表
6. 操作系统类统计报表
4.8.2 形成的报表列表
1. 每台设备的历史流量报表
2. 售票系统业务数据统计报表
3. 结算系统业务数据统计报表
4. 报表系统业务数据统计报表
5. 网上订票业务数据统计报表
6. 网络结构设备统计报表
7. 设备性能异常统计报表
8. 预警报表
9. 数据库性能报表
10.操作系统信息报表
5. 其它非功能需求
5.1 性能需求
阐述不同应用领域对软件产品性能的需求，并且说明提出需求的原理或者依据，以帮助开发人员做出合理的设计选择。尽可能详细地描述性能需求，如果需要，可以针对每个功能需求或者特征分别陈述其性能需求。在这里确定：
●相互合作的用户数量；
●系统支持的并发操作数量；
●响应时间；
●与实时系统的时间关系：
●容量需求
?存储器；
?磁盘空间；
数据库中表的最大行数。
5.2 安全措施需求
详尽陈述与软件产品使用过程中可能发生的损失、破坏、危害相关的需求。定义必须采取的安全保护或动作，以及必须预防的潜在危险动作。明确软件产品必须遵从的安全标准、策略、或规则。
5.3 安全性需求
详尽陈述与系统安全性、完整性问题相关的需求，或者与个人隐私问题相关的需求。这些问题将会影响到软件产品的使用，和软件产品所创建或者使用的数据的保护。定义用户身份认证，或备授权需求。明确软件产品必须满足的安全性或者保密性策略。也可以通过称为完整性的质量属性来阐述这些需求。一个典型的软件系统安全需求范例如下：“每个用户在第一次登录后，必须更改他的系统预置登录密码，系统预置的登录密码不能重用。”
5.4 软件质量属性
详尽陈述对客户和开发人员至关重要的在软件产品其它方面表现出来的质量功能。这些功能必须是确定的、定量的、在需要时是可以验证的。至少也应该指明不同属性的相对侧重点，例如：易用性优于易学性，或者可移植性优于有效性。
5.5 业务规则
列举出有关软件产品的所有操作规则，例如：那些人在特定环境下可以进行何种操作。这些本身不是功能需求，但是他们可以暗示某些功能需求执行这些规则。一个业务规则的范例如下：“进行达到或者超过10，000，00元人民币的储蓄业务时，必须通过附加的管理员认证。”
列举业务规则时，可以根据规则的数量，选取合适的编目方式。
6. 数据定义
数据定义是一个定义了应用程序中使用的所有数据元素和结构的共享文档，其中对每个数据元素和结构都准确描述了：含义、类型、数据大小、格式、计量单位、精度以及取值范围。数据定义的维护独立于软件需求规格说明，并且在软件产品开发和维护的任何阶段，均向所省风险承担者开放。
如果为软件开发项目创建一个独立的数据定义，而不是为每一项特性描述有关的数据项，有利于避免冗余和不一致性。但是却不利于多人协同编写需求分析报告，容易遗漏数据，也不方便阅读。因此还是建议为每个特性描述有关的数据项，汇总数据项创建数据定义，再根据数据定义复核全部数据，使得它们的名称和含义完全一致。必须注意的是，为了避免二义性，在汇总数据项时应该根据数据项所代表的实际意义汇总，而不是根据数据项的名称汇
总。
在数据定义中，每个数据项除了有一个中文名称外，还应该为它取一个简短的英文名称，该英文名称应该符合命名规范，因为在软件开发时将沿用该英文名称。可以使用等号表示数据项，名称写在左边，定义写在右边。常见数据项的描述方式如下：
●原数据元素
一个原数据元素是不可分解的，可以将一个数量值赋给它。定义原数据元素必须确定其含义、类型、数据大小、格式、计量单位、精度以及取值范围。采用以星号为界的一行注释文本，描述原数据元素的定义。
●选择项
选择项是一种只可以取有限离散值的特殊原数据元素，描述时一一枚举这些值，并用方括号括起来写在原数据元素的定义前。在两项离散值之间，使用管道符分隔。
●组合项
组合项是一个数据结构或者记录，其中包含了多个数据项。这些数据项可以是原数据元素，也可以是组合数据项，各数据项之间用加号连接。其中每个数据项都必须是数据定义中定义过的，结构中也可以包括其它结构，但是绝对不允许递归。如果数据结构中有可选项，使用圆括号把该项括起来。
●重复项
重复项是组合项的一种特例，其中有一项将有多个实例出现在数据结构中，使用花括号把该项括起来。如果知道该项可能允许的范围，就按“最小值：最大值”的形式写在花括号前。
7. 分析模型
这是一个可选部分，包括或涉及到相关的分析模型，例如：
●数据流程图；
●类图；
●状态转换图；
●实体-关系图。
8. 待定问题列表
编辑一张在软件产品需求分析报告中待确定问题时的列表，把每一个表项都编上号，以便跟踪调查。
E-Storage Management System Software Requirements Specification 电子化仓储管理系统软件需求规格说明书 版权所有不得复制 Copyright ? BroadenGate Technologies, Co., Ltd. All Rights Reserved
Revision Record 修订记录
Catalog 目录
错误!未找到引用源。 Keywords 关键词：仓储管理 Abstract 摘要：本文主要描述电子化仓储管理系统的设计需求，包括功能需求和性能需求，以及其他设计约束等。 List of abbreviations 缩略语清单：
1Introduction 简介 1.1Purpose 目的 1.2Scope 范围 本文档包含电子化仓储管理系统V1.0的对外接口和功能描述，以及和外部的约束关系。2General description 总体概述 2.1Software perspective 软件概述 2.1.1About the Project 项目介绍 2.1.2Environment of Pruduct 产品环境介绍 2.2User characteristics 用户特征 2.3Software function 软件功能 2.4Assumptions & Dependencies 假设和依赖关系 3Specific Requirements 具体需求
3.1Functional Requirements 功能需求 我们采用面向对象分析的方法来作为主要的系统建模方法，使用UML(Unified Modeling Language)作为建模语言。UML为建模活动提供了从不同角度观察和展示系统的各种特征的方法。在UML中，从任何一个角度对系统所作的抽象都可能需要几种模型来描述，而这些来自不同角度的模型图最终组成了系统的映像。 Use Case描述的是“actor”(用户、外部系统以及系统处理)是如何与系统交互来完成时，该模型将来可 派生出动态对象模型。 设计Use-case时，我们遵循下列步骤： 第一步： 识别出系统的管理员。管理员可以是用户、外部系统，甚至是外部处理，通过某种途径与系统交互。重要的是着重从系统外部执行者的角度来描述系统需要提供哪些功能，并指明这些功能的执行者是谁。尽可能地确保所有管理员都被完全识别出来。 第二步： 描述主要的Use Case。可以采取不断地问自己“这个管理员究竟想通过系统做什么？”来准确地描述Use Case。 第三步： 重新审视每个Use Case，为它们下了详尽的定义。 电子化仓库管理系统是通过对入库业务、出库业务、仓库调拨、库存调整业务信息的管理，提高仓库管理信息的实时性和准确性，达到即时库存管理的功能，并有效控制并跟踪业务的物流和成本管理全过程，实现完善的企业仓储信息管理。系统中设计了装箱算法，为客户提供合理有效的装箱方案，保证了货物集装箱的利用。本系统可以提供有关库存情况的准确信息，增强了作业的准确性和快捷性、减少了整个物流中由于商品误置、送错、偷窃、损害和库存、出货错误等造成的损耗，并最大限度减少存储成本。 总体功能时序图：（如图3-1所示）
[PRD]产品需求文档 文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改文件标识：Company-Project-RD-UR 当前版本：Beta 1.0 作者： 完成日期：2013-03-05
修订历史 序号版本编写/修订说明修订人修订日期备注1 2
目录 一、项目概述 (4) 1、产品背景介绍 (4) 2、产品概述及目标 (4) 3、阅读对象 (4) 4、参考文档 (4) 5、术语与缩写解释 (4) 二、产品角色 (4) 三、产品设计约束及策略 (5) 四、产品模型 (5) 五、产品功能性需求 (5) 1.、业务流程图 (5) 2、功能模块划分 (5) 3、功能模块设计 (5) 六、产品非功能性需求 (6) 1、软硬件环境需求 (6) 2、产品质量需求 (6) 3、安全性需求 (6) 4、产品升级维护需求 (6) 5、接口需求 (6) 6、其他需求 (6)
一、项目概述 1、产品背景介绍 提示：主要介绍在在什么环境下做这个产品，为什么要做这个产品2、产品概述及目标 提示：产品的概要介绍，期望实现的目标 3、阅读对象 提示：指明文档阅读对象，如需求评审人员，开发人员，测试人员等4、参考文档 提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：[标识符] 作者，文献名称，出版单位（或归属单位），日期 例如： [SPP-PROC-PP] SEPG，需求开发规范，机构名称，日期 5、术语与缩写解释 缩写、术语解释 二、产品角色 提示：产品的使用者
三、产品设计约束及策略 提示:应当遵循的标准或规范，包含程序与UI部分的要求 四、产品模型 提示：用概念体现主要业务实体及其关系，并加以说明，大型实体关系图可以分块展示，内容包括：模型图，概念说明，关系说明 五、产品功能性需求 1.、业务流程图 提示：产品整体业务流程图，如过大，可分块展示 2、功能模块划分 提示：针对业务流程图，将所划分出来的模块及简要说明罗列出来 3、功能模块设计 提示：包括各模块的业务流程，用例描述，用户界面，字段及其他说明
组长成员XXX系统 软件需求文档年月日
修改记录 版本号变更控制报告编号更改条款及内容更改人审批人更改日期 1.0 初稿 1.1 添加数据流图 1.2 添加业务规则
目录 1前景和范围文档 (4) 1.1业务需求 (4) 1.2解决方案的前景 (5) 1.3范围和局限性 (6) 1.4业务上下文 (6) 2用例描述文档 (9) 3需求规格说明书 (13) 3.1引言 (13) 3.2综合描述 (13) 3.3外部接口需求 (15) 3.4系统特性 (16) 3.5其他非功能性需求 (19) 3.6其他需求 (20) 附录A 词汇表 (20) 附录B 分析模型 (22) 附录C 待确定问题的列表 (23)
该附录通过“自助食堂订餐系统（Cafeteria Ordering System，COS）”这样一个假想的小型项目，阐述了本书所描述的某些需求文档和图。这里包括如下这些内容： ?前景和范围文档。 ?用例列表和若干用例描述。 ?部分软件需求规格说明。 ?某些分析模型。 ?部分数据字典。 ?若干业务规则。 因为这仅仅是一个范例，所以我们并不打算完善这些需求元素。我们的目标只是提供一种思想，各种类型的需求信息之间彼此是如何关联的，并演示我们可能如何编写文档每一部分的内容。在一个小型项目中，将不同的需求信息综合到单一的文档中，常常是有意义的，因此我们可能没有单独的前景和范围文档、用例文档和软件需求规格说明。这些文档中的信息能够以多种其他合理的方式来组织。基本的目标是确保需求文档清晰明了、完整和易使用。 这些文档总的来说都遵循照前面章节所描述的模板，但是，因为这只是一个小型项目，所以对这些模板稍微作了一些简化。有时，会将几个部分合并起来，这是为了避免信息重复。每一个项目都应该考虑如何适应组织的标准模板，以尽量适合于项目的规模和本质。 1前景和范围文档 1.1业务需求 1.背景、业务机会和客户需要 目前，Process Impact公司的大多数员工平均每天要花费60分钟去自助食堂选择、购买并用午餐，其中大约有20分钟要花在公司和自助食堂之间的往返路程、选择自己喜欢的午餐、以及以现金方式或以信用卡方式结算餐费上。当员工出去用午餐时，他们平均有90分钟时间不在岗。有些员工提前给自助食堂打电话预订午餐，请自助食堂准备好他们所选择的午餐。但是，员工并不是总能如愿以偿，因为自助食堂有些食物己卖完，而与此同时，自助食堂又不可避免地会浪费大量的食物，因为有些食物没有卖出去而只好倒掉。早餐和晚餐同样面临着这样的问题，只是到自助食堂用餐的员工人数比午餐要少得多。 许多员工都通过允许自助食堂用户在线订餐的一个系统而提出订餐请求，要求在指定的日期和时间内将所订的午餐送到公司的指定地点。通过这样一个系统，使用这一服务的员工可以节约相当可观的时间，而且订到自己所喜欢的食物的机会也增大了。这既提高了他们的工作生活质量，也提高了他们的生产率。自助食堂提前了解到客户需要哪些食物，就可以减少浪费，并提高自助食堂员工的工作效率。要求送货上门的订餐员工将来还可以从本地的饭店来订餐，这就大大扩大了员工对食物的选择范围，并通过与饭店的大量购餐协议而有可能节约费用。Process Impact公司也可以只在自助食堂订午餐，而在饭店订早餐、晚餐、特定事件的用餐以及周末会餐。 2.业务目标（Business Objective，BO）和成功标准（Success Criteria，SC）
软件开发文档模板 1 可行性研究报告 可行性研究报告的编写目的是：说明该软件开发项目的实现在技术、经济和社会条件方面的可行性；评述为了合理地达到开发目标而可能先择的各种方案；说明论证所选定的方案。可行性研究报告的编写内容要求如下： 1.1 引言 1.1.1 编写目的 1.1.2 背景 1.1.3 定义 1.1.4 参考资料 1.2 可行性研究的前提 1.2.1 要求 1.2.2 目标 1.2.3 条件、假定和限制 1.2.4 进行可行性研究的方法 1.2.5 评价尺度 1.3 对现有系统的分析 1.3.1 数据流程和处理流程 1.3.2 工作负荷 1.3.3 费用开支 1.3.4 人员 1.3.5 设备 1.3.6 局限性 1.4 所建议的系统 1.4.1 对所建议系统的说明 1.4.2 数据流程各处理流程 1.4.3 改进之处 1.4.4 影响 1.4.4.1 对象设备的影响 1.4.4.2 对软件的影响 1.4.4.3 对用户单位机构的影响 1.4.4.4 对系统动行的影响 1.4.4.5 对开发的影响 1.4.4.6 对地点和设施的影响 1.4.4.7 对经费开支的影响 1.4.5 局限性 1.4.6 技术条件方面的可行性 1.5 可选择其他系统方案 1.5.1 可选择的系统方案 1 1.5.2 可选择的系统方案 2 …… 1.6 投资及收益分析 1.6.1 支出 1.6.1.1 基本建设投资
1.6.1.2 其他一次性支出 1.6.1.3 非一次性支出 1.6.2 收益 1.6. 2.1 一次性收益 1.6. 2.2 非一次性收益 1.6. 2.3 不可定量的收益 1.6.3 收益/投资比 1.6.4 投资回收周期 1.6.5 敏感性分析 1.7 社会条件方面的可行性 1.7.1 法律方面的可行性 1.7.2 使用方面的可行性 1.8 结论 2 项目开发计划 编制项目开发计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度所需经费预算、所需软、硬件条件等问题作出安排记载下来，以便根据本计划开展和检查本项目的开发工作。编制内容要求如下： 2.1 引言 2.1.1 编写目的 2.1.2 背景 2.1.3 定义 2.1.4 参考资料 2.2 项目概述 2.2.1 工作内容 2.2.2 主要参加人员 2.2.3 产品及成果 2.2. 3.1 程序 2.2. 3.2 文件 2.2. 3.3 服务 2.2. 3.4 非移交产品 2.2.4 验收标准 2.2.5 完成项目的最迟期限 2.2.6 本计划的审查者与批准者 2.3 实施总计划 2.3.1 工作任务的分解 2.3.2 接口人员 2.3.3 进度 2.3.4 预算 2.3.5 关键问题 2.4 支持条件 2.4.1 计算机系统支持 2.4.2 需要用户承担的工作 2.4.3 需由外单位提供的条件 2.5 专题计划要点
基本信息 编写人员编写时间 审核审核时间 版本V1.01 文档修订历史 序号版本号修订章节修订原因修订日期修订人修订说明 xxxx年xx月xx日
目录 前言--------------------------------------------------- 错误！未定义书签。第一章前言------------------------------------------------------------- 3 1.1编写目的---------------------------------------------------------------------- 3 1.2参考文献---------------------------------------------------------------------- 3第二章产品概述--------------------------------------------------------- 4 2.1产品简述---------------------------------------------------------------------- 4 2.2专有名词解释------------------------------------------------------------------ 4 2.3产品用户角色描述-------------------------------------------------------------- 5 2.4产品总体架构------------------------------------------------------------------ 5 2.5产品业务流程图---------------------------------------------------------------- 5 第三章产品功能需求----------------------------------------------------- 7 3.1 功能点1 ------------------------------------------------------------ 7 3.1.1需求编号及名称------------------------------------------------------------------------------- 7 3.1.2 需求说明 --------------------------------------------------------------------------------------- 8 3.1.3 功能业务流程图------------------------------------------------------------------------------ 8 3.1.4 功能流程 --------------------------------------------------------------------------------------- 9 3.1.5 产品界面原型-------------------------------------------------------------------------------- 11 3.1.6 相关字段 -------------------------------------------------------------错误！未定义书签。 第四章非功能性需求---------------------------------------------------- 12
项目管理协作支撑系统 软件需求规格说明书 目录 1.引言 (2) 1.1目的 (2) 1.2适用范围 (2) 1.3参考资料 (2) 1.4术语和缩略语 (2) 2.系统概述 (2) 2.1产品描述 (2) 2.2产品功能 (4) 2.3一般约束 (5) 3.功能性需求分类 (5) 3.1功能描述 1 .................................................................................................................错误！未定义书签。 3.2功能描述 2 (5) 4.产品的非功能性需求 (11) 4.1外部接口说明 (11) 4.1.1用户接口 (11) 4.1.2软件接口 (11) 4.2性能需求 (11) 4.2.1硬件的限制 (11) 4.3属性 (11) 4.3.1友好性 (11) 4.3.2安全性 (11) 4.3.3可维护性 (11) 4.3.4可转移 / 换性 (12) 4.4系统的运行环境 (12) 4.5其他需求 (12) 4.5.1用户操作需求 (12) 附录 A：需求确认 (14)
1.引言 1.1目的 编写此文档的目的是进一步定制软件开发的细节问题, 希望能使本软件开发工作更具体。 是为使用户、软件开发者及分析人员对该软件的初始规定有一个共同的理解，它说明了本产品的 各项功能需求、性能需求和数据要求，明确标识各功能的实现过程，阐述实用背景及范围，提供 客户解决问题或达到目标所需的条件或权能，提供一个度量和遵循的基准。 1.2适用范围 在各个行业中，当我们接受到用户的商业项目后，在项目运行的全过程中充满了不确定因素，只有有效的运用项目管理的科学和艺术，才有可能使项目取得成功。对以上方面要想达到有效的管理水平，必须有一套科学的管理方法，但是即使有了科学的管理方法，由于项目干系人之间的沟通、协作不到位，往往达不到预期的结果。鉴于这种情况我们开发一套项目管理协作支撑系统，旨在为项目干系人提供一个交流、协作以及项目的进度跟踪监控、项目的质量控制、项目相关资源的管理的软件平台，从而提高项目管理水平，实现了工作的协同化、提高了工作效率。 1.3参考资料 资料名称 [ 标识符 ]出版单位作者日期 1.4术语和缩略语 术语、缩略语解释 2.系统概述 2.1产品描述 本项目的目标是： <1>决策支持 :根据项目的需求及时提供所需信息, 并在一定阶段对各模块的进度进行追踪及提 示 , 实现工作的协同化、提高了工作效率。 <2>提高效率 : 利用软件进行管理, 避免人工管理的失误以及延迟性, 从而实现高效率的管理。
项目管理协作支撑系统（The English Name） 软件需求规格说明书 XXX项目小组
修订表
审批记录
目录 1.引言 (5) 1.1目的 (5) 1.2适用范围 (5) 1.3参考资料 (5) 1.4术语和缩略语 (5) 2.系统概述 (5) 2.1产品描述 (5) 2.2产品功能 (7) 2.3一般约束 (8) 3.功能性需求分类 (8) 3.1功能描述1.................................................................................................................... 错误!未定义书签。 3.2功能描述2 (8) 4.产品的非功能性需求 (14) 4.1外部接口说明 (14) 4.1.1用户接口 (14) 4.1.2软件接口 (14) 4.2性能需求 (14) 4.2.1硬件的限制 (14) 4.3属性 (14) 4.3.1友好性 (14) 4.3.2安全性 (14) 4.3.3可维护性 (14) 4.3.4可转移/换性 (15) 4.4系统的运行环境 (15) 4.5其他需求 (15) 4.5.1用户操作需求 (15) 附录A：需求确认 (17)
1.引言 1.1目的 编写此文档的目的是进一步定制软件开发的细节问题,希望能使本软件开发工作更具体。 是为使用户、软件开发者及分析人员对该软件的初始规定有一个共同的理解，它说明了本产品的各项功能需求、性能需求和数据要求，明确标识各功能的实现过程，阐述实用背景及范围，提供客户解决问题或达到目标所需的条件或权能，提供一个度量和遵循的基准。 1.2适用范围 在各个行业中，当我们接受到用户的商业项目后，在项目运行的全过程中充满了不确定因素，只有有效的运用项目管理的科学和艺术，才有可能使项目取得成功。对以上方面要想达到有效的管理水平，必须有一套科学的管理方法，但是即使有了科学的管理方法，由于项目干系人之间的沟通、协作不到位，往往达不到预期的结果。鉴于这种情况我们开发一套项目管理协作支撑系统，旨在为项目干系人提供一个交流、协作以及项目的进度跟踪监控、项目的质量控制、项目相关资源的管理的软件平台，从而提高项目管理水平，实现了工作的协同化、提高了工作效率。 1.3参考资料 1.4术语和缩略语 2.系统概述 2.1产品描述 本项目的目标是： <1>决策支持: 根据项目的需求及时提供所需信息,并在一定阶段对各模块的进度进行追踪及提 示,实现工作的协同化、提高了工作效率。 <2>提高效率:利用软件进行管理,避免人工管理的失误以及延迟性,从而实现高效率的管理。
Xxx系统需求说明
目录 1产品概述2 1.1目标&意义2 1.2领域知识3 1.3思维导图3 1.4业务流程图3 2功能围5 2.1功能名称5 2.1.1功能说明5 2.1.2用例说明5 2.1.3操作流程7 2.1.4界面原型9 2.1.5对应字段9 2.1.6相关规则10 3词汇表10 4非功能需求10 4.1规则变更需求10 4.2产品服务需求10 4.3帮助需求10 4.4安全性需求10 4.5上线实现需求3 5上线时间安排表10 1产品概述 说明：<简单描述项目的背景、意义、目的、目标等，描述领域知识> 1.1目标&意义 项目目标： 完整保存教师信息； 简化教师管理流程； 提高相关部门工作效率； 建立合理系统功能。 项目意义： 保证每学期开班的正常进行
建立有效的教师管理机制 按照统一规则计算工资，保证教师待遇、奖金的公平公正性 有效提高师资管理相关部门的工作效率，优化工作流程 1.2领域知识 说明：<包括：项目涉及到的业务背景、业务知识、业务词汇解释。> 项目类似于人力资源管理系统，主要信息管理、考勤、工资、合同、排名、访谈几个角度管理和利用教师信息为实际工作服务。 涉及工资核算、考勤制度。 1.3思维导图 <整个产品功能思维导图> 1.4业务流程图 <整个产品涉及业务的整个流程图>
2功能围 <主要功能描述> 2.1教师入职 2.1.1功能说明 <描述功能的作用> 新录入老师的信息管理 入职老师审批 专职老师转正审批 审批记录查询 2.1.2用例说明 <编写业务用例，即按照真实的用户业务划分用例，记录人机交互过程，完成用例描述>
软件需求分析报告文档模板 目录 1. 引言 (1) 1.1编写目的 (2) 1.2项目风险 (2) 1.3文档约定 (2) 1.4预期读者和阅读建议 (2) 1.5产品范围 (2) 1.6参考文献 (3) 2. 综合描述 (3) 2.1产品的状况 (3) 2.2产品的功能 (4) 2.3用户类和特性 (4) 2.4运行环境 (4) 2.5设计和实现上的限制 (4) 2.6假设和约束(依赖) (5) 3. 外部接口需求 (5) 3.1用户界面 (5) 3.2硬件接口 (6) 3.3软件接口 (6) 3.4通讯接口 (6) 4. 系统功能需求 (6) 4.1说明和优先级 (7) 4.2激励／响应序列 (7) 4.3输入／输出数据 (7) 5. 其它非功能需求 (7) 5.1性能需求 (8) 5.2安全措施需求 (8) 5.3安全性需求 (8) 5.4软件质量属性 (8) 5.5业务规则 (8) 5.6用户文档 (8) 6. 词汇表 (9) 7. 数据定义 (9) 8. 分析模型 (9) 9. 待定问题列表 (19)
引言 引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者 ●软件开发者 ●产品使用者 1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括 ●正文风格： ●提示方式： ●重要符号： 也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。 1.4 预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括 ●用户； ●开发人员； ●项目经理； ●营销人员； ●测试人员； ●文档编写入员。 并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议 1.5 产品范围 说明该软件产品及其开发目的的简短描述，包括利益和目标。把软件产品开发与企业目标，
目录
(9) 5
1. 范围 本指南用于指导软件开发者为****的过程，通过规范软件项目承担单位的开发过程达到提高软件质量，降低维护成本的目的。开发者应根据本指南进行软件开发和编制软件开发文档。本指南是对软件项目承担单位的基本要求。在本指南的附录A至E中提供了文档的编写模板供开发者参考，在进行具体软件开发时，开发者可根据实际情况采编写，但必须提供双方约定的文档，文档中约定的内容必须描述清楚。 2. 总体要求 2.1 总体功能要求 网络应用环境以Internet/Intranet技术为核心。 开发者应在充分分析需求的基础上，选择采用B/S结构或者C/S结构。 软件系统的数据库应依照《******规范》进行设计和建设。 本指南中没有规定开发者采用何种具体的软件工程开发方法，开发者可根据项目具体特点、自身擅长来选择采用面向过程的方法、面向对象的方法或面向数据的方法，但建议开发商使用面向对象软件工程的方法，如：采用目前被广泛使用的RUP(Rational Unified Process)方法来进行分析、设计和开发。 2.2 软件开发平台要求 开发者开发的软件必须能够在******规定的软件平台上正常运行。目前软件平台为：数据库管理系统： Oracle 9i以上版本 中间件(应用服务器)系统： IBM WebSphere OA系统： Lotus Domino/Notes 网络架构： 完全支持TCP/IP协议 开发工具或技术体系： 为保证软件的上下兼容性，开发者应选择比较通用的开发工具的较新版本进行开发，如Microsoft Visual ，Borland Delphi，C++ Builder, 或J2EE(Java2 P1atform Enterprise Edition)等。
项目编号： （项目名称） 需求分析报告 同方智能卡产品公司研发中心
目录 1. 任务概述 (3) 1.1. 目标 (3) 1.2. 系统（或用户）的特点 (3) 2. 假定和约束 (3) 3. 需求规定 (3) 3.1. 软件功能说明 (3) 3.2. 对功能的一般性规定 (3) 3.3. 对性能的一般性规定 (4) 3.4. 其他专门要求 (4) 3.5. 对安全性的要求 (4) 4. 运行环境规定 (4) 4.1. 设备及分布 (4) 4.2. 支撑软件 (4) 4.3. 接口 (4) 4.4. 程序运行方式 (5) 5. 尚需解决的问题 (5)
任务概述 1.1. 目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 1.2.系统（或用户）的特点 如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度； 如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。 2.假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 3.需求规定 3.1. 软件功能说明 列出本系统中所有软件功能子系统和功能。如果子系统比较大，每个子系统分别编写《软件功能规格说明书》，在本处列出编号和名称。 功能说明应包含以下几部分内容 3.1.1 软件功能列表 3.1.2 主要业务流程分析 3.1.3 软件部署结构分析 3.2. 对功能的一般性规定
软件系统开发需求分析模板 1. 引言 编写目的 本系统的开发目的在于更好的管理和经营酒店餐饮行业。本文档的预期读者是酒店管理系统软件开发有关的开发人员。 项目背景 本项目的名称：酒店管理系统。 随着国民经济的发展，酒店餐饮行业的队伍在全国范围（尤其是在经济发达地区）不断壮大，从事酒店餐饮行业的单位之间竞争愈加激烈。为了提升自身的竞争能力， 各酒店餐饮单位都在尽量定制或购买各项业务的应用软件，运用高科技手段进行经营 和管理。为了让酒店更好的经营，我们组织开发了本软件。 本项目的任务提出者及开发者是酒店管理系统软件开发小组，主要是面向酒店餐饮服务行业。 定义 酒店管理系统是帮助酒店自身管理和服务酒店客户的软件。 % 参考资料 ①《现代软件工程》北京希望电子出版社孙涌等编著 ②《Delphi住宿餐饮管理系统开发实例导航》人民邮电出版社 刘敬严东明马刚编著 ③《软件需求说明书（GB856T——88）.doc》 ④《iso标准之需求分析说明书.doc》 2.任务概述 目标 开发本软件是为了服务酒店，使得酒店更好的经营。适用于一些大中型酒店，主
要用于就餐管理和住宿管理。本软件产品是一项独立的软件，不过功能还可以增加，完成后可以升级以增加功能和完善系统。 用户的特点 } 使用本软件要求用户熟悉Windows 操作，并且有一定的软件操作基础。预计本软件将会在一些大中型酒店中得到广泛使用。 假定和约束 本软件由我们小组六个人共同开发，几乎不要经费，开发期限一个月左右。3.需求规定 对功能的规定 ①系统帐号管理 第一次用一个管理员账号（系统给定）登陆，登陆成功后，可以设置其他用户，包括密码、权限等。 ②就餐管理 为就餐客户查询并分配餐桌，纪录客户用餐情况并结帐。 ③住宿管理 、 为住宿客户查询并分配房间，纪录客户住宿情况并结帐。 对性能的规定 精度 本软件主要用于管理，不是科学计算，要求计算的精度不是很苛刻。所以输入,输出数据精度的要求不是很高，用于计算的数用浮点数就可以了。 时间特性要求 本软件运行的响应时间要求不超过1～2秒，基本能实现。 灵活性
目录 三、需求规格说明书 (2) 四、概要设计说明书 (12) 五、详细设计说明书 (15)
3软件需求说明书软件需求说明书的编制是为了使用户的软件开发者双方对该软件的起初规定有一个共同的理解，使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下： 3.1引言 3.1.1 编写的目的 3.1.2 背景 3.1.3 定义 3.1.1 参考资料 3.2任务概述 3.2.1目标 3.2.2用户的点 3.2.3假定与约束 3.3需求规定 3.3.1对功能的规定 3.3.2对性能的规定
3.3.2.1 精度 3.3.2 .2 时间特性要求 3.3.2 .3 灵活性 3.3.3 输入输出要求 3.3.4 数据管理能力的要求 3.3.5 故障处理要求 3.3.6 其它的专门的要求 3.4 运行环境规定 3.4.1 设备 3.4.2 支持软件 3.4.3 接口 3.4.4 控制 4数据需求说明书数据要求说明书的编制目的是为了向整个开发时期提供关于处理数据的描述和数据采集要求的技术信息。编制数据要求说明书的内容要求如下： 4.1引言
4.1. 1 编写目的 4.1. 2 背景 4.1. 3 定义 4.1. 4 参考资料 4.2 数据的逻辑描述 4.2. 1 静态数据 4.2. 2 动态输入数据 4.2. 3 动态输出数据 4.2. 4 内部生成数据 4.2. 5 数据约定 4.3 数据的采集 4.3. 1 要求和范围 4.3. 2 输入的承担者 4.3. 3 处理 4.3. 4 影响 5概要设计说明书概要设计说明书可称作系统设计说明书，这里说的系统是指程序系统，编制的目的是说明对程序的系统的设计考虑，包括
1. 引言 1.1 目的 说明编写这份报告的目的，指出预期的读者。 1.2 背景 指出待开发的软件系统的名称；行业情况；本项目的任务提出者、开发者、用户；该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 参考资料 列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、技术标准，以及他们的作者、标题、编号、发布日期和出版单位。 列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的网址。 1.4 术语 列出本报告中用到的专门术语的定义。
2.任务概述 2.1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2系统（或用户）的特点 如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度； 如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。3.假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 4.需求规定 4.1软件功能说明 逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。 4.2对功能的一般性规定
软件需求规格说明书 文件编号：QMS—PROC－RD02 版本：1.0 受控签章
修改历史
目录 1引言 (4) 1.1目的 (4) 1.2背景 (4) 1.3术语 (4) 1.4预期读者与阅读建议 (4) 1.5参考资料 (4) 1.6需求描述约定 (5) 2.项目概述 (6) 2.1系统功能 (6) 2.2业务描述 (6) 2.3数据流程描述(可选) (6) 2.4用户的特点 (6) 2.5运行环境要求 (6) 2.6设计和实现上的限制 (6) 3.功能需求的描述 (6) 4.非功能需求 (7) 4.1系统性能要求 (7) 4.2系统安全及保密要求 (7) 4.3系统备份与恢复要求 (7) 4.4系统日志 (7) 5.外部接口说明 (7) 6.其他需求 (8) 7 需求变更识别 (8) 8.功能列表 (8) 9.附件 (8)
1引言 1.1 目的 说明编写这份软件需求规格说明书的目的，如：通过本文档定义ＸＸＸ产品的需求，以求在项目组员与相关成员之间达成一致的需求描述。 1.2 背景 描述系统产生的背景，包括： a．需开发的软件系统的名称，和英文缩写（可选），项目编号（可选）； b．列出此项目的任务提出者、开发者 c．软件系统应用范围、用户。 d．产生该系统需求的原因或起源，如社会背景、市场发展、政策趋势、原有系统局限性 1.3 术语 列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。也可用附件说明。或放到本文件的最后。 1.4 预期读者与阅读建议 描述本文档的主要读者，以及这些读者在阅读时的阅读重点与建议。可用列表的方式列 1.5 参考资料 列出有关的参考资料，如： a．本项目经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 d．行业标准和规范。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
软件开发需求文档模板
目录
1. 范围 本指南用于指导软件开发者为南京市交通局开发软件项目的过程，通过规范软件项目承担单位的开发过程达到提高软件质量，降低维护成本的目的。开发者应根据本指南进行软件开发和编制软件开发文档。本指南是对软件项目承担单位的基本要求。在本指南的附录A至E中提供了文档的编写模板供开发者参考，在进行具体软件开发时，开发者可根据实际情况采编写，但必须提供双方约定的文档，文档中约定的内容必须描述清楚。 2. 总体要求 2.1 总体功能要求 网络应用环境以Internet/Intranet技术为核心。 开发者应在充分分析需求的基础上，选择采用B/S结构或者C/S结构。 软件系统的数据库应依照《南京市交通局信
息化数据库建设规范》进行设计和建设。 本指南中没有规定开发者采用何种具体的软件工程开发方法，开发者可根据项目具体特点、自身擅长来选择采用面向过程的方法、面向对象的方法或面向数据的方法，但建议开发商使用面向对象软件工程的方法，如：采用目前被广泛使用的RUP(Rational Unified Process)方法来进行分析、设计和开发。 2.2 软件开发平台要求 开发者开发的软件必须能够在南京市交通局规定的软件平台上正常运行。目前软件平台为： 数据库管理系统： Oracle 9i以上版本 中间件(应用服务器)系统： IBM WebSphere OA系统： Lotus Domino/Notes 网络架构： 完全支持TCP/IP协议 开发工具或技术体系：
为保证软件的上下兼容性，开发者应选择比较通用的开发工具的较新版本进行开发，如Microsoft Visual https://www.doczj.com/doc/a1260151.html,，Borland Delphi，C++ Builder, 或J2EE(Java2 P1atform Enterprise Edition)等。 2.3 软件项目的开发实施过程管理要求 2.3.1 软件项目实施过程总体要求 （一）开发者提交软件开发工作大纲，交通局组织专家组对工作大纲进行评审，并提出整改意见。 （二）通过评审后，开发者根据整改意见完善工作大纲，经过交通局认可后组织项目组进行软件开发。软件开发工作按照需求分析、概要设计、详细设计、编码、测试等几个阶段进行，在开发过程中，开发者需分阶段提交相关文档。 （三）在软件开发工作完成后，开发者应向交通局提交完整的软件文档，交通局组织验收组对软件进行验收审查。 2.3.2 软件项目实施变更要求 在开发过程中，需求或设计不可避免地需要
需求分析 1.引言 1.1目的 说明编写这份报告的目的，指出预期的读者。 1.2背景 指出待开发的软件系统的名称；行业情况；本项目的任务提出者、开发者、用户；该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3参考资料 列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、技术标准，以及他们的作者、标题、编号、发布日期和出版单位。 列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的网 1.4术语 列出本报告中用到的专门术语的定义。 2.任务概述 2.1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
2.2系统（或用户）的特点 如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度； 如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。 3.假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 4.需求规定 4.1软件功能说明 逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。 4.2对功能的一般性规定 本处仅列出对开发产品的所有功能（或一部分）的共同要求，如要求界面格式统一，统一的错误声音提示，要求有在线帮助等。 4.3对性能的一般性规定 4.3.1精度 说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。 4.3.2时间特性要求 说明对于该系统的时间特性要求。 4.3.3灵活性 说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。 4.4输入输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。 对系统的数据输出及必须标明的控制输出量进行解释并举例。
XXX软件/项目/系统 详细设计说明书 拟制日期 评审人日期 批准日期 编写单位或个人
修订历史
目录 XXX软件详细设计说明书 (1) Revision Record 修订记录 (2) 1引言 (3) (3) 2 3 (5) 4总体方案确认 4.1系统总体结构确认 (5) 4.2系统详细界面划分 (5) 4.2.1应用系统与支撑系统的详细界面划分 (5) (5) 5 6、 7非功能性设计8 (8) 9环境配置 (8)
1引言 1.1编写目的 说明编制的目的是，大体上介绍一下软件系统中各层次中模块或子程序、以及数据库系统的设计考虑，表明此文档是主要是为编码人员提供服务，并且其他类型的项目参与人员也可以通过此文档对软件/项目有更深入了解。 1.2背景 说明此软件或系统的项目背景、需求背景、开发目的等，还可以列出参与人员等相关信息。 1.3参考资料 列出本文档中引用的文献、资料、标准等相关信息（一般是具有出版或版权性质的文件）。 1.4术语定义及说明 列出文档中用到的和开发有关，或与行业、业务、需求有关的专业术语，并进行解释。 2设计概述 2.1任务和目标 说明详细设计的任务及详细设计所要达到的目标。 2.1.1需求概述 对所开发软件的概要描述, 包括主要的业务需求、输入、输出、主要功能、性能等，尤其需要描述系统性能需求。 2.1.2运行环境概述 对本系统所依赖于运行的硬件，包括操作系统、数据库系统、运行库、中间件、接口软件、可能的性能监控与分析等软件环境的描述，及配置要求。 2.1.3条件与限制 详细描述系统所受的内部和外部条件的约束和限制说明。包括业务和技术方面的条件与限制以及进度、管理等方面的限制。 2.1.4详细设计方法和工具 简要说明详细设计所采用的方法和使用的工具，如数据库设计工具、界面设计工具、原型设计工具等。 3系统详细需求分析 主要对系统级的需求进行分析。首先应对需求分析提出的企业需求进一步确认，并对由于情况变化而带来的需求变化进行较为详细的分析。