综合积分业务需求说明书 - 2016

综合积分业务需求说明书 - 2016
综合积分业务需求说明书 - 2016

文档编号:

综合积分系统业务需求说明书

四川省农村信用社联合社版权所有,2013

本文件中包含的任何文字叙述、文档格式、插图、照片、方法、过程等内容,除另有特别注明,版权均属四川省农村信用社联合社所有。未经许可任何人不得将此文件中的任何部分以任何形式进行复制,储存和传播。

文档发布声明

本【业务需求说明书】自公布之日起在四川省农村信用社联合社信息科技中心内有效。

版本记录

目录

1 引言 (5)

1.1 目的 (5)

1.2 背景 (5)

1.3 术语和缩略语 (5)

1.4 约束条件 (6)

2 业务范围 (6)

3 功能需求描述 (6)

3.1 业务功能分类 (6)

3.2 机构、岗位及权限设置 (7)

3.3 客户综合积分营销管理系统各项功能模块 (7)

3.3.1 客户端功能模块描述 (7)

3.3.2 管理端功能模块描述 (8)

3.3.3 积分商城 (11)

3.3.4 合作伙伴积分兑换功能 (11)

3.3.5 数字地图及商圈服务 (12)

4 报表需求 (12)

4.1 积分管理报表 (12)

4.2 供应商管理报表 (12)

4.3 系统预警报表 (13)

5 管理支持类数据需求 (13)

1引言

1.1目的

本文准确描述关于开办积分系统业务功能的需求,明确积分系统的功能与管理设计,作为开发人员了解系统的基础、设计开发的依据和用户验收的标准。供用户、开发人员、测试人员和项目负责人等相关人员阅读。

1.2背景

金融市场的竞争日趋激烈,竞争的焦点也逐渐转向差异化和专业化,为适应市场发展的需求,进一步增强竞争力,急需建设客户综合积分营销管理系统(以下简称“积分管理系统”),通过科技和系统创新来吸引潜在客户,留住既有客户。同时借助此系统实现有效区分或筛选客户群体,便于针对性营销宣传,形成对业务发展切合实际的营销工具,有效刺激客户购买本行产品或服务的意愿和积极性,提升客户忠诚度,提高客户综合收益贡献。

1.3术语和缩略语

■客户综合积分营销管理系统:综合积分系统是一套集客户管理与营销管理于一身的应用系统,涉及营销活动的设置、审批、执行、客户积分管理、内置规则计算引擎、客户服务渠道支持到礼品供应商管理、订单处理等各个环节,并最终形成了一个协作、分析、集成的闭环管理,通过本系统的实施,可增强客户的忠诚度、并建立起企业整体忠诚度战略管理体系。

■积分合并:是指系统用户遵循一定的权限控制,可以将客户的多个指定账户或客户所有账户产生的积分合并到统一客户号下,实现客户维度的积分汇总、管理和维护。

■积分迁移:是指遵循一定的权限控制,将客户某个账户的积分(或客户的综合积分)按照一定的转移规则约定,转移到其他客户的某一账户(或其他客户)的积分中。

1.4约束条件

1.开发测试时间6个月,系统上线时间2016年6月底前完成系统的开发测试工作;

2.系统目前只支持人民币,所有交易默认为人民币交易。

2业务范围

■客户范围:

■业务产品范围:此业务系统满足客户积分和积分管理功能。包括积分查询、积分兑换、积分消费、积分管理等。

■渠道范围:可通过门户网站、网上银行、手机银行等多渠道实现此系统的相关业务功能。

■适用币种范围:目前仅适用人民币。

3功能需求描述

3.1业务功能分类

根据用户登陆角色的不同,实现不同的功能,具体功能分类见图1-1。

图1-1 客户综合积分营销管理系统功能示例图

3.2机构、岗位及权限设置

3.3客户综合积分营销管理系统各项功能模块

客户综合积分营销管理系统功能模块包括:客户端功能模块和管理端功能模块。客户端功能包括通用查询、积分兑换、积分消费、积分兑换撤销等;管理端功能包括

3.3.1客户端功能模块描述

(1)通用查询。客户凭身份登录可查询客户基本信息(含客户在生产系统中留存的基本信息)、客户积分总额、积分详细查询、礼品信息、礼品兑换信息、积分兑换规则、公告等信息。根据客户名称及有效身份证件,实现客户详细信息及积分详细信息查询功能。在查询客户积分明细时,可以显示客户号下所有账户的积分情况。

(2)积分礼品兑换。客户发起积分兑换指令,后台系统通过有效身份证件或客户号识别客户并查询显示该客户的可用积分,系统默认根据客户的当前可用积分和兑换规则,搜索出相应范围的可兑换产品,进行积分礼品兑换操作。

(3)积分兑换撤销。当兑换订单尚未进行派送时,可以进行积分兑换的撤销。撤销的同时,系统将自动进行积分冲正。积分冲正适用于错扣积分、错转积分等情况。

3.3.2管理端功能模块描述

(1)系统管理。根据管理者身份和级别的不同,进行不同机构及管理角色配置。省级联社可管理适用机构、市州联社管理角色配置;市州联社进行县区联社管理角色配置;联社管理部门进行营销管理角色配置。

(2)权限管理。实现对系统的组织机构、用户、角色、权限的管理,并实现页面菜单信息的灵活定制,基础代码表信息的维护管理。

(3)机构管理。此功能模块实现积分系统中的机构的新增、撤销、查询、维护和管理。

(4)角色管理。此功能可以在系统内新增、修改、删除某一角色,在新增和修改角色时,可以设置角色名称、描述以及该角色具有的使用权限设定。可以在系统内对角色信息进行查询,包括查询角色的权限范围。

(5)用户管理。此功能可以在某一机构和业务部门下新增、修改、删除用户,在新增和修改用户时,可为该用户配置一定的角色可以根据角色、机构和部门查询到管辖的所有用户详细信息。

(6)积分规则管理

■通用积分规则。通用积分规则由总行统一制定,各分行也可以根据自身特色业务自定义基础规则,上报总行后执行。通用积分规则是设置积分的基本条件,具体积分规则需根据业务发展的侧重点进行配置。

■营销活动积分规则。主要针对总行或分行开展营销活动时,产生营销活动积分设立的规则。

■赠送积分规则。主要针对高端客户生日或某些特殊活动时,对客户进行积分赠送设立的规则。

■积分合并规则。例如普通卡的积分要合并到金卡账户上,可设置适当的合并系数。

■积分转移规则。设置客户(账户)积分转移到另一客户(账户)时的规则,例如只能转移金卡以上账户的积分。

■积分消费规划。设置积分消费的规则,例如积分可用于抵扣某些交易的手续费用。

(7) 积分管理

积分管理实现对积分的合并、迁移、调整、冲正等管理。

■积分合并。积分合并是指系统用户遵循一定的权限控制,可以将客户的多个指定账户或客户所有账户产生的积分合并到统一客户号下,实现客户维度的积分汇总、管理和维护。经过积分合并后,客户指定账户的积分可以按照一定的合并约定合并使用。

