文档库 最新最全的文档下载
当前位置:文档库 › XX新账户体系需求说明书V1.5

XX新账户体系需求说明书V1.5

XX新账户体系需求说明书V1.5
XX新账户体系需求说明书V1.5

新账户体系需求说明书

一、需求背景 (4)

二、需求列表 (4)

1.账户拆分改造 (4)

2.清算模式改造 (4)

3.垫资模式改造 (4)

4.充值模式改造 (4)

5.后台改造 (4)

三、业务定义 (5)

1.账号及账户定义 (5)

2.业务账户定义 (5)

3.清算规则定义 (5)

4.垫资模式定义 (5)

四、账户设计 (6)

1.账户概况 (6)

1.1 账务表设计 (6)

1.2 账户业务 (6)

1.3 账户设计步骤 (6)

2.收单账户 (7)

2.1账户用途 (7)

2.2表设计及字段解析 (7)

2.3账户记账类型 (9)

2.4业务处理流程 (10)

3.垫资账户 (12)

3.1账户用途 (12)

3.2表设计及字段解析 (12)

3.3账户记账类型 (13)

3.4账户支持业务 (13)

4.余额账户 (17)

4.1账户用途 (17)

4.2表设计及字段解析 (17)

4.3账户记账类型 (18)

4.4业务处理流程 (18)

五、清算流程 (19)

5.1清算模式介绍 (19)

5.2交易及资金处理流程 (20)

5.3清算标识改造方案 (21)

5.4自清算记账清算流程 (23)

5.5代清算流程介绍 (26)

一、需求背景

现有系统的账户体系,由于未对账户进行拆分,导致计算可结算金额和垫资金额时的出现异常,并引发账户的一系列问题。

随着业务发展,XX定位为第四方平台,不对资金直接进行清算,因此需要对账户体系进行优化,满足XX代清算和自清算(虚拟资金池)的两种清算模式,并且支持收单、退款、结算、代付、垫资等业务。账户优化的基本要求如下:

1)合规性:满足不同渠道代清算、自清算的合作模式,资金不过XX银行账户。

2)可用性:满足商户现有基础业务的账务处理,解决各类账户异常问题。

3)拓展性:满足后续对账户在此基础上进行开发,以支持新业务模式的需求。

为实现上述要求,需要根据业务来划分不同的账户,使各账户的处理逻辑互相独立,以减少账户间的耦合性,并提升拓展性。

基于目前的业务情况,前期先将账户拆分成“余额账户”、“收单账户”、“垫资账户”等三个账户即可满足需求,后期可在此基础上叠加营销账户、授信账户等。

二、需求列表

1.账户拆分改造

将商户的账户根据业务需求拆分成“收单账户”、“余额账户”、“垫资账户”,并梳理出各账户主要字段的用途、所支持的业务流程,以及不同账户操作的处理规则。

2.清算模式改造

根据与渠道的合作模式,收单分为代清算和自清算,需分别梳理出代清算和自清算下的收单规则及清算规则,并考虑代清算下渠道日切时间、退款模式、差错订单等导致的异常情况处理方法。

3.垫资模式改造

确认商户垫资账户的额度、比例控制等计算规则,并梳理出垫资账户支持的业务流程,以及垫资出款、垫资退款、出款冻结、出款退回等账户操作的处理规则。

4.充值模式改造

充值入账至收单账户,清算后入账至余额,但是充值与收单业务,可以分开走渠道商户,以实现收单代清算,充值自清算的效果。

5.后台改造

基于上述系统底层改造完成之后,需要对现有商户后台的账户展示、资金管理、交易对账等进行改造,以便于商户对不同清算模式的交易都能够方便对账,且清晰了解资金的情况。

三、业务定义

1.账号及账户定义

商户在XX平台入网时,系统会自动给商户生成一个账号,用于标识该商户主体。商户所有业务行为都是基于该账号进行的。

账户是系统在商户账号下设置的,用于记录其不同业务导致的资金变动情况及结果的载体,且一个账号主体可以有多个账户,用以区分不同业务的资金变动。

2.业务账户定义

商户的不同账户具备不同的业务用途:

1)收单账户:主要用于统计商户收单成功后,尚未清算的资金,包括自清算和代清算收单。

2)垫资账户:平台根据商户当日自清算的收单金额,先给与商户一定的垫资额度,商户用于出款用途。3)余额账户:用于统计平台已清算给商户的收单资金,商户可以用于代付、提现、退款等用途。

商户不同的业务类型会使用不同账户的资金,在同一笔业务当中理论上不允许跨账户使用资金,例如:商户发起退款时,要么使用收单账户的资金,要么使用余额账户的资金;发起代付,要么使用垫资账户的资金,要么使用余额账户的资金。

除外,账户之间的资金可以遵循一定的规则进行转移,例如:商户自清算类型的收单资金,过了风险预存期之后,平台会汇总商户的应清算款,并将其清算至商户的余额账户。当后续有其他如手续费账户、营销账户、保证金账户时,也可以与余额账户之间互相调拨。

3.清算规则定义

自清算清算规则:

是指在系统日切后,对商户收单账户中自清算部分的收付账务记录,逐笔计算汇总后,按照商户在平台侧的清算周期汇总轧差算出平台应清算给商户的资金,在跑批清算时将应清算款清算至商户余额账户。

代清算清算规则:

是指在渠道日切后,对商户收单账户中代清算部分的收付账务记录,逐笔计算汇总后,按照商户在渠道侧的清算周期汇总轧差算出渠道应清算给商户的资金,跑批清算时将应清算款在代清算累计中扣除。

主要区别有:

1)日切时间2)清算周期来源3)资金清算方4)清算款清算方式

4.垫资模式定义

商户的收单资金,正常流程需渠道T+1日清算给平台后,平台才能清算给商户。商户如需使用当天的收单资金用于出款时,则平台可根据商户当日的自清算收单金额,给与商户一定的垫资额度,商户可使用垫资额度用于出款,平台先垫付这部分资金给商户出款。

1、不允许跨日垫资。

2、自清算收单才计算垫资。

四、账户设计

1.账户概况

