(CMMI文件)xx银行XX项目需求规格说明书()
(CMMI文件)XXX银行XX平台系统开发项目配置管理计划()
编码：XXXX档案管理平台项目配置管理计划更改控制页序号版本号更改时间更改内容描述填写人目录1目的 (1)2范围 (1)3术语定义 (1)4输入 (1)5项目中配置项的命名 (1)6人员及职责 (1)6.1配置管理人员 (1)6.2配置管理干系人 (2)7配置管理软硬件资源 (2)8配置项计划 (3)8.1配置项 (3)8.1.1基线的配置项 (3)8.1.2非基线的配置项 (4)9基线计划 (6)10配置库规划 (7)11配置库备份计划 (8)12配置项审计计划 (8)13本计划审批意见 (8)1目的明确项目过程中配置管理人员和项目组成员在配置管理活动中的职责和工作范围。
定义配置管理活动过程中采用的工具、方法、技术。
2范围涉及到XXXX档案管理平台项目过程中的所有配置的管理活动。
3术语定义CCB：Change Control Board，变更控制委员会，是公司的常设机构，由公司总裁、研发中心与销售部的相关成员组成，针对不同性质和级别的重大变更问题进行决策，不同的问题组织不同级别的CCB。
4输入依据《项目过程定义书》和《项目计划》完成本计划的编写。
5项目中配置项的命名NK-项目名称缩写-过程名称-类型序号(中文名称)当部分配置项在用当前文件命名规则时,如果仍无法区分可加入日期或姓名配置项命名规则遵循公司<配置项命名规则>文件的要求.6人员及职责6.1配置管理人员角色人员职责及工作范围配置管理员1)选择配置管理工具；2)制定配置管理计划；3)创建配置库、分配权限；4)管理配置库；（包括填写相关的配置管理表格、进行配置库备份等；）5)进行配置审计；6)进行配置变更管理；7)发布基线；8)项目结束后，整理完善文档和记录并提交到组织。
CCB成员1)里程碑评审，基线评审；2)审批重大变更；6.2配置管理干系人角色人员职责及工作范围项目经理审核配置管理活动；项目组成员配合项目经理和配置人员的工作，及时完成和提交配置项；QA工程师定期检查项目的配置管理过程，报告不符合问题；7配置管理软硬件资源配置管理软硬件资源说明配置管理软件名称VSS用来管理文档等；cvs用来管理代码计算机名称计算机配置内存: 4G CPU: 4CPU配置服务器的网络地址128.96.96.348配置项计划作者在开发区完成相关的工作产品后, 工程类产品放入测试评审区，待相关人员完评审修正后，通知配置管理员放入受控区。
银行管理系统 需求规格说明书
银行管理系统需求规格说明书银行管理系统需求规格说明书1.引言1.1 编写目的本文档旨在明确银行管理系统的需求，包括功能、性能、安全性和界面等方面的要求，为开发团队提供清晰的开发指导，确保系统开发符合用户需求。
1.2 读者对象本文档主要面向开发团队成员、项目管理人员及其他相关技术人员。
2.项目概述2.1 项目背景银行管理系统是为了满足银行机构日常运营及客户服务需求而开发的系统。
该系统包括账户管理、贷款管理、存款管理、交易管理等模块，旨在提高银行机构运营效率和服务质量，并满足相应的合规要求。
2.2 项目目标项目目标是开发一个安全、高效、易用的银行管理系统，能够支持多种功能和业务操作，满足银行机构的日常运营和客户服务需求。
3.功能需求3.1 用户管理3.1.1 注册功能：用户可以通过系统注册账号。
3.1.2 登录功能：已注册用户可以通过用户名和密码登录系统。
3.1.3 用户权限管理功能：系统管理员可以设置用户的权限级别和相应的操作权限。
3.2 账户管理3.2.1 开户功能：银行工作人员可为客户办理账户开户操作。
3.2.2 关闭账户功能：银行工作人员可为客户办理账户关闭操作。
3.2.3 账户查询功能：客户可通过系统查询自己的账户余额和交易记录等信息。
3.2.4 账户冻结功能：银行工作人员可对账户进行冻结，防止异常操作。
3.3 存款管理3.3.1 存款功能：客户可以通过系统进行现金存款。
3.3.2 存款查询功能：客户和银行工作人员可通过系统查询存款余额和存款交易记录。
3.4 贷款管理3.4.1 贷款申请功能：客户可以通过系统进行贷款申请。
3.4.2 贷款审批功能：银行工作人员可对客户的贷款申请进行审批。
3.4.3 贷款还款功能：客户可以通过系统进行贷款的还款操作。
3.4.4 贷款查询功能：客户可以查询贷款余额和贷款交易记录。
3.5 交易管理3.5.1 转账功能：客户可以通过系统进行账户之间的转账操作。
3.5.2 交易查询功能：客户和银行工作人员可查询账户的交易记录。
(CMMI文件)中国XX银行XX管理平台项目度量计划
编码：NK-ECM-MA-T01 中国XX银行XX管理平台项目
度量计划
更改控制页
目录
1目的 (1)
2范围 (1)
3项目概述 (1)
4角色与职责 (1)
5资源 (2)
6度量内容 (2)
7度量活动安排 (3)
8分析活动安排 (12)
9审核 (13)
1目的
本文档的目的在于指导公司项目组如何进行度量以及对度量进行分析，以便支持管理对信息的需要。
2范围
本计划适用于XX银行档案管理平台项目，对该项目进行管理信息的收集、管理。
3项目概述
项目名称：银行档案管理平台
任务提出者：XXXX银行股份有限公司
开发部门：北京XXXX科技股份有限公司
使用部门：XXXX银行股份有限公司
项目背景：
为建行档案管理信息指标体系的建立和应用提供技术支持手段，解决建行档案管理信息收集和档案管理落后的面貌，启动了XXXX银行档案工作管理平台项目建设工作。
按照“充分准备、广泛调查、小组讨论、集中梳理、多次迭代、领导决策”的总体工作思路；二是搜集整理分析了总行近两年来制定、下发的各种档案管理制度、通知、会议纪要；说明书涵盖档案管理的所有方面。
4角色与职责
5资源
电脑:数量1,配置4CPU，内存:2G,硬盘40G
相关度量模版
6度量内容
度量内容，即度量项，详细请参见《度量数据表》。
度量目标，写明选择该度量要达到、满足哪些管理要求。
也就是要体现出为何要选择该度量目标。
详细度量的目标参见《度量方法指南》。
7度量活动安排
8分析活动安排
9审核。
(CMMI文件)XX银行XX平台系统拆分项目技术方案()
稽核系统拆分项目技术方案目录1引言 .......................................................................................................................................... 1-11.1编写目的........................................................................................................................... 1-1 1.2项目背景........................................................................................................................... 1-1 1.3定义................................................................................................................................... 1-2 1.4参考资料........................................................................................................................... 1-22系统目标................................................................................................................................... 2-3 2.1总体说明........................................................................................................................... 2-32.1.1项目需求................................................................................................................... 2-32.1.2业务目标................................................................................................................... 2-62.1.3关键质量指标........................................................................................................... 2-72.1.4应用范围................................................................................................................... 2-8 2.2设计策略及遵循的规范 ................................................................................................... 2-82.2.1松耦合整合方式....................................................................................................... 2-82.2.2开放性和可扩展性................................................................................................... 2-82.2.3整合性....................................................................................................................... 2-92.2.4模块化原则............................................................................................................... 2-92.2.5最少开发原则........................................................................................................... 2-9 3技术方案..................................................................................................................................3-103.1稽核系统现状..................................................................................................................3-103.1.1部署现状..................................................................................................................3-103.1.2逻辑结构.................................................................................................................. 3-113.1.3稽核系统拆分策略.................................................................................................. 3-11 3.2集中部署方案（建议方案） ..........................................................................................3-133.2.1拆分后原系统各功能部署方式..............................................................................3-133.2.2总体架构..................................................................................................................3-143.2.3应用架构..................................................................................................................3-153.2.4数据架构..................................................................................................................3-173.2.5技术架构..................................................................................................................3-223.2.6物理架构..................................................................................................................3-243.2.7安全架构..................................................................................................................3-253.2.8与其他系统关系......................................................................................................3-263.2.9环境规划..................................................................................................................3-273.2.10系统维护设计........................................................................................................3-323.2.11技术风险................................................................................................................3-33 3.3分散部署方案（备选方案） ..........................................................................................3-343.3.1拆分后原系统各功能部署方式..............................................................................3-343.3.2总体架构..................................................................................................................3-353.3.3应用架构..................................................................................................................3-353.3.4数据架构..................................................................................................................3-363.3.5技术、安全架构......................................................................................................3-373.3.6环境规划..................................................................................................................3-373.3.7系统维护设计..........................................................................................................3-373.3.8技术风险..................................................................................................................3-37 3.4建议的技术方案 ..............................................................................................................3-384开发计划..................................................................................................................................4-394.1项目工期建议..................................................................................................................4-39 4.2项目时间建议..................................................................................................................4-39 4.3实施进度建议..................................................................................................................4-39 4.4实施方式建议..................................................................................................................4-405投资估算及投入产出分析......................................................................................................5-405.1投资估算..........................................................................................................................5-405.1.1硬件费用..................................................................................................................5-405.1.2软件费用..................................................................................................................5-415.1.3开发费用..................................................................................................................5-415.1.4费用总计..................................................................................................................5-41 5.2投入产出分析..................................................................................................................5-421引言1.1编写目的本技术方案是针对现有会计档案管理及会计稽核系统（以下简称“稽核系统”）实施拆分后，按照稽核作业改造的要求，对现有稽核功能进行优化的基础上，建设新的稽核系统所采用的系统架构、接口设计、性能设计、环境规划、安全保密设计、系统维护设计等内容进行全面的、概括性的说明，为后续的设计、开发工作奠定基础。
(CMMI文件)XXX银行业务资料管理系统项目详细设计说明书()
业务资料管理系统项目详细设计文档修改记录目录1引言 (4)1.1编写目的 (4)1.2项目背景 (4)1.3定义 (4)1.4参考资料 (5)2系统的层次结构关系 (5)3接口设计 (11)4详细设计说明 (12)4.1模块1 (15)4.1.1模块实现的功能描述 (15)4.1.2模块所需达到的性能要求 (38)4.1.3数据采集和输入输出项 (38)4.1.4逻辑流程描述 (38)4.1.5和其它模块的接口和限制条件 (38)4.1.6测试要点 (38)4.1.7目前尚未解决的问题 (38)4.2模块2 (38)1引言1.1编写目的为使档案管理应用优化项目各方对本项目所涉及的业务模式、操作流程、工作内容和系统功能设计和要求有个共同的理解，使之作为项目开发工作的前提和基础，特编写此项目说明书，为下一步的系统代码编写提供设计方案。
供本《详细设计说明书》读者对象为项目组全体人员和测试人员使用。
1.2 项目背景●本项目开发的系统全称为《中国建设银行业务资料管理系统》。
●项目的委托单位、开发单位和主管部门项目的委托单位：中国建设银行会计部项目的开发单位：中国建设银行信息技术部、北京京北方科技股份有限公司项目的主管部门：中国建设银行信息技术部●本系统的目标：本系统此次开发的目标是完成会计凭证及报表存储、查询，同时为系统将来的开发预留接口。
本系统的远期目标是建立一套中国建设银行的跨部门多任务的内容管理平台。
1.3 定义会计档案范围：包括会计凭证、会计账簿和会计报表等会计资料。
会计凭证范围：包括本外币对公、对私业务会计凭证（含清单式凭证）。
会计账簿范围：包括流水账、明细账、总账和登记簿（系统自动登记的登记簿，不包括手工登记的纸质登记簿）。
会计报表范围：包括各报告期核算系统产生的各类日常会计报表和会计决算报表，以及手工编制的报表。
索引：为方便查询对结构化非结构化数据的元数据描述项进行数据库保存，并对主要索引项进行表索引创建。
CMMI需求规格说明书
需求规格说明书变更日志1引言1.1 目的I说明编写这份软件露求说明书的目的,指出狡劭的读-若。
/1.2 背景I说味(1＞恃开发的软料系统的N称:(2)本项目的任务提癌者、开发毒、用户及实现该软件的过算中心或过算机网络:⑶该软件系统同其他系统或其他机构他举本的柏行来往关系。
本过程适用于级次内部的标准软件过程及相关过程资产的泠理,I1.3 定义I下衣列出本报告中专门术语的定义、英文缩写词的磔词组和意义、项R组内达成一致意见的专用词汇.同时继承全部的先前过程中定义过的词汇.]词汇名称词汇含义务注1.4 参考资料t列出用得若的参考资料,如；(I)本项目的经核戏的计翅任务书或合同、上级机关的批文:(2、诚于本项H的其他已发丧的文件:(3)本文件中各处承用的文件、资料、包括所要用到的软件开发标准.列出这鼓文件费科的标SS、M件编号、发衣H期和出版单位,说明能够出到这些文件责料的来源.[■号费科名称说明2任务概述2.1 目标1叙述该项软件开发的意图、应用目标、作用范用似及其他感阳读者说册的有关该软件开发的背景材料。
解弃被开发软件与其他有关软件之间的关盛，姐果木软件产品是•项独立的软件,而且全部内容自含,W说明这一点。
如果所定义的产品是一个更大的系统的一个姐成部分,则应说明本产品与谈系统中其他任组成部分之间能关系,为此可使用一张方框图来说明该系统的组成和本产&网其他界深分的联系和接n.12.2 用户的特点t列出本软朴的最终用户的特点,充分说明糠作人员、维护人员的教育水¥和技术专长,以及本软件的授期使电顿瘦。
这或是软件设计工作的求整约束.)2.3 假定和约束t的出迸行本软件开发工作的假定和约束.纲如姓跟限耐、开发期果等,I3需求规定t以下各小节可节选或者合并.]3.1 对功能的规定t用外衣的方式（例如IFo我即输入、处理、榆出我的形式）,逐项定录和定性适叙述对软件所推出的功能要求.说明输入什么蛾、经怎样的处理、褥到什么输出,说明软件应支持的终於数和应支持的并行操作的用户数。
银行需求规格说明书
银行需求规格说明书1.项目概述用户可以通过银行系统办理各类业务，如注册新用户，取钱，存钱，转账，理财，也可以修改自己的注册信息，查询余额和保险等。
1.2项目任务用户到银行可以办理各项业务，到网上银行可实现相同功能，一个完整的银行系统由后台部分，前台部分和网上银行组成。
1.3项目背景传统的银行方式下,用户需要到银行办理业务,经常需要排队等待。
通过网上银行进行业务办理,银行的业务是在一种“虚拟”的网络环境下进行的,银行可以节约网点，减少服务人员，为用户节约时间。
1.4项目目标1. 银行通过网络可以更多的收集顾客的意见,并让顾客参与系统的设计、开发、修改,为每个顾客提供独特化、个性化的理财或服务,实现一对一服务,真正做到以顾客需求为中心。
2. 良好的双向沟通。
因特网是一种互动式的多媒体,可以利用文字、声音、图像等多种手段将产品或服务信息全方位地展现给用户，用户可以通过互联网从不同角度察看各种业务的办理流程,理性的消费者在对业务各个方面全面了解、比较后,再做出决策。
银行可以通过在自己的网站上提供电子邮件信箱、自由讨论区等了解顾客需求信息和具体要求,并对常见问题进行网上咨询和解答,从而更好地为顾客提供服务。
3.提高业务受理效率。
传统银行方式中,用户办理业务要去银行网点，再等待，办理。
这一过程少则几分钟,多则数小时,再加上往返路程时间,耗费了消费者极大的时间和精力。
现代社会的生活节奏日益加快,人们闲暇时间越来越少,会更加珍惜闲暇时间,充分享受生活,因此网上银行的使用频率将越来越高。
2．系统业务需求利用文字、声音、图像等多种手段将产品或服务信息全方位地展现给用户, 顾客可以通过互联网从不同角度察看各种业务的办理流程,理性的消费者在对业务各个方面全面了解、比较后,再做出决策。
银行可以通过在自己的网站上提供电子邮件信箱、自由讨论区等了解顾客需求信息和具体要求,并对常见问题进行网上咨询和解答,从而更好地为顾客提供服务。
项目需求规格说明书
项目需求规格说明书1. 引言1.1 概述：本文是一份项目需求规格说明书，旨在明确和详细描述该项目的所有需求。
本文将提供有关项目背景、需求概述、需求详细描述以及项目交付与验收标准等内容。
1.2 文章结构：本文按照以下结构进行撰写：引言、项目背景、需求概述、需求详细描述以及项目交付与验收标准。
1.3 目的：本文的目的是为了在项目开发过程中提供一个清晰的指导，确保团队成员对于该项目的需求有清晰而一致的理解。
通过明确定义项目需求，可以帮助开发团队有效地进行系统设计和开发，并且确保最终交付符合客户期望并达到预期目标。
同时，该规格说明书还可作为承包商和客户之间所达成的共识基础，在项目交付和验收阶段起到重要指导作用。
以上是“1. 引言”部分内容的详细描述，请根据需要进行修改或补充。
2. 项目背景2.1 公司介绍我们公司是一家专注于软件开发的科技公司，成立于20XX年。
多年来，我们致力于为客户提供高质量的软件解决方案和服务。
我们拥有一支经验丰富、技术过硬的团队，擅长开发各类定制化软件应用。
2.2 项目背景和重要性随着信息技术的快速发展和社会进步，越来越多的企业开始将业务迁移到互联网平台上。
为了提高效率、降低成本，并更好地满足用户需求，客户希望开发一种全新的基于互联网的管理系统。
该管理系统将涵盖企业内部各个部门的业务流程和数据管理，实现信息共享与协同办公。
通过该系统，企业可以更加高效地进行资源调配、任务分配、进度监控等工作。
这对于提升企业运营效率和竞争力具有重要意义。
2.3 市场需求分析在市场上存在着许多传统方式进行企业管理的方法，如纸质文档、Excel表格等。
然而，在面对大量数据处理、多人协同操作等复杂场景时，这些方式存在许多问题，如信息传递不畅、数据易丢失、人力成本高等。
因此，客户需要一种灵活性强、功能齐全且易于使用的企业管理系统。
通过对市场需求的深入分析和调研，我们发现目前还没有一款完美符合客户需求的解决方案。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
xxxx行股份有限公司信息科技系列XXXX行远程审计平台需求规格说明书目录1引言 (3)1.1 目标 (3)1.2 范围 (3)1.3 术语和缩略语 (3)1.4 参考资料 (4)2总体说明 (4)2.1 产品前景 (4)2.2 产品特性 (4)2.3 用户类及其特征 (5)2.4 运行环境和资源需求 (6)2.5 设计和实现约束 (7)3具体需求 (7)3.1 用户界面原型 (7)3.2 功能需求 (8)3.2.1[模型定义] (9)3.2.2[模型条件配置] (11)3.2.3[业务表维护] (13)3.2.4[预警事件处理] (15)3.2.5[预警数据查询] (20)3.2.6[预警登记清单] (22)3.2.7[机构风险点统计表] (23)3.2.8[机构风险点按时间统计表] (25)3.2.9[机构管理] (28)3.2.10[操作员管理] (30)3.2.11[角色管理] (32)3.2.12[操作员登陆情况查询] (33)3.2.13[模型分析日志查询] (34)3.2.14[风险数据删除] (35)3.2.15[邮件提示] (37)3.3 报表需求 (37)3.4 数据库需求 (37)3.5 系统接口及兼容性需求 (38)3.6 非功能性需求 (38)3.6.1用户文档 (38)3.6.2版本发布时回滚需求 (38)3.6.3安全性需求 (38)3.6.4服务支持及时间要求 (38)3.7 参考资料 (39)需求规格说明书1引言1.1目标本文档是《xxxx行远程审计平台需求规格说明书V1.0》，对于系统设计开发人员，是系统设计、编码工作的依据和基础；对于系统测试人员，是系统测试的依据；对于用户，是项目监理和系统验收工作的依据。
1.2范围本需求分析说明书是对《远程审计平台技术需求说明书》进行整理、分析的成果。
其目的是分析清楚拟建系统的功能性需求和非功能性需求。
功能性需求分析主要是划分用户和功能，并明确每项功能的具体要求。
非功能性需求分析主要是明确拟建系统的性能、安全性、可用性、可靠性等要求。
本说明书是下一步系统设计开发的基础。
本需求分析说明书的读者主要有：拟建系统用户、项目组全体人员系统名称：xxxx行远程审计工作平台提出部门: xxxx行稽核监察部系统建设单位：北京京北方科技股份有限公司使用单位：xxxx行稽核监察部及相关部门1.3术语和缩略语1.4参考资料《银行审计平台采购合同》《远程审计平台技术需求说明书》及附件2总体说明2.1产品前景本产品是一个比较成熟的风险控制软件，结合银行核心业务系统的应用，为其应用核心业务系统的数据进行风险控制管理而配套开发的业务应用软件。
能够灵活的处理各类帐务性和非帐务性数据、能够灵活定制各种风险分析模型、能够进行网络化的差错处理、并实现丰富的统计功能，全方位对银行潜在风险进行预警和监控。
2.2产品特性本系统主要有以下几个特点：能够灵活的处理各类帐务性和非帐务性数据；能够灵活定制各种风险分析模型；能够进行网络化的差错处理；主要的系统功能架构如下：2.3用户类及其特征阐述本产品的各种角色及其职责。
各种角色的具体行为将在功能性需求中描述。
2.4运行环境和资源需求远程审计平台运行服务器包括应用服务器和数据库服务器，具体硬件配置要求如下：应用服务器的硬件配置：4CPU (Intel 4 核处理器，3.0G及以上)，8G以上内存，SAS硬盘(15k rpm)空间不小于100G数据库服务器的硬件配置：4CPU(Intel 4 核处理器，3.0G及以上)，16G以上内存，SAS硬盘(15k rpm)空间不小于1T2.5设计和实现约束本系统的编程语言为Java语言，编程工具使用Eclipse3.2，数据库使用Oracle10g；本系统采用B/S架构，客户端访问需要安装IE6.0及以上版本的浏览器；审计平台预警数据的生成，基于xxxx行其他业务系统的数据，比如财会系统、信贷系统以及外汇系统等系统的日常数据，所以每天需要行方定时将正确的数据完整的导入到远程审计平台数据库的指定表中，审计平台将根据预先定义的预警模型，自动生成每天的预警数据；3具体需求3.1用户界面原型1．系统主界面原型：其它界面原型见“3.2功能需求”的“用例”。
3.2功能需求本系统共分为4个大功能模块，包含12个小功能模块，每个模块的功能说明见下表：3.2.1[模型定义]用例编号模型定义简要说明通过此用例使用户了解“模型定义”功能作用。
前置条件此模型对应的数据表已经存在。
后置条件可以为本模型配置风险条件。
执行者系统管理员。
工作流程用户进入模型定义菜单可以进行对模型的“增加”、“修改”、“删除”、“配置预警条件”等操作。
增加：操作员通过“增加”功能可以增加“风险模型”，“风险模型”有以下几个要素：1．预警编号：此预警模型的编号（可以自己定义一个编号的规则）。
2．预警名称：此预警模型的名称（最好能够表达出模型的意思）。
3．预警所属类别：标明此预警模型所属的类别(财会类、外汇类、信贷类、其它)。
4．数据抽取百分比：此模型分析出的数据中抽取多少由操作员去处理（1% 、2%、5%、10%、20%、100%）5．预警模型详细描述：对此预警模型的描述。
修改：用户可以对增加模型时配置的所有字段进行修改。
删除：用户可以删除此风险模型。
配置预警条件：跳转到模型条件配置界面进行模型条件配置（见：用例2.模型条件配置）。
基本工作流程无。
备选工作流程无。
补充规约无。
3.2.2[模型条件配置]用例编号模型条件配置简要说明为模型定义中定义的模型配置风险条件。
前置条件模型已经定义。
后置条件模型分析时可根据此条件分析数据得到风险数据。
执行者系统管理员。
工作流程操作员进入模型条件设置菜单可以进行对模型条件的“增加”、“修改”、“删除”等操作。
增加：操作员可以为选定的风险模型增加一模型条件，模型条件有以下几个要素：对应的业务表、对应的业务表中的哪个字段、对应选中字段的一些判断（大于、小于、等于、在…之间等）。
修改：操作员可以对增加的模型条件进行修改。
删除：操作员可以删除已经存在的条件。
基本工作流程无。
备选工作流程无。
补充规约无。
3.2.3[业务表维护]用例编号业务表维护简要说明为在模型定义功能以及模型条件配置中所用的“业务表”以及“业务字段”进行维护。
前置条件在数据库中存在此“业务表”以及“业务字段”。
后置条件无。
执行者系统管理员。
工作流程操作员进入业务表维护菜单可对业务表及业务表字段进行增加、修改、删除等操作。
对业务表的增加：可增加一个业务表，业务表要素有：表名称：数据库表名。
表描述：对表的说明。
对业务表的修改：可对增加的业务表名和表描述进行修改。
删除业务表：可删除一条已经存在业务表。
对业务表字段维护：对业务表字段的增加：可以为已有的业务表增加一个字段，字段要素有：字段名称、字段描述、字段类型、数据长度、数据精度。
对业务表字段的修改：可以对业务表字段的相关要素进行修改。
对业务表字段的删除：可以删除已存在的业务表字段。
基本工作流程无。
备选工作流程无。
补充规约无。
3.2.4[预警事件处理]用例编号预警事件处理简要说明审计员、机构操作员、审核员输入查询条件，查询出自己所处理阶段的数据进行处理。
前置条件本阶段所处理的是根据配置的风险模型分析出的风险数据。
后置条件无。
执行者审计员、审核员、机构操作员、审计负责人、常规稽核员。
工作流程风险数据状态图：注：1代表审计员， 2 代表审核员 3 ，代表机构操作员。
1．模型分析完生成风险数据，此时数据处于“初始待审计状态”，此时审计员和审核员都可以操作此风险数据，可以将“初始待审计状态”更改为：“待回复状态”、“差错状态”，“无风险状态”。
2．当数据处于“待回复状态”，审核员可以将“待回复状态”更改为：“差错状态”、“无风险状态”、“待审计状态”，机构操作员可以将“待回复状态”更改为“待审计状态”。
3．当数据处于“差错状态”，审计员可以将数据更改为：“无风险状态”、“待回复状态”，审核员可以将数据更改为：“无风险状态”、“待回复状态”、“待审计状态”。
注：审计员只能更改自己操作过的数据。
4．当数据处于“无风险状态”，审计员可以将数据更改为：“差错状态”、“待回复状态”，审核员可以将数据更改为：“差错状态”、“待回复状态”、“待审计状态”。
注：审计员只能更改自己操作过的数据。
5．当数据处于“待审计状态”，审计员和审核员都可以将数据更改为：“待回复状态”、“差错状态”，“无风险状态”。
注：审计员只能更改自己操作过的数据。
注：以上“1代表的审计员”包含“常规稽核员”。
注：“常规稽核人员”和“审计员”有相同的权限，但是“常规稽核人员”只能处理“日常”数据。
操作员可以在此处输入一些查询条件，先查询出需要处理的数据，有以下几个查询条件：交易日期：需输入起始时间和结束时间机构名称：下拉列表预警类型：下拉列表，包含信贷、财会、外汇、其它四项预警信息流水号：日期＋风险类型＋序号业务流水号：业务系统内流水号审计方式：下拉列表，包含远程、日常两项操作员可以对查询出的数据进行处理：注：在以上处理界面上部的风险信息包含此风险模型所配置要显示的所有信息。
审计员，审核员：可以把数据置为“差错状态”，“待回复状态”，“无风险状态”。
审核员：可以把数据置为“待审计状态”让审计员重新审计。
机构操作员：无需选择直接提交，默认置为“待审计状态”。
在处理界面，操作员可以选择处理意见（正常、异常），还可以输入自己的意见，并且能够看到其它处理员的意见，选择数据的下一处理状态，转到下一处理员进行处理。
在处理过程中操作员可以上传一些相关附件，审计员或审核员可以查看机构操作员上传的附件。
注：审计员可选择的下一处理状态为：“差错”、“待回复”、“无风险”。
审核员可选择的下一处理状态为：“待审计”、“差错”、“待回复”、“无风险”。
机构操作员不能选择下一处理状态，直接提交，默认下一处理状态为“待审计”。
注：以上的审计员包含“审计员”和“常规稽核员”。
注：在以上处理界面，当用户“处理批示”选择“正常”，而提交下一处理为“差错”，或者“处理批示”选择“异常”，而提交下一处理为“无风险”系统会提示“所选处理批示和提交状态不一致”。
基本工作流程无。
备选工作流程无。
补充规约无。
3.2.5[预警数据查询]用例编号预警数据查询简要说明操作员在此可以查询数据，审计员或审核员可以对数据进行处理。
前置条件通过模型分析生成风险数据（包括已处理和处理到任何阶段数据）。
后置条件无。
执行者审计员，审核员，机构负责人，机构操作员，常规稽核人员、审计负责人。
工作流程操作员可以在此处输入一些查询条件先查询出需要的数据，有以下几个查询条件：交易日期：需输入起始时间和结束时间机构名称：下拉列表预警类型：下拉列表，包含信贷、财会、外汇、其它四项预警信息流水号：日期＋风险类型＋序号业务流水号：业务系统内流水号审计方式：下拉列表，包含远程、日常两项处理状态：下拉列表，包含初始待审计状态、待审计状态、待回复状态、差错状态、无风险状态五项。