■积分迁移。是指遵循一定的权限控制,将客户某个账户的积分(或客户的综合积分)按照一定的转移规则约定,转移到其他客户的某一账户(或其他客户)的积分中。

■积分调整。是指积分管理平台的管理人员根据业务需要,对用户的积分进行适当的分值增加、删除等调整行为。

■积分冻结/解冻。对严重违约的贷款逾期客户或其他黑名单客户的积分进行冻结,对于已冻结积分的客户,如果已还款可做解冻处理。积分的冻结可通过在积分策略中设置贷款逾期最大天数,由系统自动筛选逾期贷款客户进行积分冻结;也可根据客户的其他违约情况,使用本功能进行手工冻结。当客户的违约事项解除时,使用本功能进行积分解冻。积分冻结的客户不允许使用积分进行消费,不允许进行积分合并和转移,但可继续产生积分。

■积分互换。当积分平台与第三方平台进行积分互换时,如果是由第三方积分换至银行时,需要第三方提供客户的积分数据;反之,银行传送客户的积分或者依据积分互换策略将计算完成后的积分,转至第三方平台。根据积分互换的策略,客户的银行积分和第三方的积分进行相互兑换。

■积分有效期管理。是指银行为了进行业务或产品促销,而对该业务或产品交易产生的积分设置有效期限,规定该笔积分在一定时间段内有效,超过固定期限则该项积分自动失效。客户积分产生后的这段可以消费使用的时间称为积分有效期。积分有效期管理指针对积分有效期进行设置和维护。

(8)礼品管理

礼品管理主要完成对各类礼品信息的新增、修改、删除、查询、上下架维护等管理,可通过导入供应商提供的礼品目录文件,进行礼品的上下架管理。供应商提供Excel文件应遵循本系统的格式要求。

■礼品分类管理。在系统内设置不同的礼品分类,礼品供应商提供的礼品数

据也应按此分类进行,可进行礼品分类的增加、删除、查询和修改。

■礼品库存管理。对供应商提供的礼品,系统将根据供应商提供的数据进行库存维护,当客户兑换礼品的时候,相应更新礼品库存。

■礼品退换管理。受理客户提出的礼品退换申请,并经主管审核后通知供应商进行退换货。

(9) 供应商管理

此功能由总行和分行营销管理人员操作,实现对礼品供应商的增、删、改、查等日常维护管理。客户礼品兑换订单产生同时,系统自动按照供应商和礼品的不同分布产生供应商订单,积分管理平台的营销管理员可查询系统内不同供应商的礼品订单情况,并可按照不同供应商导出 Excel 文件,分发给不同供应商进行礼品派送,并相应维护系统内的订单状态。

(10) 商户管理

■商户信息管理。商户信息管理对行内的合作商户信息进行管理,实现新增、修改、删除、查询合作商户信息,包括商户编号、商户名称、商户类型、商户积分、商户等级、商户活动等信息。

■商户积分清算。为提高商户刷卡交易的积极性,系统提供商户积分管理和清算功能,能够对不限数量的合作商户进行有效的商户积分清算处理及账务结算,并产生与商户的清算结果、对账结果和差错清单。在实际建设中,系统可根据商户编号或 POS 编号进行积分管理和清算,针对积分高的商户或收银人员,可另行制定奖励政策。

(11)增值服务管理

该功能可以根据服务商编号、服务商名称、服务商注册时间等查询出服务商信息,并可根据查询出来的服务商进行增、删、改、查功能。还可根据查询出来的服务信息进行增、删、改、查功能。

(12)公告信息管理

积分商城首页显示商城活动公告,如最新积分活动公告等。同时,在“帮助中心”提供新手上路、常见问题解答、在线客服等,及时解答商城会员在使用商城过程中遇到的各类问题,提高会员满意度。

(13)订单管理

订单管理是对商城订单的确认、发货、完成和取消等操作,订单确认后将自动生成对应的物流配送单据,根据供应商和商户情况,可通过接口发送电子单据给供应商配送,商户也可直接登录商城获取配送单据。

(14)会员管理功能

积分商城的会员管理包括会员的注册、登录认证和会员信息资料的维护、会员密码修改重置等。通过会员管理,可建立完整的会员客户信息,有助于补充行内客户信息资料,支持通过网银交叉验证注册。

3.3.3积分商城

积分商城是专门为积分消费而设立的网上商城。积分商城首页包括商城公告、新品推荐和礼品兑换排行榜,并分类展示商城上架的各种商品会员可以使用积分兑换商城陈列的礼品。商城提供实物礼品和非实物礼品,包括供应商和合作商户、联盟商户的礼品等;礼品兑换包括积分兑换、积分加现金兑换方式。会员登录积分商城后,可根据积分账户的积分情况,按照商品类别、积分区间等条件查询可兑换的商品,支持收藏夹、购物车功能,确认兑换后,系统自动生成订单,会员确认支付后,进入订单配送环节。会员支付时可选择积分支付,或积分加现金支付方式。对于已生成的订单,会员可查询订单状态、物流配送情况,对于配送完成的订单,会员可进行退换货申请、商品和配送的评价。通过积分商城,可以实现礼品兑换、礼品配送、商户结算等商业流程电子化,并提供会员管理、商户管理、商品管理、订单管理、结算管理、公告管理等管理功能。为客户提供互联网积分的使用和兑换渠道。

3.3.4合作伙伴积分兑换功能

银行与第三方平台建立合作伙伴关系,客户根据银行提供的合作伙伴积分消费策略,兑换第三方提供的产品,兑换成功后将兑换信息返回至积分平台保存,供银行和客户查询。

3.3.5数字地图及商圈服务

在行内搭建地图服务器和使用互联网上的开源地理信息,实现积分系统与行内其他系统共用本行的数字地图信息。数字地图要精准显示街道、楼宇,可清晰的看到周边环境位置、交通,各营业网点分布也需要在地图中显示。在数字地图的基础上,进一步将周边合作商户的情况、优惠活动情况推送给客户,并提供商圈优惠券下载等增值服务。

4报表需求

报表管理实现对客户积分管理、积分兑换、礼品订单情况等的查询统计分析。

4.1积分管理报表

积分管理报表支持按不同要素进行积分信息查询,包括查询客户的累计积分、已兑换积分和当前可用积分余额、在一段时间内的积分明细、有效期等。“客户兑换明细查询”可查询客户在一段时间内兑换礼品的明细信息;“礼品兑换统计分析报表”实现按机构对客户兑换礼品的分析,关注兑换的礼品类别、兑换的总积分、兑换的礼品数量及比例关系;“客户积分分布报表”实现总分行根据设定的不同积分区间对客户积分分布情况进行统计,包括不同积分区间的客户数、客户属性分布、产品种类、贡献度、流失情况等,为制定营销策略、策划营销活动提供数据依据;“积分排名查询”实现根据输入的维度(含总积分、年龄段、产品种类、交易类型等)和排名数量,生成辖内客户积分排名,并提供客户清单打印。

4.2供应商管理报表