1.1 账务表设计

由于收单/充值/退款(自清算)和垫资出款,会对“收单账户”和“垫资账户”进行双账户处理。

因此收单账户和垫资账户支持的业务类型基本是一致的,包括收单/充值/退款(自清算)、垫资代付、垫资结算。除外,收单账户还支持收单/充值/退款(代清算)

余额账户管理的是商户的自有资金,资金来源只有收单资金过了风险预存期清算至余额账户的途径。余额账户与垫资账户和收单账户的业务,没有直接关联,余额账户支持使用可用余额用于余额代付、余额结算、余额退款。

1.2 账户业务

收单账户:用于商户收单/充值/退款(自、代清算)交易,及垫资出款的业务。

余额账户:商户的自由可用资金,可以用于代付、结算、退款等出款业务。

垫资账户:平台根据商户自清算收单交易给商户的垫资额度,可以用于垫资出款业务。

1.3 账户设计步骤

2.收单账户

2.1账户用途

收单账户的主要用途是用于记录商户的所有收单以及出款流水,并通过风险预存期控制收单资金的清算。收单账户支持的业务类型,包括:收单/充值/退款(自、代清算)、垫资结算、垫资代付。

收单:商户通过扫码支付、刷卡支付等支付方式进行的收款,包含自清算和代清算两种模式。

充值:商户通过后台扫码/网银充值功能,将资金充值到收单账户中,包含自清算和代清算两种模式。

退款:商户使用未结算的收单资金,发起退款业务,包含自清算和代清算两种模式。

垫资结算:商户使用未结算的自清算收单资金中的部分(垫资额度),发起结算将资金提现到结算卡。垫资代付:商户使用未结算的自清算收单资金中的部分(垫资额度),发起代付将资金代付到指定银行卡。

2.2表设计及字段解析

涉及表包括:收单账户表、自清算账户明细表、代清算账户明细表、渠道管理表

1)收单账户表

字段解析:

总收单金额:包括商户“代清算收单金额+自清算收单金额”

自清算收单金额:包括“自清算冻结金额+自清算未过金额+自清算已过金额”

自清算冻结金额:自清算订单处于退款中的金额,处于冻结状态。

自清算未过金额:自清算的收单,未过风险预存期部分的资金,可用于退款。

自清算已过金额:自清算的收单,已过风险预存期但尚未跑批清算的部分资金。

代清算收单金额:包括“代清算冻结金额+代清算可用金额”

代清算冻结金额:代清算订单正处于退款中的金额,处于冻结状态。

代清算可用金额:代清算的收单,未过风险预存期部分的资金,可用于退款。

2)自清算账务历史表

字段解析:

创建时间:交易成功后新增账务历史记录的时间,精确到年月日时分秒。

账户编号:该笔账务所属的商户的商户编号

支付方式:该笔订单的支付方式,收款则显示支付方式,退款则显示支付方式+退款。

业务类型:分为收单、充值、退款、付款四大类,收单、充值、退款,分为自清算和代清算两种模式。资金变动方向:123为增加,321为减少。

自清算收单累计金额:该笔账务变动后账户的自清算收单金额,便于后续排查问题。

变动可垫资金额:该笔账务变动金额中,使用的可垫资部分金额。

变动不可垫资金额:该笔账务变动金额中,使用的不可垫资部分金额,退款先用垫资,再用不可垫资。记账类型:记录该笔账务的记账类型,每种记账类型对应账户的处理规则不同。

清算标识:自清算即平台能把控资金清算的收单;代清算即渠道直清给商户,平台无法把控资金的收单。是否完成清算:每天日终汇总清算时,会对当日所有收单以及退款的交易进行清算汇总,已经汇总过的账务记录,则状态更改为已清算。

3)代清算账务历史表

代清算收单累计金额:该笔账务变动后账户的代清算收单金额,便于后续排查问题。

渠道编号:该笔交易走的渠道编号,代清算日切时需要根据渠道的属性对账务进行汇总处理。

是否完成清算:每天日终汇总清算时,会对当日所有收单以及退款的交易进行清算汇总,已经汇总过的账务记录,则状态更改为已清算。

2.3账户记账类型

自清算表的记账类型(6):交易入账、出款冻结、出款退回、出款扣款、待清算调账、待清算扣款代清算表的记账类型(5):交易入账、出款冻结、出款退回、出款扣款、待清算扣款

因为代清算交易平台不进行结算,因此日切时间跑批时,直接将前一日的待清算款扣减即可。

所有的业务都是对账户的记账操作,确认变动金额后,只需要根据下表对相应字段进行操作即可,变动分为直接变动和间接变动。

1)收单、充值流程(代清算)

说明:

代清算交易账务历史新增在“代清算账务历史表”,并对收单账户进行代清算【交易入账】记账操作。2)退款流程(代清算)

关键节点说明:

a、代清算交易退款订单校验时,不对账户“代清算可用金额”进行校验,直接将退款请求上送至渠道。

渠道退款一般有两种模式:实时或者轧差

实时模式,不允许账户余额为负,即“代清算可用金额”为负值;

轧差模式,允许账户余额为负,即“代清算可用金额”为负值,日终再统计当日收单减退款进行轧差。

因此,为兼容以上两种退款模式,平台无需对代清算可用余额进行校验,上送退款请求之后,只要退款成功,即做出款扣减,退款失败,则做出款退回,且允许为“代清算可用金额”为负值。因此,代清算退款不支持余额退款。

说明:

代清算退款,与自清算退款的业务流程基本一致,校验通过后请求退款接口,等待退款结果异步通知或者主动查询。

退款结果成功,则对代清算账务表新增账务记录,并进行代清算【出款扣款】

退款结果失败,则对代清算账务表新增账务记录,并进行代清算【出款退回】

3.垫资账户

3.1账户用途

垫资账户主要用途为,根据商户当日自清算收单资金以及垫资比例、最高垫资额度等控制条件,计算出平台给商户的垫资额度。商户可以使用垫资额度内的资金用于出款,相当于提前使用了自清算收单资金,因此该部分已用垫资额度,在第二天进行清算时会进行扣减不予清算。

