软件产品需求规格说明书(案例)
需求规格说明书(样例)
需求规格说明书目录第一章综述 (1)1.1编制目的 (1)1.2适用范围 (1)1.3参考依据 (1)1.4编制约束 (1)1.4.1图元约束 (1)1.4.2编码约束 (2)1.4.3格式约束 (3)1.5内容结构（可选） (4)1.6导读说明 (4)第二章项目概述 (5)2.1项目背景 (5)2.2项目范围 (5)2.3项目目标 (5)2.4现状描述 (5)第三章需求总体分析 (6)3.1功能体系设计 (6)3.1.1功能结构 (6)3.1.2功能分布 (7)3.2整体业务流程（可选） (8)3.3业务标准体系 (9)第四章功能性需求 (10)4.1功能综述 (10)4.2需求清单 (10)4.3需求优先级（可选） (10)4.4功能编码•功能项 (11)4.4.1功能综述 (11)4.4.2业务流程 (11)4.4.3关系分析 (13)4.4.4详细功能需求 (13)第五章非功能性需求 (17)5.1软件质量属性需求 (17)5.1.1运行期 (17)5.1.2非运行期 (20)5.2约束性需求 (21)5.2.1基础架构 (21)5.2.2标准规范 (21)5.2.3集成要求 (21)5.2.4其他约束 (21)第六章集成需求 (22)6.1技术要求 (22)6.2数据集成 (22)6.3应用集成 (22)6.4流程集成 (23)第七章尚需解决的问题 (24)7.1问题总表 (25)7.2问题处理 (25)附录I 业务对象 (26)第一章综述若采用分册编制方式组织，则本章与第二章、第三章单独成册，其它分册可略去本章、第二章和第三章内容。
1.1编制目的用简洁的语言描述编写这个文档的目的。
1.2适用范围本文档适用的范围。
1.3参考依据列举编写软件需求规格说明时所参考的资料或其它资源。
这可能包括且不限于：用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。
(完整word版)软件需求规格说明书
软件需求分析说明书姓名：史景伟指导老师：吴文平日期：2016年11月28号1 引言1。
1 编写目的本文详细描述任务管理系统的需求，表述的需求信息要求明确、无二义性。
开发方与软件使用者充分沟通需求，最终形成此文档。
此文档是后续软件开发的依据。
1.2 背景任务管理系统是一个南京工程学院与康尼电气新技术有限公司产学研合作项目,项目由康尼机电新技术有限公司提出，由南京工程学院承担开发任务。
1。
3 定义和缩略语本文使用了表 1.错误!未定义书签。
所显示的面向用户的术语、定义，包括通用词语在本文档中的专用解释。
表 1.错误!未定义书签。
术语/定义表 1.错误!未定义书签。
所列为本文用到的缩略语。
表 1.错误!未定义书签。
缩略语1.4 用户任务信息管理系统的目前用户为康尼公司电气事业部，电气事业部使用成功后可能会在康尼公司推广。
某餐厅餐饮管理系统的目前的用户为某餐厅。
2 任务概述2.1目标康尼公司电气事业部目前的任务主要有2类：常规工作任务和临时性工作任务。
针对临时任务布置信息很多时候是处于一种开放状态，缺少任务信息的修正、回馈、和统计分析。
而日常职责规定的常规工作,虽然可以通过标准化的文件固化下来并形成《常规工作计划表》作为一种制度来执行，也需要主管在百忙之中花很多时间去检查完成情况。
TIMS系统要求工作管理信息能够规范录入,任务信息流向可以选择，任务信息依据轻重排序，可以设定信息提醒，任务完成情况可以评估、任务完成情况依据选择项进行统计输出、工作量进行评估。
2。
2 系统的特点TIMS项目的需求主要由康尼公司电气事业部提出，因此本文档是与康尼公司电气事业部交互后形成的需求定义，系统的功能和使用特点优先满足康尼公司电气事业部的需求，若系统后续由于在康尼公司全面推广而引入的新需求，则不在本文档考虑范围之内。
2。
3 假定和约束本文档经双方确认后，开发方依据本文档进行下阶段工作。
若中途需求发生变更则康尼公司需及时告知开发方，若因康尼公司原因引入的需求变更造成开发方工作量的大幅增加，具体解决方案双方另行协商。
软件需求规格说明书模板
软件需求规格阐明书模版文献变化记录单*变化状态：A——增长，M——修改，D——删除文献同意单1.引言提出对软件需求规格阐明书旳纵览，协助读者理解文档怎样编写并且怎样阅读和解释。
1.1编写目旳对产品（也也许是项目，不过我们统称为产品）进行定义，在该文档中详尽阐明这个产品旳软件需求，包括修正或发行版本号。
假如这个软件需求规格阐明书只与整个系统旳一部分有关，那么只定义文档中阐明旳部分或子系统。
1.2文档约定描述编写文档时所采用旳原则或排版约定，包括正文风格、提醒区或重要符号。
例如，阐明高层需求旳优先级与否可以被其所有细化旳需求所继承，或者每个需求陈说与否均有优先级。
1.3预期旳读者和阅读提议列举软件需求规格阐明书所针对旳不一样读者，例如开发人员、项目经理、营销人员、顾客、测试人员等。
描述文档中剩余部分旳内容及其组织构造。
提出最适合每一类型读者阅读文档旳提议。
1.4产品旳范围提供对指定旳软件及其目旳旳简短描述，包括利益和目旳。
把软件与企业目旳或业务方略相联络。
可以参照项目范围文档，而不是将其内容复制到这里。
1.5参照资料列举编写软件需求规格阐明书时所参照旳资料或其他来源。
也许包括顾客界面风格指导、协议、原则、系统需求规格阐明书、顾客需求、有关产品旳软件需求规格阐明书。
这里应当给出详细旳信息，包括标题名称、作者、版本号、日期、出版单位或资料来源，以以便读者查阅这些文献。
2.综合描述这一部分概述了正在定义旳产品以及它所运行旳环境、使用产品旳顾客和已知旳限制、假设和依赖。
2.1产品旳前景描述软件需求规格阐明书中所定义旳产品旳背景和来源。
阐明该产品与否是产品系列中旳下一种组员，与否是成熟产品所改善旳下一代产品、与否是既有应用程序旳替代品，或者与否是一种全新旳产品。
假如软件需求规格阐明书定义了大系统旳一种构成部分，那么就要阐明这部分软件是怎样与整个系统有关联旳，并且要定义出两者之间旳接口。
提议使用系统构造图或者实体关系图表达。
(完整word版)软件需求规格说明书(案例)
软件开发方向“成绩管理系统"软件需求规约安博教育集团二零零八年十月修订历史记录目录1 引言 (5)1。
1 目的 (5)1。
2 文档格式 (5)1.3 预期的读者和阅读建议 (5)1.4 范围 (6)1.5 术语 (7)1。
6 参考文献 (7)2 系统概述 (7)2。
1 概述 (7)2。
2 功能 (7)2.3 运行环境 (8)2.4 假设与依赖 (9)3 系统特性 (9)3。
1 系统角色 (9)3.2 学生管理 (11)3.2。
1 增加学生信息 (11)3。
2。
2 修改学生信息 (11)3。
2.3 删除学生信息 (11)3.2.4 导入学生信息 (11)3。
3 教师管理 (12)3.3.1 增加教师信息 (12)3。
3.2 修改教师信息 (12)3.3。
3 删除教师信息 (12)3。
3。
4 导入教师信息 (12)3。
4 课程管理 (13)3.4.1 增加课程基本信息 (13)3。
4。
2 修改课程基本信息 (13)3。
4。
3 删除课程基本信息 (13)3。
4。
4 维护课程学生信息 (13)3。
5 成绩查询 (14)3。
5.1 学生查询成绩 (14)3.5。
2 教师查询成绩 (14)3。
6 成绩分析与统计 (14)3。
6。
1 考试成绩表 (14)3.6。
2 班级各科平均成绩表 (14)3.6。
3 年级成绩排名表 (15)3。
7 系统维护 (15)3。
7.1 数据字典维护 (15)4 非功能性需求 (15)4。
1 性能需求 (15)4。
2 安全性需求 (15)4。
3 可用性需求 (16)4.4 用户文档 (17)4。
5 其它需求 (17)5 外部接口需求 (17)5.1 用户接口 (17)5.2 硬件接口 (17)5.3 软件接口 (18)5.4 通信接口 (18)1 引言1.1 目的该文档首先给出了整个系统的整体网络结构和功能结构的概貌，试图从总体架构上给出整个系统的轮廓，然后又对功能需求、性能需求和其它非功能性需求进行了详细的描述。
软件需求规格说明书
软件需求规格说明(SRS)(用例模型、领域模型、行为模型)用例模型：用例图+用例描述（3-5个）领域模型：不带操作的类图行为模型：1、交互图（时序图 3个）2、行为图（状态图2个，1个画系统的状态图，1个画类/对象的状态图；活动图2个，1个画系统的业务流程；1个画某个类的方法的计算流程。
说明：1.《软件需求规格说明》(SRS)描述对计算机软件配置项CSCI的需求，及确保每个要求得以满足的所使用的方法。
涉及该CSCI外部接口的需求可在本SRS中给出：或在本SRS 引用的一个或多个《接口需求规格说明》(IRS)中给出。
2.这个SRS，可能还要用IRS加以补充，是CSCI设计与合格性测试的基础。
软件需求规格说明的正文的格式如下：1围本章应分为以下几条。
1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。
1.2系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。
1.3文档概述本条应概述本文档的用途和容，并描述与其使用有关的性或私密性要求。
1.4基线说明编写本系统设计说明书所依据的设计基线。
2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和发行日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。
3需求本章应分以下几条描述CSCI需求，也就是，构成CSCI验收条件的CSCI的特性。
CSCI 需为了满足分配给该CSCI的系统需求所形成的软件需求。
给每个需求指定项目唯一标识符以支持测试和可追踪性。
并以一种可以定义客观测试的方式来述需求。
如果每个需求有关的合格性方法(见第4章)和对系统(若适用，子系统)需求的可追踪性(见5.a条)在相应的章中没有提供，则在此进行注解。
描述的详细程度遵循以下规则：应包含构成CSCI验收条件的那些CSCI特性，需方愿意推迟到设计时留给开发方说明的那些特性。
软件产品需求规格说明书
软件产品需求规格说明书软件产品需求规格说明书Software Product Requirements Specification1.引⾔1.1.⽬的本节描述软件产品需求规格说明书（SRS）的⽬的，如：a.定义软件总体要求，作为⽤户和软件开发⼈员之间相互了解的基础；b.提供性能要求、初步设计和对⽤户影响的信息，作为软件⼈员进⾏软件结构设计和编码的基础；c.作为软件总体测试的依据。
1.2.定义本节列出SRS中⽤到的全部需求的术语、定义和缩略语清单。
这些信息可以由SRS的附录提供，也可以参考其他的⽂件，如果有，本节必须指明。
1.3.参考资料本节列出下列资料：a.经核准的⽤户合同、《项⽬开发意向书》、《项⽬开发委托合同书》、《技术可⾏性报告》等⽂件；b.本项⽬的较⾼层次的开发⽂档，如：《项⽬开发计划》、《系统需求规格说明书》等；c.SRS中各处引⽤的资料、标准和规范。
列出这些资料的作者、标题、编号、发表⽇期、出版单位或资料来源。
2.软件总体概述2.1.软件标识本节列出软件的标识：软件全名称、软件缩称、版本号等。
软件标识必须具有唯⼀性。
2.2.软件描述2.2.1.系统属性本节描述被开发软件与其他相关产品之间的关系。
a.如果该软件是独⽴的，应在本节说明；b.如果该软件是⼀个更⼤的系统的⼀个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系。
如果这部分内容已包含在较⾼层次的说明（如《系统需求规格说明书》）中，应在本节指明。
本节⽆须描述设计⽅案和设计约束。
2.2.2.开发背景本节说明软件的开发⽬的、应⽤⽬标和使⽤范围等背景材料。
2.3.软件功能本节为软件功能提供⼀个摘要，⽆须描述功能的细节。
应为每⼀软件功能的需求分配⼀个唯⼀性的标识，以利于需求的跟踪和测试。
应说明功能的优先级定义，和每⼀功能的优先级（从⽤户⾓度⽽⾔）。
优先级定义可采⽤以下⽅法（QFD 对功能需求的分类⽅法）：a.⾼——软件必须实现的功能，⽤户有明确的功能定义和要求；b.中——软件应该实现的功能，⽤户的功能定义和要求可能是模糊的、不具体的、或低约束的，但是这类功能的缺少会导致⽤户的不满意，因此这类功能的具体需求应当由需求分析⼈员诱导⽤户产⽣并明确；c.低——软件尽量实现的功能，并可根据开发进度进⾏取舍，但这类功能的实现将会增加⽤户的满意度。
软件产品需求规格说明书(案例)
四川托普集团技术文档卷号：卷内编号：V1.0版多层体系政务框架平台之一行政服务中心政务平台软件产品需求规格说明书Software Product Requirements Specification项目承担部门：中央研究院应用产品开发中心撰写人（签名）：完成日期：本文檔使用部门：■主管领导■项目组□客户（市场）■维护人员□用户文档验交组（签名）：验交日期：评审负责人（签名）：评审日期：软件产品需求规格说明书Software Product Requirements Specification 1.引言1.1.目的本节描述软件产品需求规格说明书（SRS）的目的是：定义软件总体要求，作为用户和软件开发人员之间相互了解的基础；提供性能要求、初步设计和对用户影响的信息，作为软件人员进行软件结构设计和编码的基础；作为软件总体测试的依据。
1.2.定义Workflow：工作流1.3.参考资料行政服务中心政务平台白皮书行政服务中心政务平台项目审批表2.软件总体概述2.1.软件标识软件全称：多层体系政务框架平台之一行政服务中心政务平台软件简称：XZFWZXZW版本号：1.02.2.软件描述2.2.1.系统属性行政服务中心是改革开放进程中一项新生事物，是实践江总书记“三个代表”重要思想的具体表现，是改善投资环境，扩大开放，吸收外来投资，加快发展的重要举措。
为了实现行政服务中心“一站式集中，一条龙服务”，为全社会提供平等竞争的市场条件和长期稳定的投资环境，塑造廉洁，规范，高效的政府形象的目标，充分利用信息化技术，建设先进实用的可扩展性强的行政服务信息系统，实现行政服务信息处理的智能化、网络化、“无纸化”成为一项迫切的工作。
为此，托普集团根据行政服务中心的业务需求，设计了行政服务中心政务平台。
2.2.2.开发背景开发目的：1、公众服务2、行政服务中心和各级政府部门应用目标：行政服务机构使用范围：行政服务机构，公众2.3.软件功能(共12个系统模块)其中内部办公模块又分为：2.4.用户的特点因为本软件是一个全新的概念，对它的使用要求领导绝对的支持，才能将这个软件系统得以很好的使用。
软件需求规格说明书
软件需求规格说明书第一章引言1.1编写目的该文档对所开发的基于LBS的市内小块件动态调度系统达到功能、性能、用户界面及运行环境等作出了详细的说明。
他作为对该系统概要设计的依据，帮助开发人员了解本系统的框架思想及实现功能，并验证核实该产品能否满足用户要求的标准，便于技术文档和需求变化的管理。
同时也是用户与开发人员双方对软件需求取得共同理解的基础。
1.2文档约定本文档按以下要求和约定进行书写：（1）页面的左边距为3.18cm，右边距为3.18cm，装订线靠左，行距为1。
（2）标题最高分三级，分别为黑体二号，黑体三号，黑体四号，标题均加粗。
（3）正文字体为宋体五号，无特殊情况下，字体颜色均采用黑色。
（4）出现序号的段落不采用自动编号功能，各级别的序号依次为（1）、1）、a）等，特殊情况另作规定。
1.3读者对象和阅读建议本文档的主要内容共分6部分：总体描述、系统功能、外部接口需求、其他非功能性需求、数据字典和业务规则与业务算法。
总体描述主要对系统的整体结构进行了大致的介绍，包含产品前景，产品的功能，用户类及其特征，运行环境，设计和实现上的约束和假设和依赖着六部分；系统功能包含描述和优先级，请求/响应序列和功能性需求这三个方面；第四章包含用户界面，硬件接口，软件接口和通信接口这四个部分；其他非功能性需求包含性能需求，安全性需求，软件质量属性和其他需求这四个部分；数据字典则包含实体关系图和实体定义；业务规则与业务算法则包含业务规则和算法说明。
本文档面向多种读者对象：（1）项目经理：项目经理可以根据该文档了解预期产品的功能，并据此进行系统设计和项目管理。
（2）设计员：对需求进行分析，并设计出系统，包括数据库的设计。
（3）程序员：配合设计要求，了解系统功能，进行系统源代码编写。
（4）测试员：根据本文档编写测试用例，并对软件产品进行功能性测试和非功能性测试。
（5）其他人员：如部门领导、公司领导等可以据此了解产品的功能和性能。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
四川托普集团技术文档卷号：卷内编号：V1.0版多层体系政务框架平台之一行政服务中心政务平台软件产品需求规格说明书Software Product Requirements Specification项目承担部门：中央研究院应用产品开发中心撰写人（签名）：完成日期：本文檔使用部门：■主管领导■项目组□客户（市场）■维护人员□用户文档验交组（签名）：验交日期：评审负责人（签名）：评审日期：软件产品需求规格说明书Software Product Requirements Specification1.引言1.1.目的本节描述软件产品需求规格说明书（SRS）的目的是：定义软件总体要求，作为用户和软件开发人员之间相互了解的基础；提供性能要求、初步设计和对用户影响的信息，作为软件人员进行软件结构设计和编码的基础；作为软件总体测试的依据。
1.2.定义Workflow：工作流1.3.参考资料行政服务中心政务平台白皮书行政服务中心政务平台项目审批表2.软件总体概述2.1.软件标识软件全称：多层体系政务框架平台之一行政服务中心政务平台软件简称：XZFWZXZW版本号：1.02.2.软件描述2.2.1.系统属性行政服务中心是改革开放进程中一项新生事物，是实践江总书记“三个代表”重要思想的具体表现，是改善投资环境，扩大开放，吸收外来投资，加快发展的重要举措。
为了实现行政服务中心“一站式集中，一条龙服务”，为全社会提供平等竞争的市场条件和长期稳定的投资环境，塑造廉洁，规范，高效的政府形象的目标，充分利用信息化技术，建设先进实用的可扩展性强的行政服务信息系统，实现行政服务信息处理的智能化、网络化、“无纸化”成为一项迫切的工作。
为此，托普集团根据行政服务中心的业务需求，设计了行政服务中心政务平台。
2.2.2.开发背景开发目的：1、公众服务2、行政服务中心和各级政府部门应用目标：行政服务机构使用范围：行政服务机构，公众2.3.软件功能(共12个系统模块)其中内部办公模块又分为：2.4.用户的特点因为本软件是一个全新的概念，对它的使用要求领导绝对的支持，才能将这个软件系统得以很好的使用。
系统管理员和维护人员：计算机水平好，文化程度高，对Notes熟悉，能胜任系统管理工作；领导：对使用这个系统有很大的支持度，会用计算机；操作人员：对计算机能熟练使用；公众：对于咨询与要求处理事件的人，没有什么特别的要求，从网上的，系统一般都给明确的提示；从窗口来的，一般与操作人员接洽处理。
2.5.限制与约束本节描述软件开发工作的某些限制，例如经费限制、开发期限、硬件限制、编程语言、通信协议、安全和保密要求、开发过程中须遵守的某些标准或规则。
本节内容不是陈述具体需求或设计约束，而是为具体需求以及设计约束的描述提供依据。
经费限制：41.07万；开发期限：2002年8月31日完成；硬件限制：硬设备有部分配置比较低，完成本需求说明中的功能和性能要求没有问题；编程语言：Notes Script ，HTML ，C++ BUILDER ，Visual C++ 通信协议：TCP/IP ，X.509安全和保密要求：Notes 提供的七级权限控制；CA 加密认证；开发过程中须遵守的某些标准或规则：编码规范采用Notes Script 、C++ BUILDER ，Visual C++的编码规范进行。
3. 具体需求本章应包括在进行软件结构设计时所需的全部细节。
3.1. 总体要求1、基本要求：构建行政服务中心政务平台，实现办件处理网络化、无纸化、科学化，内部办公自动化与政务公开化的要求，并为领导提供办件相关的统计与决策分析数据。
2、软件结构：行政服务中心政务平台采用B/S3、操作时限要求：文档处理平均响应时间为1秒，不包括查询与统计时间。
4、流程要求：提供可视化的方法修改和自定义工作流程。
流程中的人员配置、工作流控制和工作流应用三者完全分离。
人员配置是根据工作需要对工作人员进行适时配置；工作流控制可以控制工作流的流向、属性，并根据人员配置分配流程中的人员属性以及管理工作流之间的信息交换；工作流应用能够根据用户的不同流程需要开发出不同的流程应用。
流程具备回溯功能，具备流程监控功能。
5、文档管理、查询要求：能将各种办件处理结果或情况按月进行归档。
6、操作接口要求：分为B/S与C/S两种类型，B/S 体现一种清晰，严谨之感觉。
这个接口的体现是多为录入，查询与审批。
C/S 提供相应的应用接口，对无使用权限的功能不在接口上显示。
操作尽量简单，好用、易用。
这个接口体现多为管理，统计分析。
7、安全要求：严格的权限控制，严谨的保密设计。
采用NOTES的七级安全控制与CA加密认证的处理方式相结合的过程。
8、用户分类控制：使用对象按不同的标准备分为不同的类型：其中主要按使用功能对象来说分可分为：系统管理员、领导（监督者）、窗口单位操作者、公众。
9、委托授权要求：提供委托办理功能，如果在工作流中某个环节上的工作人员不在时，可由该工作人员指定代办人员来协助完成办理，有效避免了文档在某一环节的停滞。
10、流程监控和提醒功能：能自动搜索逾期未办件文档，对逾期未办件文档或指定文件进行催办，并可查看催办情况及答复催办。
当出现逾期未办理的办件，系统会自动给出文字提醒。
3.2.功能需求本节描述2.3节所述的每一功能需求。
本节可以划分为若干小节，每一小节逐一说明每一功能需求。
本节将该功能需求具体描述为输入、处理和输出的需求。
本节可用自然语言描述；也可用形式化的方法描述，如数据流程图（DFD）、IDEF0方法等。
本节由以下内容组成：输入：详细描述该功能的所有输入资料，包括：输入源、类型、长度、数值范围、精度、量纲、数量、更新和处理频度等；处理：定义对输入资料的全部操作，以获得预期的输出资料，包括：输入资料的有效性检验、操作时序或优先级、异常情况处理、输出资料的有效性检验等；输出：详细描述该功能的所有输出资料，包括：接受者、类型、长度、数值范围、精度、量纲、数量、出错信息等。
所有字体都要求以宋体为主，正文内容按具体的行文进行处理。
3.2.1.系统门户子系统3.2.1.1.内网门户操作界面：首先出现登录界面（该界面的背景为行政务服务中心图片）：登录进去之后，出现系统操作主界面：其中XX件超时为链接，点击就可以进入超时的办件视图。
3.2.1.2.外网门户以下为门户网站的外网界面：选中法律法规、审批事项，政府公告、规章制度、领导介绍、中心简介、中心职能,窗口单位电话时出现如下的界面：其中电子邮件是为行政服务中心设置的外部邮箱。
采用notes的电子邮件系统。
其界面如下：采用Notes自带的WEB邮箱点击主页上的网上咨询时出现对于没有答复的咨询不显示,点击我要咨询时出现如下表单样式。
打开问题时出现打开答复时出现:点击菜单上的网上投诉时现网上投诉表单：3.2.2.办件管理子系统办件管理的主界面如下：3.2.2.1.一站式申报模块点击主菜单上的网上申报时出现：当按确定时：系统弹出如下的信息点击完成就会关闭窗口。
点击继续申报出现如下的窗口：其中除了申报单位，申报项目，附件为空，其余的继承刚才填写的内容。
点击新的申报出现一个新的申报单。
3.2.2.2.一站式受理模块一站式受理子系统分为受理窗口办件与受理网上办件：选中一站式受理会出现如下的界面a.受理窗口办件点击一站式受理右边的窗口受理按钮出现如下的窗口办件主界面如下：当按提交时：系统弹出如下的信息受理时开始计时，一直到网上办结，点击打印就会打印出该申报单。
点击继续申报出现新的受理表单。
b.受理网上办件网上办件是来源于一站式申报的数据，其中界面如下：选中需要审批的，再选中右面的一个文档出现如下的办件受理界面：当按提交时：系统弹出如下的信息点击继续受理会出现下一个要受理的网上审批单。
3.2.2.3.网上审批模块选中需要审批的，右面的一个文档出现如下的办件审批界面：总的审批意见是显示前面审批人的意见。
当按提交时：系统弹出如下的信息点击继续审批会出现下一个要审批网上办件单。
3.2.2.4.网上办结模块网上办结的主界面如下：选中右面的一个文档出现如下的办件审批界面：总的审批意见是显示前面审批人的意见。
当按办结密码正确时：系统返回如下的信息点击继续办结会出现下一个要办结的网上办件单。
3.2.2.5.网上查询模块网上查询提供用户查询、模糊查询和综合查询、密码查询。
a.用户查询用户查询为如下界面点击确定后若申报号和密码符合则出现申报信息，见下图：b.模糊查询其界面如下：点击确定后将出现如下的界面：选中一个文档出现如下的办件审批界面：c.综合查询点击综合查询后将出现如下的界面：用户选择字段，关系符，输入值，选择与/或，添加条件到条件框中，不断的添加直到最后用户点击进行查询按按钮。
其中查询出来的信息如下：选中一个文档出现如下的办件审批界面：d.密码查询该模块对具有密码查询管理的人员才能使用，提供办件号输入，然后显示密码。
3.2.2.6.网上统计模块点击项目统计时出现：进行统计的结果：3.2.2.7.网上监督模块点击网上监督时出现：点击其中的一条记录时出现：3.2.2.8.网上咨询模块点击网上咨询时出现咨询管理界面：咨询按时间先后倒序排列，点击某一条网上咨询时出现如下的咨询表单信息：点击文档里面的答复都可以答复文档。
3.2.2.9.网上投诉模块点击网上投诉时出现投诉管理界面：点击某一条投诉时出现如下的投诉表单信息：3.2.3.决策分析子系统决策分析是自动在月初将上月的办件数据统计出来，放于决策分析库中，以利于领导做出分析。
3.2.4.触摸屏查询子系统触摸屏查询分为项目信息查询与办件查询。
3.2.4.1.项目信息查询点击项目信息查询出现如下的界面：进入XX局里面就出现该局的项目现点击具体项目出现该项目的信息.其中的图片做到用户可以方便更换。
3.2.4.2.办件查询选中一个文档出现如下的办件界面：3.2.5.系统管理子系统系统管理总体界面如下：通过Notes登录：3.2.5.1.假日设置假日设置具有设置假日的功能。
当设置了假日后，用户可以按照需要更新一下以前的办件的完成时间。
3.2.5.2.数据整合直接连接到数据整合模块上。
3.2.5.3.用户管理采用Notes用户管理界面。
3.2.5.4.流程管理直接连接到topworkflow的配置库里面。
3.2.5.5.权限管理实现对办件库的权限管理。
3.2.5.6.系统配置实现对办件所需的各种项目的配置。
3.2.5.7.日志管理连接到Domino的日志上面。
3.2.5.8.数据备份实现办件数据的定时备份。
其中定时备份为每月的第一天早上将上一个月的办结数据备份到一个办结数据库中，并将已经备份的数据从办件库中删除。