实现对供应商的差错、订单和退换货情况进行统计。“供应商对账差错统计”实现按照自然月末统计在内银行与供应商处理积分兑换订单的差异;“供应商礼品订单统计”实现分行管理员可以按月汇总出供应商礼品订单的情况,了解各个礼品供应商的礼品兑换情况、派送情况和退换货情况,从而检查供应商的礼品和服务质

量;“供应商绩效评估统计”实现对供应商礼品供货、配送、退换等情况进行统计,从而对供应商的绩效做出评估;“供应商退换货统计”实现统计当月供应商退换货情况。

4.3系统预警报表

监控预警报表是根据系统运行过程中产生的预警事项和运行状态生成报表,保证系统正常运行。包括“礼品库存预警报表”,当前礼品数量低于某一阈值时系统会自动提示,操作员可据此查看相关礼品清单,以此提醒供应商及时备货并更新库存。还可进行“用户操作日志监控”和“系统批处理监控”。

5管理支持类数据需求

积分系统提供实时对外服务接口,通过对接口模块化的管理以支持各渠道的积分查询、转移、扣减、撤销等积分账户联机操作。系统可面向网银、手机银行、CallCenter 等提供包括但不限于积分余额查询、积分明细查询、积分有效期查询、积分兑换和积分兑换撤销等服务。

软件开发 业务需求说明书模板

深圳天源迪科信息技术股份有限公司 项目编号/BRS版本:X.X 状态: XXX系统 业务需求说明书 本文件属深圳天源迪科信息技术股份有限公司所有, 未经书面许可,不得以任何形式复印或传播。

文件建立/修改记录

目录 1 简介 (4) 1.1 目的 (4) 1.2 背景 (4) 1.3 适用范围 (4) 1.4 参考资料 (4) 1.5 术语 (4) 2 业务需求 (4) 2.1 <业务需求1> (4) 2.1.1需求来源 (4) 2.1.2需求描述 (4) 2.1.3角色 (4) 2.1.4解决方案 (4) 2.1.5优先级 (5) 2.1.6补充内容 (5) 2.2 <业务需求2> (5) 2.3 <业务需求3> (5) 3 附录 (5)

1简介 1.1目的 【列举说明编写业务需求说明书要达到的目的。】 1.2背景 【可能的相关背景知识介绍。】 1.3适用范围 【说明此文档所适用的范围。】 1.4参考资料 【编写业务说明书时参考的相关资料,需指明出处与时间。】 1.5术语 【对文档中使用到的相关术语、简称作以解释。】 2业务需求 2.1<业务需求1> 2.1.1需求来源 【说明提出此需求的单位及个人。】 2.1.2需求描述 【用户提出的需求简要说明,比如“管理业务”。】 2.1.3角色 【说明与此需求相关的角色。】 2.1.4解决方案 【说明针对用户的问题,所提出的解决方案。如果有多个,可以在此处都列出来。】

2.1.5优先级 【说明此项需求的优先级。】 2.1.6补充内容 【在上面5点之外需要描述的内容。】 2.2<业务需求2> …… 2.3<业务需求3> …… 3附录 【各种需要在本文档中补充说明的附录和附表。】

银行综合业务系统需求规格说明书

银行综合业务系统 需求规格说明书 工程名称银行业务综合系统工程编号编写单位Object小组编写日期负责人周侃版本号

目录 一、引言3 1.1编写目的3 1.2工程背景3 1.3定义4 1.4参考资料5 二、任务概述5 2.1目标5 2.1.1 用户特点5 2.1.2 业务设计目标6 2.1.3 开发原则7 2.2名词解释8 三、系统概述15 3.1系统概述15 3.2具体架构说明17 四、需求分析17 4.1界面需求18 4.1.1签到界面19 4.1.2客户开户界面20 4.1.3账户客户界面20 4.1.4贷款21 4.1.5签退界面26 4.1.6查询错误!未定义书签。 4.1.6.1账户查询错误!未定义书签。 4.1.6.2贷款查询错误!未定义书签。 4.2交易需求27 4.2.1Teller端27 4.2.1.1签到27 4.2.1.2签退28 4.2.2ESB端29 4.2.2.1服务拆分29 4.2.3Core端29 4.2.3.1客户开户界面29 4.2.3.2账户开户界面30 4.2.3.3贷款发放界面32 4.2.3.4日终错误!未定义书签。 五、数据描述33 5.1 系统描述33 5.2 系统E-R图33 5.3实体及其属性的分析37 5.4实体间的关系分析38

一、引言 近年来,金融业的竞争开始由低层次向高层次发展,高科技战场将是我国各银行参与竞争、加快自身发展的主战场。银行要保持和扩大市场份额,必须拥有一种明显的、持久的优势。这种优势不是产品的优势,也不是网点的优势,而是高科技的优势。因此,银行电子化是银行提高工作效率,提高经管水平,提高服务质量,加速资金周转,促进社会经济发展的趋势。 随着计算机技术的不断发展,银行电子化水平的提高起到了积极的作用。随着客户金融意识的加强,对银行的选择条件也越来越高,而选择的尺度主要就是银行的服务质量。现在客户对银行的服务要求不仅仅是礼貌服务,更主要的看银行能不能给其提供更多的便利、更好的服务方式、更先进的服务工具来满足他们的各种需要。目前,各银行都投入许多精力,针对客户需求,在保持和完善传统业务的基础上,利用信息高技术开拓了许多新的业务领域,为客户提供了许多新的服务手段。 因此,由于银行有处理大量数据的要求,全部采用人工的方式处理显然不合适。这不仅要花费很高的成本,而且处理事物的效率和质量都存在很大的问题。处于这些问题的考虑,采用计算机来处理这类问题就是一个相当理想的解决技术方案。利用计算机可以极大地降低处理成本,更重要的是可以几乎没有错误的高效的处理所有的事务。 1.1编写目的 编写该文档的目的是明确“银行综合业务系统”工程的业务背景、业务范围、定义工程的专业名词,分析工程的核心功能和系统需求,为后续的系统设计以及开发人员和测试人员提供功能需求和非功能需求的详细定义,为测试人员提供测试用例设计的功能参考。 该文档为了便于更好地理解客户对软件的需求,对于其软件性能以及功能需求有一明确的目标,对于工程规划以及进度也做了简单的计划。 预期读者:组内成员 1.2工程背景 1.开发工程名称:银行综合业务系统 2.任务提出人员:神州数码融信软件有限公司

业务需求说明书(管理与数据类参考模板)

某银行 XX业务需求说明书 提出部门:xxxx部xxxx年xx月

文档修改记录

签署记录