垫资账户支持的业务类型,包括:收单(自清算)、退款(自清算)、垫资结算、垫资代付。

收单:商户通过扫码、刷卡等支付方式进行的收款,只有自清算收单会统计至垫资账户当日收单累计。充值:通过网银、扫码对商户账户进行的充值入账,只有自清算收单会统计至垫资账户当日收单累计。退款:商户使用未结算的当日自清算收单资金,用于垫资退款。

垫资结算:商户使用未结算的当日自清算收单资金中的部分(垫资额度),发起结算将资金提现到结算卡。垫资代付:商户使用未结算的当日自清算收单资金中的部分(垫资额度),将资金代付到指定银行卡。

3.2表设计及字段解析

1)垫资账户表

字段解析如下:

垫资额度:商户实时额度,垫资额度=当日累计自清算收单*垫资比例,垫资额度不能大于最高垫资额度。可用垫资额度:商户实时垫资额度计算出来后,可能已使用了一部分,剩余额度即为可用垫资额度,可用垫资额度=垫资额度-(当日累计冻结_可垫资-当日累计退回_可垫资)。

“累计冻结-累计退回”理论上即等于当天已用垫资额度,但是由于存在退款跨日退回的情况,该部分退回的资金允许商户累加至当日垫资额度,所以实际上其不等于当日已用垫资额度,会出现退回更多的情况。已用垫资额度:商户当天所有垫资出款的成功金额累计,不包括正在出款部分,等于当日的自清算账务表所有记账类型为出款扣款的累计金额。

冻结垫资额度:商户使用可用垫资额度进行出款时,成功扣款前资金需要冻结,即冻结垫资额度。

控制比例:控制商户的垫资额度使用,范围【0%-100%】

最高垫资额度:控制商户的垫资额度大小,垫资额度不能大于最高垫资额度。

当日累计收单:当日的垫资账户所有记账类型为交易入账的累计金额,每日0点清零。

当日累计冻结:当日的垫资账户所有记账类型为出款冻结的累计金额,每日0点清零。

当日累计退回:当日的垫资账户所有记账类型为出款退回的累计金额,每日0点清零。

清零日期:当商户有垫资变动时,用于判断商户是否清零过,未进行则触发清零。

2)垫资账务历史表

垫资账户和收单账户共用自清算账务历史表,收单账户另外还有个代清算账务历史表。

自清算账务历史表如下:

3.3账户记账类型

3.4账户支持业务

1)收单流程(自清算)

说明:

自清算交易账务历史新增在“自清算账务历史表”,并对收单账户进行自清算【交易入账】记账操作。当风险预存期为0时,即秒到,系统将自动发起发起垫资结算。

2)垫资退款流程

说明:

垫资退款,也属于垫资出款,因此遵循“不允许跨日垫资”的原则。因此,发起退款时,需判断(当日累计收单金额-当日累计冻结+当日累计退回)>退款金额,即可通过金额校验。

即当天的自清算收单资金都可以用来退款,但是当日自清算收单资金不一定全部可垫资,所以一笔退款,可能同时占用了可垫资部分和不可垫资部分。

而垫资退款不受垫资比例限制,垫资账户中的(当日累计收单-当日累计冻结)即等于当日剩余可用的自清算收单金额。

另外,需要在发起垫资退款时,对金额进行判断,优先使用可垫资部分金额,当可垫资金额不够时,再使用不可垫资金额,并在生成账务记账时,明确标识两部分的金额分别是多少,发生出款退回时,对相应的“当日累计退回金额”“当日累计退回金额_可垫资”字段进行调增。

a)金额判断流程

说明:

自清算退款分为两种情况,一是使用当日未结算收单资金进行垫资退款,一是使用余额进行一般退款,当使用垫资退款和余额退款时,校验金额的流程不一样。

需要在发起垫资退款时,对金额进行判断,优先使用可垫资部分金额,当可垫资金额不够时,再使用不可垫资金额,并在生成账务记账时,明确标识两部分的金额分别是多少,发生出款退回时,对相应的“当日累计退回金额”“当日累计退回金额_可垫资”字段进行调增。

b)垫资退款业务处理流程

3)垫资出款流程

说明:

垫资出款,包含垫资结算和垫资代付,都遵循“不允许跨日垫资”的原则。

但是垫资出款受到垫资额度的限制,并非当日所有的自清算收单都可以用于垫资出款,因此需要在代付和结算的校验过程中,判断商户的可用垫资额度是否足够进行出款。当业务逻辑校验通过后,则后续是一样的垫资出款双账户处理逻辑。

a)垫资出款金额判断流程

4.余额账户

4.1账户用途

余额账户的主要用途是用于统计商户的自有资金余额,商户可以直接使用余额进行结算、代付、退款等,来源为收单/充值过风险期后清算的资金。

结算:商户可使用余额账户中的可用余额,委托平台将资金提现至结算银行卡中。

代付:商户可使用余额账户中的可用余额,委托平台将资金代付至其它银行卡。

退款:商户使用余额账户中的可用余额,发起退款将资金退回给用户。

4.2表设计及字段解析

涉及表包括:余额账户表、余额账户明细表

1)余额账户表

字段解析:

总余额:商户的自有资金总和,包含“可用余额+冻结余额”

可用余额:商户未被冻结的余额,可直接用于结算、代付、退款等

冻结余额:商户正在出款中的余额资金,处于冻结状态。

2)余额账户历史表

4.3账户记账类型

4.4业务处理流程

1)出款账务流程

a、结算、代付、退款都属于使用可用余额进行出款的行为,只是业务类型不同,账务处理是一样的。

b、出款操作底层都会调用打款服务,如打款返回结果为失败,则退回至商户可用余额,如成功则扣款。

c、当商户的收单资金不够进行退款时,商户可以选择使用余额账户进行退款,但是一笔订单请求一般不

允许跨账户使用资金。

五、清算流程

5.1清算模式介绍

1)自清算业务模式

自清算有两种模式,一种是真实资金自清算,一种虚拟资金自清算。

