A formal document characterizing an interface. As a formal document, the ICD typically exists only when two legally distinct organizations must coordinate on the development of items that must coexist to some degree of interest to a contractual customer shared by both organizations.
Usually, the “common customer” is a CRAD customer of both organizations, and has formally directed the two to form an ACA for the purpose of coordinating their work. A series of meetings will ensue, and both will submit contractual changes to their contract holder. The changes delineate which of the two will do what types of work with regard to the I/F. The contract holder is responsible for reviewing both changes in order to determine that all of the appropriate work will be performed, and that the provisionally-agreed-to work split is within the capabilities of all parties, subsequently issuing contractual authorizations to proceed.
ICD’s are slow and expensive to develop, requiring the multi-lateral negotiation of sometimes extreme minutiae. Therefore, they’re typically reserved where the two (or more) parties involved are separate legal entities. More recent practices create ICD’s at the drop of a hat. I speculate that the increased number of paper shufflers somehow increases somebody’s profit margin.
ICD’s exist in multiple flavors to service different developmental phases and situations. See IDD, IRS, IRD, and Unilateral ICD.