目录 1.引言 (6) 1.1目的 (6) 1.2背景 (6) 1.3术语和定义 (7) 1.4业务规范与标准 (7) 1.5参考资料 (8) 2.需求目标 (9) 2.1用户描述 (9) 2.2业务价值 (9) 2.3业务现状 (10) 2.4业务目标 (10) 2.5约束和假设 (10) 3.需求范围 (11) 3.1范围概述 (11) 3.2功能范围 (11) 3.3数据范围 (11) 3.4区域/机构范围 (11) 4.功能需求 (12) 4.1功能1(适用于有流程的需求) (12) 4.1.1 功能概述 (12) 4.1.2 业务流程 (12) 4.1.2.1流程节点1 (12) 4.1.2.1.1输入 (12) 4.1.2.1.2处理 (12) 4.1.2.1.3输出 (12) 4.1.2.1.4业务规则 (13) 4.2功能2(适用于无流程的需求) (13) 4.2.1 功能概述 (13) 4.2.2 输入 (13) 4.2.3 处理 (13) 4.2.4 输出 (13) 4.2.5 业务规则 (13) 4.3功能3(适用于数据处理的需求) (13) 4.3.1 功能概述 (13) 4.3.2 输入 (14) 4.3.3 处理 (14) 4.3.4 输出 (14) 5.附件1 (17) 5.1非功能性需求 (17) 5.2数据要求说明书 (17)

5.3需求优先级 (17) 5.4表单及报表样例 (17) 5.5灾备等级评分指标 (17)

业务需求说明书模板

1 引言 (3) 1.1 编写目的 (3) 1.2 范围 (3) 1.3 项目背景 (3) 1.4 主要业务名词和术语定义 (3) 1.5 参考文献 (3) 2 需求概述 (3) 2.1 用户现状/业界当前系统 (3) 2.2 业务目标 (4) 2.3 业务过程分解 (4) 2.4 本业务模型与其他系统的关系 (4) 2.5 业务边界定义 (4) 3 详细需求 (4) 3.1 子业务1 (4) 3.1.1 业务流程 (4) 3.1.2 干系人的关注目标 (5) 3.1.3 业务规则 (5) 3.1.4 操作界面说明 (5) 3.1.5 数据实体 (5) 3.2 子业务2 (5) 3.2.1 业务流程 (6) 3.2.2 干系人的关注目标 (6) 3.2.3 业务规则 (6) 3.2.4 操作界面说明 (6) 3.2.5 数据实体 (6) 4 基础数据说明 (6) 5 非功能需求 (6) 5.1 性能 (6) 5.2 易用性 (7)

5.3 可维护性 (7) 5.4 可移植性 (7) 5.4.1 硬件环境 (7) 5.4.2 软件环境 (7) 5.5 故障处理要求 (7) 5.6 安全性 (7) 5.7 不允许发生的事件 (8) 6 附录 (8) 业务需求说明书 1引言 需求说明书说清楚了“四要素”,实际上就说清楚了如下问题:业务的办理流程是什么?业务办理条件是什么?操作员通过怎么样的界面(简单描述要求)办理该业务?系统最后操作哪些数据、生成哪些表单? 1.1编写目的 可选

1.2范围 可选 1.3项目背景 可选 1.4主要业务名词和术语定义 1.5参考文献 2需求概述 2.1用户现状/业界当前系统 可选。用于老系统改进时,主要阐述用户现状(组织架构、it现状等);用于新课题的研究时,简单阐述业界同类系统所提供的功能 2.2业务目标 阐述本模块具体是实现的业务目标,即解决的业务问题,是业务需求的出发点和核心所在。 2.3业务过程分解 根据业务目标进行业务过程分解,主要包括:主流程、配合过程、辅助过程等。 2.4本业务模型与其他系统的关系 阐述本系统/模块与QONE其他模块或客户系统可能存在的关系,可以用关系图表示

业务需求说明书

业务需求说明书 Company number:【0089WT-8898YT-W8CCB-BUUT-202108】

业务需求说明书文档版本记录

目录

1引言 1.1编写目的 本需求说明书的编写目的为: (1)使各业务部门在与系统相关的业务流程、岗位权限、业务操作方式等方面达成一致,作为项目立项、工作量估算、系统需求分析、系统设计的依据。 (2)使IT需求分析、设计人员充分理解与本系统相关各项业务需求、系统实现目标、范围,同时明确为实现业务需求所需要的功能要点。 1.2预期读者 本说明书的预期读者为安徽江淮汽车股份有限公司相关业务部门,需求分析、开发、维护等IT人员,以及系统最终用户。 1.3参考资料 【描述参考业务制度文件等】 1.4术语、定义和缩写 【描述本文档涉及的专业术语、相关定义和缩写】 2业务需求概述 2.1项目目标 【描述本项目背景和目标,说明系统应支持的业务类型,期望达到的管理目的等】 2.2总体业务流程 【描述本系统的总体业务需求,并通过图形和文字的方式,对标准业务流程以及流程特例进行说明】

2.3岗位职责 【描述相关业务岗位及其工作职责,对应于系统中的角色及权限】 3功能需求 【逐一描述业务需求、所需的系统功能和操作流程,按功能层次逐级描述】3.1功能一 【描述主要业务功能,包括界面、输入输出和业务规则等】 3.1.1功能描述 3.1.2用户界面 【描述主要用户界面和操作方面的要求,可以结合图表说明】 3.1.3输入要求 【描述输入介质,包括表单、数据清单、图形、扫描件等】 3.1.4输出要求 【描述输出要求,包括表单、报表、图形、扫描件等】 3.1.5业务规则 【描述数据处理的主要业务规则和逻辑】 3.2功能二 … 4非功能需求 4.1时间要求 【明确上线时间等要求】 4.2性能要求 【描述用户数量、数据规模、响应时间要求等】 4.3安全需求 【描述账号口令、用户账号、访问控制、通信加密等要求】

需求说明书模板

泵送零部件质量信息化之 自制大件钢印号管理需求分析说明书 Requirement Analysis Document 文档编号: 状态: ■草稿□发布□修改作者:寻浏平、王刚华

文档信息 修改记录

目录 1.引言 (4) 1.1编写目的 (4) 1.2项目背景 (4) 1.3术语定义 (4) 2.业务描述 (4) 2.1目标范围 (4) 2.2业务综述及总体流程 (4) 2.2.1业务流程图 (5) 2.2.2业务需求 (6) 2.3用户特性 (6) 2.4约定假设 (6) 3.功能需求 (7) 3.1 SAP新增自定义字段“钢印号”(F01) (8) 3.1.1功能模块流程图 (8) 3.1.2功能详细描述 (8) 3.2 MES下载订单主数据接口修改(F02) (10) 3.2.1功能模块流程图 (10) 3.2.2功能详细描述 (10) 3.3 MES终端钢印号报工功能修改(F03) (11) 3.4大件SAP/PDA收货功能(F04) (11) 3.5大件SAP/PDA出库钢印号记录功能(F05) (27) 3.6 MES返修订单质检功能(F06) (34) 3.6.1功能模块流程图 (34) 3.6.2功能详细描述 (35) 3.7 SAP大件(钢印号)可用库存查询功能(F06) (37) 4.业务编码规范 (41) 5.非功能性需求 (41) 5.1用户界面需求 (41) 5.2性能及压力需求 (41) 5.3安全需求 (41) 5.4环境需求 (41) 5.5产品质量要求 (42) 6. 批准确认 (42)