1)真实资金自清算,是指渠道将资金结算给平台后,平台再够通过各种代付渠道,将资金结算给商户。2)虚拟资金自清算,是指平台商户通过渠道进行的收单资金,会入账到平台在渠道侧开立的一个虚拟账户中,并不进行真实资金结算,但是平台能够通过代付接口,让渠道直接从备付金出款将资金打给商户。真实资金自清算和虚拟资金自清算的本质区别,在于平台是否有触碰真实资金。

基于合规模式,XX需要做虚拟资金自清算,因此所有该模式的渠道,XX都需要同时接一条代付渠道用于出款给商户。

2)代清算业务模式

代清算模式,是指平台不参与资金结算流程,渠道直接将资金结算给物业/商户,平台只做交易上送处理。该模式下,平台无需对物业/商户代清算的资金进行跑批以及结算,只需要在渠道日切时,将物业/商户当天的代清算收单金额扣除,等渠道T+1日结算给物业/商户即可。

3)统一收银模式

自清算和代清算都分为两种情况,清算给物业或者清算给商户。

当资金先入账至物业的银行账户,则为物业统一收银模式,物业方需要在与商户约定的结算周期后,将资金代付给商户。因此,平台需要给物业生成一份清算报表,方便物业代付给商户。该清算报表,在自清算模式下,可根据平台的账单生成;但是在代清算模式下,需要结合渠道的对账单再生成,以避免平台和渠道清算金额不匹配的问题。

5.2交易及资金处理流程

收单以及清结算过程中,应明确每笔交易的清算模式进行标识并进行区分处理,交易及资金处理的基本流程如下:

其中涉及到清算模式的节点如上图标识:

①给商户不同收单业务分别设置清算模式,如扫码自清算,POS代清算。充值业务无需设置。

②根据合作模式给扫码/POS渠道商户设置清算模式,为代清算或者自清算。充值渠道商户需设置。

③代清算和自清算的交易,记录账务时需要通过清算模式进行标识

④代清算和自清算的交易,清算方式需要区分处理

因此需要对以上关键流程节点进行改造,满足商户不同业务不同清算模式的需求。

管理系统软件需求说明书

厦漳大桥养护管理系统 V1.0 软件需求说明书 二〇一七年七月 2017.07

修改记录

目录

第一章引言 1.1编写目的 本文档作为甲乙双方就厦漳大桥养护管理系统需求理解达成一致共识的基础文件,作为双方界定项目范围、签定合同的主要基础,也作为本项目验收的主要依据。同时,本文档也作为后继工作开展的基础,供双方项目主管负责人、项目经理、技术开发人员、测试人员等理解需求之用。 1.2适用范围 本文档适用于所有与本项目有关的软件开发阶段及其相关人员,其中:项目负责人、公司方项目经理、技术开发人员(包括分析人员、设计人员、程序人员)、测试人员应重点阅读本文档各部分,其他人员可选择性阅读本文档。 1.3文档概述 本文档主要描述了厦漳大桥养护管理系统的软件需求。 本文档首先从业务背景、系统功能、运行环境等方面概要描述系统,其次从软件接口等方面描述系统的外部接口需求,然后进一步详细描述功能性需求和非功能性需求以及待确定的问题。 1.4参考资料 甲方提供的原型图、需求资料、项目背景资料等。 1.5业务背景 厦漳跨海大桥2013年5月28日正式投入运营,工程起点在主线K1+065处与厦门至成都国家高速公路海沧枢纽立交相接,途经青礁村、海门岛,止于漳州龙海市沙坛村后宅处,终点里程桩号K10+400.390,与招银疏港高速公路相连。路线长度为9335.390m,其中桥梁长度为8669.9m。大桥工程主要包括北汊桥、海门岛立交及收费服务区、南汊桥、海平互通立交等几个部分,双向6车道,设计时速100km/h。 全桥共打下桩基1441根、墩身322座、主塔4座,共296根斜拉索,用材11.5万吨钢筋、 68.7万立方米混凝土。能抗14级台风和7度地震。北汊主桥为连续半漂浮体系双塔双索面斜拉桥,主跨780m,可满足3万吨级船舶安全通航,在同类型桥梁中居全国第六、世界第

软件项目需求说明书(模板)

电子商务项目需求说明书(范本) 新蛋信息技术(中国)有限公司 二○一一年月日

文档修改历史记录

目录 1概述 (3) 1.1引言 (3) 1.1.1 软件项目名称 (3) 1.1.2软件项目开发背景和目的 (3) 1.1.3软件项目应用范围 (3) 1.2参考资料 (3) 1.3术语定义 (3) 2 系统功能 (3) 2.1功能分解一 (4) 2.1.1定义 (4) 2.1.2功能表述 (4) 2.1.3性能要求 (4) 2.1.4相关表单 (4) 2.1.5流程图 (4) 2.1.6特殊要求 (4) 2.2功能分解二 (5) 3 附录 (5)

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

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

系统需求说明书_初步

项目编号: Web OA系统 软件需求说明书 项目承担部门: 撰写人(签名): 完成日期: 评审人(签名): 评审日期: 批准人(签名): 批准日期:

目录 1.引言 ....................................................... 错误!未定义书签。 目的..................................................... 错误!未定义书签。 定义..................................................... 错误!未定义书签。 参考资料................................................. 错误!未定义书签。 2.软件总体概述................................................ 错误!未定义书签。 软件标识................................................. 错误!未定义书签。 项目名称............................................. 错误!未定义书签。 产品标识............................................. 错误!未定义书签。 软件描述................................................. 错误!未定义书签。 系统属性............................................. 错误!未定义书签。 开发背景............................................. 错误!未定义书签。 系统功能............................................. 错误!未定义书签。 3.具体需求 ................................................... 错误!未定义书签。 系统角色设置............................................. 错误!未定义书签。 系统初始化数据........................................... 错误!未定义书签。 功能需求................................................. 错误!未定义书签。 管理主界面........................................... 错误!未定义书签。 组织机构............................................. 错误!未定义书签。 权限管理............................................. 错误!未定义书签。 公文管理............................................. 错误!未定义书签。 流程管理............................................. 错误!未定义书签。 性能需求................................................. 错误!未定义书签。 数据库需求............................................... 错误!未定义书签。 设计约束................................................. 错误!未定义书签。 其他标准的约束....................................... 错误!未定义书签。 硬件约束............................................. 错误!未定义书签。 属性..................................................... 错误!未定义书签。 可用性............................................... 错误!未定义书签。 可靠性............................................... 错误!未定义书签。 效率................................................. 错误!未定义书签。 安全性............................................... 错误!未定义书签。 可维护性............................................. 错误!未定义书签。 可移植性............................................. 错误!未定义书签。 外部接口需求............................................. 错误!未定义书签。 用户接口............................................. 错误!未定义书签。 硬件接口............................................. 错误!未定义书签。 软件接口............................................. 错误!未定义书签。 通信接口............................................. 错误!未定义书签。 4.数据字典 ................................................... 错误!未定义书签。

