SMG文件化传审播项目【招标技术要求】
文档修订记录
目录
第1章项目概况 (1)
第1节项目背景 (1)
第2节项目定位 (1)
第3节建设原则 (1)
第4节建设目标 (2)
第2章项目总体需求 (3)
第1节业务定位 (3)
第2节用户需求 (3)
2.2.1用户现状 (3)
2.2.2需求分析 (7)
第3节系统核心架构要求 (14)
第4节整体流程需求 (15)
第5节整体技术要求 (16)
第3章集散池核心平台功能需求 (17)
第1节资源平台需求 (17)
3.1.1整体要求 (17)
3.1.2功能要求 (18)
第2节能力平台需求 (21)
3.2.1整体要求 (21)
3.2.2应用要求 (22)
3.2.3性能要求 (22)
3.2.4功能要求 (23)
3.2.5格式支持要求 (25)
第4章其他说明 (26)
第1节维护说明 (26)
第2节培训说明 (26)
第1章项目概况
第1节项目背景
目前，SMG电视节目制作播出已全面实现数字化、网络化。在上下游流程均已实现无带化生产的情况下，节目内容的无带化送播和全流程周转已成箭在弦上之势。对于台内自制的节目内容，已有自制节目无带化送播系统将进入试运行，而对于外包和外购的节目内容，亟需一套媒体文件集散池系统，实现从外网导入、审片、技审、送播、简单剪辑等基本送播功能，同时为更多类型的素材内容的导入，并向更多类型的外连系统进行内容交互、交换预留接口。
第2节项目定位
媒体文件集散池系统主要满足，
1. 外购及外来节目文件化收集、审核、技审、送播及归档需求
2. 台内用户素材及节目交换与跨系统流转的需求
通过节目信息管理平台，实现媒资版权中心对平台所管辖的流转素材、素材版、成片、播出版这四个生产阶段的管控要求。同时成为自制节目无带化送播系统的应急备份系统，配套无带化送播系统实现总局62号令的相关要求。（项目第一阶段先期实现东方卫视中心六个频道的传审播功能）
本系统为播出内容审核和其他内容汇聚转发的中转站，不设置内容的永久保存功能。系统在人工操作上完全避免磁带送审、送播工作流程上的弊端，为频道用户提供更加便捷的工作方式。
第3节建设原则
集散池平台的设计必须满足SMG文件化传审播管理要求，并力求满足功能要求的同时，要始终坚持以人为本的设计风格，应用界面友好、操作快捷简便、安全性高、性能稳定、维护使用方便、提供与其它WEB系统以及各类业务数据无缝
整合：
1、先进性：以B/S体系结构为基础，采用目前应用系统最为流行的结构体系。
2、简便性：客户端操作采用统一、标准和简单易懂的方式。
3、整合性：全面支持与多系统的对接，实现文件化节目数据流转。
4、多层次应用：支持内外部应用，支持多栏目组，多频道，多人员，提供群组化管理及集中管理应用。
5、灵活性：系统数据、工作流程、权限角色等，都可以进行动态配置。
6、安全性：保证所有数据传递的安全、准确、有效。
7、可移动性：提供移动客户端，实现移动办公。
8、定制性：提供灵活配置能力，提供流程可配置能力。
9、一体化：SMG全集团成品节目流转审片技审在一体化平台中实现。
10、多维度办公形式：实现多分支机构节目上传、跨地域节目管理、移动审批。
第4节建设目标
本系统为SMG外部节目内容汇聚转发、播出内容审核的中转站，完全避免磁带送审，不设置永久保存功能。
本系统提供外部制作机构到SMG系统内部内容的导入、审片、技术审核、送播等功能。
帮助媒资版权中心，实现对素材、素材版、成片、播出版等四个阶段的管控。
第2章项目总体需求
依托互联网及云计算技术构建一套可扩展的“以用户为中心”的资源汇聚分发的媒体内容管理平台。满足外购及外来节目文件化收集、审核、技审、送播及归档需求。满足台内用户素材及节目交换与跨系统流转的需求。
第1节业务定位
输入部分：面向外部个人或机构提供服务，向SMG提交素材和节目内容，可支持公有云平台方式提交内容。
系统内部完成内容三审、技审、备播业务的支持，只承担中转站职责，不负责素材和成片永久保存。同时面向新媒体生产、传统媒资、制作、播出业务提供支撑。
第2节用户需求
2.2.1用户现状
东视现有卫视、娱乐、星尚、卡通、艺术人文、哈哈少儿这6个频道。我们对频道的基本数据分析如下，
注释*：卡通和少儿的自制节目时长是每档自制栏目的合计时间。
由上图可见，娱乐、人文和星尚的播出栏目时长与频道自制栏目时长相当，而卫视、少儿和卡通三个频道的外购内容远高于自有栏目内容，我们认为后三个频道使用互联网传输内容有较大可能。
东方卫视6个频道播出内容的总时长约占全部播出时长的38.4%，这也就决定了媒体文件集散池在初期建设时，首先满足10天（节假日因素），约610小时的存储容量，可以基本满足频道审片、播出需求。随着媒体文件集散池在SMG 内的推广应用，存储容量可以随着应用频道数量的增加，而逐步扩大。
02
4
6
8
10
12
14
16
18
娱乐人文星尚卫视少儿*卡通*
9.25 4.177.75 6.37 4.4 1.2
9.76717.510.310.5频道自制节目与播出上载时长比较
每日自制栏目时长（小时）每日播出上载时长（小时）0 20 40 60 80 100 120 140 160
卫视中心6频道总时长SMG14个频道总时长61
159
每日播出时长（小时）
娱乐和星尚审片人数与审片机使用比例相当，这反映了频道出现审片设备使用冲突的可能性较小，而卫视、少儿和卡通频道，审片人数远大于审片机数量，预示着在实际的审片中，有存在需要协调的审片要求，这种冲突也给媒体文件集散池的使用带来了机遇。
磁带审片流程
东方卫视中心现有卫视、娱乐、星尚、卡通、艺术人文、哈哈少儿这6个频道，播出内容有完全台外制作，完全台内制作和部分台外制作台内最终合成三种制作方式。送播的内容全部使用IMX 或HDCAM 磁带。整个工作流程是以磁带作为流转介质。这种流程存在着磁带管理、录像机的使用维护成本高、元数据（白卡信息）与内容分离，内容流转时效性差等问题。
5
10
15
20
25
娱乐人文
星尚卫视炫动/少儿1162022231101868频道审片人/机比
审片人数82审片录像机43
技审媒资归档
采编播流程
对于台外制作节目，供片方根据频道的播出要求提供IX 或HDCAM 磁带。一审工作通常由制片人或编导在台外制作地点审查完成，磁带交付频道后，在台内完成二、三审和技审，通过后与白卡一道送抵播出部，播出完成后，磁带交由媒资中心归档管理。
台内制作节目在东视的索贝非编设备上完成合成和一审，然后输出到临时的网络缓存区，由索贝提供的审核软件完成二、三审，媒资的技审设备直接读取缓存区的内容，完成技审。全部审核通过后，内容进入无带化送播流程。
台外部分制作，台内完成的节目，除了台外内容由磁带送抵台内，再上载到非编外，其他流程与台内制作流程相同。
对于直播后的录播，一种是直接录制成磁带后，不加任何修改，送播；另一种是由收录系统录制到非编，编辑以后，输出磁带，送播。
非编系统的虚拟化审片流程
东视娱乐改造的一期工程由索贝提供全套的制作、合成、审核、送播流程，全部流程是以业务网为核心，通过Citrix 的虚拟应用完成OA 网的审片功能。该流程适用于台内自制节目的制播，但对于台外购买节目的审查播出，显现出安全成本、存储成本、内容在其他系统间流转复杂等一系列问题。
2.2.2需求分析
2.2.2.1内容文件化需求
东视全部6个频道使用磁带方式完成审片和送播的工作。对于有大量外购节目的频道，如炫动卡通和哈哈少儿，在播出新节目或使用片库内容重播时，都有磁带文件化的需要。我们需要建立一定数量的集中式IMX和HDCAM磁带上载工作点，供东视所有频道的磁带上载使用。
对于可以使用文件送审、送播的频道或栏目，编导可以使用任何位于OA网的办公电脑，连接USB硬盘，使用传审播平台提供的文件上载工具，将硬盘内的节目上传至平台。
对于提供节目的第三方机构，平台提供使用互联网传输文件上载方式，用户在本地安装上载客户端，在授权上载的前提下，由互联网传输节目内容。
2.2.2.2审片业务需求
?线性流程
栏目制作人员完成节目后，可以从片库的标引单获得节目的基本信息，如栏目、名称、播出频道、片长、播出时间等，节目具备内容和基本元数据两方面信息。栏目负责人（一审）在制作现场审片，并提出意见。修改完成后，编导电话、微信或短信通知送片员已提交二审，并将磁带送至二审领导。二审领导提出修改意见，栏目组修改过后，提交三审领导，三审领导提出意见后，栏目组按照意见修改。完成后由送片员由串联单确认播出元数据准确无误后（白卡绑定），提交技审。技审通过后，由送片员送至播出科上载待播。
?并行流程
栏目制作人员完成节目后，可以从片库的标引单获得节目的基本信息，如栏目、名称、播出频道、片长、播出时间等，节目具备内容和基本元数据两方面信息。栏目负责人（一审）在制作现场审片，并提出意见。修改完成后，编导电话、微信或短信通知送片员，二审、三审领导同时审片，二级审领导提出修改意见，栏目组统一完成意见修改，完成后由送片员由串联单确认播出元数据准确无误后（白卡绑定），提交技审。技审通过后，由送片员送至播出科上载待播。如果技审不通过，则编导按照技审要求修改，通过后由送片员送播。
通常，一审的意见在节目制作过程中已经完成，二审、三审的意见没有先后次序关系，二审有可能发生在三审之后，审核有意见，不需要重新发起流程。审核意见反馈给栏目后，栏目修改完毕就可以送播了，不需要重新再发给审核人重审（违规的现实）。对于某些栏目，在修改过后，栏目编辑还需要送回审片领导审核后才能继续下一流程。
2.2.2.3送播业务需求
当节目技审通过，或三审通过（非技审栏目），送播人员将来自版权媒资中心的白卡信息与节目内容绑定，播出ID写入内容文件的包头信息，文件处于待播状态，待播信息上报节目信息管理平台。播出内容迁移方式采用由节目串联单驱动的拉模式和用户主动推送至播出的推模式，由节目串联单驱动播出GMP自动到媒体文件集散池拉取即将播出的内容到播出二级库，或者根据用户主动推送信息到媒体文件集散池拉取即将播出的内容到播出二级库，完成后通知媒体文件集
散池播出节目传输成功。
2.2.2.4与版资管理的关系
?成片媒资归档（参考版资中心关于节目成品和相关素材的归档方案）
节目处于待播状态时，媒资版权中心通过节目信息管理系统获取状态信息，辅助串联单编单人员及时了解相关内容在生产、播出流程中的状态。如需要存档，则通过节目信息管理平台通知媒体文件集散池，然后主动从媒体文件集散池将内容迁出。
?版资中心在内容生命周期管理中所需的媒体文件集散池信息
内容在上载点初步完成元数据与内容的匹配功能。内容到达媒体文件集散池后，素材或素材版到达状态，以及内容元数据通过节目信息管理平台上报版资中心。如不需要进一步编辑，状态信息变更为等待审核。三审和技审的审核结果通过节目信息管理平台通知版资中心，如果出现修改状态，节目的当前状态通过节目信息管理平台上报版资中心。最后内容状态在白卡绑定和技审通过后转换成送播状态（白卡绑定是结合版权媒资中心的内容管理元数据以及上载时的基本元数据，形成节目最终的完整信息管理元数据），等待播出和媒资中心的归档迁移。播出内容由节目串联单驱动，迁往播出二级库；归档内容根据媒资中心的归档策略，由媒资版权中心主动迁出，元数据由节目信息管理平台提供。
2.2.2.5集散池内容管理
媒体文件集散池中的内容具备10天左右的存储。对于播出内容，当播出和媒资归档迁移成功两个状态同时满足，媒体文件集散池自动将内容加入删除序列，24小时后自动删除。如第7天，播出和媒资归档迁移均未执行，媒体文件集散池上报节目信息管理平台，间接警示媒资版权中心管理人员和内容相关编导，内容会在3天后删除，报警按24小时的间隔持续3天，在第10天，自动将内容移入删除序列，24小时后，删除。
媒体文件集散池内容的存储时间、存储空间策略可以根据频道和栏目的需求设定调整，并能够提供按频道或栏目所形成的组群加以统计汇报的报表。
2.2.2.6信息流程处理需求
节目文件和元数据入库之后，频道审核用户可在审片功能上进行节目内容审核（即二审、三审），如需简单剪接编辑可直接在审片平台上修改，如审核不通过，内容需要制作方（包含外包制作公司、台内栏目制作人员等）修改，则可通过消息接口分别将修改意见推至节目源客户端，要求相关人员修改，并由短信、邮件通知相关负责人员；此外，也支持外部节目源导入的节目内容迁移至台内非编系统修改。
三审通过的节目内容，将可在送播工作站上看到相关送播任务，此时需完成节目信息库导入的电子白卡信息绑定，同时节目源申请表中的元数据和三审信息的元数据也将同时绑定在该节目内容之上。完成电子白卡和其他元数据绑定之后，等待技审结果，如无需技审，则直接推送至播出系统。如果技审未通过，原因将告知制作人员，内容和白卡信息的绑定也自动解除，内容被自动移入删除队列，等待删除策略的执行。
2.2.2.7简单内容汇聚分发需求
媒体文件集散池除了完成无带化送、审、播流程外，它还具有内容汇聚和分发的功能。功能描述如下，
文件传输发起人使用上载客户端输入内容基本元数据，传输时间，目的地等传输参数。系统汇集传输请求后，产生可以以时间、传输申请人、目的地、频道等参数排序的传输调度申请单。媒体文件集散池的管理系统根据传输调度申请单，
按照文件预计到达时间检测文件是否按时到达。文件到达后，通过比对源文件和目的地文件的差别，决定是否需要转码服务。在满足预设的条件后，自动将文件推入目标文件服务器。
流程如下，
2.2.2.8技审流程
技审除了确定节目质量符合技术要求外，还要检查元数据与内容是否吻合，如片名、集数、片长等。
送审时间要求如下，
1、影视剧类（含播出影视剧类节目的固定栏目）节目带须在播出前五个工作日的12:00前送审；
2、专题类、栏目类或综艺类节目带须在播出前二个工作日的12:00前送审，属高清环绕声节目的，须在播出前三个工作日的12:00前送审。
3、复审节目带须在播出前一个工作日的12:00前送审
但在实际操作时，存在不少特列，以东方卫视中心日播类节目为例，当日晚间播出的日播类节目，上午才刚完成，大约在中午左右送至技审。节目在送技审时有因栏目而异的最晚时间要求，如果有时不能达到，则栏目组需要走频道总监签字后的热炒流程，跳过技审，直接送播。，技审部门每月统计并汇报频道。技
审部门希望能够按栏目设置技审关门时间。
技审收片后，节目由技审组长分配给所属的技审员。技审组长希望能够按播出时间的先后次序分配，同时能够监控到每个技审员指定日期段的技审进度，以及在指定频道内按播出时间排序的节目技审进度。
技审完成后，技审员要把技审信息输入到技审信息采集系统中，每月除了提供频道技审汇报外，还需要向番茄网提交汇报。
技审基本流程，
综上所述，
1.技审需要根据节目原码格式监看高清或标清SDI信号，并使用示波器测
量。
2.节目在人工技审前，首先在系统内完成自动技审。
3.技审的收片时间可以根据单个栏目自身的特点，设置不同的收片截至时
间。该时间需要在制作、审片、送片中提醒相关人员。
4.系统能够提示技审组长收到未技审的节目，需要分配给技审员。
5.系统能够根据组长前一次分配的方式，自动产生分配参考意见，由组长
6.技审组长可以查看所辖频道的技审进程，也可以查看指定技审人员的技
审进程。
7.系统能够为技审信息管理系统和番茄网提供技审信息。
2.2.2.9转码服务
1.在审片中高清频道所需的代理码率审片与标清频道是不同的。不同的频
道、栏目对于审片代理码率的要求也不同，系统可以根据不同栏目对审
片质量的要求，单独设置审片的码率。在本系统中我们初步为高清节目
设置8M和4M两种代理码率，标清节目2M。对于移动的审片码率初步采
用500K。
2.在文件交换时，系统可以根据目的地提出的文件格式要求，自动使用转
码服务，把源文件的格式自动变换成目的地的文件格式。
2.2.2.10简单编辑
对于某些不需要加入特效、字幕、多层画面或音轨合成的节目，平台提供简单的剪接功能，包含，
1.单轨视频的剪切和编辑，
2.初期支持2轨音频的独立分轨剪切和编辑，后续需支持8轨音频的独立
分轨剪切和编辑。
2.2.2.11技术管理
集散池的技术业务操作可分为一线辅助用户完成其业务流程和基本故障应急处理，三线后台应用维护，底层基础软硬件平台维护两大类。为了让不同层次的技术支持人员及时准确地了解系统运行状况，对于一线保障人员和组群管理人员，系统提供，
1可视化的流程运行图，显示任务的当前状况和问题的细节汇报
2当主要节点通过后，系统可以配置短信或微信通知
3系统提供可查询的关键节点日志服务，供管理人员了解每个关键节点的
4如果文件在流程中出现关键问题，系统可以设置自动通知流程管理人员进行人工干预
对于三线保障人员，系统提供，
1可视化的流程运行图，显示文件的当前状况和问题的细节汇报
2提供可查询的详细日志，记录文件在流转中的每一步变化和发起变化的人员和系统信息
3具有远程接入进行技术支持的能力
4系统可以对资源使用状况、故障信息等进行可以筛选的汇报
5系统提供技术人员进行系统资源优化的工具
第3节系统核心架构要求
媒体文件集散池系统整体架构分为三层，在基础IaaS之上分为平台能力层、业务应用层和客户端层。
基础IaaS层：采用虚拟化技术的私有云架构建设，包括刀片服务器资源，网络设备资源，存储资源，为整个系统提供IT资源支撑。
平台能力层：平台能力层包括资源平台和能力平台两部分，资源平台提供基础资源服务、相关公共服务支撑；能力平台则提供视音频处理相关能力服务。
第4节整体流程需求
传审播系统总体业务流程涵盖了三个核心业务场景，参考如下图：
?业务流程1：成品节目上传
成品节目上传上传包括以下几个流程：
1.台内或者台外个人采集上传媒体文件集散池
2.从云端系统获取成品节目迁入到媒体文件集散池
3.从台内生产系统推送节目进入媒体文件集散池
?业务流程2：台内栏目组对节目审核
栏目组工作流程分3个步骤：
节目上传送审：栏目组从制作系统上传成品节目发起送审，外部传输接收汇聚可直接发起送审，发起送审时需绑定节目代码或者完善栏目（期数）、播出频道及时间，此后节目状态可被统一监控。
节目三级审核：对接收到的文件进行内容审核，默认根据栏目配置进行三级审核，审片由各栏目组内部及频道人员完成，不同栏目组及审片人员、流程要求各不相同；并行与串行审核；内容审核通过后配置直接发起技审或者送播；技审通过可配置直接发起送播（白卡提前绑定）。
节目技审：技审业务由技审团队统一按照任务调度分配进行，技审人员按任务执行。
对于审核的步骤中，需要特殊处理流程，1）打回修改重审；2）取消重新发起审核；3）修改后继续审核；4）热炒流程等。
业务流程3：技术部门备播推送
对于栏目组提交的通过内审的节目，技术部门技审通过后，直接入备播系统播出。送播由不同送播人员发起，送播需要提供该送播人员组负责的节目统一状态视图和备播视图。
送播节目通知播出系统，由播出系统播出迁移到播出二级缓存。
播后节目可以按策略归档。
第5节整体技术要求
本平台的设计重点突出互联网思维，要求实现平台化、扁平化、易用性（用户节目简洁灵活，可参考百度云平台和百度视频等截面风格）、移动化（支持各类移动客户端：手机、平板电脑等）、社交化（以群组方式组织生产、控制权限和交互信息）、需求弹性扩展等的支持。
本平台会采用互联网成熟技术，架构简单清晰、易于开发测试、容易快速迭代，采用互联网开发主流技术；存储管理部分要求后续具备想对象存储扩展的能力。
本平台采用多层松散耦合架构，系统模块细粒度划分，可根据业务要求重新组装；应用之间松耦合，可独立部署；服务层提供标准化接口或服务，要求对外提供公共服务，比如：转码服务、合成服务、迁移服务、传输服务、语言识别服务等。
第3章集散池核心平台功能需求
第1节资源平台需求
3.1.1整体要求
基础资源平台作为基础平台，提供系统所需公共资源管理服务和其他公共服务。提供包括如下模块：
为了实现松耦合架构，平台各个主要部件之间采用标准服务架构。
资源平台服务层与应用层分离，实现架构分层。平台层提供标准的对外服务接口。通过这些接口提供内容汇聚、审片、技审、备播等业务应用。所有的资源内容由资源平台统一管理，各个业务应用只管理自身的应用业务逻辑和业务流程。
按照功能与性能特点，把基础服务切分为多个独立模块，实现细颗粒的服务封装，服务之间通过服务API和消息机制进行耦合，每个服务分别设计开发、分离部署、分别运行。方便开发迭代，能根据业务的实际需要、确定每个服务的规模。
需要包括，但不限于以下接口：（接口规范的要求需遵守台内各已有规范和周边系统的规范要求）
1. 引言 1.1编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体. 1.2项目背景 1.2.1项目委托单位:****公司 1.2.2开发单位:***公司 1.3定义 1.4参考资料 2. 任务概述 2.1目标: <1> 决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示 <2>提高效率:利用软件进行管理,避免人工管理的失误以及延迟性,从而实现高效率的管理. 2.2运行环境: <1> 硬件方面:Pentium级处理芯片 1兆显存的兼容显卡 256色,1024*768的兼容显示器 标准兼容打印机 <2>软件方面: WIN XP操作系统 2.3条件与限制: 编程用计算机一台 完成期限2000/7/1 无资金供给 3. 数据概述 数据流程图如下:
3.1静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据3.2 动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间3.3数据库描述: 人事管理数据库:公司内人员的个人详细信息,包括档案信息 3.4 数据字典: <1>数据流词条描述: 1.数据流名:登录信息 来源:用户的输入 去向:系统内部检验部分 组成:用户名,密码 流通量:每次登录输入一次 2.数据流名:登录结果 来源:系统 去向:用户 组成:返回信息 流通量:每次登录返回一次 3.数据流名:输入修改信息 来源:用户 去向:系统判断部分 组成:根据各数据库内容而不同 流通量:依用户输入而定 4.数据流名:反馈信息 来源:系统判断部分 去向:用户 组成:系统经判断后发回的字符数据 流通量: 依系统当前信息而定 5.数据流名:识别信息 来源:系统内部检验部分 去向:系统判断部分 组成:系统各数据库的标识信息 流通量:用户每次输入流通一次 6.数据流名:处理信息 来源:系统判断部分
一、项目概况 二、总体目标 通过BIM技术解决图纸问题，解决工地现场实际问题，减少现场签证和变更，进一步提高施工质量、控制施工进度、节约工程造价。并为业主提供基于BIM的项目施 工文件管理，将竣工资料及相关设备资料录入建筑信息模型，以方便后续物业的维护管理。 基于BIM协同工作要求进行BIM共享平台的建设，实现企业项目管理各个环节之间的信息共享和协同作业，支持扩展与企业信息化提供资源的整合、信息的共享以及业务的协同。建立支撑工程信息共享的BIM信息交换接口，实现BIM模型的导入、系 统内模型数据的整合、模型及信息的导出、模型与信息的交互浏览等。 三、具体工作内容 三维BIM模型创建：根据招标人提供的本项目各专业施工图纸建立BIM模型，BI M模型内容包括土建专业和机电设备安装专业。 碰撞检查与优化：把各专业BIM模型进行合并，在施工之前，进行各专业设计图 纸检查，提前发现图纸问题，查找机电各专业之间以及机电与建筑结构专业的冲突点，同时检查结构净高以及机电管线综合优化后净高是否满足要求。及时发现可能存在的问题并在施工之前调整设计，减少设计图纸自身错误或冲突导致的工程变更、现场签证。特别注意以下两点： 1）结合深化设计图纸 2）管线综合优化需符合施工实际情况 工程量计算 1）根据模型自动生成符合国家工程量清单计价规范标准的工程量清单及报表； 2）为招投标、进度款支付、结算等提供工程量支撑； 3）快速统计和查询各专业工程量； 4）对材料计划、使用做精细化控制，避免材料浪费。 进度管理：把计划施工时间、实际施工时间与BIM模型相结合，及时发现施工进 度偏差，优化工程进度计划。具体工作包括：
软件项目名称软件需求规格说明书 拟制: 审核: 批准:日期: 日期: 日期:
文件修改记录
目录 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. 引 言 ........................................................................................................................................... ...................... 4 1.1 编写的目 的 ........................................................................................................................................... 4 1.2 背 景 ........................................................................................................................................... ............ 4 1.3 项目专用术 语 (4) 1.4 参考资 料 ........................................................................................................................................... . (4) 2. 任务概 述 ........................................................................................................................................... .............. 5 2.1 目 标 ........................................................................................................................................... ............ 5 2.2 运行环 境 ........................................................................................................................................... .... 5 2.3 条件与限 制 (5) 2.4 工作流 程 ........................................................................................................................................... . (5)
智慧水务平台建设内容 1.1智慧水务运营数据中心 供水企业的业务支撑系统分别管理着供水基础空间数据、管网数据与业务数据，基于企业内网与数据更新机制，通过各业务支撑系统的开放数据库接口将不同专题数据统一汇总到供水综合运营数据中心，分别实现对应的基础地理信息数据库、管网GIS数据库、巡检维修数据库、管网工程数据库、SCADA数据库、营业收费数据库、客户服务数据库、用户报装数据库、水质化验数据库等数据库的实时更新，最终实现多源供水数据的统一集成，为供水业务集成与综合业务管理提供健全的数据分析依据。 建成后的智慧水务运营数据中心，既可以对供水企业各业务支撑系统的专题数据进行整合，又可无缝获取供水综合业务应用平台在运行过程中分析产生的各种综合业务数据，从而实现整个供水企业的业务数据流转、汇集、共建共享与动态更新。同时，该数据中心还可通过共享服务平台与市政行业各领域（如排水、燃气、照明等）进行在线地图服务数据、市政基础设施数据的交换与共享，从而满足数字市政的长远发展需要。 因此，智慧水务运营数据中心以其丰富、完整、全面的数据信息为基础，不仅可以支撑供水综合业务应用平台的开
发建设，还可以向各业务支撑系统及市政其他领域提供专题业务数据，以及将综合业务应用平台产生、获取的综合业务数据或市政基础设施数据向各业务支撑系统进行发布共享，实现供水各专题业务与综合业务的信息共享与业务协同，从而整合、盘活整个供水企业的信息化管理与服务。 1.2智慧水务共享服务平台 充分考虑供水企业业务管理需求与服务模式需求，以供水综合运营数据中心为基础，供水信息共享服务平台采用面向服务的体系架构（SOA），提供丰富的面向供水业务管理的数据服务、功能服务、运维管理、安全管理，为快速搭建开发功能完善的供水综合业务应用平台提供丰富的服务资源，同时也为今后供水企业的信息化业务拓展需要奠定快速实现基础。 （1）数据服务：提供数据筛选、数据提取、数据处理、数据集成、数据表达、数据发现、数据访问、数据交换、数据更新等服务，支持不同供水业务之间进行有效的数据共享与交换。其中，无论是面向供水综合管理的综合业务应用平台还是面向各科室的业务支撑系统均可通过服务的方式实现数据集成、共享与交换。 （2）功能服务：提供丰富的供水业务服务，如查询统计、空间定位、地图量算、地图服务、空间分析、打印输出
存储系统技术需求书 第二部分 国家图书馆 一、项目目标：
该系统主要用于解决国家图书馆数字图书馆项目中对海量数字资源的调度、备份、服务、存储、长期保存等问题，由存储系统与 设备、数据安全的系统保障等构成。存储设备主要完成对数字资源 信息的存放，是信息存放的载体与介质；数据安全的系统保障主要 承担数据的安全保障工作，由存储备份等系统构成。 二、项目范围： 该系统主要用于国家图书馆数字图书馆，将用于存储包括原始加工数据、永久保存数据、数据库数据等在内的数字资源，同时可 提供可扩展的多种业务应用。存储系统应针对不同的业务需要提供 相应的存储支持，能够提供语音、数据、视频等多种类型对象的存 储服务。存储备份系统作为国家图书馆数字图书馆建设的重要组成 部分，应可完成对数据的有效存储、管理、使用、备份和恢复。 存储系统应可配合数字资源加工系统、资源发布系统、资源保存系统等系统的不同数据的完成迁移工作，同时可根据不同的策略 完成对数据的分级存储和透明调用。 三、技术架构： 1.系统设计建设应采用高可靠的产品和技术，充分考虑系统的应变 能力、容错能力和纠错能力，确保系统运行稳定、安全可靠。系 统设计应具有一定的前瞻性，确保系统在较长时期内先进和稳 固，同时，还应具有良好的扩展性和升级能力，使系统能顺利地 实现向更新一代设备、技术平台的平滑升级。 2.系统设计必须使用科学的方法进行，避免盲目性和随意性；选择 技术先进、具有一定代表水平并且成熟的技术方法和产品来进行 系统建设。 3.由于国家图书馆的主机房到存储机房的距离很近，而且数据量庞 大，对于在馆区内的单位用光缆贯穿很容易，所以考虑存储网络 （SAN）作为主要的存储技术路线。 4.在技术上应尽量遵从开放式标准规范并充分考虑各系统之间的 兼容性、互操作性与开放性。特别是为保护原有投资，该系统应
WORD文档可编辑 X X X X X X单位 X X X X X X X项目 软件需求规格说明书 金碧信息科技
目录 第一章引言 (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) 待办公文列表排序 (11) 公文详细信息界面元素 (11) 网站信息审批 (12) 会议申请 (12) 意见录入 (12) 移动邮件 (12) 会议管理 (13) 通知通告 (13) 通讯录管理 (14) 2.车辆管理模块升级改造需求 (14) 系统功能架构 (14) 网络拓扑结构 (15)
3.电子公文预览需求 (15) 电子公文交换网络 (16) 电子公文交换流程 (18) 4.政务信息管理系统平台功能需求 (19) 第四章软硬件或其他外部系统接口需求 (21) 1.用户界面 (21) 2.硬件需求 (22) 3.网络需求 (22) 4.接口需求 (22) 5.通信需求 (23) 6.运行环境 (23) 第五章其他非功能需求 (24) 1.性能需求 (24) 2.安全设施需求 (25) 3.安全性需求 (25) 4.扩展性需求 (26) 5.可移植性需求 (26)
第一章引言 1编写目的 为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。 2软件需求分析理论 软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。 软件需求分析是一个项目的开端，也是项目实施最重要的关键点。据有关的机构分析结果表明，设计的软件产品存在不完整性、不正确性等问题80％以上是需求分析错误所导致的，而且由于需求分析错误造成根本性的功能问题尤为突出。因此，一个项目的成功软件需求分析是关键的一步。 3软件需求分析目标 软件需求分析的主要实现目标： 1)对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一 致性和完整性，促使用户在软件设计启动之前周密地、全面地思考软件 需求； 2)了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一 个基准； 3)为软件管理人员进行软件成本计价和编制软件开发计划书提供依据； 需求分析的具体内容可以归纳为六个方面：软件的功能需求，软件与硬件或其他外部系统接口，软件的非功能性需求，软件的反向需求，软件设计和实现上的限制，阅读支持信息。 软件需求分析应尽量提供软件实现功能需求的全部信息，使得软件设计人员
智慧水务 智慧供水综合运营平台 解 决 方 案 1
目录 第1章概述.................................................................................................................... - 1 - 1.1、智慧供水概念 (1) 1.1.1、感知的智慧 ................................................................................................... - 1 - 1.1.2、业务的智慧 ................................................................................................... - 1 - 1.1.3、人的智慧....................................................................................................... - 1 - 1.2、建设背景 (1) 1.3、企业运营存在的问题 (3) 1.3.1、基本的业务系统建设还不完善 ...................................................................... - 4 - 1.3.2、各业务系统相对独立..................................................................................... - 4 - 1.3.3、缺少有力的运营管理整合工具 ...................................................................... - 4 - 1.4、企业运营需求分析 (4) 1.5、智慧供水信息化建设方向 (5) 1.5.1、完善基础设施构建软件定义的数据中心........................................................ - 5 - 1.5.2、整合信息资源建立智慧决策体系................................................................... - 5 - 1.5.3、优化水务工作建设智慧水务机制................................................................... - 5 - 1.5.4、构筑统一安全管理夯实智慧水务基础............................................................ - 5 -第2章支持技术............................................................................................................. - 6 - 2.1、3S技术 (6) 2.2、物联网技术 (7) 2.3、客户端技术 (8) 2
软件项目需求书 项目背景 随着公安信息化向“大整合、高共享、深应用”快速发展，公安信息资源种类和数据激增，信息集中度和敏感度明显增加，信息应用和共享方式日趋复杂，数据盗取、越权访问等造成公安敏感信息泄露、侵犯公民隐私的现象时有发生，严重威胁公安信息网安全，亟待从安全技术手段上加强对公安信息资源的保护。为此，从公安应用系统资源库的应用日志入手，实现对用户操作行为（增、删、改、查询、登录等）和接口服务情况（批量比对、查询等）的完整记录，是破解当前“跟踪不下去、查不到源头、取不到证据”难题，防范敏感信息泄露、保护数据安全的有效途径之一。 公安部办公厅于年月日下发《关于加快推进公安信息系统应用日志安全审计工作的通知》（公传发〔〕号）；随后公安部科信局于年月日下发《公安信息系统应用日志安全审计平台建设任务书》（公科信传发〔〕号）。天津市为贯彻落实公安部相关文件指导精神，加大公安信息资源安全保障力度，规划设计我局应用日志安全审计平台项目建设（以下简称“安审平台”）。 商务需求 技术需求
附件一：实施要求 （）投标人确保在合同签订后，项目建设在个月内完成，包括平台安装部署、级联调试、应用系统日志对接。在项目建设过程中要求为应用系统接入改造提供技术支持服务，确保应用系统日志改造工作的顺利进行。 （）若因应用系统接入改造导致的工期延迟，不影响该项目的正常验收。但是承建商应在服务期内持续为应用系统接入改造提供高质量的技术支持服务。 （）投标人在项目实施前应与使用方签订《信息数据保密协议》。 （）为保证此项目按时按质地顺利进行，投标人应建立专门的项目开发组和管理组，由专人负责。 （）投标人应提供详细的项目实施详细的实施方案、时间表和各阶段各方人员安排及相关的工作内容，经使用方同意后，方可实施。 附件二：系统验收要求 验收内容主要以合同签订时双方确认的《软件需求规格说明书》为依据，对软件的各项功能进行全部的核查，如无异议，双方对《用户验收报告》进行签字、盖章。 投标人在程序开发各阶段需提供的资料作为本项目所签定合同的正式附件，与合同正本具有同等的法律约束力。 项目验收标准如下： （）平台能够实现与各个应用系统对接； （）软件要能达到需求说明书规定的要求; （）软件在测试与试运行期间无致命及重大软件缺陷； （）中标人向用户提供项目相关的计划文档、软件需求说明书文档、软件部署实施文档、软件测试报告文档。 附件三：公安信息系统应用日志安全审计平台需求 、系统架构要求 安审平台系统功能架构要求如下图：
第四章数据中心机房建设项目监理技术需求书 1、工程综合说明 云南红塔银行低碳中心机房工程（以下简称机房工程）主要包括二个范围：三楼中心机房，建筑面积约为600平米；地下负一楼UPS电池间，面积120平米。本机房工程的建设项目包括：装修、电气、综合布线、安防、气体消防、机柜及冷通道封闭、动力环境监控、暖通等8个系统。 1.1机房建设基本目标 1.1.1该数据中心是自用型数据中心； 1.1.2结合低碳中心大楼实际，综合考虑整体建设成本和系统的可用性、可靠性，云南红塔银行低碳中心机房按B级加强等级进行建设，即机房整体建设按照B级机房标准，同时空调及供电系统参考A级机房标准； 1.1.3机电系统：具备同时可维护性，支持所有机电设备正常维护需求而无需宕机； 1.1.4安全防范：数据中心整体应具有高安全性，通过完整周到的安全策略和切实可靠的安全手段保障数据中心建筑、设施、IT设备、人员等的安全。 1.2机房工程造价 机房工程项目已确定机房建设承包方，中标金额为1080万。 其中设备费用占比50%以上。
1.3机房设计、施工执行标准和规范 1.3.1总体要求 云南红塔银行数据中心机房参照国家A级机房标准，关键指标超过A级机房标准或达到国际Tier 4标准，规划和建设符合现行的国家计算机机房建设和验收规范： 《电子信息系统机房设计规范》（GB 50174-2008） 《电子信息系统机房施工与验收规范》（GB 50462-2008）《金融业信息系统机房动力系统规范》（JR/T 0131-2015）《金融业信息系统机房动力系统测评规范》（JR/T 0132-2015） 《安全技术信息安全管理体系》（GB/T 22080-2008） 1.3.2 国际及国内相关规范 《数据中心电信基础设施标准》（TIA/EIA- 942） 《信息安全管理体系》（ISO 27001） 美国Uptime Institute - Tier Classifications Define Site Infrastructure Performance - White Paper (2008) 《电子计算机机房设计规范》（GB50174-2008） 《电子计算机机房施工及验收规范》（GB50462-2008） 《金融业信息系统机房动力系统规范》（JR/T 0131-2015）《金融业信息系统机房动力系统测评规范》（JR/T 0132-2015）
Confidential (公司内部文档) XXXX需求规格说明书
需求规格说明书
目录 1 前言 (4) 1.1编写目的 (4) 1.2文档约定 (4) 1.3术语和缩略词 (5) 1.4参考资料 (5) 2 项目概述 (5) 2.1项目背景 (5) 2.2项目目标 (6) 2.3需求范围 (6) 2.4总体框架 (6) 2.5组织机构 (6) 2.6用户特点 (6) 2.7设计约束 (7) 3 功能性需求 (7) 3.1总体流程 (7) 3.2角色定义 (7) 3.3系统功能 (7) 3.4功能描述 (8) 4 非功能性需求 (10) 4.1软件需求 (10) 4.2硬件需求 (11) 5 风险分析 (12) 6 其他说明 (12)
1前言 1.1编写目的 [说明编写这份需求规格说明书的目的，指出预期的读者（一般包括评审人员、软件设计人员、软件开发人员，针对具体情况，还可能包括客户），它是软件开发的基础。] 示例： 1.准确全面定义、阐述xx业务需求，明确xx系统的目标和功能。 2.为有关业务部门和技术部门提供对这个系统的统一的文字的理解。为业务部门判断系统 是否满足其业务需要提供文字依据，为技术部门监督项目功能提供统一标准。 3.在xx系统之前尽可能周密考虑全部需求及设计要求，减少以后可能的重新设计、重新 编码、重新测试等工作。 4.为设计项目方案、编制计划进度提供文字依据。 5.为对项目的完成进行确认和验证提供基准。 本需求规格说明书合法读者对象为：软件开发项目管理者、设计师、测试工程师、技术人员、业务人员。 1.2文档约定 [描述编写文档时所采用的字体标准或排版约定，包括标题和正文的字体和字号约定。完成文档编写后，文档编写完成后本部分须裁剪] 字体大小约定： 标题1 宋体三号加粗 标题2 宋体小三号加粗 标题3 宋体四号加粗 标题4 宋体小四号加粗 标题5 宋体小四号 正文宋体五号 段落约定：文章中每段落需抬头，即段落开头需有两字元的缩排，单倍行距。 表与图编号约定：文中所有表、图须按章节编号，如：第四章节第二个表，编号为：表4-2。
技术需求（技术规范书） 移动互联网网络监测子平台开发——硬件平台搭建 2015年11月12日
一、总则 1.概述 1.1 本文件为工业与信息化部电信研究院（以下简称招标人）对移动互联网网络监测子平台——硬件平台搭建软件采购中的设备供应商（以下简称投标人）提出的技术规范书。本规范书将作为谈判的基础。 1.2 投标人所提供的软件系统应符合技术标准的要求如下： （1）符合有关标准或规范（如ITU-T、CCSA、IEEE、OIF、ISO、ETSI、IETF 等），投标人应在建议书中具体说明； （2）若投标人的系统包含自己的专用技术和协议，应在建议书中具体说明； （3）本文件中未给出，但相关组织已有建议的技术标准及技术规范，投标人均应满足其最新规定； （4）待新标准(中华人民共和国通信行业标准及相关国际标准组织的标准)制定出来后，投标人应免费修改其系统以满足要求； 1.3 投标人应按照本文件的要求提供报价和详细的技术建议。投标人提供软件系统的功能、性能应完全符合招标人指明的标准，并满足或高于招标人指出的要求。对于本文件未规定的有关系统功能及性能，投标人应提出建议，并陈述其理由。 1.4 投标人应根据本文件的要求提供建议书，建议书要求采用中文书写；要求必须提供建议书的电子文档。 1.5 本项目执行期间，产生的所有知识产权，归招标人所有 1.6 本项目的执行期截止到2017年12月31日 2.投标人的技术部分文件要求 2.1 投标人技术部分文件的内容格式要求 投标人所提供的技术部分文件应按照以下内容格式进行编制： 附件—工程技术建议书 ——参与方背景资料
——硬件介绍、数据库软件介绍等 ——投标人应列出其建议书中所提供系统在国内的应用情况。 以及投标人为说明建议方案所给出的其他图纸 附件二技术文件清单 技术文件清单，应包含本次提供的技术文件的种类、数量及简要内容介绍附件三硬件功能清单 附件四工程安排及分工界面 附件五测试及验收（提供验收测试方案） 附件六售后服务 附件七培训 附件八投标人承诺 2.2投标人在建议书中应说明给最终用户提供的技术文件、技术支持、技术 服务、人员培训等的次数、范围和程度。 3.配置清单范围 3.1 配置清单应有分类汇总（按照包括第三方中间件产品、数据库软件、 WEB应用软件等）并有各项的目录价。 3.2本技术规范书应视为保证系统运行所需的最低要求，如有遗漏，投标人 应予以补充，否则一旦采购将认为投标人认同遗漏部分并免费提供。 3.3 投标人应说明随着系统规模的扩充、用户数的增加，其软件扩容方式 及其收费基准。 二、移动互联网应用监测子平台-硬件平台搭建功能需求 1.项目背景 本项目是移动互联网与智能终端公共服务平台的子平台--移动互联网网络监测平台：平台实现对移动互联网性能的整体感知测量，准确判断定位、全面综合分析。实时掌握移动网络运行情况，快速定位移动网络故障及问题，服务行业发展。总体涵盖两大功能部分，一为终端采集模块，依托原有的各省监测点开发固定终端采集，并开发基于各种手机系统和制式的移动终端采集，对移动互联网
第七章技术需求书 第一部分概述 （一）相关背景信息 截至2015年底，京津冀地区共有机动车2621.38万辆，其中北京、天津、河北分别 为557.04、285.90和1778.44万辆，京津冀及周边地区机动车保有量占全国机动车保有 量的28%；一氧化碳、碳氢化合物、氮氧化物和颗粒物等四项污染物排放总量为474.35 万吨，其中北京、天津、河北分别为70.76万吨、55.92万吨、347.67万吨。北京、天津、 石家庄等城市源解析结果显示，北京机动车等移动源排放为污染物首要来源，占比达到 31.1%；天津、石家庄机动车等移动源排放占比相对较小，分别为20.0%、15.0%，在各类 污染源排放分担率中排第三、第四位。机动车已成为京津冀地区大气污染物的重要来源。 2016年实施的《大气污染防治法》提出在不影响正常通行的情况下，可以通过遥感 监测等技术手段对在道路上行驶的机动车的大气污染物排放状况进行监督抽测，公安机关 交通管理部门予以配合。《大气污染防治行动计划》提出加强在用机动车年度检验，对不 达标车辆不得发放环保合格标志，不得上路行驶。《“十三五”生态环境保护规划》提出加 快区域内机动车排污监控平台建设，重点治理重型柴油车和高排放车辆。《关于进一步规 范排放检验加强机动车环境监督管理工作的通知》提出公安交管部门在不影响正常通行 的情况下，要支持配合环保部门采用遥感监测等技术手段对在道路上行驶的机动车进行监 《关于印发<京津冀汽车电子标识试点工作方案>和<京津冀汽车电子标识试点技术督抽测。 方案>的函》提出京津冀地方政府组织开展省际卡点识读基站建设，组织开展中心城区高 排放车辆禁行和限行区域的识读基站建设。《加强“车油路”统筹加快推进机动车污染综 合防治方案》提出，2015年起，京津冀、长三角、珠三角等区域的地级及以上城市推行 遥感监测法，将排放不达标车辆信息通过政府公共信息平台提供查询服务。 （二）建设目标和建设内容 1、建设目标 建设城市机动车国家遥感监测信息联网系统，接收城市机动车遥感监测信息联网平台
招标内容与技术需求▲招标内容与技术需求 项目背景 目前，我校“校园卡”主要有后勤的金龙卡（光电卡），主要用于食堂就餐和打开水，但与图书馆、机房等其他应用不连通，给师生带来不便，另外校园各 系 台使用SQL server数据库。 ●图书馆管理系统：使用汇文图书馆管理系统，使用条形码卡借还书，图 书馆门禁管理系统是上海华宏，通过条形码卡身份识别进出。 我们认为校园一卡通是数字化校园建设的重要内容，是数字化校园不可分割的重要组成部分，所以校园一卡通的建设必须纳入数字化校园建设统一规划和指导。校园一卡通将作为整个数字化校园平台的一个子业务系统，性能和功能上要与整个平台友好地兼容，数据之间的传递要稳定、可靠、正确、实时。
校园一卡通的总体目标 建立以卡为媒介的、面向校园师生的综合性服务平台，覆盖身份识别、金融服务、信息服务等领域，形成高效稳定、功能全面、扩展灵活、管理方便的新一代校园一卡通平台，实现“一卡在手，走遍校园”，成为数字化校园的核心内容之一。具体目标包括： 1 实现证卡统一，提供一体化的服务 本系统要形成完善的、多层次的运营管理体系，为一卡通运营管理人员的日常运营管理和决策分析提供支持。具体包括： ●统一帐户管理。对系统所有客户及其帐户进行集中管理，建立客户 档案，管理其帐户信息及交易记录，实现客户和帐户基本信息的全 局共享。 ●集中资金结算。集中的资金结算和财务管理模式，实现每日结算。
在校内设立结算中心，在各个消费点放置消费终端机，实现多处消 费，统一结算。同时系统留有结算接口，校园其它的管理系统（如 图书馆、医院等）也可以通过结算接口利用校园卡在结算中心进行 结算。 ●多级管理模式。支持一卡通管理中心、分中心、网点等多层次的运 营管理模式，根据学校的地理分布进行灵活部署。 ●自动数据分析。每日产生一卡通运营的统计报表和分析数据，使学 我们知道孤立的一卡通系统应用受到很多限制，不能与其他应用系统互动将严重影响它发挥更大的作用，为了与其他应用系统共享和交换数据，需要建立共享数据库平台和数据交换平台，通过交换平台能快速构建共享数据库，提供反映整个学校全面情况的数据信息。通过构建该平台，并制定统一的校园信息交换标准，公开统一的数据交换接口，为将来的应用系统集成打下坚实的基础。本次采购中要求的各应用系统间的数据交换也要求建立在共享数据库和交换平台的基础上。
智慧水务平台建设 颜愉愉1，高旭2，王冉2 （1上海积成慧集信息技术有限公司，2中国市政工程东北设计研究总院有限公司） 摘要：构建全面感知、整理分析及应用信息的管理平台是智慧水务的主要建设内容，本文以长春水务集 团智慧水务平台建设为例，阐述了智慧水务平台的建设技术路线、建设内容及特征、实现的功能。 关键词：智慧水务平台；物联网；云服务；智能感知；大数据 1引言 智慧水务是智慧城市建设的重要组成部分，旨在提升水务管理和服务水平，为城市的发展提供更好的支撑。长春水务集团智慧水务平台，是在现有水务信息化的基础上高度整合信息及开发利用，通过物联网、云服务等新技术与水务信息系统的结合，实现信息共享和智能化管理。通过水务信息分析与处理， 做出相应的辅助决策建议，以更加精细和动态的方式管理供水系统的生产运营和服务。 2平台建设内容及特征 智慧水务平台以供水业务为核心，覆盖了原水、供水、二次供水、污水处理的管理。以ArcGIS云服 务为基础平台，以业务流程为核心，搭建了17套业务系统，实现日常生产和管理的初步智慧化，平台 具有以下四方面主要特征。 实时感知。将净水厂、配水管网、二次供水的实时监测设备高效连接起来，实时综合管理生产实时 数据，反映从水厂生产到居民用水的全过程情况，为从源头到龙头的管理奠定基础。 全面整合。利用SOA架构实现各业务系统间完全链接与融合；利用云计算进行大量信息的分析和保存，实现信息共享；以“一张图”为展示模式，集成、展示各类业务数据。 协同运作。通过统一的智慧水务平台，实现生产、运行调度、供水服务的统一管理，协同运作，达 到资源优化配置及高效运行的目的。 智慧应用。充分利用物联网、云计算、数据仓库、智能决策支持等先进技术，结合水力学、水文学 和其他模型，实现更多的预判、预警、预报工作，从事后解决的工作方式逐渐转变为预判分析、快速 响应、高效处理、过程透明的工作模式。 3平台建设中采用的技术路线 综合运用了物联网、大数据分析、三维实景技术、ArcGIS云等新兴技术。物联网是通过射频识别（RFID）、红外感应器、全球定位系统、激光扫描器等信息传感设备，按约定的 协议，把任何物品与互联网相连接，进行信息交换和通信，以实现智能化识别、定位、跟踪、监控和 管理的一种网络概念，“水联网”是物联网在水务行业上的应用与扩展，其本质是通过各种信息传感设备， 将水务要素传递到互联网上，进行信息交换和通讯，以实现智能化识别、定位、跟踪、监控、计算、 模拟、预测和管理的一种涉水网络[1]。 云GIS建设模式与云计算相同，基于主流的虚拟化技术，将底层的基础设施资源同ArcGIS软件资源 一起，封装为不同能力的GIS资源池，满足供水业务上多样化的应用需求。平台具有灵活可扩展的优势，结
项目编号：KF2016001 XX项目 业务需求说明书 V1.0 XX银行XX分行 XX项目组 2016年5月
修订文档历史记录 权复制或利用。
目录 1引言 (5) 1.1目的 (5) 1.2项目背景及目标 (5) 1.3业务术语 (5) 1.4参考资料 (5) 2业务系统的总体描述 (5) 2.1系统描述 (5) 2.2与其它业务系统关系 (5) 3性能需求 (5) 4安全需求 (6) 4.1访问控制 (6) 4.1.1用户管理 (6) 4.1.2用户认证 (6) 4.1.3用户授权 (6) 4.1.4会话控制 (6) 4.2数据保护 (7) 4.2.1重点保护数据 (7) 4.2.2数据完整性 (7) 4.2.3加密技术及服务 (7) 4.2.4密钥管理 (7) 4.3编码安全 (7) 4.3.1设计和编码要求 (8) 4.3.2保护机密性要求 (9) 4.4安全日志 (11) 4.4.1安全日志的内容 (11) 4.4.2安全日志禁止记录的内容 (11) 4.4.3安全日志的格式规范 (11) 4.4.4安安全日志的保存与归档 (11) 4.5部署准备 (11) 4.5.1清理调试信息 (11) 4.5.2清理WEB源代码注释 (11) 4.5.3清理不需要的代码 (12) 4.5.4网络服务管理 (12) 4.6开发环境管理 (12) 4.6.1开发环境的软件版本控制及变更 (12) 4.6.2开发环境安全管理软件防护 (12) 4.6.3第三方交付物的安全使用 (12) 4.6.4开发环境用户权限管理 (12) 4.6.5运行环境的完整性保护 (12) 4.6.6其它软件资源的完整性 (13)
软件设计需求说明书 Revised by Liu Jing on January 12, 2021
xxxxxxx系统软件开发需求说明书 xxxxx科技有限公司 二○一五年七月
目录
1引言 1.1编写目的 为明确软件需求，方便与用户统一思想，确定系统功能、数据范围，便于项目规划与进度安排、组织软件开发与测试等，特撰写本文档。 本文档的读者为业主、用户、数据库建设人员、系统设计人员、开发人员和测试人员。 1.2范围 XXXXX动态监管系统软件即：XXXX一体化动态监管平台。 围绕XXXXX水库运行调度设计的要求，以水库运行调度设计为核心，运用先进、成熟技术，建设水库一体化管理平台，实现XXXXX水库监控视频、水雨情监测、流量阀门控制、实地三维仿真等数据自动汇集和信息共享交换，为XXXXX管理部门及时掌握水库区域内的重要水情信息和控制区域（点）的水资源状况，建设现代化、科学化的水库管理调度系统，提高水库运行调度管理能力和水平的提高提供高效的数据支撑和信息服务。 应用说明 本软件建设应以数据中心为基础，依托建设的信息采集系统，实现水库区域视频监控、水雨情监测、水资源调度等信息的收集、处理、交换，为数据中心提供信息来源。构建水库一体化管理平台的基础框架，实现信息共享交换。
1.3定义 监测站点：水库区域监控视频覆盖区域、水库水雨情信息、水资源调度的阀门流量监控等。 监测信息：视频画面、水库水位雨量数据、水库排水流量与水量数据。 三维仿真：基于XXXXX水库实地勘测，制成三维仿真展示，增加三维展示的视频链接热点。 1.4参考资料 《XXXXX施工组织方案》遵义水文局 《水文情报预报规范》GB/T 22482-2008 《防洪标准》GB50201—94 《水位观测标准》GBJ38-90 《降水量观测规范》SL21-90 《实时雨水情数据库表结构与标识符》SL323-2011 《全国分布式水文数据库系统结构版》文档号01-DC-13 计算机软件开发规范（GB 8566-88） 计算机软件产品开发文件编制指南（GB 8567-88） 计算机软件需求说明编制指南（GB 9385-88） 计算机软件测试文件编制指南（GB 9386-88）
招标内容与技术需求 ▲招标内容与技术需求 项目背景 目前，我校“校园卡”要紧有后勤的金龙卡（光电卡），要紧用于食堂就餐和打开水，但与图书馆、机房等其他应用不连通，给师生带来不便，另外校园各种收费项目专门多，现金流通量专门大，现金收付、清点方面造成的问题日益突出。因此校园卡须走出食堂，进入如超市、洗浴、上机等校园消费的各个领域，实现全面的“以卡代币”。并实现幸免各种闲杂人员、未交费学生搭便车现象，使资源科学合理的利用。因此迫切需要在全校实现真正意义上的“校园一卡通”，新系统能够有更高的实时性、可靠性和连通性，能在功能上融金融交易、身份识别和综合服务于一身，在地域上实现跨校区服务，在时刻上实现数据实时全局共享。 目前我校已建成各自独立运行的食堂就餐、教务、学籍、科研、人事、资产、研究生、图书馆、上机计费及财务等治理系统，待建的有学工治理系统和OA系统，缺乏数据的共享和交换，加大了系统使用和爱护的难度，加大了治理人员的工作量。通过新一卡通系统的建设来逐步解决这些问题。目前我校卡应用的各种系统的现状： ●食堂就餐系统：使用金龙卡，有效持卡人数近3万人，收银机100余台， 目前使用情形良好。 ●机房治理系统：大多由杭州联创信息技术承建，共20多个运算机机房， 3000余台运算机，使用由联创公司提供的IC卡刷卡上机，后台使用SQL server数据库。 ●图书馆治理系统：使用汇文图书馆治理系统，使用条形码卡借还书，图 书馆门禁治理系统是上海华宏，通过条形码卡身份识别进出。 我们认为校园一卡通是数字化校园建设的重要内容，是数字化校园不可分割的重要组成部分，因此校园一卡通的建设必须纳入数字化校园建设统一规划和指导。校园一卡通将作为整个数字化校园平台的一个子业务系统，性能和功能上要与整个平台友好地兼容，数据之间的传递要稳固、可靠、正确、实时。
技术需求书 一、本次招标采购的主要设备范围： 本次蚌埠市公安局所采购的警用350兆无线集群通信设备为警用350兆无线集群手持台及配件。 二、投标文件技术响应要求： 1、标有“★”的参数为关键性技术参数，必须无条件满足，如有一项不能满足，视为未实质性响应采购需求； 2、未标“★”的参数为非关键性技术参数，如有三项或三项以上不满足，也视为未实质性响应采购需求。 三、对警用350兆集群对讲机的统一要求 1、投标方所提供主要设备须通过公安部安全与警用电子产品质量检测中心的检测，准许在公安系统入网销售，投标方需提供相应的检测报告。350兆数字集群对讲机需同时提供公安部检测合格证明。 2、投标方中标后签订合同前须提供设备生产厂商质量承诺书（模拟、数字集群对讲机）、生产厂家盖章确认的技术参数资料（模拟、数字集群对讲机）。 3、投标方应具有严格的保密措施，须提供为保守公安机关通信秘密而与安徽省公安厅签订的《保密协议》。 4、投标供应商提供的所有设备必须是原厂正品新货，在交货时，
须提供生产厂商出具的原装机器、电池证明函。 四、主要采购设备技术指标及要求 ⑴警用350兆模拟集群对讲机的技术指标及要求： 1、符合《公安部移动通信网警用自动级规范》（GA176-1998）的要求，并通过公安部相关部门的检测。带有键盘，兼容CPSX/MPT-1343编号计划。 2、采用先进的制造技术，超强抗震、抗高低温、防水防尘，通过IP54/55防水标准。 3、符合美国军标：MIL-STD- 810 C/D/E/F。 4、★中文显示：采用全点阵液晶显示屏，内置标准中文字库，符合GB2312标准，16X15点阵显示汉字。 5、采用≥1950mAh超大容量锂电池和快速充电器。 6、输出功率：不低于4 W（高）/1W（低）。 7、★多系统入网，最多可设置6套网络参数，适合应急及跨区域增援通信使用。可分别设置为CPSX制式或者MPT1343制式。 8、★超出服务区提示音。确保用户确认是否处于有效通信区域内。 9、4级电池容量显示，具有低压告警功能。 10、内置语言加密功能，对语音频谱进行特别处理，防止被窃听。