1.引言 1.1编写目的 将泵送制造本部钢印号管理业务需求转化为功能需求,为设计、开发、测试、实施人员提供参考依据。 1.2项目背景 目前泵送制造本部所有自制大件实物上都需打钢印号。实物上的钢印号编码是由制造部各工作中心根据既定的规则自行进行编码和打印钢印号的,MES系统只检验时才开始对钢印号与生产订单信息进行关联和记录。为加强对自制大件质量的管控,泵送质保部提出要对钢印号整个生命周期进行管控的需求。经泵送质保本部、泵送制造本部综合管理部、泵送制造本部物料管理部共同商讨决定对泵送自制大件实现从计划下达、生产制造、质量记录、生产返工、装配记录、售后质量追溯全生命周期的管理。 1.3术语定义 钢印号:为实现对自制大件生产过程质量追溯,自制大件组焊完成后在实物上打印的钢字码。钢印号一般包含以下信息:型号、生产日期、流水号等。 2.业务描述 2.1目标范围 泵送制造本部所有自制大件均需实现钢印号管理,先在转塔工作中心(转塔台和转塔座)实现和试用,优化完成后再推广到泵送制造本部其他大件。 2.2业务综述及总体流程 从整体描述项目业务需求及业务流程,相互关联,及总体流程图。

投诉业务子系统需求规格说明书

CallCenter投诉业务子系统需求规格说明书 一、引言 (1) 1.1编写目的 (1) 1.2项目背景 (1) 1.3定义 (2) 1.4参考资料: (2) 二、任务 (2) 2.1目的 (2) 2.2运行环境 (3) 2.3条件与限制 (3) 三、功能需求 (3) 3.1系统流程 (3) 3.2贵阳农行系统流程 (7) 四、数据描述 (8) 4.1数据流图 (8) 4.2静态数据 (10) 4.3动态数据 (10) 4.4数据字典 (10) 五、性能要求 (12) 六、运行需求 (12) 一、引言 1.1编写目的 本文档定义投诉业务子系统的功能需求、数据描述、运行环境。 本文档可作为CALLCENTER系统设计人员,售前技术支持人员,程序员,测试人员、使用人员的参考资料。 1.2项目背景 本设计文档参考了UT斯达康DSD R&D CALLCENTER开发小组“浙江移动呼叫中心” 项目的客户呼叫中心投诉、建议功能模块设计说明书及业务需求分析而写的,对原有的

说明书进行修改并增加了一些功能,如投诉处理、处理结果反馈等功能,使本子系统具有一定的通用性,不仅适合电信局,也适用于银行等。 1.3定义 投诉:包括投诉与建议,是指CallCenter中,处理客户通过电话、信函、传真、EMAIL 等手段对服务质量的投诉和一些客户对有关部门的建议。并且将客户的投诉、建议统一录入服务器中心数据库(或本地数据库),然后进行分类,再将投诉、建议发往相关部门处理。对处理进行全过程追踪,并将处理结果反馈给客户,将客户对处理结果的意见进行记录。作为评价处理部门的工作的依据。 UUI:系统各模块之间交换应用数据的桥梁,主要应用在以下几方面:呼叫从IVR转移到Agent、Agents之间呼叫互转和多个Agents、用户实现会议电话。UUI携带的信息主要为语种、应用的识别号AppID、应用信息的标识符等等[1]。 CTI SERVER:联结PBX和LAN。 IVR SERVER:电话语音处理服务器。 DLL:动态链接库(Dynamic Link Library), WINDOWS程序之间相互调用的一个机制。 1.4参考资料: [1]UUI数据包结构(黄武) [2]应用程序模板文件使用说明(张磊) [3]开发部文档编写指南 [4]浙江移动客户呼叫中心项目建议书中有关投诉、建议的描述 [5]CALLCENTER开发小组前台程序的体系结构和管理模块的设计 [6]贵阳市农业银行客户服务系统业务范围确认表(诸伟) 注:由于投诉与建议的内容基本上是一样的,下面的内容只说明投诉部分,实际在处理时,可将两部分做在一起。 二、任务 2.1目的 提供给系统分析员一个总体思想,是概要、详细设计的指导.可为CALLCENTER系统设计人

软件需求规格说明书实用模板(超详细)

XXXXXX 单位
XXXXXXX 项目
软件需求规格说明书
龙子湖网络科技

项目 文档 文档 ID 说明 作者 最后更新时间
项目名称 软件需求规格说明书
V1.2 *** 2011-10-20
版本更新概要 版本号 V1.0
V1.1
V1.2
时间 2011-10-02
2011-10-20
2011-11-08
更新人
更新摘要 移动 OA、车辆管理模块
需求容 移动政务资源管理系统
平台需求容 根据业务需求,电子公
文在线预览
项目负责人审核与确认 供应商:
职位
审核时间
审核意见(签字)
客户方:

目录
第一章 引言 ................................................................... 5
1 编写目的 .................................................................. 5 2 软件需求分析理论........................................................... 5 3 软件需求分析目标........................................................... 5 4 参考文献 .................................................................. 6
第二章 需求概述................................................................ 7
1. 项目背景 .................................................................. 7 2. 需求概述 .................................................................. 7 3. 条件与限制(可选)........................................................... 8 4. 移动办公系统结构........................................................... 8 5. 移动办公网络拓扑图......................................................... 9
第三章 系统功能需求........................................................... 10
1. 移动办公系统升级改造需求.................................................. 10 界面显示要求 ........................................................... 11 待办公文列表 ........................................................... 11 待办公文列表排序 ....................................................... 12 公文详细信息界面元素.................................................... 12 信息审批 ............................................................... 12 会议申请 ............................................................... 12 意见录入 ............................................................... 12 移动 ................................................................... 13 会议管理 ............................................................... 13 通知通告 ............................................................... 14 通讯录管理 ............................................................. 14
2. 车辆管理模块升级改造需求.................................................. 14 系统功能架构 ........................................................... 14 网络拓扑结构 ........................................................... 16

软件系统需求说明书

专 组号:小组成员: 完成时间:

目录 1.系统概述 (3) 1.1. 系统功能简介 (3) 1.2 系统用户角色 (3) 2.理由 (3) 3.项目范围 (3) 4.系统假设 (3) 5.系统定义 (4) 6.用户场景 (5) 7.用户用例 (5) 7.1 用户用例步骤 (5) 7.2系统需求 (9) 7.2.1 功能需求 (9) 7.2.2 非功能需求 (12) 8.文档历史 (14)