项目需求规格说明书模板

软件项目名称软件需求规格说明书 拟制: 审核: 批准:日期: 日期: 日期:

文件修改记录

目录 1 范围 (4) 2 总体概述 (4) 2.1 产品描述. (4) 2.2 软件功能. (4) 2.3 一般约束. (5) 2.4 假设和依赖. (5) 3 具体需求 (5) 3.1 功能需求. (5) 3.1.1 功能需求.................... 1 5 3.1.2 功能需求.................... 2 6 3.1.n 功能需求n (7) 3.2 外部接口需求. (7) 3.2.1 用户接口 (7) 3.2.2 硬件接口 (7) 3.2.3 软件接口 (7) 3.2.4 通讯接口 (7) 3.3 性能需求. (7) 4 设计约束 (8) 4.1 标准的约束. (8) 4.2 硬件的限制. (8) 4.3 技术的限制. (8) 5 软件质量属性. (8) 5.1 安全性. (9) 5.2 可维护性. (9) 5.3 可移植性. (9) 6 其他需求 (9) 6.1 数据库. (9) 6.2 本地化. (10) 7 待确定问题 (10)

模板使用说明: [1] 注明可选的部分,可以根据实际情况选择是否填写;如果不必说明,请保留相关的章节标题,同时在该可选章节的内容中填入“无” ;未注名可选的,则必须描述;如果有些设计此模版中没有合适的地方填写,则补充在最后的其他栏目中 [2] 模版中斜体字相当于撰写指南,最后文稿请将本模板中所有的斜体字部分全部删除。 [3] 模板里并不说明设计技术和方法,而只是说明应包含哪些内容,以及如何描述、组织这些内容。

OA管理系统需求规格说明书

WebOA管理系统需求规格说明书 2009/11/20

1 概述错误!未指定书签。 1.1编写目的错误!未指定书签。 1.2参考资料错误!未指定书签。 1.3术语和标记错误!未指定书签。 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.1.6工作流程模块........................................................... 错误!未指定书签。 3.1.7组织管理模块........................................................... 错误!未指定书签。 3.1.8权限管理模块........................................................... 错误!未指定书签。 3.1.9系统管理模块........................................................... 错误!未指定书签。 人事档案模块........................................................... 错误!未指定书签。 3.2性能需求错误!未指定书签。 3.3非功能需求错误!未指定书签。 3.4故障处理错误!未指定书签。 4数据需求错误!未指定书签。 4.1数据项错误!未指定书签。 4.2数据间关系(E-R图)错误!未指定书签。 5行为需求错误!未指定书签。 5.1控制模型错误!未指定书签。 6接口需求错误!未指定书签。 6.1用户界面错误!未指定书签。 6.2软硬件接口错误!未指定书签。 7环境错误!未指定书签。 7.1运行环境错误!未指定书签。 7.2开发环境错误!未指定书签。 附录:项目成员介绍及组内评分错误!未指定书签。

XXX系统需求规格说明书

环境与灾害监测预报小卫星星座环境应用系统 XX系统需求规格说明书 单位: 作者: 完成日期: 签收人: 签收日期: 修改情况记录:

目录 1.引言 (1) 1.1.编写目的 (1) 1.2.背景 (1) 1.3.定义 (1) 1.4.参考资料 (1) 2.需求概述 (1) 2.1.目标 (1) 2.2.运行环境 (2) 2.3.关键点 (2) 2.4.约束条件 (2) 3.需求规格 (2) 3.1.软件系统总体功能/对象结构 (2) 3.2.软件子系统功能/对象结构 (2) 3.3.描述约定 (2) 3.4.功能或对象的描述 (3) 3.4.1.功能或对象1 (3) 3.4.2.功能或对象n (3) 3.5.性能 (4) 3.6.外部接口 (4) 3.7.数据 (4) 3.7.1.空间数据 (5) 3.7.2.非空间数据 (5) 3.8.操作 (5) 3.9.可使用性、可维护性、可移植性、可靠性和安全性 (5) 3.10.故障处理 (5) 3.11.算法说明 (6) 4.尚未解决的问题 (6) 5.支持信息 (6)

1.引言 1.1.编写目的 说明编写本软件需求规格说明书的目的,指出预期的读者。 1.2.背景 a.说明待开发产品或项目(以下简称产品)的名称。 b.列出此开发任务的提出者、开发者、用户等。 c.说明本产品与其他产品的关系。 1.3.定义 列出本文件中用到的专门术语的定义和缩写词原文。 1.4.参考资料 a.本文件中引用的属于本开发产品的其他文件。 b.本文件中引用的其他文献、资料以及软件开发标准。 2.需求概述 2.1.目标 a.本产品的开发意图、应用目标及作用范围(现有产品存在的问题和建议 产品所要解决的问题)。 b.本产品的主要功能、处理流程、数据流程及简要说明。 c.表示外部接口和数据流的系统高层次图。说明本产品与其他相关产品的 关系,是独立产品还是一个较大产品的组成部分(可用方框图说明)。

酒店管理系统需求说明书

酒店管理系统需求分析说明书

