现在管理软件项目中接口需求很多，很多项目接口实现得并不理想，原因就在于接口协议质量不高，而接口协议是和接口调研紧密相关的。一般接口调研和其它调研方法是一样的，但要做好接口调研就必须具备一定的专业知识，这可能是能否做好接口调研的关键。
接口协议除一般性协议要素外，应该包括如下内容：
一、 接口技术实现方式
接口方式最高级一种是主动式。
即通过直接对其它软件的数据库进行操作。这种方式因为涉及到对用户数据读写操作，对于对方软件而言，安全性是最大的问题，验证的复杂程度也最高。主动式基本有两种方式：
1)DATA方式，通过数据库语言对数据库进行直接读写。这种情况要求对对方数据有详细认识。需要对方的人员可以提供数据库的详细资料。为了保障数据的安全，要界定对读写要求。一般和用户自行开发的系统会比较多出现此类要求，商品化ERP很少提出这种方式。
2)利用其它软件提供的工具。除了直接对数据进行读写外，有些软件也提供了一些工具(可能是控件，函数，脚本等)。可以通过这些工具对数据库进行操作。例如现在神州数码易飞ERP就全部采用控件方式接口。
这种情况下要提供这些工具的详细使用说明。
接口方式相对主动式的就是被动式开放。
同主动式对应，即开放软件商自己的数据库或开发接口给其它供应商读取数据。这种方式涉及到软件商提供的数据或开发程序。对方要我们的哪些数据，将成为了解需求的重点。按提供方式的不同可以分为以下四种。
1)DATA方式。即开方我们的文件或数据库格式给对方。由对方软件直接读取数据。这样的情况一般在企业有开发能力，而且只需要信息提取(不是写入)时才使用。这种情况很少。
2)脚本方式。早期的脚本语言，多是一种专用高级编程语言。实现了基本的程序流程语句，简单的数据结构，在此基础上，提供访问软件内部数据的语句。通过这类专用语言，用户可以对程序进行界面配置，实现简单的功能扩展，给用户提供了一定的灵活性。而只需用户懂一点程序设计知识即可。这类语言的缺点是没有通用性，功能有限，由于解释执行，速度受到很大限制，并且应用软件开发商实现专用编程语言及调试环境有较大难度。对于应用程序，需实现三个要求，就可拥有脚本语言编程接口：
A)应用程序的对象模型
B)适合应用程序对象模型的对象
C)脚本语言编程引擎
前面两个方面，需要应用程序用组件对象模型的方式构造。采用组件方式，是软件开发的发展方向，提供对象模型是一件很自然的事情。第三个方面，有通用脚本语言编程引擎供选择，微软的ActiveX脚本编程引擎可以免费使用，VBA脚本引擎需要购买。ActiveX脚本引擎实现了基本功能，没有调试环境。VBA是一种通用编程语言，其核心就是应用广泛的VB，拥有大量函数支持，窗口编辑能力，强大的调试环境。很明显，微软希望VBA成为应用软件二次开发的通用语言。例如CAPP和国外PDM的接口就属于这种开放方式。
3)链接库方式。基于结构化的软件，可以提供软件内部使用的动态连接库，供用户使用。动态连接库是速度最快的接口，应该说是一种很好的选择，CAPP目前的二次开发接口就属于动态连接库方式。
但是动态连接库在接口升级时会遇到麻烦，用户程序难以和正在运行的应用程序进行数据交换。用户也难以使自己的模块(用户实现的动态连接库)嵌入应用程序。因为动态连接库的通常首先实现的(至少要定义输出函数接口)，而后才能使用动态库。但应用软件开发时，用户实现的动态库根本不存在，AutoCAD的ObjectARX用一种特殊的机制，才使AutoCAD可以使用用户开发的动态库。目前国内很多AutoCAD二次开发软件，就是使用ObjectARX开发的，可以完全的嵌入AutoCAD。
4)COM组件方式。COM对象接口：基于组件对象模型的软件，可以提供软件的COM对象接口。组件应用程序由多个组件打包而成，组件之间的联系是一种松散耦合，使其中某个组件的改变不影响其他组件，应用程序修改，改进变得方便。这就如同一台复杂的机械设备的各种零部件用螺栓连接起来，零部件可以轻易更换。而传统应用程序就像所有零部件都通过焊接连接的，如果要改进，只能重新做一个新的。组件程序由于由许多具有位置透明性(无需知道组件的位置)的组件构成，可以很容易实现分布式应用。组件架构强调实现对象模型，开发接口是基于对象的，符合用户的思维方式，比动态库提供的API，更易于理解，使用。组件是完全与语言无关的,任何过程性语言够可以用来开发组件，根据不同的需求，可以轻易的用不同语言开发应用程序的不同部分，用户可以选择任何过程性语言做二次开发。通过COM的底层机制，可以访问运行中的应用程序对象，实现与运行中程序交换数据。用户组件也可以易于嵌入应用程序中。COM的主要问题是，运行速度比动态库慢，特别是自动化接口；对系统稳定性要求高于动态库，要求系统的COM平台能正常工作。
最常用也是最安全，成本最低的接口方式是中间文件接口。
双方的数据交流通过中间文件进行。这种方式由于比较灵活，接口双方都比较明确工作。而且重要是的，接口双方的软件升级，对于接口本身(对方软件本身)可以说没有影响。是目前采用较多的接口方式。
如果是中间文件的还需要确定是全量式接口还是增量式接口。
接口本身是为了双方数据可以保持交流和数据一致性进行的。一方提供数据，另一方根据对方的数据来更新自己的系统的数据。所以对于哪些信息是新加，哪些是删，哪些是更新要进行判断。从数据提供方而言可以提供以下几种：
全量：按软件数据内的数据提供全部的数据，不进行区分哪些是增，哪些是删。这种方式需要用户对比自己内部的数据进行区分哪些是增，哪些是删。
增量：由数据提供方进行对比后，区分哪些数据是要更改的，哪些是要删除的。对方软件根据数据提供方提供的文件直接更新数据库。这种方式的重点是要掌握同什么数据对比，得出增减记录。另外，对不不同的记录(增/减记录)是提供不同的文件，还是在同一文件内对于不同的记录做上标记也是要定义的。此时可能就要在接口字段上定义更改标识，更改单号，版本号等信息。
二、 接口内容
接口方式一旦确定，就需要确定接口的内容。
接口内容首先要确定接口入口，从哪里开始汇总接口数据，接口数据每次包含多少对象，这些对象是如何联系在一起的。例如接口数据每次都从一个完整的产品上开始汇总，或者从一个完整的工程任务上开始汇总，或者从任意零部件上都可以发起汇总。
第二接口内容要确定接口时机，要明确哪些字段由数据提供方(其它系统)写，那些读，在什么时候进行。也就是约定当数据达到怎样的规定后才可以启动接口输出，此时也可以约定接口输出负责人员。例如当产品结构发布，相关工艺数据也发布后才能启动接口，如果有明确接口时机要求，接口程序应适当做校验性判断，防止提供不正确的数据给下游系统。
第三接口内容要确定接口格式。
接口格式包括明确数据交换提交的方式：是文件级还是数据库级，然后明确交换文件的名字，存盘路径。
明确文件的格式，包括文件或数据表包含的字段名，字段次序，字段类型，字段长度，分隔符(如是文本文件)，是否必填，默认值，下游系统对应含义，实际数据样例，接口对应数据来源，该字段在实际操作中填写规则。
第三接口内容要确定接口样例。
接口技术协议附件必须包括用户方提供的样例数据，样例数据必须具备典型特性，能够覆盖企业各种可能的实际数据情况，保证验证样例数据对接口测试的完整性；
如果一个样例不能覆盖可以提供足够样例数据，用户方可提供多个样例，直到可覆盖各种可能情况为止。
用户方要保证样例数据的规范性。此时可能还需要针对接口样例提供数据规范性录入操作说明。
依据所提供样例最终得到的接口中间文件将以完整实例作为验证标准依据。如果有多个样例，则需提供多个完整的接口中间文件实例。准备接口样例将大大加快验证时间和接口程序调整反复时间，也有利于企业，供应商快速就接口协议达成一致性理解，是看起来慢，实际上最快的有效接口方式。
接口数据的一致性通握手方式来保障。一致性分为静态一致性，动态一致性，双向一致性。
静态一致性：如物料编码信息，原始工艺设计信息。
动态一致性：如设计match更改信息，在一个系统内的数据更新后，要求另一个系统内的数据也要进行相应的处理。握手方式即明确如何让对方系统得到要进行更改的信息(也可能是依靠人员来进行手工操作)，这样对方系统对接口文件进行处理。
双向一致性：复杂的系统甚至要求，对方系统处理的数据结果要进行反馈。从而更新本身系统的数据。这里面也要对反馈进行定义。