1.系统概述 1.1. 系统功能简介 教务处工作人员根据设置的用户名和密码,登录到学生信息管理系统,并对学生提交的信息修改进行审核,,系统优先级高; 档案管理员添加、查看、删除、修改学生的基本信息, 系统优先级高; 老师查看自己所管班级的学生的信息, 系统优先级高; 学生修改、查看自己的某些信息, 系统优先级高; 1.2 系统用户角色 2.理由 由于现在的学校规模在逐渐的扩大,设置的专业类别、分支机构及老师、学生人数越来越多,对于过去的学生信息管理系统,不能满足当前学生信息管理的服务性能要求。本报告对于开发新的<<学生信息管理系统>>面临的问题及解决方案进行初步的设计与合理的安排,对用户需求进行了全面细致的分析,更清晰的理解学生信息管理系统业务需求,深入描述软件的功能和性能与界面,确定该软件设计的限制和定义软件的其他有效性需求,对开发计划进行了总体的规划确定开发的需求与面临困难的可行性分析。 3.项目范围 学生信息管理系统是典型的信息管理系统,其开发主要包括后台数据库的建立、维护以及前端应用程序的开发两个方面。对于前者要求建立起数据一致性和完整性强、数据安全性好的数据库。而对于后者则要求应用程序具有功能完备,易使用等特点。学生信息管理系统对全校学生实行统一的管理,可以方便的进行增添、查询、修改、删除学生信息的工作。为了使本系统成功达到用户的要求,需要在2012.12.28之前完成本系统的开发测试,并写提交相关的技术文档。通过与用户的沟通,及时获得用户的最新需求以便于本系统的完善。 4.系统假设 本项目的开发时间为2012.9.9—2012.12.28 开发人员人数:3人 技术文档写作人员人数3人

项目需求说明书

项目需求说明书 一、资质要求 1.为保证项目实施和设备售后服务质量,投标方需为辽宁本地中央政府采购协议供货商或在本地有独立服务机构的外地中央政府采购协议供货商。 2.投标方需提供企业法人营业执照扫描件,税务登记证扫描件、单位组织机构代码证扫描件,在竞价时须以附件形式上传相关资质证明。 3.投标方应提供液晶拼接屏产品的生产厂家售后服务承诺函原件。(竞价时以附件形式上传) 4.投标方应提供视频会议终端生产厂家售后服务承诺函原件。(竞价时以附件形式上传) 二、总体要求 1.投标报价应为交货含税价(以人民币为结算单位),包括货物、配件、附件运至指定交货地点费用;安装费、调试费,使用培训费、系统集成费、售后服务费用、税金及其他所有相关费用的总和。采购方不再单独支付其他任何费用。 2.投标方所提供的设备需为原装正品、全新、符合国家相关质量标准。所有设备均需包含安装使用所必需的信号线、电源线等附属品。 3.投标方所提供的视频会议终端和摄像头应能与我省气象部门现有的华为设备实现数字级联,并能做到音视频及双流的双向互联互通互控,能实现对新老系统中所有的MCU和终端进行统一调度和管理。所提供设备如为其他品牌,需同时提供由权威机构出具的和华为产品兼容的测试报告。(竞价时以附件形式上传) 4.为保证系统集成工作顺利进行,投标方须针对本项目自行踏勘现场后制定完善的整体系统集成规划方案和效果图。(竞价时以附件形式上传) 5.设备验收时投标人需负责提供原生产厂商对货物的售后服务质量承诺书原件等相关资料。 三、硬件设备及技术指标 (一)清投视讯液晶拼接系统1套。主要设备含46寸液晶拼接屏12块、拼接屏底座及支架1套、内置图形处理系统1套、图形控制系统1套及相应线缆。为保证系统的安全性,要求图像拼接控制器与液晶大屏幕为同一厂商生产的合格产品。(需提供图像拼接控制器彩页加盖制造厂商公章。)具体技术指标如下: 1.液晶拼接屏采用12块(3*4)46寸液晶屏组成,两块液晶拼接单元间拼缝不大于5.5mm ,面板平整度小于0.3mm,液晶拼接单元须采用三星原装46寸S-PVA面板,需提供三星进口面板报关单以及产品彩页加盖制造厂商公章。 2.液晶拼接单元背光源采用直下式LED灯点阵排列,物理分辨率需达到1920×1080,支持信号的输入分辨率为1920×1080,对比度要求达到3500:1,屏幕亮度达到450cd/㎡,可视角度需达到178°以上(横向和纵向)。可满足7×24小时长时使用,寿命不低于50000小时。 3.液晶显示设备需要具有国家强制CCC认证、电工产品安全测试的CB体系认证报告及CE认证,投标人须提供公安部相关检测机构出具的性能检测报告。(在投标文件中提供复印件,加盖制造厂商公章) 4.液晶显示设备需经国家广电质检中心检测,必须通过抗震检测报告(8级),防尘级别达到IP5X,噪音测试报告(≤36分贝)等测试,(在投标文件中提供复印件,加盖制造厂商公章)。 5.液晶显示设备需要为节能环保产品,需要通过ROHS认证以及中国技能产品认证(在投标文件中提供复印件,加盖制造厂商公章)。

网站业务需求说明书

中国邮政电子商务网站(网上营业厅)项目业务需求说明书 —机票预订分册 (V1.5) 神州数码系统集成服务有限公司 中国邮政电子商务网站(网上营业厅)项目组 2010年6月

目录 第1章引言 (1) 1.1 术语、首字母缩写 (1) 1.2 使用者 (2) 1.3 参考资料 (2) 第2章业务总体说明 (3) 2.1 业务简介 (3) 2.2 用户特点 (3) 2.3 功能描述 (3) 2.3.1 功能结构组成 (3) 2.3.2 功能分类 (4) 2.4 涉及的角色与第三方系统 (6) 2.4.1 涉及的角色 (6) 2.4.2 第三方系统关系 (7) 2.5 系统主要流程 (7) 2.6 异常流程 (10) 2.7 订单状态说明 (14) 第3章业务用例 (16) 3.1 用例模型 (16) 3.1.1 前台预订机票 (16) 3.1.2 前台管理机票订单 (16) 3.1.3 后台管理机票业务 (17) 3.1.4 后台管理机票订单 (17) 3.1.5 后台管理页面信息 (18) 3.1.6 后台管理统计报表 (18) 3.2 用例角色说明 (18) 3.3 用例说明 (19) 3.3.1 前台预订机票 (19) 3.3.2 前台管理机票订单 (21) 3.3.3 后台管理机票业务 (21) 3.3.4 后台管理机票订单 (22) 3.3.5 后台管理页面信息 (23) 3.3.6 后台管理统计报表 (23) 第4章用户界面 (25) 4.1 前台预订机票 (25) 4.1.1 功能说明 (29) 4.1.2 操作说明 (29) 4.2 前台管理机票订单 (29) 4.2.1 功能说明 (32) 4.2.2 操作说明 (32) 4.3 后台管理机票业务 (32) 4.3.1 功能说明 (33)

软件需求规格说明书标准模板

软件需求规格说明书 文件编号: QMS—PROC-RD02 版本:1.0 受控签章

修改历史

目录 1引言 (2) 1.1目的 (2) 1.2背景 (2) 1.3术语 (2) 1.4预期读者与阅读建议 (2) 1.5参考资料 (2) 1.6需求描述约定 (2) 2.项目概述 (2) 2.1系统功能 (2) 2.2业务描述 (2) 2.3数据流程描述(可选) (2) 2.4用户的特点 (2) 2.5运行环境要求 (2) 2.6设计和实现上的限制 (2) 3.功能需求的描述 (2) 4.非功能需求 (2) 4.1系统性能要求 (2) 4.2系统安全及保密要求 (2) 4.3系统备份与恢复要求 (2) 4.4系统日志 (2) 5.外部接口说明 (2) 6.其他需求 (2) 7 需求变更识别 (2) 8.功能列表 (2) 9.附件 (2)