目录 1、引言 (3) 1.1编写目的 (3) 1.2适用范围 (3) 1.3编写原则 (3) 1.4读者对象 (3) 2、项目概述 (3) 2.1项目任务 (3) 2.2项目背景 (4) 2.3项目目标 (4) 3、新系统的用例模型及分析模型 (4) 4、系统完整用例图 (4) 5、用例说明 (5) 5.1添加操作员 (5) 5.2删除操作员 (6) 5.3修改密码 (6) 5.4预定客房 (7) 5.5调房 (7) 5.6住宿查询 (8) 5.7退宿结账 (8) 5.8统计收入 (9) 6、分析模型 (10) 7、非功能性需求 (13) 8、附件 (13)

1、引言 1.1编写目的 本文档是对酒店管理系统需求分析进行明确、清晰、较全面的定义将先进的电脑技术与现代酒店服务管理完美地结合起来,实现了住宿、餐饮、娱乐全新概念的服务和管理方式。 1.2适用范围 小、中型酒店管理。 1.3编写原则 统一规划、统一设计思想、统一技术规范。 最大限度的满足客户需求。 根据实际业务需求,不断完善系统。 应用先进技术实施系统。 1.4读者对象 对有关业务和系统做出决策的管理人员。 参与需求分析和需求确认的有关人员。 有关技术决策人员。 软件开发人员。 2、项目概述 2.1项目任务 1.为销售提供全面、准确的信息数据。

2.为财务提供严密的账系统。 3.提高决策依据:管理者可以随时了解经营情况,以制定相应的经营方 针。 4.树立良好的酒店形象。 2.2项目背景 传统的酒店管理往往令管理者花大量的时间来处理顾客投诉,例如错误查询、烦琐的登记和结账手、旅客费用计算错误、空余客房资料不能及时提供等,从而影响出租率,使管理人员不得不集中精力规划管理运行策略和进行决策。以上问题可通过电脑系统辅助解决,酒店管理的电脑化,不仅是体现酒店现代化形象的一个重要标志,而且对于提高员工工作效率,加速资金周转、降低各项成本及改善服务质量都有十分积极的作用。 2.3项目目标 实施网上酒店管理,客户可以在网上查看酒店客房相关的信息及预订客房。 3、新系统的用例模型及分析模型 4、系统完整用例图

项目需求规格说明书模板

精品文档 软件项目名称 错误!未指定书签。 拟制:日期: 审核:日期: 批准:日期:

文件修改记录

目录 1范围 (4) 2 总体概述 (4) 2.1 产品描述 (4) 2.2 软件功能 (4) 2.3 一般约束 (5) 2.4 假设和依赖 (5) 3 具体需求 (5) 3.1 功能需求 (5) 3.1.1 功能需求1 (5) 3.1.2 功能需求2 (6) 3.1.n 功能需求n (7) 3.2 外部接口需求 (7) 3.2.1 用户接口 (7) 3.2.2 硬件接口 (7) 3.2.3 软件接口 (7) 3.2.4 通讯接口 (7) 3.3 性能需求 (7) 4 设计约束 (8) 4.1 标准的约束 (8) 4.2 硬件的限制 (8) 4.3 技术的限制 (8) 5 软件质量属性 (8) 5.1 安全性 (9) 5.2 可维护性 (9) 5.3 可移植性 (9) 6 其他需求 (9) 6.1 数据库 (9) 6.2 本地化 (10) 7待确定问题 (10)

模板使用说明: [1]注明可选的部分,可以根据实际情况选择是否填写;如果不必说明,请保留相关的章节标题,同时在该可选章节的内容中填入“无”;未注名可选的,则必须描述;如果有些设计此模版中没有合适的地方填写,则补充在最后的其他栏目中 [2]模版中斜体字相当于撰写指南,最后文稿请将本模板中所有的斜体字部分全部删除。 [3]模板里并不说明设计技术和方法,而只是说明应包含哪些内容,以及如何描述、组织这些内容。

1范围 说明文档所包括和不包括的内容,具体是: a.待开发的软件系统的名称; b.说明软件将干什么,如果需要的话,还要说明软件产品不干什么; c.描述所说明的软件的应用。如果有一个较高层次的说明存在,则应该使其和高层次说明中的类似的陈述相一致(例如,系统的需求规格说明)。 2 总体概述 2.1 产品描述 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分,则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2 软件功能 概述软件必须实现的和通过用户操作实现的主要功能。这里只需要进行简要描述(例如目录列表),详细描述在详细需求部分描述。 有时,如果存在较高层次的规格说明时,则功能摘要可从中取得,这个较高层次的规格说明为软件产品分配了特殊的功能,为了清晰起见,请注意: a.编制功能的一种方法是制作功能表,以便客户或者第一次读这个文件的人都可以理解; b.用方框图来表达不同的功能和它们的关系也是有帮助的。但应牢记,这样的图不是产品设计时所需求的,而只是一种有效的解释性的工具。 例如:高层的数据流图,面向对象的分析等。

软件系统需求说明书

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

目录 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人

课程管理系统需求说明书

燕京理工学院YANCHING INSTITUTE OF TECHNOLOGY 课程管理系统 软件需求说明书 学院:信息学院 姓名:郭文月 学号: 140210100 专业班级:计科1404 指导教师:周建敏

1引言 1.1编写目的 (3) 1.2背景 (3) 1.3定义 (3) 1.4参考资料 (3) 2任务概述 2.1目标 (3) 2.2假定和约束 (3) 3需求规定 3.1对功能的规定 (4) 3.2结构图 3.2.1系统结构图 (4) 3.2.2功能结构图 (4) 3.2.3数据流词条描述 (5) 3.3对性能的规定 (5) 3.2.1精度 (5) 3.2.2时间特性要求 (6) 3.2.3灵活性 (6) 3.4输人输出要求 (6) 3.5故障处理要求 (6) 3.6系统安全性要求 (6) 3.6其他专门要求 (6) 4运行环境规定 4.1设备 (7) 4.2支持软件 (7) 4.3接口 (7) 4.3.1 内部接口 (7) 4.3.2 硬件接口 (7) 4.3.3 软件接口 (7) 4.3.4 通讯接口 (7) 4.4控制 (8)

