项目技术需求.docx
- 文档编号:12709995
- 上传时间:2023-04-21
- 格式:DOCX
- 页数:14
- 大小:25.34KB
项目技术需求.docx
《项目技术需求.docx》由会员分享,可在线阅读,更多相关《项目技术需求.docx(14页珍藏版)》请在冰豆网上搜索。
项目技术需求
项目技术需求
a)一、项目概况
1、建设目标
通过校园百事通项目,整合与我校相关的线上线下所有办事场景,为我校打造一个统一的师生咨询服务入口,给师生提供一个更便捷的获取校园服务的触达通道,帮助我校建设一个智能化师生服务体系。
为师生提供一款轻量化应用服务,相当于个人专属智能助手,遇到问题,拿起手机,搜一下,想知道的、想办理的,就可以轻松获取。
就像天猫精灵、小爱同学那样,用起来非常方便。
因为是基于使用者视角设计,能解决传统网上办事大厅服务覆盖面不足、用户使用个性化不足、体验差的弊端。
通过管理后台,学校管理员可以看到师生整体的应用使用情况,师生问的哪些问题最多,情感分析、校园热点问题、校园舆情、师生评价,相关运营数据都是实时可以看到的,也可以定期导出多维度的分析报告,通过这些客观数据积累展示师生用户真实需求,指引信息化建设理性决策。
2、预期的建设效果
通过校园百事通项目建设将会解决如下几个问题:
(1)精确解决师生问题,师生“只需跑一次”
我校内部除了可以进行线上办理的事务之外,依然有大量的事务办理是全线下进行,包括可以线上办理的事务也涉及线下材料的交接、盖章等步骤。
通过校园百事通建设可以帮助师生准确的找到办事的流程和需要的材料,让师生办事更方便,提高办事效率。
(2)办事指南统一管理
目前各个部门梳理的办事指南格式不统一,无法进行统一管理维护工作。
对于用户对于办事流程的反馈建议也无统计分析,无法了解用户的真实需求。
通过校园百事通建设可以实现我校办事指南统一管理,通过大量我校的知识库数据,形式高频且覆盖面广的模板数据库,并经过10万次级别的训练,保证上线的准确率。
让我校可以快速的构建属于我校自己校内知识库。
(3)办事指南高效的触达通道
目前我校内部的办事指南分布在不同的部门、网站、公众号等各种渠道,缺乏一个统一获取渠道。
同时对于办事流程咨询也只能固定在办公时间,无法做到随时随地。
通过校园百事通建立24小时全时间段机器人自动回复,同时移动端,网页Web端数据统一同步,全面覆盖。
b)二、项目需求描述
提供基于AI自然语义识别技术,创建我校内部的业务知识库,在移动端和PC端展示入口,全面提升终端用户的搜索、查询、办事体验的一款校级智能问答服务系统。
1、基本功能要求
校园百事通系统应具备如下特性并基于机器学习和人工智能,提供主动问答服务:
(1)单轮对话:
需要具备强大的自然语言处理和意图识别能力,在没有人工参与的情况下基于知识库准确回答用户问题,可以处理复杂的长句;
(2)容错能力:
需要对于同音字、近义词、句法结构不规范、口语化表达等易混淆问句具备纠错和意图还原能力;
(3)自学习能力:
机器人具备强大的自学习能力,对于提问问法的泛化能力强,人工教育机器人的成本较低,教育方法便捷、多样,能利用历史人工服务记录进行教育,能在日常人工服务过程中通过实际案例教育机器人;
(4)情感分析:
机器人支持对用户问句进行情感分析和敏感信息识别,并根据分析结果采用差异化的服务策略;
(5)主动推荐:
当用户问法模糊、有歧义、未明确意图的提问,系统能根据用户的语境和倾向,推理出最接近的用户意图的知识条目并主动推荐,同时推荐首屏学校热点的问题;
(6)每日数据看板:
提供包括但不限于访客数、会话数、咨询量、准确率、服务可用率等运营指标数据仪表盘展示,并能从时间、地域、业务等不同维度进行查询。
2、用户端功能要求
(1)24小时单轮对话服务
1)自然语言处理能力
需要提供不同于传统的“关键字搜索”技术,而是理解用户的语言或问句拆解成词法、句法、语义。
再加上机器推理从而更准确的理解用户的语言或问句。
提高与用户对话的有效性。
2)意图识别
需要通过自然语言处理能力,对用户的问句进行更精准的理解,通过意图识别能力,推理出用户的真实意图,从而在给予用户答案的同时辅助给予相关度较高的其他知识点,串联出用户的完整意图。
(2)寒暄服务
需要系统自带通用聊天库,覆盖日常简单聊天对话
(3)容错能力服务
需要对于同音字、近义词、句法结构不规范、口语化表达等易混淆问句具备自动纠错
(4)自学习能力服务
需要系统具备自动化的问题泛化能力,知识库或模型不需要人工的提取和组织规则,在知识库或模型维护时不需要考虑与历史维护内容冲突问题。
系统会自动对相同问法的问题进行归类并学习
(5)知识发现功能服务
需要针对日常交互过程中的未解决问题,系统具有自动归类并主动发现新知识点的功能。
3、管理端功能要求
校园百事通管理控制台是我校的知识库管理平台,管理员可查看校园百事通的运营情况并且可以进行知识库的增删改查等管理操作,便于学校进行知识库的维护。
(1)服务概览
1)数据概览:
用户可查看每日的提问量数据,已经当前的知识库准确率,同时该数据会对比上月数据,可了解当前知识库的对比趋势。
2)提问量趋势:
用户可查看目前的提问量趋势,可显示今天24小时的趋势以及近7日和近30日的一个提问量趋势。
3)热门问题:
显示今天、近7日、近30日的top10热门问题及其提问量。
4)知识包提问量占比:
显示今天、近7日、近30日的各个知识包的提问量占比,可了解各个知识包的使用情况。
5)点赞排名:
显示今天、近7日、近30日的点赞及点踩次数最多top5问题排名。
(2)AI服务
1)寒暄服务:
植入寒暄的闲聊问答库,提升机器人的人性化及趣味性。
2)智能咨询:
预置了校内的常用的标准知识包,学校可自行进行FAQ管理维护,同时可查看每个知识包的使用情况。
3)高级技能:
高级技能为与金智应用打通的技能场景。
(3)知识包管理
用户可对问题进行上下线管理,同时可显示每个问题的提问次数及相似问法。
所有问题都预置了答案模板,用户可选择用模板进行填写也可以自定义的方式进行填写。
答案可关联相关服务并且可设置改问题是否公开,公开情况下,问题可让校外用户进行访问。
4、集成校内资源和应用接口需求
校园百事通系统需要根据学校的具体业务场景集成校内信息资源和应用接口,并提供校内第三方业务系统集成方式。
能够明确校内知识库权威源概念,以此保证各业务部门不需要重复填报数据,终身受益。
5、运营服务要求
(1)知识库咨询服务要求(上线前)
需要提供知识库模板并交由相关我校教师,并解释填写规则。
同时运营人员协助我校教师进行填写,最终由校方提供知识包。
(2)知识库优化训练(上线前)
需要根据校方提供的知识包,由承建方运营人员进行优化格式,并进行训练。
(3)知识库知识点检查(上线前)
需要通过问答的形式,检查每个知识点的可用性,保证每个知识点的格式及样式正确,确保上线无误。
(4)知识库上线推广
需要招募内测人员,对知识库举行为期3天的内测活动。
并提供相应的推广宣传物料,方便校方进行推广。
(5)知识库日常训练-30天/次(日常运营)
需要每30天提供一次知识库的日常教育训练,有服务产品提供方的训练员利用问句聚的技术对近30天的客服日志中的新问法及新问题进行聚类标注,从而维持以及提升知识库的准确率(准确率85%以上)。
同时整理出新发现的热点FAQ提供给校方。
(6)知识库升级-90天/次(日常运营)
需要每90天提供一次知识库的底层升级,利用机器学习+AI能力。
结合近90天师生的客服日志以及互联网最新语聊数据进行训练,提升知识库准确率(准确率85%以上)。
(7)知识库日常维护(日常运营)
需要支持对未解决问题进行统计,同时聚类用户真实问句,自动挖掘出知识库未覆盖到的知识点,学校自主控制所有数据,可导出和使用全部数据库,在学校授权和管理下运营人员协助整理数据,并通过运营人员整理并反馈给校方。
并进行知识库日常的增删改相关工作。
(8)年度运营分析报告
需要提供对全年度的知识库运行情况进行多维度分析,包括热点、舆情、情感、满意度等多方面系统分析。
(9)提供本地化服务
需要提供本地化服务,例如业务知识包整理,平台推广宣传,管理端培训等。
c)三、项目技术要求
1、总体要求
1)遵循统一规划、顶层设计的原则,从技术角度实现学校现有数据资源、身份认证和访问界面的集成,搭建统一的应用集成框架,支持未来应用的可持续发展,从“实现使用价值”的角度使得招标方的总体收益最大化。
2)引入SOA服务化、组件化的成功管理思想和技术,融合现代化管理理念和流程,并根据高校的共性以及学校自身的特点,因地制宜的打造一套满足学校整体运营管理和服务的业务身份统一与认证的支持平台。
通过信息化的手段强化学校身份账号的管理能力,提升面向师生的身份账号服务水平,实现和谐发展。
2、关键技术指标
关键技术指标是对项目建设效果的量化评价,包括但不限于如下要求:
1)客服机器人使用深度学习与自然语义处理算法,短期教育后准确率能够达到80%以上,机器人服务平均耗时在500ms以下,服务可用率稳定在99.9%以上。
2)支持100万笔日峰值业务处理量,每秒100笔并发业务处理量;在3G及以上网络条件下,单笔业务响应速度低于1秒。
3、对项目技术架构和技术实现途径的要求
平台和系统均要求采用B/S结构,可运行于Unix、Linux、windows等高安全性操作系统。
开发技术应采用J2EE标准、组件技术及在数据交换上对XML的支持,使系统功能最优化,同时将整体系统内部在技术上的相互依赖性减至最低。
具体要求如下:
1)平台及应用系统软件必须遵循J2EE的技术路线,采用Java编程语言和服务器端Java技术进行开发,业务应用系统和数据集成平台均必须基于oracle11g或以上的大型数据库之上。
2)采用面向对象的组件技术,着重于开发构成应用程序“业务对象”的可重复使用的组件,利用这些组件顺利地建立分布式应用程序。
3)采用成熟的SOA架构及设计理念,保证学校内部各业务系统集成和交互过程中异构技术架构和异构数据结构集成中的稳定性和可管理性。
4)应用程序开发与运行结构要基于统一的技术开发平台的三层架构,即Web服务器、应用支撑服务器和数据库服务器。
5)系统必须支持负载均衡,支持动态监测负载状况,自动对可用资源进行并发检测,调整和分配等功能。
4、项目验收及质保期
合同签订后3个月内交付所有功能并接受验收。
项目验收须达到如下要求:
(1)直接回答比例大于50%;
(2)综合准确率大于90%;
(3)准确率大于90%。
项目免费质保周期为二年。
5、付款方法和条件
本项目在签署合同后按照分期付款方式执行付款,项目申请人须明确付款进度,并将相关要求写入合同商务条款中。
具体如下:
1)首付款:
合同签订一周内支付合同总金额的30%;
2)乙方按甲方需求进行开发,项目上线正式运行后支付项目进度款60%;
3)项目整体验收完毕六个月内支付项目验收款10%;
4)甲乙双方可选择按阶段付款,签订合同时协商阶段付款方案,如协商不成则按以上办法支付合同款项。
6、售后维护要求
(1)对项目使用培训的要求
投标方需根据用户需求不断改进系统功能和性能,并提供有效的二次开发培训。
应针对本项目的最终用户和系统运行维护用户提供分层次培训。
需提供灵活多样的培训方式,包括最终用户的操作培训、对运行维护人员的技术培训等。
应制定详细的人员培训方案,培训方案应包括培训目的、培训时间安排、人员层次、人数、次数、培训课程(包括课程介绍)主要内容(列出培训基本内容)培训组织方式等。
对于提供的所有培训,必须保证师资力量,主要培训教员应是产品的主要设计和开发者。
培训的内容及方案应由双方协商制定。
供应商前来进行技术培训的人员的费用包括在合同总价中。
(2)对项目售后服务的要求
在项目实施地点要有售后服务机构。
在服务期内,应始终通过现场服务、电话服务、远程服务等方式提供快速、高效的维护服务。
服务期内须提供所供软件系统的系统BUG修复、系统性能优化等服务。
协助提供系统数据备份服务,并定期检验数据备份的有效性。
协助采购人对产品运行环境(包括操作系统、数据库、中间件以及其它相关软件)及时进行打补丁、查病毒服务。
投标人在投标时须提出软件系统及运行环境的定期维护计划,对采购人要求的不定期维护提出响应措施。
实施系统维护或修改设计后,应在1周内更新有关技术文档并提交采购人。
技术支持方面,提供7×24小时的技术咨询服务,每年提供至少2次对系统运行状况的评估服务,提供每月1次巡视服务,检测软件系统及运行环境的运行情况。
故障响应方面,提供7×24小时的故障服务受理;对重大故障提供7×24小时的现场支援,一般故障提供5×8小时支援;故障服务的响应时间小于1小时;中断时间不能超过3小时。
d)四、项目与学校信息化总体框架兼容的要求
1、系统对接要求
(1)统一身份认证接入要求
统一身份认证服务通过统⼀管理用户的认证过程和认证信息,使登录后的用户在应用之间可以不需二次登录,为用户带来“单点登录,多点漫游”的便利。
校园用户提供与校园其他系统数据/功能对接的唯一标识,因此在系统登录与用户身份需与校园统一身份认证服务进行对接。
(2)共享数据中心数据对接要求
按学校相关的数据标准,以只读视图的方式授权和开放系统数据,这些数据将会被同步至共享数据中心,供其他业务系统使用。
面向其他应用系统需提供数据访问接⼝的服务,根据数据访问的要求对元数据进行封装,以WebService接口的形式对外发布。
(3)统一通信服务对接要求
基于校园各类应用系统信息统一收发要求,除系统内通知消息外,所有业务系统通过短信、微信、邮件等通道发送的消息均须对接校园统一通信服务,由统一通信服务负责发送,包括回执消息的接收。
(4)校园门户集成要求
包括四个方面的集成内容:
1)资讯对接:
为系统的资讯类内容提供RSS或API订阅接口,以供第三方系统的统一调用。
2)待办/已办接口对接:
包括系统产生的流程类状态信息等。
此类数据需由系统提供相应的webservice接⼝,供门户系统待办/已办功能调用。
3)服务对接:
校园门户内提供校园办事服务功能,涉及到师生服务的申请、办事类应用需与办事服务进行对接。
4)应用对接:
校园门户提供开发者服务功能,支持门户内应用的开发与集成,对于能够为师生提供的简单应用,应在门户平台中遵循相应的接口与界面规范建立对应的应用(第(5)条要求的移动应用集成同理)。
5)应用或服务与门户的对接可能涉及到直接跳转、数据集成、界面集成等多种方式,每个应用或服务具体的对接策略待之后双方视具体情况共同商议决定。
(5)校园移动应用集成要求
包括移动数字校园APP与校园微信公众服务号/企业号,内置的应用商店。
功能支持HTML格式的、移动端页面优化的应用服务直接入驻,技术上涉及到认证、身份的对接等。
对于第三方系统已形成的移动端服务,可直接进行测试迁移。
对于一些数据查询类型的服务,可通过数据与校园共享数据中心的同步后进行独立设计。
其他移动端功能性应用可根据需要逐步实施。
具体的技术方案可由双方技术人员进行详细对接。
(6)GIS系统集成要求
支持与GIS系统集成,调用三维虚拟校园地图,实现地址定位功能、导航功能。
(7)校园一卡通系统集成要求
如果系统存在与一卡通系统相关业务,系统应具备与校园一卡通系统对接集成的能力:
1)能根据一卡通系统提供的标准化接口实现与一卡通系统的集成开发。
2)能提供标准化开放式接口,用于一卡通系统获取相关数据。
具体的技术方案可由双方技术人员进行详细对接。
2、对系统扩展性的要求
具备良好的应用集成能力,提供标准的数据接口,支持二次开发。
扩展能力是由系统的技术架构和技术的先进性所决定的。
系统的扩展性是系统的生命力之所在,良好的扩展性和二次开发能力,能确保系统具有适应性,降低系统的实施和开发成本。
系统须具备良好的扩展性,具有较长的生命周期,在后期的应用过程中能够基于平台进行业务扩展。
3、对系统安全性的要求
(1)总体要求
1)信息系统开发者对于因为程序代码、框架技术以及使用的中间件而产生的应用系统漏洞或bug等程序错误终身负责维护升级;
2)系统上线前须经学校的安全准入检测,不合格的系统不能上线并验收。
(2)系统配置要求
1)系统必须保证为正常上线系统,须更新为最新。
禁止采用失去技术升级的系统(如:
windows2003等);禁止采用含有已知漏洞的组件、应用程序、框架(如:
Struts2.5-Struts2.5.10)、应用程序服务器、web服务器、数据库服务器和平台定义,以上系统必须执行安全配置,禁止默认安装。
所有的软件应该保持及时更新;
2)保证系统服务正常与上线系统一致,无各种调试、报错信息(如:
断点,printf等调试信息)及注释信息,系统需删除系统默认安装的各种例程、文档及管理程序;
3)系统中禁止暴露配置信息(如数据库连接信息),源码备份文件,.git,.svn仓库等。
(3)服务要求
1)本机关闭不需要的端口(如:
关闭windowsnetbios等服务),设置本机防火墙如iptable对于访问的源地址进行限制,同时相关服务设置类似host.allow,host.deny等策略;
2)须按照标准端口配置服务,严禁自行设置非标服务端口。
(4)数据库配置要求
1)数据库和应用系统如在同一台服务器,须采用本机回路进行访问,如前端及数据库分为不同服务器,须设置本机防火墙访问规则,禁止非前端服务器访问数据库网络端口;
2)使用最低权限的数据库用户作为web应用所需,禁止具有不必要的额外权限。
(5)开发要求
1)对用户输入进行严格有效过滤防止sql注入,xss跨站脚本,命令执行,crsf跨站请求伪造等,建议采用白名单过滤策略;
2)禁止在HTTP请求中以明文或可逆编码(如base64、url编码等)的形式传递SQL语句到后端程序代入执行,禁止由Web前端直接生成和传递SQL语句到数据库进行执行,数据库查询必须采用预编译和参数结构化查询。
如果程序确实需要将SQL语句作为内容(非可执行代码的形式,如学生毕业设计、代码样例等)到后台,请在项目上线交付前书面说明相应的功能代码及位置;
3)控制上传点,对于上传文件类型进行严格控制(禁止用js进行控制),同时上传目录不能有执行权限,原则上不允许有未经登陆验证的上传点;
4)设置有效的身份认证、会话管理及访问控制机制,防止越权、平行权限及提权等(禁止利用js进行控制及验证)。
(6)密码复杂度要求
系统必须有密码复杂度检查模块,设置有效的验证码或者滑动等手段防止暴力破解,密码长度须大于8位,含字母(大小写)、数字及符号组合,重要系统须采用二次认证。
禁止在数据库中明文存放用户密码,需进行带salt的哈希之后入库。
对于多次错误登陆进行封堵。
如果长期不登陆默认账号应停用处理。
(7)数据保护要求
对于身份信息、单位职务、财务信息、健康信息、通讯信息等敏感信息禁止在数据库中明文存放。
4、对系统部署方式的要求
平台部署应充分考虑到哈尔滨工业大学现有的IT环境以及对未来发展的适应性,要求系统部署支持单机部署、双机部署、集群部署以及云平台部署。
支持集群及负载均衡技术。
对提出的系统资源配置需求,需提供相应的申请内容,包括但不限于业务平台拓扑、计算资源需求、网络资源需求、存储资源需求(要求提供针对我校实际需求的计算依据,如最大并发、用户增长、网络带宽、CPU、内存、存储需求量测算及具体对外提供服务端口等)。
5、对相关文档和交付物的要求
乙方在项目验收通过后向甲方提供该项目形成的成果和相关文档。
乙方向甲方提供的成果和文档资料不得人为设置技术障碍影响甲方的维护和二次开发。
本项目交付成果(参见项目建设内容)。
提供的文档资料包括:
(1)《项目实施计划》
(2)《项目实施计划变更协议》(如果有变更)
(3)《需求说明书》
(4)《需求变更协议》(如果有变更)
(5)《上线试运行确认单》
(6)《系统技术文档》
(7)《系统管理员手册》
(8)《用户手册》
乙方按哈尔滨工业大学档案馆归档要求,完成项目归档工作。
e)五、技术情报和资料的保密要求
采购甲乙双方均对对方提供的技术情报和资料承担保密义务,如需公开或向第三方提供,需经对方同意。
乙方在工作中获取的甲方提供的信息、资料、数字均应予以严格保密,乙方负责本项目的人员不得向任何单位和个人泄密。
如因泄密造成后果的,乙方应承担全部法律的责任。
乙方对甲方提供的信息资料等在完成合作后返还甲方。
不论本合同是否变更、解除、终止,本条款长期有效。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 技术 需求