FIT我的工作台需求规格说明书v12.docx
《FIT我的工作台需求规格说明书v12.docx》由会员分享，可在线阅读，更多相关《FIT我的工作台需求规格说明书v12.docx（18页珍藏版）》请在冰点文库上搜索。
FIT我的工作台需求规格说明书v12
外贸信托业务管理综合信息系统
我的工作台
需求规格说明书
[机密]
文件状态：
[]草稿
[√]正式发布
[]正在修改
文件标识：
当前版本：
1.0
作者：
完成日期：
2007-08-01
版本历史
版本/状态
作者
参与者
起止日期
备注
1.0
刘清
1.1
刘清
1.2
刘清
1.引言
1.1.目的
为了准确定义中国对外经济贸易信托投资有限公司（以下简称外贸信托）我的工作台模块的系统需求，业务管理综合信息系统项目组依据《外贸信托概要需求说明书》及各部门需求说明书，按照软通动力公司系统需求编写规范，抽取提炼出各需求公共部分的基础设置，撰写了此规格说明书。
本说明书重点描述我的工作台模块的系统功能性和非功能性需求，并针对每个需求都具体描述其实现过程和要求。
1.2.读者对象及阅读建议
Ø业务管理综合信息系统外贸信托工作小组：
应阅读全文。
Ø业务管理综合信息系统外贸信托实施小组：
应阅读全文。
Ø业务管理综合信息系统软通动力方项目组：
应阅读全文。
1.3.文档范围
本文档的范围是在对系统管理中心需求进行综合描述的基础上，对系统的具体需求包括功能需求和非功能需求进行详细的描述和说明。
1.4.参考文档
Ø《外贸信托概要需求说明书》
Ø《计划财务部需求说明书》
Ø《业务部、稽核法律部需求说明书》
Ø《理财服务中心业务需求说明书》
Ø《集团信托业务部需求说明书》
Ø《综合管理部业务需求说明书》
Ø《自营证券详细需求说明书》
Ø《外贸信托公司角色及职责》
1.5.术语与缩写解释
●集团公司：
中化集团
●外贸信托：
中国对外经济贸易信托投资有限公司
●业务管理综合信息系统：
按照外贸信托提出的需求开发的业务管理综合信息系统；
●用户：
系统中允许登录的操作用户。
●角色：
本说明书所称角色是用户在工作中所承担职责的抽象，与岗位无对应关系，一个用户同时承担两个岗位的工作但可只有一个角色，同时一个人也可以担任多个角色。
●帐套：
相当于财产分类，就信托公司而言分为自有和信托。
所有信托项目从属于帐套。
●项目：
对应于信托项目，对每一个项目实现项目隔离，独立核算，自有一套账。
2.综合描述
2.1.系统概述
我的工作台是整个业务管理综合信息系统的门面，包括工作提醒、工作笔记、快捷方式链接等。
可以根据个人情况，设置常用的功能链接。
是基于整个系统的一个抽象模块。
2.2.功能摘要
序号
功能描述
功能说明
影响干系人
1
2
3
4
5
6
7
8
2.3.功能清单及重要程度说明
编号
级别
重要程度
功能名称
功能描述
备注
SR1
一级
高
SR1.1
二级
高
SR1.2
二级
高
SR1.3
二级
高
SR1.4
二级
中
SR1.5
二级
低
SR2
一级
高
SR2.1
二级
低
SR2.2
二级
高
SR2.3
二级
高
SR3
一级
高
SR3.1
二级
高
SR3.2
二级
高
SR3.3
二级
高
SR4
一级
高
SR4.1
二级
高
SR4.2
二级
高
SR4.3
二级
中
SR4.4
二级
中
SR4.5
二级
中
SR4.6
二级
中
SR5
一级
高
SR5.1
二级
高
SR5.2
二级
高
2.4.产品应当遵循的标准或规范
系统采用J2EE架构，系统业务逻辑与数据库无关，未来系统可以在不同数据库（MSSQLServer、Informix、Oracle、DB2）之间迁移。
3.功能性需求
在这一部分应对所有的软件需求进行足够详细的描述。
详尽程度应以足够软件设计人员进行概要设计和系统测试人员进行系统测试计划和编写测试用例为准。
按系统功能的体系结构组织本章内容。
3.1.日常工作提醒
3.1.1.业务概述
日常工作提醒是整个系统的提醒中心，所有与业务或财务相关的提醒，都在这里体现。
大致分为：
审批流、项目执行计划、分配方案、工作笔记和固定周期五类，见下表：
提醒
来源
范围
业务
拨款
项目执行计划
项目经理、财务具有该账套权限的人
收款
项目执行计划
项目经理、财务具有该账套权限的人
股权代持项目终止前三个月提醒是否延续
项目执行计划
项目经理、财务具有该账套权限的人
审批提示
审批流
审批流该环节相关人员
提交管理报告、月末提前5天且季末提前10提醒
固定周期
项目经理
项目执行监督报告
固定周期
项目经理
清算兑付提醒
分配方案
项目经理、财务具有该账套权限的人、理财服务中心分配岗
股权代持项目确认信托经理后提醒理财进行信息披露
审批流
审批流该环节相关人员
项目变更
审批流
审批流该环节相关人员
债权转让通知函10天提醒是否受到回执
工作笔记
财务
审批完成时间提示
审批流
审批流该环节相关人员
开户提示
审批流
审批流该环节相关人员
提示缴纳印花税
项目终结审批流中提醒
财务部税务岗
自营代垫提示信托财务
不提醒
3.1.2.使用者
所有操作员。
3.1.3.输入要素
提醒类型：
选择，读取数据字典表。
提醒标题：
字符型，录入，30个字。
提醒内容：
字符型，100个字。
提醒开始时间：
日期型。
提醒结束时间：
日期型。
提醒周期：
整形，选择：
年、季、月、周、日或一次性提醒。
信息源表名：
由业务系统传的时候写入
信息源ID：
业务表记录ID
提醒范围：
提醒范围：
1项目相关，2个人，0全部（公告）
关联项目：
业务所属项目，根据项目提醒相关人员。
提醒用户：
当前操作用户（个人工作笔记）
操作日期：
读取当前系统日期。
3.1.4.处理流程
所有提醒均与业务关联，即提醒与本业务相关的人员，如：
收益分配，根据需要作分配的项目，提醒业务部项目经理，同时提醒财务部拥有相应账套（对应该项目）权限的财务人员，并提醒理财全部人员。
注：
审批流提醒由审批流单独处理，根据审批流所设审批节点的角色发出提醒。
新增提醒：
1、项目执行计划、分配方案、工作笔记保存时，须在提醒表中相应插入一条记录；项目执行计划、分配方案可以根据所设置提前提醒天数提前提醒，工作笔记为一次性当天提醒。
2、财务中心利率变动保存时，默认新增一条系统公告。
3、添加提醒记录时，须记录来源数据表及ID，以备修改或删除时更新提醒表
修改提醒：
1、若项目执行计划、分配方案、工作笔记被修改，须匹配相应来源表及ID，更新提醒表；
2、工作笔记修改，可以再次设置提醒。
删除提醒：
1、若业务删除，须匹配相应来源表及ID，删除相应提醒。
屏蔽提醒：
1、用户可以根据自己情况，设定提醒屏蔽
2、可以根据提醒类型，设定屏蔽，不接受此类提醒
3、可以根据项目，设定屏蔽，不接受此项目相关的所有提醒
4、也可以屏蔽所有提醒
3.1.5.输出要素
个人工作提醒信息。
3.2.快捷功能链接
3.2.1.业务概述
此部分主要根据用户的日常工作需要，设置某些菜单的快捷方式，需要判断权限。
若之前有权限的菜单被设为快捷方式，当该菜单权限被收回时，该快捷方式置灰，不可链接，但可以删除此快捷方式。
3.2.2.使用者
所有操作员
3.2.3.处理流程
设置快捷方式。
新增：
1、新增快捷方式组，可自定义名称
2、根据个人工作需要对每个快捷方式组新增快捷方式，默认原菜单名称，可以自定义名称
修改：
1、可以修改快捷方式组名称
2、可以修改快捷方式链接名称
删除：
1、删除快捷方式链接
2、如果该菜单权限备收回，相应快捷方式置灰，但可以删除
3.2.4.输出要素
个人常用菜单快捷方式。
3.3.工作笔记
3.3.1.业务概述
用户可以根据各人情况编写工作笔记，选择设置提醒功能。
3.3.2.使用者
所有操作员
3.3.3.输入要素
用户：
读取当前操作用户。
标题：
字符型，录入，30个字以内。
内容：
字符型，录入，100个字以内。
提醒标记：
checkbox，选择是否做提醒，此处是一次性提醒。
提醒时间：
提醒时间
录入时间：
读取当前系统时间
3.3.4.处理流程
新增：
增加工作笔记。
可以选择是否做提醒。
修改：
修改工作笔记，已经提醒过的还可以修改提醒日期，并再次提醒。
删除：
删除工作笔记，已经提醒过的工作笔记可以删除。
3.3.5.输出要素
工作笔记信息。
3.4.出勤管理
3.4.1.业务概述
此功能主要针对部门内部管理，分两部分内容：
外出申请、重大事项执行计划。
各部门尤其业务部门，根据日常工作需要，在需要外出拜访客户的情况下，需要提起外出申请，便于部门管理、也可避免重复拜访客户。
而重大事项，是由领导交付办理的任务，需要分步骤制定执行计划，并逐步跟踪执行情况。
3.4.2.使用者
所有操作员
3.4.3.输入要素
外出申请：
申请人：
自动读取当前操作员。
开始时间：
时间型，默认当前时间，可编辑。
结束时间：
时间型，默认为空，可编辑。
内容：
字符型，录入，100个字以内。
批准人：
默认只能是部门经理。
批准时间：
时间型，默认当前时间，可编辑。
状态：
0申请中，1已批准
重大事项执行计划：
计划人：
自动读取当前操作员。
交付办理人：
从用户表选择，不能为空。
交付时间：
日期型，默认当前日期，可编辑。
完成时间：
时间型，默认当前时间，可编辑。
内容：
字符型，录入，500个字以内。
事项要点：
字符型，录入，100个字以内。
步骤编号：
整型，自动增加，可编辑。
步骤内容：
字符型，录入，500个字以内。
步骤计划完成时间：
日期型，选择或录入。
步骤成果描述：
字符型，录入，300个字以内。
步骤评价：
字符型，录入，300个字以内。
综合评价：
字符型，录入，300个字以内。
状态：
0未交付，1已交付，2已办完
3.4.4.处理流程
外出申请：
每个人只能看到自己的申请，部门领导可以看到本部门所有人的申请。
按时间倒叙排序。
新增：
1、新增外出申请，须填写开始时间、结束时间和内容。
2、新增时不做时间约束。
修改：
1、在未批准前，可以修改开始时间、结束时间和内容。
2、批准后，不得修改。
删除：
1、在未批准前，可以删除。
2、批准后，不得删除。
批准：
1、部门经理可以批准本部门内人员的外出申请。
重大事项执行计划：
每个人只能看到领导交付给自己办理的事项，领导可以看到所有自己做的计划及交付他人办理的事项。
按日期倒叙排序。
新增：
1、新增时，须指定承办人，并填写交办事项描述、事项要点、执行步骤及每个步骤的计划完成时间。
2、新增时不做时间约束。
修改：
1、在未交付办理前，可以修改所有相关内容。
2、交付办理之后，不能修改。
删除：
1、在未交付办理前，可以删除。
2、在交付办理后，不能删除。
交付办理：
1、交付承办人办理事项，交付后承办人可以看到该事项及执行计划。
2、交付后不得修改删除。
计划管理：
1、承办人可以根据实际情况调整步骤内容及时间，并填写阶段性成果描述。
2、交付人可以修改或调整步骤内容、时间及阶段性成果描述。
阶段评价：
1、交付办理后，交付人可以针对每个步骤填写阶段评价。
2、交付人可以修改阶段评价。
3、已做阶段评价后，承办人不得修改该步骤的内容、时间及阶段性成果，但其他步骤仍可修改。
综合评价：
1、交付人根据承办人的办理情况，可以填写综合评价。
2、综合评价只能做一次，不能重复做综合评价。
3、做过综合评价后，该事项所有信息不得修改，只能查看。
3.4.5.输出要素
外出信息及重大事项执行情况信息。
3.5.提醒天数设置
3.5.1.业务概述
可以根据业务要求，设置各种类型提醒的提前提醒天数。
若取不到提前提醒天数，默认为当天提醒。
3.5.2.使用者
系统管理员
3.5.3.输入要素
提醒类型：
选择。
读取数据字典表。
提前天数：
整型，录入。
描述：
字符型，三十个汉字以内，录入。
3.5.4.处理流程
新增：
分类型设置提前提醒天数。
修改：
修改各种提醒类型对应的提前提醒天数。
删除：
删除提前提醒天数。
3.5.5.输出要素
提前提醒天数信息。
4.非功能性需求
在这一部分应对所有的软件需求进行足够详细的描述。
详尽程度应以足够软件设计人员进行概要设计和系统测试人员进行系统测试计划和编写测试用例为准。
4.1.技术需求
4.1.1.软硬件环境需求
4.1.2.性能需求
性能需求表示用户对系统响应速度、处理能力、数据处理精度以及可靠性等指标的要求。
一般性能需求分类如下：
Ø处理速度——简单查询响应时间1秒以内、动态查询响应时间3秒以内、后台处理效率待定。
Ø处理结果的精度要求——小数点后三位。
Ø需要保留15年数据。
Ø并发用户数20个。
4.1.3.安全保密需求
指的是保护软件的要素，以防止各种非法的访问、使用、修改、破坏或者泄密。
这个领域的具体需求产品的安全性、保密性和完整性三方面需求。
例如：
要求对接入系统的用户进行身份验证。
对不同角色的用户设置不同的权限，通过角色定义实现不同角色个性化菜单的定制，有效控制用户的功能权限。
系统应提供日志记录和管理功能，记录所有用户访问系统的全部活动，并能够形成审计报告。
要求在传输过程中对数据进行加密处理，保证数据传输的安全性和完整性。
系统应具备病毒防范能力。
防止主机崩溃方法和数据备份方法等。
4.1.4.运行保障需求
运行保障需求，主要从系统推广、运行后日常维护角度进行考虑，包括硬件、系统软件、应用软件、数据备份等的运行保障。
1、对硬件，特别是应用服务器和数据库服务器，要求一般故障能够在3天之内予以解决；对于硬件重大故障，要求在2星期之内予以解决。
另外，要对系统数据量做出正确估算，预测硬件需要升级的时间点。
2、系统软件，主要指操作系统及数据库软件，对一般问题能在60分钟以内予以解决，对重大问题在3天之内予以解决。
3、应用软件。
应用软件出现问题后，有关人员能及时到位，在最短时间内查找问题原因，予以解决。
4、数据备份。
对系统数据制定备份策略，定期进行数据备份与保管。
零级备份每个月做一次。
增量备份针对于一定时期内发生变化的数据。
譬如：
有重大事件发生时等。
4.2.接口需求
详细说明对系统的用户界面等的要求。
还可包括和其它系统的接口、地址、协议等。
4.2.1.用户接口
提供用户使用软件产品时的接口需求。
例如，如果系统的用户通过客户端进行操作，就必须指定如下要求：
Ø对屏幕格式的要求；
Ø报表或菜单的页面、打印格式等用户对软件外观风格的一种要求。
如：
公司标志，界面色彩基调等。
规格的定义方式可以采用草图或静态原型的方式表示，一般描述分为两个部分：
整体描述和基于每个界面的细节描述。
Ø输入输出的相对时间；
Ø程序功能键的可用性。
4.2.2.硬件接口
要指出软件产品和系统硬部件之间每一个接口的逻辑特点和交互方式。
还可能包括如下事宜：
支撑什么样的设备，如何支撑这些设备，有何约定。
4.2.3.软件接口
在此要指定需使用的其他软件产品（例如，数据管理系统、操作系统或有关软件包），以及同其他应用系统之间的接口。
对每一个所需的软件产品，要提供如下内容：
1.名字；
2.助记符；
3.规格说明号；
4.版本号；
5.来源。
对于每一个接口，这部分应说明与软件产品相关的接口软件的目的，并根据信息的内容和格式定义接口，但不必详细描述任何已有完整文件的接口，只要引用定义该接口的文件即可。
4.2.4.通讯接口
指定各种通信接口。
例如，局部网络的协议等等。
4.3.质量需求
4.3.1.可用性
用户使用的方便性、易用性和易学习性，如：
1.输入的无合法性检查和值域检查
2.对于复杂的动作要有必要的提示信息
3.记忆用户的设置或操作习惯，方便用户操作
4.对系统或数据进行重大修改，要有用户确认
4.3.2.可靠性和健壮性
在这一部分应对所有的影响软件的可靠性需求进行足够详细的描述。
应注意用数字说明所要求的可靠程度。
同时避免如“24x7”这样的陈述。
例如使用年度正常运行时间、月正常运行时间、维护时间、当机时间来说明系统的可靠程度；使用可允许的缺陷数量来界定系统质量，如最大缺陷数量、缺陷比例、安全操作——系统强壮性要求和操作的有效性要求，比如用户误操作的系统容错能力、操作的正常次序要求和有效性输入检查等等。
通常给出平均无故障时间或两次故障间的平均间隔时间等。
4.3.3.可维护性
规定若干需求以确保软件是可维护的。
例如：
1.软件模块所需要的特殊的耦合矩阵；
2.使用行业标准、编码标准、开放式结构、可兼容语言、备份及复原和数据交换等。
3.规定把软件从一种环境移植到另一种环境所要求的用户程序，用户接口兼容方面的约束。
4.3.4.可扩展性
说明该软件在需求或环境发生某些变化时，该软件对这些变化的适应能力的要求，如：
1．需求及流程变化；
2．操作方式变化；
3．机构人员变化；
4．空间地点变化（移动用户、分布式）；
5．操作系统环境变化。
5.验收标准
详细说明对系统的验收要求。
此要求将作为验收测试计划和测试的基线。
如果所开发的产品能满足此要求，则项目可结束并由客户方按合同规定付款。
6.附录B：
系统原型
如果已开发了系统原型或计划开发系统原型，则在此进行说明。
7.附录C：
需求确认
参见《需求评审报告》
升级会员 