In the sea of non-functional requirements, interoperability is defined as how easily a system can share information and exchange data with other systems and external hardware.
Interoperability is often overlooked, much like other non-functional requirements because analysts and stakeholders often focus on the application’s functional requirements rather than the semantics of information. However, interoperability can play a crucial role in the final product, and overlooking these requirements can cost valuable time.
I have seen multiple projects delayed as a result of poor interoperability requirements. In one recent case, I witnessed the results of a poorly defined ETL process, which led to data never reaching the receiving system. The information was not being transformed correctly, which prevented the receiving system from processing it. It took almost a month to resolve that issue alone.
Breaking Down Interoperability
Considering how crucial these requirements can be, it’s important to ask some key questions as you build them.
-
Hardware Interoperability
What hardware must connect to the system? Does the software need to run on different types of devices (mobile vs. PC)? How about different types of equipment (ex. “system must be backwards compatible with credit card machines generation 1.001-3.003”)?
-
Information Interoperability
How easily must information move from one system to another? Must it be seamless and on demand, or can information be shared on a scheduled basis? Must the applications share the same data format or can an ETL process be used?
-
Technical Interoperability
How are other technical services shared? Determining these requirements is important, because applications are often maintained differently in a development environment than in a production one. For example, can application A and B share the same server, or does “A” require its own due to special technical circumstances?
-
Business Interoperability
What business processes are shared? If both payroll accounting and cost accounting use different software (yes, this exists), and both must access employee timecard information, then that highlights potential information interoperability requirements.
Interoperability requirements are often intertwined with other requirements as well, so the key becomes thinking about how the software will interact with other software and hardware components. An example of this is evident in security, because if one system works with an encrypted data stream then by nature your software may also be forced to encrypt data in order for the receiving system to accept it.
Therefore we must keep in mind the complexity and level of system interactions, and remember that visual models can often assist in decoding non-functional requirements like interoperability (ex. Information Interoperability via Ecosystem Maps).