1 引言 1.1编写目的 为了使本系统的使用者和软件开发者双方对该软件的初始规定有一个共同的理解,使之对整个开发工作的基础,明确系统需要实现的功能,确定需求边界。特编制本文档。本文档一经确认,将成为系统开发人员进行开发以及用户对系统验收的依据。 本文档的预期读者有:本系统最终使用者、系统管理人员、本系统开发人员、本系统测试人员。 1.2背景 开发软件的名称:学生课程管理系统 项目的任务提出者:燕京理工学院信息院郭文月 用户:学生 实现软件的单位:1404班郭文月学生 兼容系统:Windows XP SP2/SP3,win7 ,win8 开发工具:Myeclipse 10 1.3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4参考资料 [1]《软件工程模型与方法》,肖丁等,北京邮电大学出版社。 [2]《https://www.wendangku.net/doc/8f682634.html,+Dreamweaver8案例精粹》武新华等,西安电子科技大学出版社 [3]《信息系统应用与开发案例教程》,陈承欢,清华大学出版社 2任务概述 2.1目标 课程的管理:包括课程的添加,修改和删除等 学生信息的管理:包括学生信息的添加,修改和删除等 学生课程的管理:包括学生通过浏览器进行添加登录用户,学生添加课程的学分信息等。 | 2.2假定和约束 经费限制:100万 开发时间:六个月之内 3需求规定 3.1对功能的规定

工程项目需求规格说明书

工程项目管理软件 功能需求 2016年4月

目录 第一章.引言 (3) 1.1编写目的 (4) 1.2预期读者 (4) 1.3参考资料 (4) 第二章.系统概述 (5) 2.1项目总体要求 (5) 2.2技术整体要求 (5) 第三章.功能需求 (6) 3.1基础数据 (6) 3.2项目管理 (8) 3.3项目查询 (12) 3.4项目统计 (12) 3.5人事档案 (12) 3.6行政制度 (13) 3.11后台管理 (14) (1)组织机构管理 (14) (2)帐号管理 (15) (3)权限分配 (16) (4)角色管理 (16) (5)日志管理 (17) 第四章.项目时间计划 (18) 第五章.外部接口需求 (18) 5.1硬件接口 (18) 5.2软件接口 (18) 第六章.非功能需求 (18) 6.1性能需求 (18) 6.2安全性需求 (18) 第七章.项目预算 (19) 第一章.引言 1.1编写目的 本文档是在对项目需求文档进行充分分析的基础上,描述实现项目需求的详细说明,包括项目功能结

构图、总体流程图以及功能模块分析和表单设计等。 编写此文档的主要目的:文档化项目的实现方案,涵盖系统的基础功能、系统管理、项目管理、人事管理、规则制度管理等功能模块,以方便项目组和用户对项目的业务功能需求在理解上达成一致。该文档也是以后的概要设计、详细设计的基础,是对详细设计活动的约束和指导。 1.2预期读者 文档的主要读者:双方项目成员。 1.3参考资料 《计算机软件产品开发文件编制指南》GB8567-88 《计算机软件开发规范》GB8566-88 《计算机软件质量保证计划规范》GB/T12504-90 《计算机软件配置管理计划规范》GB/T12505-90 《计算机软件需求说明编制指南》GB9385-88 《计算机软件测试文件编制指南》GB9386-88 《软件工程术语》GB/T11457-1995 《信息技术软件生存周期过程》GB/T8566-1995 《计算机软件文档编制规范》GB-T8567-2006 《软件文档管理指南》GB/T16680-1996

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

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

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

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

软件项目需求规格 说明书模板

组态建模工具需求规格说明书 西安电子科技大学 2011/5/19

目录

1概述 编写目的 指出编写《需求规格说明书》的目的。下面是示例: 编写此文档的目的是进一步定制软件开发的细节问题,希望能使本软件开发工作更具体。为了使用户、软件开发者及分析和测试人员对该软件的初始规定有一个共同的理解,它说明了本软件的各项功能需求、性能需求和数据需求,明确标识各项功能的具体含义,阐述实用背景及范围,提供客户解决问题或达到目标所需要的条件或权能,提供一个度量和遵循的基准。具体而言,编写软件需求说明的目的是为所开发的软件提出: a)软件设计总体要求,作为软件开发人员、软件测试人员相互了解的基础。 b)功能、性能要求,数据结构和采集要求,重要的接口要求,作为软件设计人员进 行概要设计的依据。 c)软件确认测试的依据。 编写依据 指明该《需求规格说明书》的依据。一般可以写依据XXX软件的方案书,策划书等。术语和缩略词

2软件概要 软件总体描述 从总体上描述该软件的情况,包括软件的形式(网站,运行时系统,插件等)和软件的主要的功能,使读者对该软件有一个整体的认识。一般一两段话即可。 软件设计约束及有关说明 软件设计的约束以及有关说明如下所示。 ●开发环境: ●编程语言: ●遵循的规范:软件的设计和开发过程需要严格按照合同要求,根据软件的设计方 案来进行。软件开发过程应遵循软件工程规范,对过程和版本进行管理和控制。 ●测试环境:可以写明在什么单位测试,测试单位使用的软硬件环境。 ●软件交付形式: ●软件交付日期: ●其他:见合同。 使用者特点 指明软件的使用者具有的特定。示例: 本软件主要在甲方工作环境中使用,使用者包括项目管理人员,开发人员及工程师等,使用者在计算机的应用、使用上不存在障碍,都在计算机的操作和使用方面得到过相关的培训。

运维管理系统需求说明书

