金税三期工程架构服务需求

金税三期工程 架构管控 项目 第 1 页 /共 34 页 目录 第 1 章 . 3 总体战略目标 . 3 总体技术目标 . 4 总体架构要求 . 5 第 2 章 应用设计约束 . 6 规划思路 . 6 纳税人渠道 . 6 功能约束 . 6 技术约束 . 7 纳税服务应用支撑 . 9 功能约束 . 9 技术约束 . 9 第 3 章 数据设计约束 . 11 规划策略 . 11 数据分类 . 11 数据质量 . 12 第 4 章 集成约束 . 13 界面集成 . 13 应用集成 . 13 数据集成 . 14 安全集成 . 14 第 5 章 非功能性约束 . 16 范围 . 16 系统性能 . 16 可靠性 . 17 可用性 . 18 易用性 . 18 可维护性 . 18 可扩展性 . 20 可伸缩性 . 20 可移植性 . 20 可重用性 . 20 第 6 章 安全性约束 . 21 安全等级要求 . 21 策略和措施 . 21 应用层安全 . 22 应用系统安全设计要求 . 22 应用开发安全要求 . 23 金税三期工程 架构管控 项目 第 2 页 /共 34 页 身份认证系统 . 23 全防护 . 24 数据层安全 . 24 终端安全策略 . 24 系统层安全 . 25 网络层安全 . 26 网络结构安全 . 26 划分子安全域 . 26 网络访问控制 . 26 恶意代码防范 . 27 网络安全审计 . 27 边界完整性检查 . 27 入侵防范 . 27 网络设备安全防范 . 28 物理层安全 . 28 第 7 章 部署约束 . 29 第 8 章 架构管控约束 . 30 第 9 章 标准约束 . 32 标准体系概述 . 32 系统标准遵循说明 . 33 金税三期工程 架构管控 项目 第 3 页 /共 34 页 第 1章 金税三期概述 总体战略目标 金税三期工程的业务战略目标是： 统一税收执法； 统 一纳税服务； 统一 管理决策 ； 统一征管数据实时监控。 首先，统一税收执法是在国家税法统一的前提下，以总局统一的政策管理为依托，包括国、地税税收执法尺度的统一，为纳税人提供公平、公正的税收环境。在现阶段，公平、公正是对纳税人最好的服务。同时，统一税收执法，也是现阶段实现应收尽收，保证税款及时入库的有效保证。 其次，统一纳税服务，不是简单的建立一个平台，而是保证服务目标、服务内容、服务水平的一致，避免不同地区、不同税务人员对同类事项执法不一、口径各异和服务差异。 第三，统一 管理决策 ，是采用科学的方法，利用数据集 中和信息共享手段，为各级领导提供一致的管理和决策依据。 第四，建立在全国大集中基础上的统一实时的征管数据监控，是促进统一执法、统一服务、统一 管理决策 的手段保障。 在国内外新的经济形势下，为了实现四个统一的战略目标 ,总局确定了信息管税的总体战略，信息管税就是以税收风险管理理念为指导，以现代信息技术为依托，以对涉税信息的采集、应用为主线，优化资源配置，完善税源管理体系，加强业务与技术的高度融合，着力解决征纳双方信息不对称问题，不断提高税法遵从度和税收征收率。 其中，信息管税是一项系统工程 ,必然要涉及到税务管理的 思想观念、制度机制、业务流程、组织机构等一系列变化。 如下图所示： 金税三期工程 架构管控 项目 第 4 页 /共 34 页 这里的“全国大集中”，涵盖 核心业务系统 全国集中部署和应用，统一业务需求管理、统一应用开发和运行维护管理。 总体技术目标 金税三期工程建设的主要内容是：计划用四年时间，在现有资源基础上，通过制度、业务和技术创新，完成“一个平台、两级处理、三个覆盖、四个系统”的建设，进一步强化纳税服务和税务管理，提高税法遵从度和税收征收率，降低税收成本，为税收法律法规的统一执行提供有力保障。上述目标 可具体概括为“一门户、三网、四平台、七库”，具体描述如下： 1、“一门户”是通过实施全国数据大集中，优化业务流程和功能配置，统一国地税征管系统，为全国各级税务人员提供统一的内部门户和工作平台，实现全国税收业务的统一、规范管理。 2、“三网”是建成税收征管业务网络、行政办公网络、涉密网络，这三个网络全国国、地税统一建设，具备强大的信息采集、存储、处理、交换等功能，安全可靠程度高，确保各项税收业务与管理在统一、安全、稳定的网络化信息平台支撑下平稳运行。 3、“四平台”是指建设全国统一的纳税服务平台、征管和行管业 务操作平台、 管理决统一税收执法 统一纳税服务 统一管理决策 统一征管数据实时监控 统一全国征管数据标准、口径 统一国、地税核心征管应用系统版本 实现全国征管数据大集中 统一、规范全国的纳税服务平台 以 术整合行政管理系统 以流程管理理念开发征管系统 以风险管理理念开发管理决策系统 建设网络实时开具的电子发票平台 金税三期的业务战略 总体战略 树立税收风险管理理念 以数据的采集和分析为核心 以健全税源管理体系为落脚点 加强业务、技术高度融 合 信息管税 金税 三期的六个亮点 信息管税 金税三期工程 架构管控 项目 第 5 页 /共 34 页 策 平台，这四大平台能使广大纳税人方便、快捷地办理各项税费事宜，广大基层税务人员高效、简洁地处理各项业务，使各级税务管理者及时有效地实施管理与决策。 4、“七库”是指在总局、省局两级建立并逐步完善法人涉税数据库、自然人涉税数据库、发票数据库、第三方信息数据库、税收风险管理数据库、税务机构数据库（包括财务、固定资产等）和人力资源数据库、税收法规数据库（包括文件、档案等）这七个数据库，并进行数据的集中存储和处理，同时建立第三方信息共享机制，实时、完整、准确地掌握纳税人涉税费信息和税务机构、人员等 情况，以利于提高税收服务与管理水平。 总体架构要求 总体架构既包含业务、应用、数据、技术、安全 等方面的框架，也包括架构管控 的体系。一方面，作为框架，总体架构定义了业务、应用、数据、技术、安全等架构的目标蓝图，还包括相关模型，及各部分的指南、设计准则，项目需要根据总体架构的约束来实现其 应用；另一方面，作为架构管控 ，它指明了项目在进行项目实施的时候需要遵守的标准、规范，可以参考的相关架构资源以 及需要遵守的架构管控流程，以确保项目的实施符合金税三期的总体规划 。 总体架构主要由业务架构、应用架构、数据架构、技术架 构（包括系统软件、基础设施等）、安全架构、运维架 构、标准、架构 管控 体系等组成，这些总体架构的内容将构成对项目 架 构方面的约束，项目需要在这些架构的约束下进行业务需求分析、设计以及 实现。 金税三期工程 架构管控 项目 第 6 页 /共 34 页 第 2章 应用 设计 约束 规划思路 按照 金税三期总体 应用架构 规划设计 ，纳税服务系统由 服务渠道、 纳税服务应用支撑两部分 组成，其中服务渠道包括 大厅、网络 、 电话 、 短信、邮寄、自助终端 ，在整体金税三期应用环境的位置如下图中 红色框 部分所示。 但综合考虑业务的连续性耦合度要求和项目 划分及 实施的情况，大厅 、自助终端以及邮寄 的建设划入核心征管系统项目。 下面 重点对 纳税人渠道 和 纳税服务应用支撑 的功能 约束 和技术约束 进行说明 。 纳税服务 渠道 功能约束 纳税 服务 渠道 从技术手段主要包括网络、电话、短信以及邮寄，从支撑的业务范围 主要 包括 三类服务，一是面向包括纳税人在内的所有公众提供的静态信息服务，它是宣传税务局形象的窗口；二是为纳税人提供信息 交互服务的通道 ；三是纳税人办税的 重 要 服务形式 ，它是一个虚拟的 办税服务 渠道 。 渠道的技术实现要求支持以下几类形式 ，其中 大厅、自助终端、 邮寄类渠道由核心征金税三期工程 架构管控 项目 第 7 页 /共 34 页 管来负责处理 ： 网络 ： 提 供基于网站的 各类 服务 ，包括通知公告发布、纳税人互动交流以及在线业务办理的相关功能 等 。 电话 ： 提供基于电话语音的各类服务， 包括通知公告发布、纳税人互动交流以及在线业务办理的相关功能 等 。 短信 ： 提供 统一的短信 服务，包括通知公告发布、 业务 交互 等服务 等 。 此外要求能够接入未来的各类商业纳税人端渠道，提供统一的技术和数据接入标准。 渠道服务 主要包括以下 内容 ： 通知公告 ：对纳税人提供各类通知公告的机制。 税法宣传 ： 包括税法法规和办税指南 等 。 预约： 提供对各类预约业务的支持。 涉税公告： 包括定额公示公告、非正常户公告 、欠税公告、催报催缴和违法违章公告 等 。 电子邮件： 在网络 渠道中 提供电子邮件 的 方式实现同纳税人的交互。 互动交流： 包括 咨询 、举报投诉建议、 评价 调查、在线访谈和电子导税员 等 。 涉税查询： 包括发票查询、登记信息查询、欠税查询、信用等级查询和发票真伪查询 等 。 个性化服务： 包括涉税提醒和受理反馈信息 等 。 在线办税： 包括税费申报、实时缴款、财务会计报表、网上认证、网上抄税、委托代征、出口退税申报和网上开票 等 。 所有渠道必须 提供统一规范标准的接口 支持各种形式的数据导入 。 具体 功能 参见业务需求。 技术约束 服务渠道 建设统一的 信息访问入口，包括静态信息服务、 信息交互服务和 办税服务，统一访问后台所有需要访问的应用系统和信息资源，并为用户提供个性化服务。 服务渠道提供 门户框架、内容管理、 短信、电话语音、安全认证 、系统集成 等 功能 ， 具体 如下： 名称 定义 技术约束 金税三期工程 架构管控 项目 第 8 页 /共 34 页 名称 定义 技术约束 门户框架 提供各类网站页面开发、部署、运行、 管理以及集成的框架环境。 考虑到 网络渠道 需要加载的业务未来将会不断增加，要求必须能够提供完整的门户框架来保证不同类型业务的扩展需求。 纳税人个人门户管理机制 提供界面布局、样式以及内容的个性化定制机制。同时包括纳税人的个性信息、个 人涉税记录等各类能够进行个性化定制的功能和信息机制。 为了更好的提升纳税人的交互体验，方便纳税人网上办税，要求提供纳税人个人门户空间机制，允许其在一定范围内根据个人喜好进行功能和信息层面的定制。 内容管理机制 提供完整的 网络 信息 采集、审核、存储、 全文 检索、发布平台环境，实现对各类信息的统一管理 。 内容管理是实现 渠道 信息公开类业务的关键性技术，要求必须提供能够满足全国集中规模下的内容管理平台环境。 短信 机制 提供完整短信平台，实现基于短信的信息发布、提醒通知 、业务交互 等功能 短信方式是实现对纳税人主动服务 的一种重要手段，因此要求必须提供能够满足全国集中规模下的 短信 管理平台环境 。 电话 语音机制 提供完整的基于电话的语音服务平台，实现同纳税人的互动交流以及相关业务办理等功能。 要求必须提供能够 满足全国集中规模下的 电话语音 管理平台环境 。 可靠的 认证 机制 提供可靠的认证方式，以保证整个 渠道 的访问的安全性。 要求必须提供满足安全策略要求的认证方式，支持总局统一的安全认证机制。 数字 签名及 数据 加密 提供 数字 签名及 数据 加密机制 。 为了保障网上涉税业务中纳税人的权利和义务， 服务渠道 必须提供符合全局安全性要求和标准的数 字 签名和 数据加密机制 。 页面表单 提供页面表单的缓存管理，避免页面重复生成带来的性能开销，提升交互的响应时间 。 对于大量的静态信息页面以及频繁使用的各类业务模板 ,要求采用页面缓存机制来提升性能 。 代码缓存机制 提供代码缓存机制 ,降低大量代码数据对网络、磁盘 消耗，提升系统整体的性能 。 考虑到全国大集中模式下各类代码数据会急剧增加，因此必须在客户端提供不同策略的代码缓存机制，有效缓减海量代码带来的性能问题 。 并发控制 并发控制是提升系统可靠性，降低系统性能风险的关键性机制。通过并发控制，及时掌握系统 当前的用户访问流量，进行监控预警。并发控制作为前端的一个总控点，需要保证健壮和稳定，并且支持分布式部署。 考虑到全国大集中模式下 各类渠道 的业务量会逐年上升，因此必须提供并发控制来有效保障系统的可靠性 。 金税三期工程 架构管控 项目 第 9 页 /共 34 页 纳税服务应用支撑 功能约束 纳税服务应用支撑 是提供给税务干部进行 纳税人交互类服务处理的 统一 、 集成 、多种服务渠道共享 的 平台，它主要包括 例如 集成的联络界面、纳税人 接触历史 管理、 渠道集成、功能集成、 服务管理等内容 . 集成的联络管理界面： 提供一个以纳税人为中心来组织纳税人各类信息的统一的界面视图，便于税务干部 迅速、准确的处理纳税人提出的各类服务请求； 接触历史管理 ： 为税务干部提供完整的纳税人和税务局之间发生交互行为的历史信息； 渠道 服务 集成 ： 必须提供统一的渠道接入标准，同时 能够 根据需要 接入 或者访问多种服务渠道， 并 能把来自不同渠道的 交互类 服务 请求进行统一管理 ； 功能集成： 能够实现将服务信息内容与核心征管、 行政管理、 风险管理和知识库等进行相应功能集成。 数据集成： 纳税服务应用支撑必须保留能够支撑纳税人进行各类查询的业务明细数据和业务状态数据，根据各类业务数据的特性提供相应的数据同步策略和机制。 交互 类 服务 ： 实现各类 渠道的咨询、预约、通知通告、评价调查、提示提醒、举报投诉等交互服务的处理； 查询 类 服务： 为 各类渠道 提供纳税人 相关的业务状态以及业务明细数据 的查询服务。 服务 质量 管理： 对 税务干部提供 纳税人 的 服务 进行质量 管理， 如服务评价、服务满意度调查、服务监督 等。 技术约束 纳税服务应用支撑 技术约束包括以下几个部分 ： 名称 定义 技术约束 流程处理机制 实现 纳税服务应用支撑 中相关服务的流程定义、运行、监控和维护机制。 与总局指定的流程管理平台能兼容和互操作。 金税三期工程 架构管控 项目 第 10 页 /共 34 页 名称 定义 技术约束 界面集成支持 支持统一的业务工作门户和外网纳税服务门户进行界面层集成，界面层的设计和开发必须遵循界面集成标准。 总局会建设全局统一的业务工作门户和外部纳税服务门户，实现所有业务系统界面层的一体化展现，以及面向纳税人的纳税服务门户，要求 纳税服务应用支撑 的界面环境必须能够实现与业务工作门户和外部纳税服务门户的完全融合 渠道集成机制 对于各类服务渠道，需要提供完备的管理机制，定义和维护渠道的接入协议、接入报文规范、接入安全机制、服务质量等特性 纳税服务应用支撑 信息来源众多，涉及到征管、 管理决策、行政办公、 网络 ，12366、短信、电话、外部门反馈等多个信息来源渠道，针对这些 众多的信息来源渠道， 纳税服务应用支撑 平台需要提供完善的渠道集成机制。 服务监控机制 实现对各类型 纳税人 服务的实时监控，使得纳税人和税务干部能够实时掌握关键服务的动态执行过程 、结果 ，以及服务提醒。 纳税服务应用支撑 是集成以纳税人为中心的各类服务，要求提供服务监控服务机制，使税务干部和纳税人能够实施掌握关键服务的流程，执行状态，并能够为其相关业务平台提供服务提醒功能或者提醒机制。 符合服务集成封装机制 符合全局的服务注册、调用以及管理标准，能够很方便的将内部业务逻辑根据需求封装为全局性服务，以供其他系统进行 消费 所有需要提供给外部各应用的业务接口，必须符合全局的应用集成体系所定义的服务集成标准，从而保证各类对外暴露的服务能够被其他应用所共享 知识库集成机制 提供与知识库进行衔接的集成机制 一方面 ， 纳税服务应用支撑 利用知识库的知识为纳税人提供服务， 另一方面 纳税服务应用支撑 形成的知识 纳入知识库管理 。 金税三期工程 架构管控 项目 第 11 页 /共 34 页 第 3章 数据设计约束 规划策略 在金税三期的大集中战略指导下， 纳税服务系统 数据设计 应遵循以下 关键 策略： 性能优先 考虑到全国大集中后各类渠道业务量将会持续增长，因此数据设计必须以性能为关键设计原则进行优先考虑，充分考虑数 据 模型设计和物理 分布给性能带来的影响。 共享 状态 信息 集中管理 各渠道需要共享的各类业务数据，例如纳税人基本信息、业务状态信息等，统一由 纳税服务应用支撑 集中管理，以服务的方式提供给各渠道使用。对于各类渠道业务的状态信息，例如纳税人咨询交流状态、业务办理状态等过程信息将统一由 纳税服务应用支撑 进行集中管理，以服务方式提供给各渠道使用。 渠道共享信息的范围和手段必须从性能角度去分析，如果性能不能满足建议采用渠道冗余存储的方式。 业务明细数据集中管理 针对各类纳税人查询的明细数据，考虑到未来全国大集中带来的查询性能压力 ，因此要求各类渠道查询必须用到相关业务明细数据集中 可以 由核心系统同步到纳税服务应用支撑。提供合理的数据复制策略，在不影响核心系统性能的情况下，保证业务 明 细数据的及时性 、一致性和完整性 。 采用适当的数据库设计，避免全国数据大集中的性能瓶颈。如支持缓存数据、根据内聚性按照那个某种业务属性进行数据库拆分等。 数据分类 纳税服务系统 至少包含以下类型的数据： 静态类 服务 信息 外网网站数据是指外网网站采集和发布的信息，它用于 支持总局外部网站的静态类应金税三期工程 架构管控 项目 第 12 页 /共 34 页 用 主数据 包括纳税人基本信息、纳税人状态信息、代码信息等数据的副本 ，这类数据原则上统一由 纳税服务应用支撑 进行存储管理 ； 业务交易明细数据 包括各类涉税查询的业务明细数据，对于实时性要求不高的各类交易明细数据 可以 将其统一同步集中存储到纳税服务应用支撑。 渠道 交易类数据 包括受理各类网上办税业务时产生的 本地数据、 临时缓存 和暂存 数据，如 纳税人的本地渠道数据、申报临时数据、 网上预约、网上申报 暂存 记录 等 信息 ； 交互服务类数据 为纳税人提供交互类服务时产生的数据，例如咨询历史记录、调查信息、投诉举报信息等等。 数据质量 数据质量 管理应遵循“事前预防、事中监控、事后补救”的设计思 路： 事前预防，指在数据录入时提供在线帮助，提示数据的录入规范； 事中监控，指在数据录入端引入对数据项的校验功能，包括数据格式校验、逻辑关系校验等，对录入错误及时发现并提示修改，有效避免错误数据的进入； 事后补救，指数据录入后，基于标准进行数据质量的审计，对错误数据提供更正界面，以避免后台数据库调整；同时，制定规范的数据更正流程，确保数据修改的高效执行和安全管理。 金税三期工程 架构管控 项目 第 13 页 /共 34 页 第 4章 集成约束 金税三期 纳税服务 系统 项目要遵循架构设计约束 ，在应用架构、集成架构、数据架构、安全架构设计等方面要求遵循金税三期相关技术规范和标准。 整体的集成环境说明及相关要求和策略请参见应用总集成架构需求文档，下面给出纳税服务系统需要遵循的相关集成要求。 界面集成 服务渠道 的主要用户是纳税人 ， 纳税服务应用支撑 的主要用户是税务人员 ，它们在界面集成的要求上 有些区别 ， 主要的界面集成要求如下 ： 针对 纳税服务应用支撑 的界面集成要求： 要求 纳税服务应用支撑 遵循总局统一内部工作门户集成标准 ； 要求 纳税服务应用支撑 支持统一单点登录控制 ； 要求 纳税服务应用支撑 支持统一的用户管理； 针对 网络 渠道 的界面集成要求： 要求 网络 渠道 遵循总局统一外网门户集成标准 ，即静态信息 服 务 、办税信息服务和交互信息服务符合 外网 门户框架的 集成标准 ； 要求 网络 渠道 遵循安全架构要求 应用集成 纳税服务 系统 应用集成包括 渠道系统 与 前置系统 的集成以及渠道系统与 纳税服务应用支撑 系统的应用集成 ，要求遵循总局统一的应用集成架构设计规范和标准。 1、 要求 必须遵循总局应用集成架构制定的服务协议标准。 2、 要求所有应用系统中需要被外部应用调用的功能必须将其暴露为共享服务，注册发布到全局的应用集成平台之中。 3、 要求渠道 采用总局集成标准接口与 总局前置进行集成 ，所有涉及渠道与核心系统的交互都必须通过前置来进行，不能直接访问核心系统。 4、 要求 纳税服务应用支撑 采用总局集成标准接口与 各类渠道进行集成。 金税三期工程 架构管控 项目 第 14 页 /共 34 页 5、 要求 纳税服务应用支撑 采用总局集成标准接口与 后台系统集成，如核心征管、知识库、风险管理、行政管理等 。 数据集成 纳税服务 系统 涉及到的数据库有 总局外网网站数据 、 外部应用业务数据 和 纳税服务应用支撑 数据库，内部各数据库之间存在多种数据交换 模式，同 核心征管 系统与管理决策系统 之间还存在数据 层 交互。 数据集成应用场景的不同，需要采用不同的数据集成策略，但都必须遵循以下数据集成原则，同时 在数据库设计时遵循总局统一的数据集成规范和标准。 1、 对于海量数据，有较高的实时性要求，如主库同备份库之间数据集成、同构库间的数据同步复制、总局到省局的数据库下发等要求采用物理库表级的集成策略。 2、 对于批量或异构数据，实时性要求不高，集成逻辑比较复杂，需要大量转换的如生产库到 向各类主题的统一操作型数据存储数据库）， 数据仓库；生产库到历史库；有非结构库到结构化库要求基于 据的抽取、转换、装载）的批量集成策略。 3、 对于 基于文件的非结构或半结构化数据，如总局同省局的跨层级交换、总局同外部机构间的 数据交换、其他涉及到文件交换的场景等要求基于消息报文的集成策略。 4、 对于 小数据量，实时性要求高，如应用系统间的实时数据访问、构建虚拟的数据视图等要求可以基于数据服务的集成策略。 安全集成 纳税服务 系统 安全集成包括与总局和省局应用安全支撑平台等几方面内容集成，安全集成要求遵循总局总体应用安全支撑体系规划要求。 要求支持总局指定的认证管理机制； 纳税服务应用支撑 必须遵循全局的用户管理 要求支持认证与权限分离，支持多种身份鉴别机制，例如 户名 /密码、动态口令、 等 ，未来可以灵活扩展； 金税三期工程 架构管控 项目 第 15 页 /共 34 页 所 有渠道必须遵循全局标准的前置接入安全标准 . 必须遵循全局标准的数据签名和加密标准 必须遵循全局标准的数据通道安全标准 金税三期工程 架构管控 项目 第 16 页 /共 34 页 第 5章 非功能性约束 范围 非功能需求规定了系统必须满足的服务水平、系统非运行时间的属性以及系统必须遵守的约束。非功能需求适用于整个系统、系统的几个部分或特定的用例。 非功能需求虽然不直接影响系统功能，但在用户和系统支持人员对该业务系统的认可方面具有很大的影响。 非功能需求包含许多方面。主要的非功能需求包括以下几方面： 系统性能 可靠性 可用性 易用性 可维护性 可扩展性 可伸缩 性 可移植性 可重用性 系统性能 交易可以定义为：一个交易是当一个单一角色跨越系统边界触发一个事件并执行一定数量的处理和数据库访问，它将影响架构中的所有服务器层。交易响应时间指完成目标系统中的交互或批量处理所需的响应时间。 根据业务处理类型的不同，把交易划分为三类：交互类业务、查询类业务和大数据量批处理类业务，分别给出响应时间要求的参考值，包括峰值响应时间、平均响应时间。 交互类业务 日常交易指传统的大厅交互业务，如申报、发票销售、税务登记等，具有较高的响应要求。 金税三期工程 架构管控 项目 第 17 页 /共 34 页 业务复杂性 平均响应时间 参考值（秒） 峰 值响应时间 参考值（秒） 日常交易 3 秒 5 秒 备注：以上交易如果涉及与其它系统之间交互，响应时间应包括系统之间交互的时间 ;以上给出的响应时间 为 参考值， 查询类业务 查询业务由于受到查询的复杂程度、查询的数据量大小等因素的影响，需要根据具体情况而定，在此给出一个参考范围。 简单查询 如登记资料查询、 业务清册、 申报表查询等。 复杂查询如多表数据关联统计分析查询类报表等等。 如有特殊要求，可以在具体用例文档中单独给出响应时间要求。 备注：业务处理过程的交互操作的响应时间参见上面交互类业务的相关指标。 大数据量、批处理业务 批量交易指一次完成多笔业务处理的交易，如批量扣缴等，由于批量交易的数据量不确定，需要根据具体的情况确定响应时间。 业务复杂性 平均响应时间 参考值（秒） 峰值响应时间 参考值（秒） 批量交易 视提交数据量、业务处理量而定 可 靠性 1、 最大宕机时间 网络渠道 ： 最大宕机时间 1 小时 。 纳税服务应用支撑 ： 最大宕机时间 1 小时 。 12366 系统 参考 12366 系统现有非功能性需求。 短信 ：最大宕机时间 8 小时。 电子邮件 ：最大宕机时间 8 小时。 2、 系统备份 金税三期工程 架构管控 项目 第 18 页 /共 34 页 提供备份系统，防止单点故障 3、 灾难恢复备份 遵循 金税三期工程容灾设计方案。 可用性 业务 系统 应满足 7 24 小时可以使用。 易用性 1、 易理解 a) 系统所有的业务功能界面风格和操作流程一致； b) 业务表单尽量做到所见即所得； c) 界面美观、简洁、高效；界面各部件的布局应该保持合理性和一致性； d) 界面风格一致，颜色调和、提示清晰、窗口大小适当，使用方便。 e) 在选择快捷键、缩写、暗示和图标时应符合 税务行业为 习惯。 2、 易操作 a) 常用操作有快捷键支持，大部分操作能够在小键盘内完成； b) 信息录入能够完全通过键盘完成； c) 无论逻辑步骤还是操作步骤都应避免繁杂。 3、 易学习 a) 提供在线帮助，系统关键业务 操作应提供在线帮助文档和提示信息，使操作人员能够快速直观的利用这些信息进行相应的业务操作，并 对各种状态和操作结果进行及时的反馈和提示。 b) 提供符合税务行业习惯， 详细、易读、易理解 的操作 使用手册 4、 需遵循“金税三期”工程的界面集成标准规范； 可 维护 性 1、 可配置 a) 人员机构的可维护 金税三期工程 架构管控 项目 第 19 页 /共 34 页 系统应具备人员 /机构等基础信息的维护功能，系统应该能够快速的对人员 /机构信息进行维护和调整操作。 b) 岗位权限的可维护性 系统应具备岗位权限的维护功能，系统应该能够快速的对岗位权限进行权限赋予和回收等维护操作。 c) 业务流程的可维护性 系统主要业务 流程应具备维护功能，可根据业务规则的变化快速的对业务流程进行调整维护操作。 d) 服务接口的可维护性 系统主要业务功能应提供标准的服务交换接口，可通过开关配置快速的提供对外服务能力。 e) 参数指标的可维护性 系统应具备规范、完善的参数指标的管理功能，具备针对系统运行基础性能参数进行配置和维护的功能。 2、 可监 控 a) 提供日志审计功能 系统每个组件应具备规范、完善的的日志管理功能，具备多级日志搜集开关、有效 /失效开关、性能指标搜集开关以及开配置参数表。 b) 业务流水机制 为保证 关键 业务一致性，建议考虑 采用 流水机制。 c) 标准监控协议支 持 符合业界主流监控软件的接口规范，能够将监控数据方便的接入 到监控软件中 ，便于集中监控和管理； 3、 可读 、易于修改 要求在系统的建设过程中要有规范、清晰、完整和详细的文档，如业务需求阶段要有业务用例模型、业务活动图、业务规则、表证单书等；系统需求分析阶段要求有系统用例模型、用例文档、规则说明等；概要设计阶段要求有宏观设计文档；详细设计阶段要求有类图、时序图等；编码阶段要求有程序设计说明、变量定义说明等；测试阶段要有测试用例、测试记录等。 金税三期工程 架构管控 项目 第 20 页 /共 34 页 4、 易于升级 要求数据库、应用服务器、开发工具能方便地进行版本升级，具有向下 兼容性；易于升级也要求客户端的升级工作量较小， 建议采用 浏览器客户端 而不是 户端 。 可扩展性 在设计上必须具有适应业务变化的能力，当系统新增业务功能或现有业务功能改变时（界面的改变、业务实体变化、业务流程变化、规则的改变、代码改变等），应尽可能的保证业务变化造成的影响局部化。 系统应提供一个弹性的架构，支持使用配置而免编程的方式对业务流程、业务表单、查询统计等功能的定制与调整。 可 伸缩性 当系统容量发生变化时，应能通过各个层次的扩充，保证系统合理的响应时间和吞吐量，支持负载的划分与均衡。 可移植性 应用 系统硬件平台无关性，支持主流的硬件平台和操作系统。 可重用性 可重用性主要是指软件产品在不同的系统建设中可以被重复利用的程度。 要提高系统的可重用性，应采用构件化的设计思想，即在提供标准化的服务接口的前提下可以替换各种可选的实现，而不会影响系统其他部分的实现，以此将系统可重用部分可能的变