If the business requirement is to automate the data flow between two systems – data consumer IT System and data source IT System (a.k.a. source of records – SoR), it must be split to the following items to ease integration implementation for IT folks:

1. Current process and data flow (As-Is)

Detailed description of the business process that includes the steps on how data from SoR system is moved to the current process to be automated. E.g. For new System, data can be copied from the SoR system and pasted into Excel or Word file; for existing System, data can be exported from the SoR system as an “.csv” file and imported into existing System.

2. SoR System

Data Structure, which must be described as a table with the following columns:

• • Record name
  • Type – can be anticipated: Text, String, Integer, Float, Date/Time, List, i.e. Dropdown, Boolean (true/false, checkbox)
  • Reference to SoR System’s storage (e.g. column in database)

Screenshots of SoR System interface with highlighted record. This can help to validate the data during testing and to identify the record in SoR System’s storage (e.g. DBMS). Screenshots can be also from SoR System’s storage if it is already known.

3. Process and data flow requirements for integration (To-Be)

• Data update time requirements (period, time-range, duration) with detailed explanation and reason based on the current process flow.
• Data storage time requirements (e.g. store data for last 12 hours). Since the data consumer system cannot eventually become the SoR system, the data must be removed periodically.
• Selection criteria – ensure that minimal required data is provided limiting it using some criteria, e.g. by date (e.g. no need to get obsolete data) or status (e.g. no need to get records with “deleted” or “archived” status)

4. Timestamp usage

If the data transferred via any broker system (e.g. OSIsoft PI Server or Magnitude Kalido) timestamp is required to know the last synchronization time between broker system and SoR System.

5. Continuous data synchronization

If continuous data synchronization is critical, possibility for alternative ways has to be stated in case of failure of the main data flow detected via the timestamp, for example. Alternative ways can be

• allowing User to manually enter the data (this can lead to risk of entering wrong data that doesn’t exist in SoR System)
• any other automated alternative data flow.

6. Mockups of UI

Mockups of UI of the data consumer system. Simple mockups can be drawn in Visio, more sophisticated – in Balsamiq Cloud or other similar app, ideally – in data consumer system itself if it already exists.

7. Testing specification

Testing specification (if separate testing is required). It is description of the process updated after integration completion.

Good Integration Requirements document will be a solid basis for successful data integration of the systems supporting the next step – operational feasibility analysis.