1引言 1.1 目的 说明编写这份软件需求规格说明书的目的,如:通过本文档定义XXX产品的需求,以求在项目组员与相关成员之间达成一致的需求描述。 1.2 背景 描述系统产生的背景,包括: a.需开发的软件系统的名称,和英文缩写(可选),项目编号(可选); b.列出此项目的任务提出者、开发者 c.软件系统应用范围、用户。 d.产生该系统需求的原因或起源,如社会背景、市场发展、政策趋势、原有系统局限性 1.3 术语 列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。也可用附件说明。或放到本文件的最后。 1.4 预期读者与阅读建议 描述本文档的主要读者,以及这些读者在阅读时的阅读重点与建议。可用列表的方式列 1.5 参考资料 列出有关的参考资料,如: a.本项目经核准的计划任务书或合同、上级机关的批文; b.属于本项目的其他已发表的文件; c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 d.行业标准和规范。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。

系统需求规格说明书 (1)

XXX系统或XXX项目 产品需求规格说明书 版本信息 注:状态可以为N-新建、A-增加、M-更改、 对方的所得税说明:版本信息必须更新,审核人和审核时间也必须审核后填写,审核人要求部门经理级别以上。否则开发测试可拒绝评审。审核业务功能是否有遗漏、业务流程是否符合规划、关键业务逻辑是否有合理 目录

1.关于本文档 1.1.内容说明 说明:此处描述的是文档说明,产品需求文档更新需要走修订模式,下次更新前先接受修订,并且每次更新必须更新版本号和版本记录。 例子: 本文档用于描述苏宁开放平台物流状态服务系统的需求定义。包括各个需求的功能描述,处理逻辑规则,界面定义,与其它功能的关系,与其它系统的接口等各个方面的定义。是苏宁物流状态服务系统唯一的全面需求定义文档。 本文档将根据需求管理流程和要求,随系统功能变化进行及时的修订和更新,以确保本文档的全面性,准确性和实效性。因此在阅读使用此文档时,请注意从项目的文档管理系统中获取最新版本。 1.2.名词解释

1.3.参考文档 《系统需求定义规范使用说明》 2.系统概述 2.1.业务背景 说明:此处描述业务背景,不可裁剪,清晰的业务背景描述能更好的帮助研发和测试理解产品需求,明确业务测试场景,此部分是产品需求定位的核心导向。 例子一:电子面单的业务描述 随着电子商务服务和物流服务信息化飞速发展,包裹运单号成为快递公司串联快递单、订单、商家、商品等各种信息的枢纽。相比之下,传统纸质面单价格高、信息录入效率低、信息安全隐患等方面的劣势已愈发凸显。我司在两年前就开始了电子面单在自营物流上的应用,经过长期的的磨合和积累,目前将我司的应用经验推广到社会物流上,让社会上愿意与我司物流合作的伙伴,也同样享受到我司电子面单服务。 例子二:LSQ的业务描述 物流作业状态服务存在不足 1)服务无标准不统一 需物流作业的各渠道订单,作业状态转化为文案描述处理的逻辑系统多,且处理规不统一, -B2C自营订单,逻辑在B2C,数据源在OMS -菜鸟平台/4PS平台订单状态展示,逻辑在LAPI,数据源在LAPI

业务需求描述模板

XXXXXXX-BRS 业务需求说明书,v1.1.1 [毕业论文管理系统] 业务需求说明书 文件状态:[ ]草稿[√]正式[ ]修改[ ]批准 文件标识:thesis-manage-v1.0 当前版本:V1.0 作者:张琳娜,张静,张雪,李东方,吴若兰 完成日期:2014-11-11 Index.v小组

版本历史

目录 1 文档简介 (4) 1.1 文档简介 (4) 1.2阅读建议 (4) 2 项目概述 (4) 2.1 项目背景 (4) 2.2 项目的目标 (4) 2.3项目范围 (5) 2.4用户 (8) 2.5约束 (9) 2.6假设和依赖 (9) 3业务流程 (10) 3.1业务1 (10) 3.2业务2 (12) 3.3业务 (12) 附录 (15) 专业术语 (15) 参考文献 (15)

1 文档简介 1.1 文档简介 系统名称:毕业论文管理系统 本文档是关于“大学生毕业论文管理”项目的软件需求规格说明书。该文档将作为后续设计和开发的依据。 1.2阅读建议 本文包括三个部分。 第一章是文档简介,简要描述了文档的主要内容。 第二章是项目概述,描述项目的背景、目标、范围。 第三章是业务流程,使用业务流程图描述此系统中所涉及的角色和部门的业务状况。 2 项目概述 2.1 项目背景 毕业论文管理系统是基于互联网的应用软件。鉴于以往学生毕业论文采用人工管理方式,工作量大且效率地下,而且毕业生毕业时大多离校,给导师指导学生毕业设计,学生提交论文等工作带来诸多不便。希望开发一个系统来对课题,以及毕业论文选题进行规范化管理,从而方便导师对学生的论文写作进行指导和控制,方便学院管理毕业生论文。利用计算机来管理毕业论文设计管理活动实现制度化,规范化,管理化。 2.2 项目的目标 本系统对毕业论文的日常管理工作进行详细分析和整合,规范管理流程,细化管理内容,确定管理框架,以此为出发点需要实现的具体目标如下。 1.对毕业论文管理工作的业务流程进行详细分析,规范管理流程。 2.通过网络做为交流的平台,方便学生的论文提交、撰写和修改,以及与导师的沟通和指导。 3.实现毕业论文信息管理的自动化,尽可能的消除管理业务流程中的手工作业,提高工作效率。 4.实现论文信息(包括指导老师和学生信息)的正确性和一致性,并实现数据持久化管理。

软件项目需求说明书

中央国家机关住房资金管理中心 管理信息系统 需求说明书 (范本) 中央国家机关住房资金管理中心 二○一○年月日

文档修改历史记录 目录

1概述 1.1引言 (本需求说明书的编写目的以及阅读对象) 1.1.1 软件项目名称 (说明软件项目全称和简称) 1.1.2软件项目开发背景和目的 (简述软件项目开发背景和目的以及实现了哪些大的功能) 1.1.3软件项目应用范围 (叙述软件项目主要使用的范围、使用者等) 1.2参考资料 (本需求说明书的参考资料,包括法律法规、政策文件、国家标准、制度规范等) 1.3术语定义 (逐个定义重要术语,没有可以不写本条) 2 功能一 (定义本软件项目实现的一级功能及其内涵,一个软件项目由多个

一级功能组成) 2.1功能分解一 2.1.1定义 (说明功能分解一的含义以及实现过程) 2.1.2功能表述 (逐一列出对本功能分解一的各项功能表述,每项功能均需详细描述,并使读者没有歧义,描述方式可以为:输入什么、输出什么、需要系统如何加工等) 2.1.3性能要求 (详细列出对本功能分解一的系统性能要求,如:系统数据校验、缺省项判断、系统反应时间、操作的便捷性、错误或故障的处理、系统的接口等) 2.1.4相关表单 (详细列出本功能分解一涉及的相关表单) 2.1.5流程图 (功能分解一实现过程的流程图)