1概述 1.1开发背景和意义 随着公司规模的迅速扩大,现行的纯纸质化办公,效率低下、资料保存和查询非常困难、成本高、不利于多人协同办公,成为日常办公的严重制约。尤其是需要审批的事项,如果遇到审批人出差或不在公司,往往需要等待,协调的成本很高,工作决策不能及时进行,大大降低了工作效率。开发审批系统,使得申请人和审批人不受地域和时间限制,审批流程自动流转,相关人可以快键协调。 1.2开发目标 系统在需求设计时要充分考虑了用户的使用习惯、模块间的相互独立性,减少系统间的相互依赖,使其能单独运行,便于开发和维护,也有利于以后的扩充,做到与其他业务系统的高内聚、松耦合。 特别强调系统的用户体验,以及与实际审批业务的贴合性,真正方便用户的申请和审批业务快键开展。 1.3主要内容 系统主要内容包括: (1) 考勤管理:员工的加班、调休、请假、市内外出、出差等的申请、审批、查询和统计。 (2)转正申请:员工完成试用期,进入转正审批环节,完成该环节后,成为正式员工。 (3)物资申请:办公用物资的申请和审批。 1.4用户对象 包括总公司、山西、广西、河南、湖北等办事处、分公司全部员工。

1.5业务数据时间要求 针对用户对数据的要求,业务数据做永久性保存,部分业务数据可转入查询库中作为历史数据供查询使用。 2功能需求 2.1功能框架 2.1.1总体框架 操作系统运行监控: 虚拟机可用性 cpu负载 内存使用 IO情况 空间使用情况 OS日志 进程情况 计划任务情况 时钟偏差 端口使用情况 路由表 一页查看 多操作系统执行命令: 中间件运行监控: 取jmx的一些指标。 数据库运行监控: 主目录 集群状态 实例状态 监听器状态 表空间预警 归档情况 rman备份情况 不良sql 未使用的索引 大表数据量 alert文件报错

项目需求说明书

项目需求说明书 一、资质要求 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认证以及中国技能产品认证(在投标文件中提供复印件,加盖制造厂商公章)。

系统需求规格说明书模板(结构化标准版)

走过,留下种种希望。啊,朋友,我们从人生的四季走过,将给人生留下些什么? (项目名称) 系统需求规格说明书 文件版本 编写日期 发布日期 没有落日般的瑰丽,没有流云般的飘逸,但可以有水晶般的清纯与透明。没有大山般的巍峨,没

走过,留下种种希望。啊,朋友,我们从人生的四季走过,将给人生留下些什么? 文件修改记录 *变化状态:C――创建,A——增加,M——修改,D——删除 文档审批信息 没有落日般的瑰丽,没有流云般的飘逸,但可以有水晶般的清纯与透明。没有大山般的巍峨,没

走过,留下种种希望。啊,朋友,我们从人生的四季走过,将给人生留下些什么? 目录 1概述 (1) 1.1目的 (1) 1.2预期读者 (1) 1.3背景(可选) (1) 1.4参考资料 (1) 1.5标准(可选) (1) 1.6术语定义 (1) 1.7图例说明 (1) 2系统描述 (1) 2.1现状综述 (1) 2.2系统目标 (1) 2.3目标系统概述 (2) 2.4范围 (2) 2.5系统假设/约定 (2) 2.6接口与界面 (2) 2.6.1外部接口(可选) (2) 2.6.2硬件接口 (2) 2.6.3软件接口 (2) 2.6.4通信接口(可选) (2) 2.6.5用户界面 (3) 3功能需求 (3) 3.1系统流程图 (3) 3.2功能一览表 (3) 3.3功能描述 (3) 3.3.1功能1 (3) 3.3.2功能n (4) 3.4公共功能描述 (4) 3.4.1功能1 (4) 3.5数据描述(可选) (4) 3.5.1业务数据描述 (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 附录 ................................................................. 错误!未定义书签。1概述 1.1引言 ( 本需求说明书的编写目的以及阅读对象)

管理系统需求说明书-boobooke

车辆管理系统需求说明书 中国电信安徽公司 二00九年三月

目录 1. 需求功能点阐述 (3) 1.1.车辆档案管理 (3) 1.2.车辆保险合同管理 (4) 1.3.人员档案管理 (5) 1.3.1.驾驶员档案管理 (5) 1.3.2.车队管理人员档案管理 (6) 1.4.出车管理 (7) 1.4.1.派车流程管理 (7) 1.4.2.出车费用管理 (9) 1.5.车辆维修管理 (10) 1.5.1.车辆维修申请流程 (10) 1.5.2.维修单信息管理 (12) 1.6.车辆统计 (12) 1.7.车辆信息提醒 (14) 1.8.人工成本 (15) 1.9.管理成本 (15) 1.10.车辆管理文件 (16)

1. 概述 为精确车辆管理,细化车辆运行费用,准确管控油料消耗等成本开支,进一步加强对外包车辆的日常规范管理,掌握车辆运行基本情况,实现省、市、县一体化车辆管理。 车辆管理系统主要实现省、市、县车辆档案管理,人员档案管理,派车管理,车辆维修管理,车辆各项费用的管理及统计,车辆信息提醒。具体的包括: 1)车辆档案管理:实现车辆基本档案的基础数据的录入、维护及分级查询的需求; 2)人员档案管理:实现驾驶员档案及车队管理员人员档案的基础数据的录入、维护及 分级查询的需求; 3)派车管理:实现用车人提请派车申请,从申请审批到返程确认的闭环电子管理,记 录车辆的使用及油耗数据的需求; 4)车辆维修管理:实现车队人员提请送修申请电子审批流程,维修记录录入、维护及 分级查询的需求; 5)车辆统计:实现省、市、县分级车用费用的日、月、年度统计,部门用车公里数统 计,维修统计; 6)车辆信息提醒:各种待办信息提醒,车辆年审提醒,车辆保险到期提示,驾驶 员年审提醒,车辆报废提醒,油耗超标提示; 2. 需求功能点阐述 2.1.车辆档案管理 1)车辆档案录入与维护由各车队人员录入、维护所辖车辆的信息。数据项:车辆号牌,厂牌车型,座位 /吨位,排气量(升),燃油种类,发动机号码,车架号码,购置日期,注册日期,行驶公里数,耗油标准市内(公升),耗油长途标准(公升),使用单位,产权单位,年审日期,年审期限,报废公里数,报废年限,车辆状态<是否报废>,投保日期,保单终止期,分配驾驶员,车辆照片。 2)车辆档案查询省、市、县分级查询。省综合管理部人员及车队管理人员可以查看到

相关文档
相关文档 最新文档