文档编号：T-JKJS
文档版本：0.01
项目编号：XX-DX- PECS
《XX电信工程外部协作系统》
Project Exterior Cooperation
System
施工单位接口技术解决方案
编写人：南疯日期：2006-10-30
审核人：日期：
批准人：日期：
XXXXXX信息科技股份有限公司
地址：XXXXXXX 邮编：XXXXXX
电话：XXXXXXXX传真：XXXXXX
网站：XXXXXXXXX
修改记录（Revision Chart）
版本号批准人修改人修改0.01南疯2006-10-30
0.02详细修改记录：
序号
1引言
1.1编写目的
1.2覆盖范围
1.3预期读者与阅读建议
1.4文档约定
1.5术语与缩略语
1.6参考文献
2概述
3接口方式
4接口安全
4.1接口认证
4.2数据安全
5事务处理
6性能考虑
7容错处理
8数据格式
8.1约定
8.2施工系统向外协系统发送请求
8.2.1请求查询一个业务数据
8.2.2新增一条记录，得到记录的键值
8.2.3修改一条记录
8.2.4删除一条记录
8.2.5文档上传
8.2.6一条记录中一个文档字段上传多个文件
8.2.7补充上传文档
8.2.8在记录中删除一个文档
8.2.9获得文档的基本信息
8.2.10获得文档的所有兄弟信息
8.2.11获得文档的所有父亲信息
8.2.12下载一个文档
8.2.13获得字典
8.3外协系统向施工系统发送请求
8.3.1发送变更后的数据
8.3.2发送变更后的字典
8.3.3文档发送请求
9信息数据项
9.1数据表
9.2字段信息
9.3字典类型
10网页地址
11Web Service接口
11.1接口命名规范
11.2输入参数
11.3输出参数
11.4外协系统提供的其他接口
12附录：待定问题
1引言
1.1编写目的
本文档为XX电信工程外部协作系统（以下简称外协系统）与电信工程施工单位内部系统（以下简称施工系统）接口技术解决方案，以此作为外协系统与施工系统实施接口的技术方案依据和项目设计标准。
1.2覆盖范围
XX电信工程外部协作系统项目组
施工系统接口开发技术组
1.3预期读者与阅读建议
XX电信企业信息化部
XX电信工程建设部
XXXX公司开发人员
施工系统开发人员
1.4文档约定
粗体正文表示强调内容
红色正文表示未完成或需要今后考虑的内容
蓝色正文表示待讨论内容
1.5术语与缩略语
术语、缩略语定义
外协系统XX电信工程外部协作系统
施工系统电信工程施工单位内部系统
PECS XX电信工程外部协作系统英文简称
1.6参考文献
(XXXX)
2概述
建设XX电信工程外部协作系统的目标，是在工程项目的管理、建设、使用和实施单位之间搭建起数据交换和协同工作的信息平台，延伸与拓展工程建设管理信息化的应用范围，实现通信工程建设过程的信息化管理，促进工程项目的管理部门、建设部门、实施部门和使用部门之间业务流程协调有序地开展，实现工程项目设计、施工、监理管理功能，将相关的设计、施工、监理单位纳入到工程建设管理中，完善工程项目建设过程管理体系，通过信息化推动管理的规范化，在信息化的应用过程中不断探索市场环境下工程建设管理的新思路和新方法。
根据工程部业务工作的实际情况，项目首先满足工程建设管理中应用最广泛、问题最突出的基本需求。
项目功能需求包括：
建立工程外部协作系统与MSS等系统的接口；
建立设计协作服务、监理协作服务、施工协作服务模块，为邮电设计院、电话监理公司和电信工程公司提供工程部所需的协作服务，保证工程建设实施流程的开展；
在建立工程协作服务模块的基础上，建立工程外部协作系统与邮电设计院、电话监理公司、电信工程公司信息系统的接口，实现工程部与三家实施单位的信息交互与业务协作；
本技术解决方案就是针对实现工程建设部与三家实施单位信息交互与业务协作接口中施工单位接口的技术解决方案的组成部分。
在接口的调用过程中，存在施工系统调用外协系统接口的情况，这时候，施工系统作为客户端，外协系统作为服务端；也存在外协系统调用施工系统的情况，这时候，外协系统作为客户端，施工系统作为服务端。本方案中，除了特殊另外说明外，不考虑外协系统和施工系统角色换位的问题。如果一方发起了调用，那么它就是客户端，另一方就是服务端。反之亦然。
4 接口方式
◆工程外协系统与施工系统之间的接口采用Web Service接口形式来进行业务数据的交
互。
◆接口数据传输采用XML数据交换格式，utf-8编码。
◆在外协系统中提供Web Service的API接口。提供由施工系统调用获得信息；并且提供
施工系统提交信息的API接口。
◆同样，在施工系统中提供Web Service的API接口。提供由外协系统提交信息的API接
口。
◆考虑到工程外协中的数据信息不仅包括了XX电信工程公司的数据而且还包含了其他的
施工单位的数据信息。而这些单位也各有其各自工程应用系统。这样，外协系统对各个施
工单位系统所提供的接口API及其参数信息、格式均是统一的。同时，也要求各个施工单
位所提供的接口API及其参数、格式等也必须要求统一。外协系统与施工系统属于一对多
的关系。
◆外协系统要求能够有目的，信息有过滤的把业务信息通过接口正确的发送给相应施工系
统接口。非相关的信息不要发送给对应的施工系统。
◆施工系统建立用户映像对照表、字典对照表、单位对照表等数据映像，传递给外协的数
据使用的是映像中转换后的外协系统能够识别数据；同时，接收到的数据也根据对照表转
换成各自能够解释的数据格式。
◆数据初始化的时候，由施工系统主动调用外协系统的接口，以获得用户信息、字典信息、
单位信息、项目信息等基础信息。以后，一旦发生数据的变动，由外协系统主动往施工系
统发送信息。
◆外协系统不主动请求施工系统获得数据，但是外协系统会主动请求施工系统发送数据。
◆施工系统主动请求外协系统获得数据，也会主动请求外协系统发送数据。
4接口安全
4.1接口认证
调用认证：
虽然接口双方都是存在于电信内部网络中，但是，仍不能排除接口服务被攻击、恶意调用以及非法调用等。所以，从接口调用上，必须考虑调用的认证安全问题。
◆本方案中的接口，在客户端调用服务端的时候，必须经过调用身份认证。考虑施工系统
的开发平台的多样性，但同时接口服务运行平台都是Windows的情况，本方案采用Windows
安全身份认证的方式。即在访问接口所在的服务的时候，都必须进行资格审查（使用
Credentials发送认证信息）。
◆另外，接口采用SOAP协议，因此在接口配置上面需要屏蔽HTTP GET 和HTTP POST等其
他协议。
◆在接口中审核并进行日志的记录。
◆使用最低权限的进程帐户运行 Web 服务（通过 Machine.config 中的
元素来配置）。
◆接口不支持动态生成WSDL,因此作为服务端，应该禁止文档协议。
◆在服务端禁用跟踪，禁用调式编译
业务用户认证：
由于接口涉及电信工程中的各个不同的业务，有获取字典、获得项目信息、发送开工报
告等，所以，建立一套业务的用户认证机制是必须的。不同的用户，所具备有的授权不一样，所能执行的业务也不一样。同时，业务用户认证中的用户信息也是记录接口日志中的重要组成部分。
本方案采用的是在接口信息中包含业务认证用户信息的方式来进行认证。服务端在收到请求的时候，应先验证业务的授权用户，如果该业务用户没有执行当前业务的权限，应终止业务的执行，并给出非法用户的警告信息反馈回客户端。
一般情况下，业务认证的用户是系统中的用户。业务认证其实就是应用系统认证的组成部分。
业务认证的用户信息经过加密之后包含在要发送的信息（XML体）中，即在发送的信息中包含业务用户的信息（参见下面的数据格式说明）。
4.2数据安全
数据的安全表现为如何保证数据在网络传输过程中不会被截获并被解析其中的内容而引起信息泄露与如何保证数据在传输的过程中的数据的完整性两个方面。
Web Service采用XML数据格式来传输信息。所以，无论是发送数据还是返回结果，都要求采用对XML数据加密之后来传输。至于采用何种方式的加密技术，本方案为了保密，只能在开发的时候由开发人员口头告知。涉及到加密技术就要涉及到加密的密钥问题。目前，外协系统和施工系统接口上有很多种类型的业务，到底是每种类型的业务采用不同的密钥，还是按分组来采用同一种密钥的方式，还是所有的业务全部采用同一种的密钥的方式，按照需求各有不同的选择。本方案采用的是最后一种的方式。密钥的发布由作为服务方来发布，由客户端获取。密钥的发布方式待定。
为了保证数据的完整性，首先：方案采用数据签名（SOAP Security Extensions: Digital Signature）。利用XML的数字签名（XML Digital Signature syntax [XML-Signature]）对SOAP进行扩展，在SOAP的头元素中定义签名属性（
5事务处理
事务是一组相关的任务，作为独立于其他任务的独立单元成功（提交）或失败（中止）。分布式事务是影响多个资源的事务。要提交分布式事务，所有参与者都必须保证对数据的任何更改是永久的。不论系统崩溃或是发生其他无法预料的事件，更改都必须是持久的。即使只有一个参与者无法保证这一点，整个事务也将失败，在事务范围内对数据的任何更改均将回滚。
外协系统和施工系统是处于网络之上的两个分布式接口，使用的是分布式事务。要启用
XXXX系统 Web Services业务接口规范说明书 拟制 审核 会签 批准 【公司名称】
版本历史
目录 1.范围 (1) 2.术语、定义和缩略语 (1) 2.1 术语、定义 (1) 2.2 缩略语 (1) 3.接口设计 (1) 3.1 接口公共参数 (1) 3.1.1请求参数 (1) 3.1.2返回参数 (2) 3.2 业务功能接口 (3) 3.2.1业务模块1 (3) 4.MD5加密 (6) 5.参考文献 (6)
1.范围 本规范文档主要适用于XXXX系统和其它业务系统信息数据的接入。 2.术语、定义和缩略语 2.1术语、定义 2.2缩略语 3.接口设计 3.1接口公共参数 接口服务器通过：http://IP:port/EIP/WebService/ 连接服务器，同时对外提供业务功能接口，接收的参数和返回的参数都用一定的xml格式进行封装。 3.1.1请求参数 1.请求类型为String类型
3.请求参数体param定义 参数体param中的具体请求参数，根据不同的业务而不同，详见各业务接口。 3.1.2返回参数 1.返回类型为String类型
XXX接口说明书(版本：V1.0)
修订记录
1简介 1.1文档目的 接口文档是前端与后端交互密不可分的环节，接口的规范性会直接影响双方对接过程中的效率和质量。本着快速高效开发的目的性，避免对接过程中的错误率。 1.2接口规范 (1) 遵循RESTful API设计风格 (2) 数据格式采用json格式 (3) 返回统一结构数据 例如： 结构：data（数据）、errorCode（状态码）、msg（提示信息） { data:{}, // 数据类型不一定为object类型 errorCode:10001, msg:'' } (4) 枚举型参数应列举参数所有值及说明 例如： gender：性别（男：1，女：2） userInfo:{ name:'张三', age:23, gender:1 }
(5) 具有嵌套关系的参数应指明嵌套关系及子级数据结构例如： billList: 账单列表(父级) billList:[ { id:'001', billName:'测试数据', billStauts:1, address:'雁塔区' } ] (6) 返回参数数据类型保持一致性 例如： billList: 账单列表（有数据） billList:[ { id:'001', billName:'测试数据', billStauts:1, address:'雁塔区' } ] billList: 账单列表（无数据） billList:[] 返回的参数数据类型都为：array (7) 下拉及选择型数据以键值对的形式返回 例如： orderOperate：订单操作 orderOperate:[
{产品名称} 软件需求规格说明书 编写人： 编写日期：年月日
目录 1.产品描述 (3) 1.1.编写目的 (3) 1.2.产品名称 (3) 1.3.名词定义（可选） (3) 2.产品需求概述 (3) 2.1.功能简介 (3) 2.2.运行环境 (3) 2.3.条件与限制（可选） (3) 3.功能需求 (3) 3.1.功能划分（可选） (3) 3.2.功能1 (4) 3.3.功能N (4) 3.4.不支持的功能 (4) 4.数据描述 (4) 5.性能需求（可选） (4) 6.运行需求（可选） (4) 6.1.用户界面 (4) 6.2.硬件接口 (4) 6.3.软件接口 (5) 6.4.通信接口 (5) 7.其它需求（可选） (5) 8.特殊需求（可选） (5) 9.不确定的问题（可选） (5) 10.编写人员及编写日期 (5) 11.附录 (5) 11.1.引用文件 (5) 11.2.参考资料 (5)
1.产品描述 1.1.编写目的 【说明编写本软件需求规格说明书的目的，指出预期的读者。】 1.2.产品名称 【本项目的名称，包括项目的全名、简称、代号、版本号。】 1.3.名词定义（可选） 【对重要的或是具有特殊意义的名词（包括词头和缩写）进行定义，以便读者可以正确地解释软件需求说明。】 2.产品需求概述 2.1.功能简介 【对产品的基本功能做一个简介，包括： 1.本产品的开发意图、应用目标及作用范围。 2．概略介绍了产品所具有的主要功能。可以用列表的方法给出，也可以用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图等。 3．说明本产品与其他相关产品的关系，是独立产品还是一个较大产品的组成部分。 可以用表示外部接口和数据流的系统高层次图，或者方框图说明。】 2.2.运行环境 1.硬件环境： 【详细列出本软件运行时所必须的最低硬件配置、推荐硬件配置(如主机、显示器、外部设备等)以及其它特殊设备。】 2.软件环境： 【如操作系统、网络软件、数据库系统以及其它特殊软件要求。】 2.3.条件与限制（可选） 【说明本软件在实现时所必须满足的条件和所受的限制，并给出相应的原因。 必须满足的条件包括输入数据的范围以及格式。 所受的限制包括软件环境、硬件环境等方面的内容。例如：必须使用或者避免的特定技术、工具、编程语言和数据库；企业策略、政府法规或工业标准；硬件限制，例如定时需求或存储器限制；经费限制、开发期限；项目对外部因素存在的依赖。例如其它项目开发的组件。等等】 3.功能需求 【功能需求描述系统特性，即产品所提供的主要服务。可以通过使用实例、运行模式、用户类、对象类或功能等级等不同方法来描述，还可以把它们组合起来使用。 功能需求的表述形式可以参见《需求分析和管理指南》第8.2节。】 3.1.功能划分（可选） 【此部分从用户的角度描述将软件划分成不同的部分，并给出总体功能结构。对于复杂
文档编号：T-JKJS 文档版本：0.01 项目编号：XX-DX- PECS 《XX电信工程外部协作系统》 Project Exterior Cooperation System 施工单位接口技术解决方案 编写人：南疯日期：2006-10-30 审核人：日期： 批准人：日期： XXXXXX信息科技股份有限公司 地址：XXXXXXX 邮编：XXXXXX 电话：XXXXXXXX传真：XXXXXX 网站：XXXXXXXXX 修改记录（Revision Chart） 版本号批准人修改人修改0.01南疯2006-10-30 0.02详细修改记录： 序号
1引言 1.1编写目的 1.2覆盖范围 1.3预期读者与阅读建议 1.4文档约定 1.5术语与缩略语 1.6参考文献 2概述 3接口方式 4接口安全 4.1接口认证 4.2数据安全 5事务处理 6性能考虑 7容错处理 8数据格式 8.1约定 8.2施工系统向外协系统发送请求 8.2.1请求查询一个业务数据 8.2.2新增一条记录，得到记录的键值 8.2.3修改一条记录 8.2.4删除一条记录 8.2.5文档上传 8.2.6一条记录中一个文档字段上传多个文件 8.2.7补充上传文档 8.2.8在记录中删除一个文档 8.2.9获得文档的基本信息 8.2.10获得文档的所有兄弟信息 8.2.11获得文档的所有父亲信息 8.2.12下载一个文档 8.2.13获得字典 8.3外协系统向施工系统发送请求 8.3.1发送变更后的数据 8.3.2发送变更后的字典 8.3.3文档发送请求 9信息数据项 9.1数据表 9.2字段信息 9.3字典类型
XXX接口说明书 (版本： 文档编号保密等级 作者最后修改日期 审核人最后审批日期 批准人最后批准日期
修订记录 日期版本修订说明修订人
1简介 1.1文档目的 接口文档是前端与后端交互密不可分的环节，接口的规范性会直接影响双方对接过程中的效率和质量。本着快速高效开发的目的性，避免对接过程中的错误率。 1.2接口规范 (1) 遵循RESTful API设计风格 (2) 数据格式采用json格式 (3) 返回统一结构数据 例如： 结构：data（数据）、errorCode（状态码）、msg（提示信息） { data:{}, .] 订单列表 orderList orderId string 否订单id orderName string 否订单名称
isStudent boolean 是false false 是否学生（是：true，否： false） 返回参数： 参数名类型示例值默认值描述 data array […]返回的数据 data id string 用户id gender number 1 1 用户性别（男：1，女：2）invoiceTitle string 抬头 address string 地址 billList array [...] 订单列表数据 billList id string 订单id billName string 订单名称 billStauts number 1 1 订单状态（待开票：1，回款： 2，核销：3） address string 客户地址 userInfo object {} 用户信息 userInfo name name 用户姓名 age number 用户年龄 gender string 1 1 用户性别（男：1，女：2）errorCode number 状态信息 msg string 信息提示 返回示例值: { data:[ { id:'1', gender:2, invoiceTitle:'帝国快运', address:'陕西省西安市雁塔区科技路24号', billList:[ { id:'001', billName:'测试数据', billStauts:1, address:'雁塔区' }, { id:'002', billName:'测试数据02',
媒讯集团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来生成客户端代理。
POE模块说明 一、POE简介 POE被称为基于局域网的供电系统(POL, Power over LAN )或有源以太网( Active Ethernet)，有时也被简称为以太网供电，这是利用现存标准以太网传输电缆的同时传送数据和电功率的最新标准规范，并保持了与现存以太网系统和用户的兼容性。 POE有两个通用标准： 1.IEEE 80 2.3at：最新POE供电标准，为大功率终端的需求而诞生，最大可以提供30W的输出功率。 2.IEEE 802.3af ：首个POE供电标准，规定了以太网供电标准，是现在POE应用的主流实现标准，最大可以输出13W的功率。 POE标准为使用以太网传输电缆输送直流电到POE兼容的设备定义了两种方法： 1.中间跨接法(Mid -Span)：使用以太网电缆中没有被使用的空闲线对来传输直流电，需要8芯网线来供电，4芯数据线，4芯供电线。 2.末端跨接法(End-Span)：在传输数据所用的芯线上同时传输直流电,其输电采用与以太网数据信号不同的频率。总共只需要4芯线，既传数据，也可以供电。 我司开发的POE模块支持IEEE 802.3at标准也兼容IEEE 802.3af标准，采用标准的38*38大小，同时支持mid-span及end-span两种方法，可以与我们现有的电源板直接对接，有着极好的兼容性，使用方便。
二、接口说明 1.1 POE 模块正面接口 图1 POE 正面图 表1 POE 正面详细接口列表 图中代号 接口详细编号 接口定义 接口定义 实现功能 P1 1 NC 空脚 2 NC 空脚 3 GND 地 4 +12Vin +12V 电源输入 输入 P2 1 +48 48V 正极 输入 2 +48_GND 48V 负极 输入 3 GND 地 4 +12Vin +12V 电源输出 输出
客户化开发需求规格说明书 媒讯集团E A S项目 CTC与EAS接口 需求及设计说明书 文档作者： 创建日期：2013-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来生成客户端代理。
软件(结构)设计说明(SDD) 说明： 1.《软件(结构)设计说明》(SDD)描述了计算机软件配置项(CSCI的设计。它描述了CSCI级设计决策、CSCI体系结构设计(概要设计)和实现该软件所需的详细设计。SDD可用接口设计说明IDD和数据库(顶层)设计说明DBDD加以补充。 2.SDD连同相关的IDD和DBDD是实现该软件的基础。向需方提供了设计的可视性，为软件支持提供了所需要的信息。 3.IDD和DBDD是否单独成册抑或与SDD合为一份资料视情况繁简而定。
目录 软件(结构)设计说明(SDD) (1) 1引言 (3) 1.1标识 (3) 1.2系统概述 (3) 1.3文档概述 (3) 1.4基线 (3) 2引用文件 (3) 3 CSCI级设计决策 (3) 4 CSCI体系结构设计 (4) 4.1体系结构 (4) 4.1.1程序(模块)划分 (4) 4.1.2程序(模块)层次结构关系 (4) 4.2全局数据结构说明 (4) 4.2.1常量 (4) 4.2.2变量 (4) 4.2.3数据结构 (5) 4.3 CSCI部件 (5) 4.4执行概念 (5) 4.5接口设计 (6) 4.5.1接口标识与接口图 (6) 5 CSCI详细设计 (7) 6需求的可追踪性 (8) 7注解 (8) 附录 (8)
1引言 1.1标识 本条应包含本文档适用的系统和软件的完整标识。(若适用)包括标识号、标题、缩略词语、版本号、发行号。 1.2系统概述 本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。 1.3文档概述 本条应概述本文档的用途与内容，并描述与其使用有关的保密性或私密性要求。 1.4基线 说明编写本系统设计说明书所依据的设计基线。 2引用文件 本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章也应标识不能通过正常的供货渠道获得的所有文档的来源。 3 CSCI级设计决策 本章应根据需要分条给出CSCI级设计决策，即CSCI行为的设计决策(忽略其内部实现，从用户的角度看，它如何满足用户的需求)和其他影响组成该CSCI的软件配置项的选择与设计的决策。 如果所有这些决策在CSCI需求中均是明确的，或者要推迟到CSCI的软件配置项设计时指出，本章应如实陈述。为响应指定为关键性的需求(如安全性、保密性、私密性需求)而作出的设计决策，应在单独的条中加以描述。如果设计决策依赖于系统状态或方式，则应指出这种依赖性。应给出或引用理解这些设计所需的设计约定。CSCI级设计决策的例子如下： a.关于CSCI应接受的输入和产生的输出的设计决策，包括与其他系统、HWCI, CSCI和用户的接口(本文的4.5.x标识了本说明要考虑的主题)。如果该信息的部分或全部已在接口设计说
软件需求说明书编写规范
————————————————————————————————作者：————————————————————————————————日期: ?
案卷号 日期 <项目名称＞ 软件需求说明书 作者:王浩天 完成日期: 8.２3 签收人： 签收日期: 修改情况记录: 版本号修改批准人修改人安装日期签收人
目录 １引言 .................................................................................................. 错误!未定义书签。 1.1 编写目的.................................................................................................... 错误!未定义书签。 1.2范围?错误!未定义书签。 1．３定义?错误!未定义书签。 1．４参考资料............................................................................................... 错误!未定义书签。 2 项目概述?错误!未定义书签。 2.１产品描述?错误!未定义书签。 2．2 产品功能................................................................................................. 错误!未定义书签。2．3 用户特点................................................................................................. 错误!未定义书签。 2.4 一般约束.................................................................................................... 错误!未定义书签。 ２.５假设和依据............................................................................................ 错误!未定义书签。 ３具体需求?错误!未定义书签。 3.1 功能需求.................................................................................................... 错误!未定义书签。 3.1.1 功能需求１?错误!未定义书签。 3.1.2 功能需求２......................................................................................... 错误!未定义书签。 3.１.ｎ功能需求n...................................................................................... 错误!未定义书签。 ３．2 外部接口需求....................................................................................... 错误!未定义书签。 3.2.1 用户接口?错误!未定义书签。 3.２.2 硬件接口?错误!未定义书签。 3．２．３软件接口................................................................................. 错误!未定义书签。 3.2．4 通信接口?错误!未定义书签。 ３．3 性能需求?错误!未定义书签。 3.4 设计约束.................................................................................................... 错误!未定义书签。 ３.4．１其他标准的约束.......................................................................... 错误!未定义书签。 ３.4.2 硬件的限制?错误!未定义书签。 3.5 属性?错误!未定义书签。 3.5.１可用性?错误!未定义书签。 3.5.2 安全性?错误!未定义书签。 3．5．3 可维护性....................................................................................... 错误!未定义书签。 3．5．4 可转移\转换性............................................................................ 错误!未定义书签。 3.5.5 警告?错误!未定义书签。 3.6 其他需求.................................................................................................... 错误!未定义书签。 3．6．1 数据库........................................................................................... 错误!未定义书签。 3.6．２操作 (7) ３．６.３场合适应性需求?错误!未定义书签。 ４附录 .................................................................................................. 错误!未定义书签。
文档编号： 密级： 预约挂号系统 接口设计说明书 （HIS部分） 编制： 审核： 批准： 2010年 10
文档修改记录
1总体设计 1.1 总体要求 预约挂号系统平台与各医院HIS之间是一对多的接入关系，因医院HIS系统各不相同：建设厂家不同，版本不同，环境不同；与平台间的网络连接方式也存在差异。为保证平台的兼容性和可扩展性，要求该接口规范具备高通用性，可跨平台、跨语言实现，且适用于不同的网络环境和硬件设备。 1.2 系统拓扑 1.3 模块说明 本文档涉及的接口应用布署于拓扑图中的“医院His前置”上。 预约挂号系统包括两大类应用： 一．HIS向预约挂号平台上传预约挂号系统所需的基本信息（如：医院信息、科室信息、医生信息、排班信息、停诊信息等）和其他交易信息（如：患者预约后
的实际就诊情况、患者投诉情况、患者注册信息等）。该类交易平台为服务端， HIS为客户端。平台方提供DLL函数接口，供HIS调用。 二．平台向HIS发起的实时交易请求（如：预约挂号、预约取消、患者信息向医院传送等）。该类交易平台为客户端，HIS为服务端。HIS提供存储过程供平台调 用。 三．详细业务部分请参阅《省预约挂号平台业务操作规范.doc》 2平台与医院HIS接口 平台与医院HIS前置之间采用TCP/IP通讯协议，建立两对SOCKET端口（互为客户/服务端）：一对用于医院HIS系统发起的交易（HisToEbs），一对用于平台发起的交易(EbsToHis)。其中客户端作为发送数据端口，服务端作为接收数据端口。HIS作为客户端时，通过调用平台提供的DLL函数发起交易请求；HIS作为服务端时，向平台开放存储过程。 交易方式采用短链接的方式。在一个TCP/IP连接上完成数据包的发送和接收，在成功发送了一个数据包，并收到成功应答后，即中断该连接。 HisToEbs和EbsToHis均采用同步方式。 文件传输采用FTP方式。 2.1 HisToEbs 该接口主要用于HIS系统向平台传输院方相关基础及变更信息，如：医院介绍、科室设置、医生、排班等。 该接口的实现采用HIS调用Dll函数的方式，Dll函数接口由平台提供。函数封装了底层通讯协议和交易逻辑。 2.1.1初始化服务器设置 Int SetIpAndPort(char*szHospitalID,char *szIp,int nPort) 函数说明：设置医院编号、His Server（HIS前置）的ip和端口号。在HIS系统启动（初始化）时加载调用，必须先调用该函数进行初始化，否则会提示调用失败。 输入参数：szHospitalID 医院ID，由省平台统一分配（6位字符） szIp HIS前置服务器的ip，如192.168.1.202，具体到实施时确定 nPort HIS前置服务器的port，如8098（最大65535），具体到实施时确定 输出参数：无 返回值：0 成功 1 连接服务器失败
需求规格说明书 软件需求规格说明书是软件开发过程需求分析阶段需要产出的文档，是为了使用户和软件开发者对软件的规格有一个共同的理解而撰写的，软件需求规格说明有标准的模板 方法/步骤 第一章是引言。 描述软件需求规格说明书的纵览，帮助读者理解文档如何编写并且如何阅读和理解，包含五
个部分： 1.1 编写目的 //对产品(项目)进行定义，在该文档中详尽说明这个产品的软件需求，包 //括修正或发行版本号。如果这个软件需求规格说明书只与整个系统的一 //部分有关，那么只定义文档中说明的部分或子系统。 1.2 文档约定 //描述编写文档时所采用的标准或排版约定，包括正文风格，提示区或重 //要符号。例如，说明高层需求的优先级是否可以被所有细化分需求所继 //承，或者每个需求陈述是否都有优先级。 1.3 读者对象和阅读建议 //列举软件需求规格说明书所针对的不同读者，例如开发人员、项目经理、//营销人员、用户、测试人员等。描述文档中剩余部分的内容及其组织结//构。提出最适合每一类读者阅读文档的建议。 1.4 项目范围 //提供对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业 //目标或业务策略相联系。可以参考项目范围文档，而不是将其内容复制到 //这里 1.5 参考资料 //列举编写软件需求规格说明书时所参考的资料或其它来源。可能包括用户 //界面风格指导、合同、标准、系统需求规格说明书，用户需求、相关产品 //的软件需求规格说明书。这里应给出详细的信息，包括标题名称、作者、 //版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。
第二章是总体描述。包含六个部分： 2.1 产品前景 //描述软件需求规格说明书中所定义的产品的背景和起源。说明该产品是否 //是产品系列中的下一个成员，是否是成熟产品所改进的下一代产品，是否 //是现有应用程序的替代品，或者什邡市一个全新的产品。 //如果软件需求规格说明书定义了大系统的一个组成部分，那么就要说明这 //部分软件是怎样与整个系统相关联的，并且要定义出两者之间的接口。建 //议使用系统结构图或者实体关系图表示 2.2 产品的功能 //概述产品所具有的主要功能，详细内容在第4节描述，所以这里只需要概括 //总结，例如用列表的方法给出。很好地组织产品的功能，使每个读者都易 //于理解。用图形表示主要的需求分组以及它们之间的联系。 //建议使用数据流程图（DFD）的顶层图或者类图来实现图形化
接口设计说明(IDD) 说明： 1.《接口设计说明》(IDD)描述了一个或多个系统或子系统、硬件配置项HWCI、计算机软件配置项CSCI、手工操作或其他系统部件的接口特性。一个IDD可以说明任何数量的接口。 2.IDD可用于补充《系统/子系统设计(结构设计)说明》(SSDD)、《软件(结构)设计说明》(SDD)和《数据库(顶层)设计说明》(DBDD)。IDD及其相伴的《接口需求规格说明》(IRS)用于沟通和控制接口的设计决策。 接口设计说明的正文的格式如下： 1引言 本章应分以下几条。 1.1标识 本条应包含本文档适用的系统、接口实体和接口的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。 1.2系统概述 本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。 1.3文档概述 本条应概括本文档的用途与内容，并描述与其使用有关的保密性或私密性要求。 1.4基线 说明编写本系统设计说明书所依据的设计基线。
2引用文件 本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章也应标识不能通过正常的供货渠道获得的所有文档的来源。 3接口设计 本章应分条描述一个或多个系统、子系统、配置项、手工操作和其他系统部件的接口特性。如果设计的部分或全部依赖于系统状态或方式，则应指出这种依赖性。如果设计信息在多条中出现，则可只描述一次，而在其他条加以引用。如果此信息的部分或全部在别处提供，则此处可以引用。应给出或引用为了理解设计所需的设计约定。 3.1接口标识和接口图 对于1.1中所标识的每个接口，本条应陈述赋予该接口的项目唯一标识符，(若适用)并用名字、编号、版本和文档引用等标识接口实体(系统、配置项、用户等)。该标识应说明哪些实体具有固定的接口特性(因而要对这些接口实体强加接口需求)，哪些实体正被开发或修改(从而已将接口需求施加于它们)。(若适用)可用一个或多个接口图来描述这些接口。 3.x(接口的项目唯一标识符) 本条(从3.2开始编号)应通过项目唯一标识符标识接口，应简要标识接口实体，并且应根据需要划分为几条描述接口实体的单方或双方的接口特性。如果一给定的接口实体本文没有提及(例如，一个外部系统)，但是其接口特性需要在本文描述的接口实体时提到，则这些特性应以假设、或“当[未提到实体]这样做时，[被提到的实体]将……”的形式描述。本条可引用其他文档(例如数据字典、协议标准、用户接口标准)代替本条的描述信息。(若适用)本设计说明应包括以下内容，它们可按适合于要提供的信息的任何次序给出，并且应从接口实体角度指出这些特性之间的区别(例如数据元素的大小、频率或其他特性的不同期望)。 a.接口实体分配给接口的优先级别； b.要实现的接口的类型(如：实时数据传送、数据的存储和检索等)；
<项目名称> 需求规格说明书 腾讯科技（深圳）有限公司版权所有侵权必究
修订记录
目录 修订记录 (2) 目录 (3) 1前言 (4) 1.1文档目的和范围 (4) 1.2参考文献 (4) 1.3术语表 (4) 2总体描述 (4) 2.1业务执行角色 (4) 2.2运行环境 (5) 2.3设计和实现上的约束 (5) 2.4整体流程/逻辑关系 (5) 3特性 (5) 3.1特性F MMM F EA TURE (5) 3.1.1特性描述 (5) 3.1.2功能性需求(Functional Requirements，FR) (6) 3.1.2.1Fmmm.FR.nnn 功能需求1 (6) 3.1.3性能需求（Performance Requirements，PR） (6) 3.1.3.1Fmmm.PR.nnn 性能需求1 (6) 3.1.4用户界面（User Interface，UI） (6) 3.1.5接口需求（Interface Requirements，IR） (6) 3.1.6安全性需求（Security Requirements ,SR） (7) 3.1.7国际化需求(Internationalization Requirements,I18NR ) (7) 3.1.8数据统计需求(Date Statistic Requirements，DSR) (7) 3.1.9其他需求 (7) 3.1.10该特性受限时的用户体验 (7) 3.2特性F MMM F EA TURE (7) 4附录 (8)
说明：本文中蓝色斜体字体为说明性文字，写文档时请删除。 1前言 1.1文档目的和范围 1)文档目的:本文档针对 **系统/模块的目标、范围的描述，以此作为系统选型、设计、 开发和实施的依据。 2)范围：软件产品名称标识 ****。说明产品将干什么，若需要还将说明产品不干什么。 1.2参考文献 说明：列出本文档的所有参考文献（可以是非正式出版物）； 格式如：[标识符] 作者，文献名称，出版单位（或归属单位），日期；参考网址则列出URL。 1.3术语表 说明：列出本文档中所用到的专门术语的定义和缩略语的全称和解释。 2总体描述 2.1业务执行角色 说明：阐述本产品的各种角色及其相应的活动或权限。各种角色的具体行为将在功能性需求中描述。如QQ会员、蓝钻、黄钻用户等
1 引言 1．1编写目的 说明编写这份详细设计说明书的目的，指出预期的读者。 1．2背景 说明：a．待开发软件系统的名称 ；b．本项目的任务提出者、开发者、用户和运行该程序系统的计算中心。 1．3定义 列出本文件中用到专门术语的定义和 外文首字母组词的原词组。 1．4参考资料 列出有关的参考资料，如：a．本项目的经核准的计划任务书或合同、上级机关的 批文；b．属于本项目的其他已发表的文件；c．本文件中各处引用到的文件资料，包括所要用到的软件开发标准。列出这些 文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。 2 程序系统的结构 用一系列图表列出本程序系 统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间的层次结构关系。
3 程序 1（标识符）设计说明从本章 开始，逐个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。对于一个具体的模块，尤其是层次比 较低的模块或子程序，其很多条目的内容往往与它所隶属的上一层模块的对应条目的内容相同，在这种情况下，只要简单地说明 这一点即可。 3．1程序描述 给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且，还要说明本程序的特点 （如是常驻内存还是非常驻？是否子程序？是可重人的还是不可重人的？有无覆盖要求？是顺序处理还是并发处理卜…．．等 ）。 3．2功能 说明该程序应具有的功能，可采用IPO图（即输入一处理一输出图）的形式。 3．3性能 说明对该程序的全部性 能要求，包括对精度、灵活性和时间特性的要求。 3．4输人项 给出对每一个输入项的特性，包括名称、标识、数据的类型和格 式、数据值的有效范围、输入的方式。数量和频度、输入媒体、输入数据的来源和安全保密条件等等。 3．5输出项 给出对每
文档编号： 项目名称 XXXX CSCI详细设计说明书 单位名称 XXXX年X月
修改记录
1 范围 1.1 标识 1.2 CSCI 概述 1.3 文档概述 2 引用的文档 3 CSCI 设计 3.1 CSCI结构 3.2 CSCI运行组织 3.3 CSCI性能要求 3.4 CSCI设计限制和约束 3.5 CSCI测试计划 4 CSC 设计 4.x CSC的名称和唯一标识符 4.x.y 下一级CSC的名称和唯一标识符 4.x.y.z CSU的名称和唯一标识符 5 CSCI数据说明 5.1 CSCI内部数据元素 5.2 CSCI外部接口数据元素 6 CSCI数据文件 6.1 CSC和CSU数据文件的交叉引用 6.x数据文件名和唯一标识符 7 需求可追踪性
1.1 标识 【系统背景】 系统标识符：（系统标识符） 系统名称：（系统名称） 缩写：给出系统的缩写 【适用的CSCI】 标识符：（CSCI标识符） 名称：（CSCI名称） 缩写：给出CSCI的缩写 1.2 CSCI 概述 【系统功能概述】 简要描述本系统的功能。 【CSCI功能概述】 （给出CSCI在需求规格说明书中对应的需求规格标识号的引用）。 如有必要可用图示表示本CSCI在系统中的位置（顶层系统结构图）。1.3 文档概述 【用途】 本文档用于描述在进行CSCI详细设计中每个阶段的设计结果，提供CSCI 的详细设计说明书。 【内容】 本文档的主题内容如下： 描述CSCI的功能和作用； 定义CSCI的结构（用一组CSC，以及这些CSC之间的接口关系，定义CSC 的名称，标示符，分配的需求集）； 定义CSCI设计限制； 定义CSCI资源使用设计； 定义CSCI每个CSC以及CSU的详细设计。 描述每个CSC可追溯的需求规格和接口规格说明。
媒讯集团 EAS 项目 CTC与 EAS接口需求及设计说明书 文档作者： 创建日期：2013-05-10 确认日期： 当前版本： 拷贝数量：1 审批签字: 客户方： 实施方：
文档控制 修改记录 日期作者版本参考版本备注
目录 1.概述错误 !未定义书签。 读者错误 ! 未定义书签。 图例错误 ! 未定义书签。 目的错误 ! 未定义书签。 二、业务现状错误 !未定义书签。 三、概要设计错误 !未定义书签。 接口通讯方式错误 !未定义书签。 通讯内容定义错误 !未定义书签。 媒讯 CTC系统提供接口使用范例错误!未定义书签。 金蝶 EAS提供接口使用范例错误!未定义书签。 媒讯 CTC系统提供接口服务地址错误!未定义书签。 金蝶 EAS提供接口服务地址错误!未定义书签。 接口需求错误!未定义书签。 四、详细设计错误 !未定义书签。 EAS接口错误!未定义书签。 概述 金蝶与用户及用户业务系统方通过多次讨论，制定了接口开发需求设计说明书，作为双方后续开发指引。读者 本文读者对象为业务管理人员、系统设计、开发人员、测试人员。
图例 本文中如未进行特殊说明，各图标代表的含义如下： 表示一个活动； 表示动态的业务数据，如系统单据； 表示流程走向； 表示条件判断、流程分支； 表示静态的业务数据，如基础资料； 表示系统外一个手工处理活动； 表示系统外手工填制的单据； 表示当前系统之外的活动； 表示当前系统之外产生的业务数据。 目的 本文档是媒讯 CTC系统与 EAS 系统接口的需求及设计方案相关文档，可用于指导开发、测试工作和作为验 收相关依据文档。 二、业务现状 待补充 三、概要设计 接口通讯方式 金蝶 EAS与媒讯 CTC系统之间通讯采用WebService方式进行数据传输。 通讯内容定义 对于记录型的大对象，在通讯时，采用 String 型的 xml 格式的参数进行传递。对于其他非记录型的对象，在通讯时，可采用非xml 格式的参数进行传递，也可使用多个参数。具体格式，请参照每个接口的通讯用例说明。 媒讯 CTC系统提供接口使用范例 待补充。