财务系统需求分析说明（共9篇）
文档信息：
项目名称：财务管理系统项目经理：sGlobalMethod阶段:需求分析
·1.引言
1.1 编写目的
为使系统开发人员和业务需求人员达成对本次虚账户管理系统项目开发需求的一致理解，同时做为下一阶段系统设计的依据，特编写此《需求分析说明书》。
2收入管理需求描述
根据业务提出需求，需要增加学费管理，寝室费管理菜单，下面对功能进行详细描述。
2.1收入管理
2.1.1功能概述
收入列表显示，添加，删除，修改
2.1.2界面描述
2.1.2.1寝室费
第一页寝室费收入列表显示（所有数据）按院校日期，地点，寝室号等分类查询 显示寝室费收入列表；
添加功能，单条/批量删除，修改功能，导出功能。按添加按钮跳入第二页 第二页寝室费录入功能
含有表头的可编辑的空表格，添加可编辑行数（1）删除可编辑行数（1）保存；
2.1.2.2学费
第三页学费收入列表显示（所有数据）按院校日期等分类查询 显示学费收入列表；
添加功能，单条/批量删除，修改功能，导出功能，导出当前所选择的记录。按添加按钮跳入第四页 第四页学费录入功能
含有表头的可编辑的空表格，添加可编辑行数（1）删除可编辑行数（1）保存；
3支出管理需求描述
3.1支出管理 3.1.1功能概述
支出列表显示，添加，删除，修改
3.1.2界面描述
3.1.2.1财务报销
第一页财务报销支出列表显示（所有数据）按院校，报销类别，日期等分类查询； 显示财务报销列表
添加功能，单条/批量删除，修改功能，导出功能。按添加按钮跳入第二页 第二页财务报销录入功能
含有表头的可编辑的空表格，添加可编辑行数（1）删除可编辑行数（1）保存；
3.1.2.2付款申请
第一页付款申请支出列表显示（所有数据）按院校，付款类型，日期等分类查询； 显示付款申请列表
添加功能，单条/批量删除，修改功能，导出功能。按添加按钮跳入第二页 第二页付款申请录入功能
含有表头的可编辑的空表格，添加可编辑行数（1）删除可编辑行数（1）保存；
3.1.2.3采购申请
第一页采购申请支出列表显示（所有数据）按院校，采购类型，日期等分类查询； 显示采购申请列表
添加功能，单条/批量删除，修改功能，导出功能。按添加按钮跳入第二页 第二页采购申请录入功能
所以排课系统应该具备教学计划的导入、课程表元素初始化设置、课程表的优化生成、课程表信息查询、课程表信息打印导出等基本功能。对课程表元素初始化参数设置考虑的是否全面、是否人性化将在很大层面上影响生成课程表的优化程度。
课程表的编排涉及到教师、教室、班级、学生、时间等方方面面的因素, 设计过程中需要反复调整来避免冲突。本排课系统针对大部分院校的授课特点完成对学习周、时间单元、教学区域等课程表中相关元素信息的统一属性设置, 以使设计开发的排课系统能够具有一定的普适性。下面列举出对课程表编排过程中需要考虑到的一些重要因素。
学习周:每学期学习周总数将在已经实施的教学计划中体现。
单双周:有些课程单双周授课方式并不相同, 这便需要在课程属性中有所体现, 以便于科学合理排课。按照教学计划设定学期周数, 并根据具体情况安排是否单双周授课。
授课天数上限值:每周上课天数为D天, D小于或等于7天。每学期根据学校要求设置D的上限值。例如, 当授课时间充足的情况下, 可设置D的上限值为5。
时间单元:最小授课单位设置为两学时, 即两小节为一个时间单元 (或称为时间片) 。每天分为三个大的时间段, 上午 (P1) 、下午 (P2) 和晚上 (P3) 。P1包含两个时间单元1 (1、2节) 和2 (3、4节) , P2包含两个时间单元3 (5、6节) 和4 (7、8节) , P3包含1个时间单元5 (9、10节) 。
课程类型:课程可分为必修课和选修课两种。按照授课内容又可分为公共基础课、专业基础课和专业课三种。一般来说, 公共基础课可安排同届或同专业合班上课, 甚至可以跨专业合班上课。排课过程中必修课的优先级要高于选修课, 尽可能安排在上午和下午时段, 选修课尽可能考虑到需要面向的所有学生, 安排统一时间, 例如可以安排在晚上时段, 或分成两组授课供学生进行时段选择。
教学区域:各教学楼之间距离一般较远, 将邻近的教学场地视为同一个教学区域, 然后为其分配区域编码, 例如:jxq01教学区、jxq02教学区等。每个教学时段学生、教师均在同一个教学区域进行教学活动。
2 系统用户管理需求
排课系统应该结合各部门、各使用人员的具体需求进行权限设置。一般来说, 高等院校的排课系统使用人员主要由系统管理员、教务处管理人员、各学院、各系管理人员、教师和学生组成。系统用户根据自身权限将获得不同的服务。
系统管理员:所有用户中权限最大 (权限值为1) , 能够进入排课系统所有界面, 使用排课系统全部功能。
教务处管理人员:权限值为2, 具有系统管理员的部分功能。主要功能是:排课参数设置、自动排课及课程表人工调整、课程表结果查询打印、数据分析等。
各学院 (各系) 管理人员:权限值为3, 具有系统管理员的部分功能。主要功能是学院 (各系) 对教学计划的导入、课程表结果查询打印、数据分析等。
教师:权限值为4, 仅具有查看自己授课信息的权限。
学生:权限值为5, 具有查看自己班级课程表安排的权限, 还具有查看公共选修课课程安排的权限。
3 系统主要功能需求
整个排课系统根据功能需求可划分成五个功能模块, 具体内容如图1所示。
3.1 初始化信息管理模块
初始化信息管理模块的主要功能是完成排课过程所需要的初始信息录入及数据信息管理维护等方面的工作。此模块包括7个功能子模块, 如图2所示。
(1) 行政班级信息管理模块:可完成班级编码、班级名称、班级人数、所属学院、系、专业等信息的录入、修改、删除等功能。 (2) 教学区域信息管理模块:可完成教室编码、教室名称、教室类型、所属教学区域等信息的录入、修改、删除等功能。 (3) 教师资源信息管理模块:可完成教师编码、教师姓名、所授课程等信息的录入、修改、删除等功能。 (4) 课程信息导入模块:可完成每学期各学院 (系) 教学计划的导入、修改、删除等功能。 (5) 数据信息管理模块:包括数据备份、数据恢复、数据库清空等功能。 (6) 排课初始信息设置模块:学期周数、每周上课天数上限值等初始信息设置。 (7) 退出系统模块:完成规定操作后, 用于结束现有操作。
3.2 自动智能排课模块
自动智能排课模块的主要功能是系统获取足够的参数信息后, 进行自动排课, 再根据具体情况进行人工调整, 最后输出排课结果。此模块包括4个功能子模块, 如图3所示。
(1) 系统参数设置模块:设置自适应参数、种群规模大小等。 (2) 预先排课模块:对具有特殊要求的情况, 进行预先排课。 (3) 自动智能排课模块:系统操作员输入排课所需信息并验证无误后, 点击“排课”按钮, 系统将自动完成排课。 (4) 人工调整模块:根据需要, 人工调整不适合实际需要的课程表安排, 最终生成可用课程表。
3.3 课程表查询管理模块
课程表查询管理模块的主要功能是能够以不同的方式查询课程表, 并根据不同需要进行打印输出。此模块包括4个功能子模块, 如图4所示。
(1) 教师课表查询模块:可查询任一名教师的课程表, 并能完成查询结果的打印输出。 (2) 班级课表查询模块:可查询任一个班级的课程表, 并能完成查询结果的打印输出。 (3) 教室课表查询模块:可查询任一个教室 (包括实训室) 的课程表, 并能完成查询结果的打印输出。 (4) 公共选修课查询模块:可查询任一门公共选修课的课程表, 并能完成查询结果的打印输出。
3.4 数据统计分析模块
数据统计分析模块的主要功能是对排课系统中的一些数据进行分析和统计, 目的是为了更好地指导排课系统进行科学、合理排课, 同时也为学校的一些工作提供基础数据。此模块包括3个功能子模块, 如图5所示。
(1) 教室场地利用率统计模块:统计各教室、实训室的日常使用情况, 为学校硬件配套设施的更新提供基础数据。 (2) 教师工作量统计模块:统计每学期每位教师的工作量, 为各学院 (系) 下一学期教学安排以及教务课时费发放提供基础数据。 (3) 班级教学任务统计模块:统计各行政班级已完成的教学任务, 为教学计划的实施验收提供基础数据。
3.5 用户管理模块
用户管理模块的主要功能是设置不同用户权限。此模块包括两个功能子模块, 如图6所示。
(1) 系统管理员管理模块:可以修改当前管理员的密码, 添加、修改、删除用户功能。 (2) 密码重设模块:可以修改学院 (各系) 、教师、学生等用户密码。
4 系统总体界面需求
在本排课系统的设计过程中, 界面设计主要从以下几方面需求进行考虑:
界面简单友好。用户能够很方便的处理各种应用问题。
使用术语标准, 并保持一致化。用户可以轻松读懂应用流程并进行熟练操作。
拥有完整的帮助说明文档。用户可根据帮助文档在最短的时间里了解系统的性能和使用概况。
摘要：排课问题即是课程表问题, 它的生成过程需要考虑到教师、教学场地、学生、课程、时间等诸多因素, 一个科学、可行的课程表必须是无冲突的。使用计算机排课的一个重要目的就是提高排课效率, 降低教务人员的排课难度。本文主要从功能要求入手对排课系统的设计进行需求分析设计。
关键词：排课问题,课程表,需求分析
参考文献
[1]姜谦.中小学排课系统的研究与设计.南京理工大学硕士学位论文, 2010.10-35.
[2]成伟.基于遗传算法的排课系统的设计与实现.湖南大学硕士学位论文, 2011.8-17.
[3]张华.智能排课算法的研究及实现.山东大学硕士学位论文, 2010.35-43.
[4]杨珊珊.基于多维遗传算法的成教排课系统的研究和设计.河南理工大学硕士学位论文, 2011.13-15.
关键词：民办高校；信息需求；政府监管
中图分类号：G648.7 文献标志码：A 文章编号：1000-8772（2012）19-0075-02
一、引言
民办高校的蓬勃发展，在一定程度上缓解了我国社会对高素质人才的需求与高等教育稀缺这一现实情况之间的矛盾，而且从我国现阶段的情况来看，民办高校在这方面的作用还会进一步增强。然而随着我国民办高校数量的增加，如何范化其管理，以维持其健康持续的发展，保证教学的质量，也成为了民办高校各利益相关方所必然要面临的问题。为实现这些目的，民办高校的信息披露就成为了各利益相关方的必然需求。而民办高校的经济性质也决定了其信息需求的多样性。
公共产品理论认为，高等教育从经济性质上讲属于混合产品的范畴：一方面，高等教育可以提升公民的素质，为国家培养建设人才，从而促进社会经济的发展，这是高等教育具有公益性的一面；而另一方面，受教育者可以从高层次教育中获得比一般受教育者更多、更高的知识和技能，从而为将来找到一份较好的职业、获得较高的收入奠定基础，因此高等教育的供给者可要求这些受教育者为其获得的教育付费，这是高等教育具有商品属性的一面，在这一点上，民办高校的经费来源使其具有比公办高校更为明显的营利性特征。因此，从其需求目的的性质来看，民办高校的财务信息需求者可以分为公益需求者和自身效用需求者这两类，在公益性需求者中最具代表性的是政府，而有自身效用需求的则是民办高校的投资者和民办高校所服务的对象——学生。
二、政府对民办高校财务信息的需求分析
教育的公共产品属性决定了政府是教育的传统提供者，但是在我国现阶段高等教育资源稀缺的情况下，政府并不能投入足够的资源来满足全部的高等教育需求，因此，鼓励高校民办，积极引导民间资本进入高等教育办学领域，就成为了政府解决高等教育稀缺性的一种途径。
促进民办教育的发展并不代表政府会放任民办高等教育完全市场化。在引导民办教育发展的这一过程中，为了保证民办高校发挥正面的社会效益，保障民办高校的办学质量，政府会在一定程度上提供一些必要的帮助，但更主要的，还是会通过各种方式来对民办高校进行规范和管理，其中，财务监管就是最主要的监管内容之一。
政府利用民办高校财务信息所要做出的决策主要是“是否许可”，具体来说，包括是否颁给民办高校办学的“许可证”，或是否对民办高校的某些权利予以支持（比如办学资质、等级，或财政资金支持）等。政府的这些“许可”的权力对民办高校而言是十分重要的，而且因为这些权力具有“垄断性”。因此，从某种意义上讲，政府可以通过这些决策强制民办高校提供各类信息，而民办高校为了获得政府的“许可”，也会主动提供政府需要的信息，尽管这些信息的真实性和充分性并不能得到完全的保证，但是政府完全可以通过引入第三方审计来解决这一问题。
与政府不同，投资者和学生对民办高校财务信息的需求更多是从提高自身效用出发，这一点体现了民办高校的“教育市场化”的特点。
三、投资者
我国2002年颁布的《中华人民共和国民办教育促進法》第51条规定：“民办学校在扣除办学成本、预留发展基金以及按照国家有关规定提取其他的必需的费用后，出资人可以从办学结余中取得合理回报。”也就是说，在一定意义上，民办高校和一般企业一样，是投资人合法的谋利工具，因此我们也可以推断，投资者进行决策的目标，是要实现自身收益的最大化。为了实现这一目标所需要作出的决策包括是否投资，投资多少，选择谁作为管理者等。
正是因为投资者将经济收益作为民办高校投资的目标，所以也会面临委托—代理关系带来的激励问题。因为投资者并不会直接参与民办高校的日常经营管理，而学校管理者想要实现的目标可能和投资者的目标存在利益上的冲突（这种冲突并不一定是由于管理者想要“贪污”或“偷懒”，还有可能是出于想要提供给学生更好的教学服务的目的，也就是价值观的不同），所以投资者只能从财务上来监管学校的运营效率。与向公益出资人披露信息类似，民办高校的管理者出于维持管理的目的，很可能只会向投资者提供对自己有利的信息，或者隐藏一些于己不利的信息。投资者在信息获取上处于弱势地位，从而产生了对规范化的财务信息披露的需求。为实现这一要求，投资者一般也是通过审计来完成，但是如果民办高校的会计核算方法不规范甚至根本记录的内容就不完全，审计的难度可想而知。
四、学生及家长
学生是民办高校最直接的服务对象，也是民办高校办学品质最直接的体验者。作为难以享受到公办高等教育的群体，民办高校的（潜在的）学生最关心的，无非是自己支付的学费与其能享受到的办学条件，以及最后受教育结果（比如能不能拿到学位，能不能找到工作等）是否匹配的问题。所以他们将要作出的决策需要进行相当多的比较，要考虑到学费的悬殊，也要考虑学校的建设情况，还要考虑学校的教学水平等。以此来选择：什么“价位”的学校？是办学条件较低的公办院校还是较高的民办院校？选择哪个学校？什么专业？……但是学生需要的信息，除了费用信息外，一般除非学生和家长进行“实地考察”，否则都很难获得，因为学校出于吸引学生扩大生源的目的，往往都会粉饰信息，夸张宣传，从而使学生（和其家长）被其误导，作出并不适合自己，甚至是极为错误的决定。
这些现象，如果用商品市场的相关理论来进行解释，首先可以从信息不对称的理论来进行分析，民办高校是其服务的创造者，而学生是其提供服务的购买者，这就使得学生在信息交换中处在了天然的弱势地位上，因为民办高校显然会对自己的条件更为了解；另一方面，从商品供需弹性的理论来看，由于我国现阶段高等教育的稀缺性，尽管随着民办高校的增加，相互之间的竞争也越来越激烈，但是总的来说，民办高校面对的还是全国高等教育相对刚性的需求，所以学生群体作为民办高等教育的购买者，只能被动地接受民办高校的“报价”（因为供需双方都知道，这个“价格”总会有人接受），而没有影响民办高等教育“价格”的能力。从我国现阶段的情况来看，我们短期之类显然还无法解决高等教育稀缺性带来的“供需平衡”问题。
从以上的分析可以看出，无论是出于公益目的还是自身效用的目的，民办高校的相关利益方都有其各自获取民办高校财务信息的迫切需求（虽然各方的目的并不完全一致），但是这些需求都要面临一个共同的问题，即民办高校财务信息不尽不实的问题。虽然各方对这个问题并非毫无办法（比如可以聘请专业人员来对学校财务进行审计，学生可以亲自到学校来了解各方面情况等），但是总的看来，单独进行这些行动对信息需求者来说，信息获取的成本都较高，所以由政府强制监管，建立一个规范的公开披露信息的机制，不仅可以为所有的信息需求者提供必要的信息，保证信息的完整性，而且从披露的成本和需求满足上比较，无疑是十分划算的。
参考文献：
[1] 孙莹.公办高校与民办高校财务运作模式异同比较研究[J].当代经济，2011，（5）
[2] 孙芳城，王海兵 肖传志.非营利组织的会计目标及会计信息披露[J].财会月刊，2006，（7）.
[3] 李亮，于沛利，胡胜.谈高校财务信息披露改革[J].财会月刊，2008，（2）.
[4] 倪国爱，程昔武.非营利组织信息披露机制的理论框架研究[J].会计之友，2009，（4）.
实验目的
采用C/S模式完成一个小型的图书管理系统；完成从需求分析、数据模式设计到编码实现、系统调试的所有流程；通过此一图书管理系统的实现，在实践中掌握数据库系统设计的特点、方法和步骤。
实验环境
SQL Server 2000 ＋ ERwin + Power Builder 可2～3人组成一组，共同开发完成；
问题及算法描述
完成一个小型图书管理系统，功能要求如下：
1)能够通过书籍基本信息（包括：书号、书名、出版社、出版日期、作者、内容摘要）单个或以AND方式组合多个条件查询书籍信息；
2)对于每一种书籍，除可查看其基本信息之外还可查看其总数以及目前在馆数量 3)可增添新的书籍
4)可删除已有书籍（如有读者借了该书籍尚未归还，则不允许删除）5)可修改书籍的基本信息
6)能够通过读者基本信息（包括：证号、姓名、性别、系名、年级）单个或以AND方式组合多个条件查询读者信息
7)对于每位读者除可查看其基本信息之外，还可查看其已借的书籍列表、数量、借还日期 8)可增添新的读者
9)可删除已有读者（如该读者有尚未归还的借书，则不允许删除）10)可修改读者的基本信息 11)可完成借还书籍的手续
12)还书时如超期，应该显示超期天数
13)借书时如果有超期的书没有还，则不允许借书
14)可查询有哪些读者有超期的书没有还，列出这些读者的基本信息
结果要求
一份E-R图 表结构定义（使用表格说明）程序框架流程图 部分核心代码
1.2背景.........................2
1.3定义.........................2
1.4参考资料...............................2
2任务概述..............................2
2.1目标.........................2
2.2用户的特点...........................32.3假定和约束...........................3
3需求规定..............................3
3.1对功能的规定.......................3
3.2对性能的规定.......................43.2.1精度.........................4
3.2.2时间特性要求.......................4
3.2.3灵活性............................53.3输人输出要求.......................5
3.4数据管理能力要求......................5
3.5故障处理要求.......................5
3.6其他专门要求.......................5
4运行环境规定.............................6
4.1设备.........................6
4.2支持软件...............................6
4.3接口.........................6
4.4控制.........................6
软件需求说明书
1引言
1.1编写目的本文档的目的是阐述酒店管理系统的需求分析
预期的读者：酒店经营者、客户、中间用户(软件的管理人员、开发人员、维护人员)、最终用户。
1.2背景
待开发的软件系统的名称：酒店管理系统
本项目的任务提出者和开发者：刘畅和酒店管理系统开发小组 本项目的用户是针对各档次酒店宾馆管理定制开发的本系统环境要求：所有程序均在Windows98/XP，Windows2000操作系统下测试运行。如果数据库为SQL Server数据库，建议用户安装SQL Serve2000
1.3定义
酒店管理系统是酒店宾馆销售管理系统
1.4参考资料
《现代软件工程》陈松乔 任胜兵 王国军 编著清华大学出版社 《程序设计语言》沈志斌编著电子工业出版社 《Delphi实用教程》 郑阿奇主编电子工业出版社
2任务概述
2.1目标
开发意图：
随着人民生活的水平的日益提高，人们对于生活的品质也有了明显的提高，现在到酒店住宿已经不再是少部分人才有的享受，越来越多的人开始将之视为日常生活的一部份。人们消费观念的改变也带来了酒店业的巨大发展。跟随时代的改变，21世纪的计算机化地位也已不可动摇，计算机简单、快捷、高效、准确的特性也受到推崇，在各行各业迅速发展壮大
起来。较大规模的酒店也正一步步地朝这方面发展。
与其他软件的关系：
与相应的软件可以共享数据库，本系统考虑到今后的数据量的扩大采用SQL Server数据库。
2.2用户的特点
本软件的最终用户为各大酒店及宾馆 一般用户只需懂得计算机基本操作、具备文字录入能力。相对维护人员应具备一定的计算机专业知识，了解数据库系统的管理与维护，能排除一般计算机故障。
2.3假定和约束
从项目设计需求说明至最终审核，开发人员工作分配到位，开发小组成员在配合组长工作的同时，应能如期完成各自的工作任务。
开发期限为一个月，若小组某成员因技术缺陷或者特殊原因延误开发进度，其他组员应提供相对帮助。另有辅导老师进行指导与督促。
3需求规定
3.1对功能的规定
功能模块初步设计为五大模块分别为身份验证、系统设置、客房管理、订房管理、结算管理。各模块分别提供基本数据流图。各模块所包含的子功能如下列出为准。
身份验证：提供了系统的访问控制功能。
系统：提供了对密码的修改以及添加新用户的功能。
客房信息管理：包括两大主要功能，设置客服标准和设置客房信息，在设置客房标准中，管理员可以添加，修改，删除客房标准，在设置客房信息中，管理员可以添加，修改，删除，查询客房信息。
订房信息管理：包括查询剩余客房信息，添加，修改，查询订房信息等功能。结算信息管理：包括添加，修改，查询结算信息功能。
图1．酒店管理系统用例图
3.2对性能的规定 3.2.1精度
对金额的输入要求保留小数点后两位，其他数值不做要求。
3.2.2时间特性要求
说明对于该软件的时间特性要求，如对： a． 响应时间<=15s； b． 更新处理时间<=5s；
c． 数据的转换和传送时间<=15s； d． 等待时鼠标将变成漏斗状。
3.2.3灵活性
a． 系统的界面操作方式应以用户意见变化而灵活转化； b． 系统不能以运行环境的变化而停止运作；
c． 一般情况下不用进行程序修改而是通过修改配置选项完成相应工作。
3.3输人输出要求
数据类型： 字符数据CHAR［(N)］：存放固定长度的N个字符数据，1<=N<=8000VARCHAR[(N)]:存放可变长度的N个字符数据，1<=N<=8000 日期型数据
DATATIME：存放从1/1/1753到12/31/9999的时间数据，精确到1/1000秒 数字型数据
INTEGER：存放从-2^31到2^63的整形数据货币数据
MONEY：存放从-2^63到2^63-1的货币数据，精度为货币单位的10/1000
3.4数据管理能力要求
需要管理的文卷和记录的个数为六张表：分别是 客户住宿基本信息表，营业动态数据信息表，营业总分析表，每日客流信息表，收费项目表，当日营业额日报表。
按可预见的增长对数据及其分量的存储要求估算字段的大小不超过50。表和文卷的大小规模为中等大小。
3.5故障处理要求
a． 源数据的处理：建议全部保存；
b． 操作规程：确保系统正常工作，数据完好无损，并定期进行数据库备份；
c． 数据进入系统的过程：通过数据库管理员身份登录进行管理，或由DBA直接对数据库进行操作；
d． 数据保存、存储、恢复的处理：请软件使用者自行备份相关信息； e． 系统失效的后果及恢复的处理办法：首先请恢复备份，在这里我建议备份数据库以将可能的损失降到最低点。如果不能恢复，请与我们联系，我们将竭尽所能提供力所能及的帮助。
3.6其他专门要求
该软件安全保密的要求为中等，对该系统使用尽可能方便，对可维护性比较容易、易补充、易读、可靠。
运行环境可在windows x系列操作系统下转换。
4运行环境规定
4.1设备
服务器：
CPU：PII233或HP系列的专门服务器 内存：128M 以上 硬盘：10G 以上
显示模式：推荐分辨率为800*600 工作站：
CPU：P133以上 内存：64M以上
模式：推荐分辨率为800*600
4.2支持软件
支持软件：Win9X/2000/XP/2003
服务器：数据库系统Microsoft SQL Server 2000
工作站：局域网络运行，工作站上不需要安装数据库系统。
4.3接口
该软件同各酒店宾馆的销售系统之间的接口。
与较大的客户单位之间的接口，用来跟踪掌握大客户的相关情况。接口之间网络协议采用TCP/IP协议。
4.4控制
1、引言
1．1编写目的随着宾馆入住人数越来越多，房间的安排就成为一个越来越复杂的工作，所以就迫切需要一款能够智能管理客户入住安排的系统，来减轻工作人员的负担。此系统是基于客户入住需求所建立的前台接待管理系统。
1.2背景
随着社会经济的发展，宾馆在服务行业中扮演着越来越重要的角色。本宾馆是一家中型宾馆，主营业务有住宿、餐饮娱乐。在宾馆运作期间，其管理和服务水平直接影响到宾馆的形象和声誉。这就需要有一套前台接待系统来对客户信息情况及客户服务项目进行有效管理。以此来提高服务质量，尽可能做到让客户满意，也使我们的宾馆更易于管理。因此，我们提供的这一套宾馆前台接待系统。
1.3定义
前台接待系统：可以处理散客入住登记，合约入住，团体入住和手动入住，补填客单，修改客人信息、转房、调房、设置房态、客人留言，预定客房查询、可售客房查询等事务。
1.4参考资料
《信息检索教程》中国人民大学出版社
《实用软件需求》机械工业出版社
《软件工程实践教程》电子工业出版社
2.任务概述
2.1目标
宾馆客房管理系统的目标是为用户提供高效的服务，减少手工处理的繁琐与误差，及时准确地反映酒店工作情况、经营信息，从而提高宾馆工作质量，获得更好的经济效益，具体目标包括：
（1）快速办理客人入住、换饭、退房手续，实现客人在酒店消费自动化;
（2）准确无误地记录客人每笔消费信息
（3）实时、快速、准确提供客房动态
（4）住宿、餐饮、购物、通信、娱乐等各种费用一次结清
2.2用户特点
本报告的读者是宾馆管理人员、服务人员和主管技术人员以及项目设计和开发人员。
主要运用系统操作人员是宾馆的前台服务人员
系统维护人为计算机专业人员，熟悉数据库操作系统，网络维护工作，维护人员为间隔性用户
2.3假定和约束
为了使客户管理系统获得更好的安全性、扩展性和更高的执行效能，整个系统采取分布式部署的方案，将承载关键业务逻辑的应用程序服务器和承载业务数据库服务隔离开来。实现管理与数据的分离，便于隔离和维护。
客户管理系统为宾馆前台接待人员及相关隔离人员才能拥有相应使用权限；应用本平台必须保证电脑或其他访问本平台的软件有杀毒能力，对于因中毒而产生的客户信息流失，本宾馆应负相关责任。
3.需求规定
3.1对功能的规定
前台接待系统
（1）散客入住登记：对于外来人员的入住时间及个人信息进行登记
（2）合约入住登记：针对于不熟悉的人员，进行合约进行登记入住，保证宾馆的安全性。
（3）团体自动入住和手动入住：对于出差或旅行的团队，实现网上自动入住可手动入住，方便大家的自行性。
（4）补填客单：主要可以讲客户的临时增加的内容进行填补，防止漏掉部分信息。
（5）修改客人信息：对于客人的服务项目的需要，随时可进行对客人的信息修改，保证其具有真实性。
（6）转房、调房：对于客户的转房，调房的需要，即使更改，保证信息的及时性和准确性。
（7）设置房态：对于每个房间的现实状况进行设置，保证房间的空余、已住、已走等信息的详尽。可以让房间服务人员了解到房间状态的现实性。
（8）预定客房查询：对于客房的情况进行查询，以便于及时进行预定。
（9）可售客房查询：对于客房的出售情况查询，以保证需求方的快捷办理。
3.2对性能的规定
3.2.1精度
宾馆前台接待系统所涉及的所有的货币金额数据类型，均按实数保存，在显示处理时保留小数点后4位。
3.2.2时间性能要求
基本信息变更验证以及资金注入，数据库访问和写卡时间控制在1秒之内
卡操作全部读写过程应控制在5秒以内，在3秒以上操作要给予适当的提示信息
本系统局域网数据在网络无故障的情况下，插入一条数据和更新一条数据的数据库操作响应时间在0.5秒/条之内。
3.2.3灵活性
程序启动和初始化时间控制在3秒之内，可实现系统满足设备的需要和需求。
留有与其他系统的接口，保证系统的灵活性更好。
“一战”至今, 随着传感器能力的提升, 战场武器装备的日益先进, 移动速度等能力都得到提升, 但人处理信息能力却始终没有变化, 所以面对复杂多变的未来战场, 开发相适应的现代化的指挥控制系统, 辅助指挥员作出正确的决策势在必行。
1 指挥控制问题描述
指挥控制系统的发展始于二战后, 美国于20世纪50年代末, 开发了“赛其” (SAGE) 半自动化防空系统。70年代初, 建成战略C3I系统。目前拥有较完善的军队C4ISR系统。我国在这方面研究起步较晚, 但是发展迅速。
指挥与控制的内容可以看作是各级指挥员在作战过程中所作出的两大决策, 决策内容和结果在各级指挥员之间存在着交互, 指挥与控制的内容可以以北约空军为例, 见图1。
具体地说, 指挥的内容是部队尚未执行任务前, 各级指挥员对整个战场环境进行考量, 作出相应决策, 即运筹, 其内容主要包括:
1) 任务分配, 根据整个战场环境配置投入到各战场的兵力比例;
2) 兵力部署, 根据各战场情况, 决定兵力的分布及具体数量;
3) 子任务兵力分配, 各部队根据分配的子任务决定出动的兵力;
4) 具体实施步骤, 以空军为例, 制定各种战术, 包括应该指派何种型号飞机执行任务, 制定进入任务以及退出任务的路线以使其所受威胁最小化, 作战效能最大化。
控制的内容是部队于执行任务过程中, 各级指挥员对战场环境的变化所作出的决策, 即规划, 其内容主要包括:
1) 资源重新分配, 预测战场环境的变化, 对兵力、物资等进行重新分配;
2) 任务重分配, 根据预测结果, 对各部队所指派的任务进行第二次分配;
3) 目标跟踪, 各部队利用现有技术, 跟踪所指派的目标;
4) 威胁预警, 当敌军进入到我方威胁区域内, 应及时预警, 作出决策。
在指挥与控制的过程中, 指挥员需要作出各类决策, 作出这些决策的时间及所需信息的多少也不尽相同。详见表1。
随着指挥层级的降低, 该层级指挥员所作出决策需要的时间呈现下降的趋势, 而信息聚合的程度也随之下降。
2 决策的制定及执行
指挥员在作战过程中根据战场信息作出相应的决策, 其制定的过程是固化在数据转化到行动的过程中, 所以指挥员首先必须能够获得战场信息, 从方方面面的战场信息中提取相关联的内容加以甄别以实现对战场的理解。指挥员在基于已有数据对战场理解的情况下, 作出一些作战方案, 对这些方案再进行评估, 最后选出最优方案。随着战况的逐步发展, 战场环境也瞬息万变, 指挥员也必须根据最新信息作出新的决策。
以上即是一个指挥员作出决策的一个描述, 根据上述描述, 我们可以将决策制定及执行的过程分解为以下四个步骤:战场态势的获取;战场态势的理解;备选方案的制定;方案的执行。
在决策制定的这四个步骤中, 指挥员都有可能出现错误, 分析如下:
1) 在战场态势的获取过程中, 指挥员可能会出现“我不知道”的问题;
首先, 指挥员需要知道尽可能多的战场信息以为自己决策提供数据支持, 然而战场信息涉及到各个方面, 作战武器装备繁多, 各式各样的行动又在不间断的进行着, 但是一个指挥员只能拥有有限的传感器, 即信息收集渠道, 每个传感器的监视范围又存在范围、天气、作战要求等的限制;
另一方面, 战场本身是动态的, 指挥员如果不能有效的, 合理的使用各传感器, 也可能造成指挥员不能收集战场态势信息的错误。
指挥控制系统在防止指挥员出现“我不知道”这个问题上应从以下两个方面出发:
首先, 应帮助指挥员建立起何时、何地应从各种传感器上了解什么的意识, 设计一个战场信息态势图可以很好的解决这个问题, 战场信息态势图应包括以下信息: (1) 所有传感器当前和规划后的位置; (2) 传感器能够覆盖的区域; (3) 监测的频率; (4) 重点监测区域; (5) 亟待监测区域显示; (6) 数据上传及处理流程; (7) 传感器使用限制区域 (减小反辐射导弹对雷达的威胁) ; (8) 可使用的兵力及武器; (9) 给出时间截点。
2) 在战场态势理解过程中, 指挥员可能会出现“我不理解”的问题;
即使在获取了全部战场信息的情况下, 指挥员可能依然会出现不能正确理解战场态势的问题, 其根本原因就是战场信息的不确定性。这主要体现在以下两方面:
首先, 战场态势被隐藏在了众多的数据之后, 需要指挥员去发掘;
另一方面, 指挥员对战场态势理解的方向出现偏差, 不是从已知事实出发, 没有通过更多信息的检验。这一点涉及到指挥员对战场走向的预测能力。
指挥控制系统在防止指挥员出现“我不理解”这个问题上应从以下两个方面出发:
首先, 对获得的信息进行过滤筛选, 提高信息纯度, 使决策时间尽可能短, 避免“噪音”对其的影响。
其次, 基于一些已有的假设去诠释战场态势, 推理敌军意图, 这又要求指挥员意识到以下几点:
(1) 敌军的目的、能力、原则、作战程序; (2) 可供敌军的选择; (3) 由于数据的缺失, 我军在行动上的不确定性。
最后, 指挥员应该意识到, 决策一旦作出, 需要更多实时信息检验指挥员对战场态势的理解是否正确。
3) 在备选方案的制定的过程中, 指挥员可能会出现“我没有考虑”的问题;
面对一个战场, 指挥员需要时刻关注转瞬即逝的机会, 比如天气、地形、敌军出现的决策错误。指挥员通常会制定几个可供选择的方案以创造优势交战或者是摆脱劣势交战, 以使我军行动效益最大化, 这就要求指挥员在大部分的时间内都要考虑选择何种方案。“我没有考虑”这个问题的根本来源于对行动结果的不确定性的忽视。
指挥控制系统在防止指挥员出现“我没有考虑”这个问题上应该帮助其了解我军及敌军的能力、地形和天气等各种因素, 各行动目标之间的关联, 在此基础上给出一些备选方案, 并且, 能够评估这些方案的结果, 给出相关风险和收益。
4) 在方案的执行过程中, 指挥员可能会出现“我没有行动”的问题;
在执行方案的过程中, 指挥员由于情绪的干扰, 外界的影响可能并没有按照既定方案执行任务, 或者在执行过程中出现执行时间或者是实施步骤错误的问题。
指挥控制系统在解决这个问题上应帮助指挥员确定如果不按照该方案行动, 所产生的后果如何, 应能够快速评估行动的结果以解决执行过程中可能出现的错误。
3结束语
随着以信息技术为核心的高新技术在现代战争中的广泛应用, 面对海量数据, 单纯依靠指挥员发挥自身能力作出决策明显跟不上现代战争的步伐, 所以应加快设计研究适应各级指挥员的指挥控制系统的步伐, 旨在未来战场中辅助指挥员快速的作出正确的决策。
参考文献
[1]孔祥忠.战场态势估计和威胁估计[J].火力与指挥控制, 2003, 28 (6) :91-94.
[2]雷蕾, 尚丽娜, 张列航.空战目标威胁排序与目标分配算法[J].电光与控制, 2010, 17 (4) :38-40.
[3]Rosenberger J M, Hwang H, Pallerla R, et al.The Generalized weapon target assignment problem[C]//10thInternational Commandand Control Research and Technology Symposium the Future of C2, Mclean, VA.2005.
[4]罗德林, 段海滨, 吴顺详, 等.基于启发式蚁群算法的协同多目标攻击空战决策研究[J].系统仿真学报, 2008, 20 (24) :677-678.
关键词：竞赛管理系统；需求分析；数据流程图；用例图
中图分类号：TP311.52
职业技能大赛是我国职业教育领域的重大创新，是促进职业教育向技能培养发展的重要手段，通过它可以培养选拔高素质劳动者和高水平技能型人才。目前，职业技能大赛已经成为各个职业院校教学和管理中的一项重要工作，但目前我院针对竞赛信息的管理主要是采用人工管理的方式。如何形成一套行之有效的管理機制、方法、工具和软件，来帮助竞赛的各方面相关人员（项目干系人）来更加轻松、快速、准确、高效的完成各项竞赛管理事务，是我们需要迫切解决的任务。
1 职业院校竞赛管理系统的目标
竞赛管理系统所达到的总体目标是：（1）学生可以利用该系统了解各个赛项的通知和获奖情况，并能够下载和使用学习资源，并且可以和教师或他人进行在线交流等；（2）竞赛辅导教师可以利用该系统进行竞赛过程中所用资源的管理，并可以和学生及他人进行交流；（3）参加职业技能大赛的教师可以利用该系统了解教师职业技能竞赛情况，并进行在线报名，和参考相应的学习资源，并且在此平台中为教师提供一个针对教育相关主题的学习园地；（4）教务部门可以利用该系统发布学生或者教师因为竞赛而产生的调课/停课情况。同时可以发布教师参与竞赛获奖的统计信息；（5）竞赛协调员可以利用此平台发布关于竞赛的相关信息，并且发布学生职业大赛的成绩统计等信息；（6）系部和院级领导可以利用该系统查看各赛项的参与人员及竞赛成绩等内容；（7）依据年度对竞赛成绩的统计分析，从而为学院评优和教师学术统计等信息提供坚实的依据。
2 竞赛管理系统的角色定义
通过角色可以针对竞赛管理系统的用户进行有效划分和管理。系统的用户角色可以分为几类：
2.1 学生
面向学院的所有学生。主要学生用户为包括想要参加竞赛而提前进行了解和学习的学生，和被选入竞赛团队要参与竞赛的学生；学生通过校内网络进入系统后，可以浏览公告，下载学习资源，查看以往的竞赛成绩、发表博客文章，进行站内搜索等工作。
2.2 竞赛指导教师
各个赛项中指定的学生指导教师。该角色用户进行系统后，可以浏览公告，管理（增加、修改和删除学习资源），发表博客文章，进行站内搜索等活动。因为各个赛项主要是以系为单位来组织竞赛的，因此不同的指导教师只能对自己添加的竞赛资源进行管理。
2.3 赛项负责人
某个竞赛项目的指定负责人。竞赛协调员将竞赛通知分发给系部主任，由系部主任指定竞赛项目的负责人，赛项负责人要负责竞赛指导教师和参赛学生的选拔，负责与竞赛协调员联系进行竞赛各项任务的跟进，负责竞赛佳绩通告的发布，负责在竞赛完成后，将所有的资源整理后提交给竞赛协调员。
2.4 参赛教师
参加各项职业技能大赛的教师。教师也逐步参与更多的职业竞赛，参赛教师进入系统后可以进行竞赛资源和成绩等信息的浏览，并可以通过系统发表博客文章，同时可以进行评论。
2.5 教务管理人员
教务部门中进行竞赛管理的相关人员。该角色用户进入系统后可以浏览公告、管理公告（添加、删除、修改），发表博客文章，进行站内搜索，管理教师竞赛成绩的汇总等工作。教务部门的人员主要进行教师竞赛信息的发布和竞赛结果的公布等内容；
2.6 竞赛协调员
协调学生参与职业技能大赛的人员。竞赛协调人员发布各项学生竞赛通知、协调竞赛过程中的相关事宜，并进行学生竞赛成绩的汇总和成绩（包括学生的成果和教师的成果）上报，以及进行教师分值和工作量确认等工作；
2.7 系统管理员
针对系统的各项工作进行全面管理和维护的人员。系统管理员可以进行系统所有的内容管理、用户管理、系统配置、系统备份等方面的工作。是整个系统最高权限的用户。
3 竞赛管理系统的功能模块
通过对竞赛管理系统不同用户的需求进行调研和分析，可以将整个系统的功能模块划分如下：
3.1 竞赛公告管理
根据竞赛公告的性质，可以将其划分为四种不同的类型：竞赛通知、竞赛佳绩、调停课通知和其他公告等类型。竞赛公告可以由教务管理人员、竞赛协调员、系统管理员进行发布。竞赛公告内容主要包括公告标题、公告内容、公告图片、公告附件、发布人和发布时间等。
3.2 竞赛资源管理
竞赛资源划分为学生竞赛资源和教师竞赛资源。在学生竞赛资源中一级分类可以按照系部进行按照，二级分类按照该系部所负责的赛项进行划分，在每个赛项下，按照资源的类别例如竞赛总结、历年样题、学习资料等进行安排。竞赛资源内容主要包括资源标题、资源类别、资源附件、发布人和发布时间等。教师竞赛资源按照年份进行一级分类，在年份下面按照赛项名称来进行二级分类。
3.3 学生竞赛成绩管理
学生竞赛成绩可以按照学年来进行显示，内容主要包括竞赛名称、竞赛时间、竞赛等级、获奖级别、参赛学生、指导教师和所属系部等信息。可以按照系部和获奖级别进行信息的统计。
3.4 教师竞赛成绩管理
教师竞赛成绩可以按照学年来进行显示，内容主要包括竞赛名称、竞赛时间、竞赛等级、获奖级别、参赛教师、所属系部和获得分值等信息。可以按照系部、获奖级别、和参赛教师个人进行信息的统计。
3.5 博客管理
使用该系统的所有用户可以通过博客来发表或者转载文章。针对所有的用户来说，博客是一个学习交流的园地。博客内容主要包括标题、所属类别、博客内容等。其他用户可以对某个博客进行评论。
4 总束结
通过对竞赛管理系统的需求进行细致的分析，可以明确竞赛管理系统中各个不同角色的定义，在确定系统的功能模块之后，可以针对每种角色确定其功能权限。该竞赛管理系统的需求分析为各个职业院校的竞赛管理提供了一个较为基础和全面的需求说明。
参考文献：
[1]杨巨龙，周永利.软件需求十步走：新一代软件需求工程实践指南 [M].北京：电子工业出版社，2013.
[2][澳]麦斯阿塞克著，马素霞译.需求分析与系统设计（原书第3版）[M].北京：机械工业出版社，2009.
作者简介：刘继敏（1976-），女，讲师，硕士，从事Web网站开发、数据库技术的研究。
营改增系统改造项目
需求范围说明书
奇瑞汽车金融股份有限公司
二〇一六年三月
1/ 19
项目要求 第一节 概述
根据国家税务总局的安排，银行业将实施“营改增”，即银行由缴营业税改缴增值税，同时为客户提供增值税税票。为配合“营改增”改革后各类应税和税务管理信息化需求，满足财政部、国税总局颁布的各类监管要求，启动营改增系统改造建设和现有系统改造。
第二节 系统方案与技术方面要求
1.1.总体目标
1.2.技术要求
技术方案需充分考虑到先进性要求，体现在以下方面但不限于以下方面：
1、开标供应商提供的功能应满足我司业务开展的要求；
2、开标供应商所提供的系统软件应符合业界相关技术标准；
3、提供系统完整的源代码，提供开发平台，至少满足我司二次开发的要求。
4、通过我司会计核算平台及核心、总账对接的方案，5、提供完整的营改增系统改造功能应用，基于营改增要求，完成我司现有系统改造功能；
6、系统支持跨平台部署等；
7、系统应充分考虑我司数据标准化的要求，能够支撑标准化和监管统计需求；
2/ 19
8、系统应采用平台化设计，支持功能性拓展；
9、系统扩充方便，设置修改灵活，操作维护简单，能够适应业务的快速变化及发展；
10、系统提供的软件产品在业务扩展、应用工具、数据库、操作系统等方面具有开放性，做到标准化、通用化；
11、系统安全、可靠，供用户进行有效的维护与使用,系统运行维护要求自动化、参数化和交易化;
12、系统严格按照软件工程要求提供详细的各类文档；
13、能够满足我司现有的开发规范，保证代码的可读性和统一性；
14、操作系统、数据库和中间件的配置符合我司技术架构要求，ip地址与目录等参数配置信息不得写在程序中；
15、基础软件，包括操作系统、数据库、中间件必须符合我司基础软件规范；
16、不允许使用RSA1024及以下强度的加密算法，建议使用国密算法；
17、在设计技术架构时需要充分利用我司现有的软硬件环境，充分考虑我司现有的软硬件环境，保证兼容性，保护我司现有投资；
18、满足我司应用架构的管理要求，充分考虑与其他系统之间的关联性。
19、系统支持负载均衡部署方式，性能不足时可以通过增加设
3/ 19
备线性扩展处理能力。
20、产品必须是行业主流产品，符合业界相关技术标准，在国内外有成功的技术实施案例，满足监管需求；
21、产品必须有后续研发系列，并有良好的发展前景；
22、可与主流厂商软件集成而不影响系统性能；
23、与系统连接的整体配置无单点故障，所有部件采用冗余设计，确保无任何单点故障，并能满足未来7×24小时的应用服务。
24、支持在线维护、更换、升级硬件部件和微码；
25、提供后续开发支持，对于人员成本单独报价。
1.3.系统技术设计原则
1、实用性和适用性
充分利用成熟的先进技术，采用性能/价格比比较高的产品。应用系统设计必须符合实际，适用于银行信息系统建设。
2、完整性
所设计需满足增值税管理所有要求，设计范围包括营改增系统改造和现有系统改造。
3、开放性、兼容性和连通性
所设计的系统在结构上真正实现开放，各种设计规范、技术指标及产品均符合国际和工业标准，包括各种广域网、局域网、计算机及数据库协议，并可提供多厂家产品的支持能力，从而为未来的业务发展奠定基础。系统中所采用的所有产品都要满足相关的国际标准和国家标准，是开放的可兼容系统，能与不同厂牌的产品兼容，4/ 19
可以有效保护投资。系统具备与各种协议计算机通行网络互连互通的特性，确保综合网公用基础设施功能充分发挥。
3、先进性
系统技术水平要保证先进性，符合当代信息技术发展形势，代表当前计算机科学的发展方向。所选择的各平台供应商应有能力对该项进行持续开发，可以保证该项技术不断地更新并可顺利升级而维持系统的先进性。提供良好的技术支持和技术服务，以满足当前的业务需求，使业务或生产系统具有较强的运作能力。
4、高可靠性和可用性
通过提供给用户高可靠的产品（硬件、软件、服务），带有系统容错性的方案(冗余、备份)，较强的管理机制和控制手段，具备事故监控和网络安全保密等技术措施，保证系统的安全可靠和高可用性。
系统建设尽量用主流产品，以保证系统的高质量和稳定性。系统应最大限度集成世界上最稳定且优秀的技术及组件，采用成熟技术以降低系统的不稳定性。对系统如硬件、操作系统、网络、数据库应设计尽可能详尽的故障处理方案，以保证系统的快速恢复。
5、灵活性和可扩充性
所设计的系统应具有良好的扩充性，能够根据管理要求，方便扩展网络覆盖范围、网络容量和网络各层节点的功能，以适应今后可能出现的较大任务符合。硬件平台具有可升级性，当需要时可以通过新的计算机设备同原有计算机设备一起工作以提高系统的5/ 19
处理能力，而保护原有的投资。在源系统改造或者前端应用的需求发生变化时，整个系统的架构和设计方法可以适应这种变化，不会对已有的平台造成影响。
6、易维护性
在系统总体设计上注意系统的维护性。尽量采用大家熟悉的易于维护系统平台。系统软件安装简单、易于操作。
7、标准化
应用软件开发符合软件开发标准的要求，方便维护和扩展。业务处理符合国家法律、法规和有关政策规定。
1.4.功能要求
系统需满足（但不限于）奇瑞汽车金融营改增系统改造系统的以下全部需求：
基于我司IT架构优化，设计现有系统改造功能，包括： 交易认定、价税分离； 会计核算； 客户信息管理； 发票回传。
需要建立统一 “营改增系统改造”实现各类应税和税务管理信息化的目标，包括以下几个功能：
实现“增值税票”的管理、打印等功能 搭建统一的税务管理平台
6/ 19
满足对外披露需求
基础功能 1 价税分离模块
1.1 价税分离原始数据导入
通过系统自动接口（手工导入作为辅助方式）方式，将涉及价税分离的各类交易数据导入营改增外挂管理平台，并支持导入数据验证校验、版本控制、导入日志记录等功能。
1.2 价税分离交易认定规则设置
提供增值税相关各类交易（包括常规贷款交易及特殊交易，如：经销商服务费摊销、贴息摊销、逾期利息转表外、期末补提利息、期初冲回等）认定规则和计税方法配置功能，形成交易明细与价税分离规则映射关系。
1.3 税率设置
提供增值税所属税目及税率信息维护功能，根据交易代码设置的税率，并作为价税分离计算参数。
1.4 价税分离计算
根据价税分离交易认定规则、税率和交易明细数据，进行价税分离计算。
1.5 会计分录生成
支持根据价税分离计算结果和银行会计科目及分录规则，自动生
7/ 19
成增值税调整及相关分录。2 销项发票管理模块
2.1空白发票管理
支持集中维护银行购买的空白发票功能，并提供总行对空白增值税专票的统一管控功能。包括请领入库，将购买的空白专票维护到营改增外挂平台中，每笔开票记录应与实物专票一一对应；专票分发，由总行或地市分行统一管理下辖所有机构空白发票的请领入库，并分发至各机构，系统上对空白发票的请领和分发进行统一管理（目前没有分支机构，但是该功能需保留）。
2.2发票盘点
支持对空白发票进行盘点，保证总分行发票打印的准确性及发票库存的准确性。其中各打印终端可按日盘点打印成功及待打印发票信息，按月盘点发票库存情况。支持生成盘点报表，并经复核人复核。
2.3发票打印
能够与金税系统开票请求接口集成，执行增值税专票打印工作。打印时，对客户资质、是否已开具发票等自动校验，防止错开或重复开票。同时，支持同一交易对手增值税发票打印的合并与拆分，拆分方式可选择平均拆分或自定义拆分。
2.4例外处理
对增值税打印过程中遇到系统异常等意外情况进行记录，并支持对例外事件后续跟进处理。例如，打印未成功需重打，但已经从待打印池中已找不到该笔发票信息；需要冲红已打印的发票再重打；打印
8/ 19
冲红发票等情况。
2.5手工开票
对于需手工开票的业务收入，若属于系统内中间业务收入，由专票打印员通过模糊查询，向交易数据的接口提交数据请求，交易系统返回交易信息和客户信息给营改增外挂管理平台，选择需要打印的任务，提交审批完成后发起打印请求；若属于系统外相关业务收入，由专票打印员手工录入专票信息，提交审批完成后发起打印请求。
2.6发票追溯
提供增值税发票的追溯功能，支持对发票各个节点操作的记录、时间、操作人进行追溯。
2.7发票遗失管理
对遗失的增值税专用发票进行登记记录，并将信息传给金税系统进行挂失处理。
2.8发票作废
当发生空白专票或已开专票作废情况时（如尚未使用的纸质专票损毁），支持相应专票作废处理流程，并进行详细记录。
2.9红字发票管理
支持红字发票开具、申请和审批流程管理功能，并进行详细记录。2.10电子税票管理
待电子发票在行业内推行之后，支持电子发票的开具与管理，并与税务局电子发票系统对接，实现发票数据的传输。3 进项发票管理模块
9/ 19
3.1认证 扫描认证
登记银行收到的各类增值税发票，记录各类进项税票银行内部审批结果，支持进项发票审批状态查询。通过金税系统扫描登记进项专票信息，提交给税务专员审核。
电子认证
对于取得的专票，能够实现与税务局电子发票系统对接，进行电子认证。
3.2进项转出
支持对涉及进项转出的数据信息录入平台，并按照预设逻辑对进项发票进行进项转出操作，并提供汇总功能。
3.3预警提示
对进项发票的认证状态进行跟踪，对于接近认证期限仍未进行认证的发票设置自动预警提示。
3.4抵扣认证
支持通过审批的进项专票上传至税务局网站进行认证，可即时联机认证或统一批量认证，认证通过后将认证信息回传至财务管理系统进行进项科目的调整。
3.5未通过认证管理
对于未通过认证发票，显示原因并记录后续跟进和处理流程。4 税务管理
4.1纳税申报管理
10/ 19
支持增值税纳税申报数据采集、计算和人工调整功能，生成纳税申报报表和相应会计分录。
4.2税务管理统计查询
支持多维度、跨组织的税务管理数据、增值税计算明细、发票信息综合查询功能，并提供税务数据分析和风险监控功能。
4.3税会差异分析
针对增值税会计口径数据、税务申报口径以及开票口径进行自动差异分析，形成税会差异分析报表。5 系统基础管理
5.1纳税主体管理
提供纳税主体基本信息维护功能。5.2用户权限和日志管理
提供基于角色授权的用户权限管理体系和详细的系统操作日志记录机制，保障系统数据信息安全。
5.3系统接口管理
提供包括金税系统、数据仓库、财务系统、业务系统等与平台相连接的数据接口管理和维护功能，接口应为开放式，对于新增业务能够及时维护，并导入数据。
5.4工作流设置
支持系统内部各类管理流程的审批工作流配置与维护。5.5 数据备份还原管理
支持平台中各类数据、信息的备份和还原功能，确保业务连续性。
11/ 19
电子发票管理
6.1电子发票数据生成
支持按预先设置的开票规则填开发票，提交税务机关后台系统生成电子发票数据，并自动分配电子发票号码同时对开票信息加密，生成防伪码和二维码，最终生成完整的电子发票。
6.2电子发票作废
当发生开票错误等情况时支持电子发票的作废处理，并进行详细记录。
6.3电子发票红冲管理
支持电子红字发票开具、申请和审批流程管理功能，并进行详细记录。
6.4电子发票查询和统计
支持在系统中查询和统计已开/未开电子发票以及已收进项电子发票的开票项目、开票金额等信息。
6.5进项电子发票认证抵扣
支持系统录入获得的进项电子发票信息，将通过审核的进项电子发票上传至税务局网站进行认证，可即时联机认证或统一批量认证，认证通过后将认证信息回传至财务管理系统进行进项科目的调整。
6.6电子发票预警
支持对电子发票开具过程中异常情况的预警，包括作废过多、红冲过多、申报异常等。营改增系统改造其他业务要求
12/ 19
7.1实现财管系统、会计核算平台、数据集市及其他相关系统的对接，与其他系统交互通过DS或文件分发平台。
1.5其他要求
一、系统测试
系统测试是项目质量的重要保证，开标供应商必须配备专业的测试人员，组建专业的测试团队，制定完善的测试方案。测试方案包括功能测试和非功能测试。
1.功能测试方案应包括如下测试内容： －测试目标 －测试范围
－参加测试人员及组织分工。－测试过程中的缺陷管理。－测试完成标准
－测试工具：测试用例管理工具、缺陷管理工具、性能测试工具、配置管理工具等。－测试数据。－测试实施计划。-测试风险分析。－测试交付物。
－测试的审核和结果认定方法。2.非功能测试方案应包括如下测试内容： －测试目的
13/ 19
－测试范围 －测试启停准则
－模型：业务模型、测试模型 －测试指标 －测试策略 －测试内容
－测试实施准备：环境准备、工具准备、数据准备、脚本准备 －测试组织结构 －测试实施计划 －测试风险分析 －测试交付物
－测试的审核和结果认定方法。
二、项目验收
验收是在项目完成开发并成功试运行的基础上进行的。试运行期不能少于两个月。测试验收由采购人组织，对应用软件进行测试验收，合格后出具合格证明。如试运行期间统计或测试数据表明系统在功能、性能指标或可靠性方面不符合要求，开标供应商有责任及时解决，应根据问题严重程度和解决时间，顺延或重新开始试运行。
成交供应商必须为每一项的测试编写测试手册。验收测试手册的内容包括：测试目的、测试环境和测试所需的设备、测试过程的描述、测试结果及分析、具体的安装、测试和验收要求以最终合同
14/ 19
签订为准。
验收需要开标供应商提交的文档至少包括：系统建设的详细工程日志、系统的需求说明书、系统的概要设计、详细设计说明书、系统的数据库设计说明书、系统的使用说明书、系统的操作说明书、系统的测试大纲、系统的测试报告。
验收需要开标供应商提交的全部源程序，提供开发工具、自有产品及开发平台，以及相应的书面说明等，并保证其合法性，由此产生的所有争议和法律问题由开标供应商负责，由此产生的全部费用由开标供应商负责。
如试运行期间统计或测试数据表明符合要求，将通过延伸，在双方签署验证证书后进入保修期。
三、技术支持及售后服务
开标供应商在邀标文件中必须书面声明充分了解并接受奇瑞汽车金融股份有限公司的技术支持及售后服务条款，即：
1、在跟踪维护期内，乙方每年必须为甲方提供2次应用系统检测和评估，并提供检测和评估报告，侦测应用系统中可能会出现的问题，以协助防范可能出现的风险；
2、在跟踪维护期内，乙方保证按照本合同约定的服务内容、服务方式和服务质量向甲方提供合格的服务，乙方保证服务质量符合甲方要求，并通过甲方验收；
3、在跟踪维护期内，乙方保证提供服务的技术人员的数量和素质满足履行本合同的要求；保证人员的稳定性，未经甲方同意不
15/ 19
得随意更换；如果甲方要求更换服务人员的，乙方应根据甲方的要求更换；
4、对于重大系统的上线、年度决算等重要时点，乙方将提供现场的技术支持服务，以协助系统的顺利运行。
5、乙方提供7x24x365的故障应急反应机制。甲方系统一旦出现重大故障，则马上启动故障应急反应程序，提供远程技术支持，并承诺采用最快的交通工具赶到现场，提供现场的技术支持和技术保障，以协助生产和运行的顺利进行。到达现场后，乙方将协助客户进行故障诊断和排除。如故障发生的原因是由乙方提供的产品或服务引起的，则乙方会调集技术人员以尽早修复，并提出书面故障分析报告；如确认故障发生的原因是由第三方提供的产品或服务引起的，则乙方向客户提供书面故障诊断分析报告，在提供书面故障诊断分析报告之前，乙方将口头报告故障原因，并协助客户与该第三方交涉，配合第三方排除故障。
6、在跟踪维护期内，乙方为甲方提供甲方工作时间的远程技术电话支持。乙方在接到甲方通过电话或电子邮件方式提出的服务请求后，应在2小时之内给予响应。如有软件故障不能通过电话解决，乙方应在24小时内提供现场技术支持。
7、服务完成后，乙方应将完整的、与所提供服务有关的技术资料，包括但不限于：系统维护纪录、系统变更记录、完整的源程序代码等装订成册提交给甲方系统管理部门；
8、乙方应提供必要的技术指导和不少于5人天的封闭式技术
16/ 19
业务培训，保证甲方能正确、安全、有效地使用及维护系统。
9、根据甲方要求对修正系统差错、改进系统性能、增加系统功能；
10、乙方保证派出人员遵守甲方有关制度、工作纪律和安全规定，乙方服务人员应在甲方规定的工作场地范围内工作。
11、在跟踪维护期内，由于乙方软件产品质量产生的问题，乙方免费提供维护。
四、项目实施
1、项目管理
开标供应商应按照项目管理的要求向我司提供开发计划、时间进度。
开标供应商应明确提出参与本项目的工作人员构成、职责、学历背景、从业背景及参与本职工作的时间。开标供应商应确保在项目实施过程中不变更奇瑞汽车金融认可的项目经理。
在技术需求应答书中，开标供应商应明确其分担职责，进行清晰的工作任务描述。
开标供应商应向买方明确提出详细的质量控制、风险控制措施，确保项目的顺利进行。
2、项目人员
a、项目经理、咨询人员
项目经理、咨询人员必须有2（含）家以上相关银行营改增系统改造完整项目实施、咨询经验。
17/ 19
b、开发人员以及测试人员
开发、测试人员必须有2年以上的开发、测试工作经验，在通过我司相关考试、审核后方能进入项目组开始项目的开发、测试工作，开发、测试人员不允许复用。
以上项目经理、咨询、开发、测试人员，中选方在驻场实施前必须提供相应的工作、学习简历，供采购方进行审核，如采购方不予认可，成交供应商必须按照采购方的要求更换人员。在项目实施阶段，如采购方认为项目经理及实施人员达不到相应要求，采购方有权要求成交供应商更换符合要求的人员，成交供应商不得以任何形式、理由进行拒绝。另，成交供应商需承诺保证实施过程中研发团队的稳定性。
3、进度
项目应在2016年5月1日前完成（包括应急方案）。
4、技术业务支撑
参与我司项目各阶段（系统调研、硬件采购、需求分析、系统设计、系统联调测试、培训、系统上线）的工作。
第三节 售后服务
开标供应商对售后服务及系统维护、数据整理和维护工作的技术责任应作明确说明，包括质保期限承诺、服务响应承诺、系统应急方案、技术支持和相应软件的升级承诺。
一、中选供应商承诺提供一年免费原厂维护。
二、在保修期内，如果软件设计厂家对用户购买的软件有了升级
18/ 19
版本，成交供应商应及时通知用户。如果用户有要求，成交供应商应向用户免费提供相同功能的相同软件升级和技术支持。成交供应商有责任在保修期内提供以下形式的技术支持服务：
详见第二节1.5项”技术支持及售后服务”部分。
【财务系统需求分析说明】推荐阅读：
系统需求说明书06-01
监测系统需求分析报告06-18
门禁管理系统需求06-29
合同管理系统需求文档07-26
财务收支情况说明07-18
财务报表舞弊识别系统05-30
完善财务管理系统07-01
年度财务情况说明书07-14
财务信息系统实习报告07-10
库存管理系统说明文档05-26