2.1.6特殊要求 (详细列出功能分解一的特殊要求,如无,可以不列)2.2功能分解二 …… 2.3特殊要求 (详细列出功能一的特殊要求,如无,可以不列) 3 附录 示例: 中央国家机关住房资金管理中心 售房款管理信息系统 需求说明书 中央国家机关住房资金管理中心

APP产品需求说明书模板

1简介 1.1目的 本文档主要读者:产品总监、产品相关设计人员、技术总监、项目经理、开发 相关人员、测试经理及相关测试人员等。 1.2说明 项目名称:***网上商城 简述:***网上商城是公司产品打造体系的一部分,主要表现形式是手机客户端,随着移动互联网用户的增多以及相关技术的普及,移动电子商务成为了日常生活的一部分,那么通过手机实现大宗商品的现货交易成为了公司发展的一个目标,在没有电脑的情况下,客户可以使用手机登陆掌易通客户端进行相关资讯以及交易信息的查看,并且可以实现洽谈、下单、交收等业务。为现货交易更加便捷,实现随时随地电子商务。 2产品功能业务需求 2.1产品构架

产品构架图

2.2主要流程功能简述 流程简述: 打开客户端后,可以实现三大功能: 一、浏览平台发布的公告信息,竞价公告以及新闻资讯等 二、通过交易大厅、专场浏览挂牌交易信息。 三、会员登录后可以对业务进行处理。 买方会员可以通过一口价或洽谈的方式进行购买下订单。 买方会员可以在业务中心进行验货、验票、评价、将提单生成二维码等操作。卖方会员可以在业务中心进行发货、评价、将提单生成二维码等操作。 注:手机端不支持支付的功能,需在PC端进行支付。手机端不支持订单、合同的异议功能,需在PC端进行异议处理。

3功能界面展示和说明 3.1前台 ●手机客户端支持分辨率不低于640*960像素 ●本需求中页面效果图为原图,需由专业美工进行适当设计布局,手机界面的整体 色系统一、唯美,菜单、下拉框、按钮等控件风格保持一致。 ●进入手机客户端首先进入的是首页 ●加载时显示“请稍等...” 3.1.1首页

项目接口需求及设计说明文档

媒讯集团E A S项目 CTC与EAS接口 需求及设计说明书 文档作者: 创建日期:20X X-05-10 确认日期: 当前版本:1.0 拷贝数量:1 审批签字: 客户方: 实施方:

文档控制 修改记录 日期作者版本参考版本备注

目录 1.概述 (4) 1.1读者 (4) 1.2图例 (4) 1.3目的 (4) 二、业务现状 (5) 三、概要设计 (5) 3.1接口通讯方式 (5) 3.2通讯内容定义 (5) 3.3媒讯CTC系统提供接口使用范例 (5) 3.4金蝶EAS提供接口使用范例 (5) 3.5媒讯CTC系统提供接口服务地址 (7) 3.6金蝶EAS提供接口服务地址 (7) 3.7接口需求 (7) 四、详细设计 (8) 4.1XX EAS接口 (8)

1.概述 金蝶与用户及用户业务系统方通过多次讨论,制定了接口开发需求设计说明书,作为双方后续开发指引。 1.1读者 本文读者对象为业务管理人员、系统设计、开发人员、测试人员。 1.2图例 本文中如未进行特殊说明,各图标代表的含义如下: 表示一个活动; 表示动态的业务数据,如系统单据; 表示流程走向; 表示条件判断、流程分支; 表示静态的业务数据,如基础资料; 表示系统外一个手工处理活动; 表示系统外手工填制的单据; 表示当前系统之外的活动; 表示当前系统之外产生的业务数据。 1.3目的 本文档是媒讯CTC系统与EAS系统接口的需求及设计方案相关文档,可用于指导开发、测试工作和作为验收相关依据文档。

二、业务现状 待补充 三、概要设计 3.1接口通讯方式 金蝶EAS与媒讯CTC系统之间通讯采用WebService方式进行数据传输。 3.2通讯内容定义 对于记录型的大对象,在通讯时,采用String型的xml格式的参数进行传递。对于其他非记录型的对象,在通讯时,可采用非xml格式的参数进行传递,也可使用多个参数。具体格式,请参照每个接口的通讯用例说明。 3.3媒讯CTC系统提供接口使用范例 待补充。 3.4金蝶EAS提供接口使用范例 3.4.1规范说明 EAS通过webService接口与异构系统通信。EAS WebService全部是使用java编写的,其接口描述符合WSDL国际标准,其数据描述符合XSD 国际标准。 本次提供的接口除系统登录接口外,其他接口都需要调用登录接口,以便将登陆的SessionId信息放入到SOAP 的HEADER 报文中。 3.4.2使用示例 金蝶在EAS上发布WebService服务,提供wsdl文件供客户端下载,其他业务系统根据下载的wsdl文件,产生客户端。 建议使用Axis2来生成客户端代理。

业务需求说明书精编版

业务需求说明书精编版 MQS system office room 【MQS16H-TTMS2A-MQSS8Q8-MQSH16898】

业务需求说明书文档版本记录

目录

1引言 1.1编写目的 本需求说明书的编写目的为: (1)使各业务部门在与系统相关的业务流程、岗位权限、业务操作方式等方面达成一致,作为项目立项、工作量估算、系统需求分析、系统设计的依据。 (2)使IT需求分析、设计人员充分理解与本系统相关各项业务需求、系统实现目标、范围,同时明确为实现业务需求所需要的功能要点。 1.2预期读者 本说明书的预期读者为安徽江淮汽车股份有限公司相关业务部门,需求分析、开发、维护等IT人员,以及系统最终用户。 1.3参考资料 【描述参考业务制度文件等】 1.4术语、定义和缩写 【描述本文档涉及的专业术语、相关定义和缩写】 2业务需求概述 2.1项目目标 【描述本项目背景和目标,说明系统应支持的业务类型,期望达到的管理目的等】 2.2总体业务流程 【描述本系统的总体业务需求,并通过图形和文字的方式,对标准业务流程以及流程特例进行说明】

2.3岗位职责 【描述相关业务岗位及其工作职责,对应于系统中的角色及权限】 3功能需求 【逐一描述业务需求、所需的系统功能和操作流程,按功能层次逐级描述】3.1功能一 【描述主要业务功能,包括界面、输入输出和业务规则等】 3.1.1功能描述 3.1.2用户界面 【描述主要用户界面和操作方面的要求,可以结合图表说明】 3.1.3输入要求 【描述输入介质,包括表单、数据清单、图形、扫描件等】 3.1.4输出要求 【描述输出要求,包括表单、报表、图形、扫描件等】 3.1.5业务规则 【描述数据处理的主要业务规则和逻辑】 3.2功能二 … 4非功能需求 4.1时间要求 【明确上线时间等要求】 4.2性能要求 【描述用户数量、数据规模、响应时间要求等】 4.3安全需求 【描述账号口令、用户账号、访问控制、通信加密等要求】

相关文档
最新文档