We should have requirement capture templates for integration project which to be shared with customer. Smart customer will fill it up or you need to fill it up after discussion with the customer. Normally integration architect fill up the template after discussion with customer. Best way is to have workshop with the customer to understand the requirement and fill up the template. Later you can use the template in URS document or FS document. The spreadsheet comes handy to understand the requirement and subsequently effort estimation.
The template contains message type, security protocol, source system, destination system etc.
To know server location is also important when multi site integration infrastructure is available. i.e you may have integration servers available in Europe, USA. So if source application and target application is in Europe, then you should install the integration processes in Europe. There will be latency in process execution, due to cross Atlantic traffic flow, if you install the processes in US server.
From the interface requirement sheet you can roughly calculate how much process to be developed, what design pattern to be followed. You can use this template to calculate effort and cost to implement the projects.
Following standard template you can refer and share it customer.
Part1
| API Name | Source Connection Protocol | Destination Connection Protocol | Source Application | Destination Application | Location of Source end Point | Location of Destination End Point | Authentication Requirement (Source to ESB/ESB to Destination) |
| Order Master | REST | SOAP | SFDC | SAP | Cloud | EU | Basic/Basic -HTTPS |
| Customer Master | REST | jdbc | CustMG | SFDC | EU | Cloud | Basic/2Way SSL |
| Location | REST | SOAP | SCM | SAP | Cloud | EU | Basic/2Way SSL |
| Contacts | REST | REST | CustMG | OrdMG | Cloud | EU | Message Signing |
| Organization | SFTP | SFTP | SAP | SCM | US | Cloud | Basic/Basic |
| Products | SFTP | Jdbc | SAP | SCM | US | Cloud | Basic/Basic |
| Utilization | SFTP | jdbc | SAP | SCM | US | Cloud | Basic/Basic |
Part2
| Source Payload (xml/json) |
Destination Payload (xml/json) |
Data Enrichment requirement | Data Transformation Requirement | Number of Messages Per day(or TPS)/Files | SLA Response Time Sec | File Size /Message Size | Encyption
Decryption Requirement |
| XML | JSON | two external table lookup | one field numeric to char, system date conversion | 100 per day | 10 sec | 100KB | Yes |
| XML | JSON | One external webservice lookup | system date conversion | 100 per day | 10 sec | 100KB | Yes |
| XML | JSON | two external table lookup | system date conversion | 100 per day | 10 sec | 100KB | No |
| XML | JSON | two external webservice lookup | NA | 100 per day | 10 sec | 100KB | No |
| Text | Text | NA | NA | 5 files per Day | 10 Min | 10MB | No |
| XML | XML | NA | NA | 5 files per Day | 10 Min | 10MB | No |
| XML | XML | NA | NA | 5 files per Day | 10 Min | 10MB | Yes |
Part3
| Exception Handling Requirement | Audit Requirement | Synch/Asynch | Scheduling Frequency | Initial Synch Up requirement | Message Sequencing Requirement | Other requirement |
| Email to Support Team | Email success/failed report by Day end | Asynch, Publish Messages in Q | NA | Yes | Yes | messages to retried to post three times in case of connection failure |
| Email to Support Team | Email success/failed report by Day end | Asynch, Fire and forget | NA | Yes | Yes | |
| Email to Support Team | Email success/failed report by Day end | Synch | NA | No | No | |
| Email to Support Team | Email success/failed report by Day end | Asynch,Fire and forget | NA | No | No | |
| Email to Support Team | No | NA | Daily | No | No | |
| Email to Support Team | No | NA | Daily | No | No | |
| Email to Support Team | No | NA | Weekly | No | No |