Interface Control Document
Encyclopedia
An interface control drawing or interface control document (ICD) in systems engineering
and software engineering
, describes the interface of interfaces to a system
or subsystem.
The purpose of the ICD is to communicate all possible inputs to and all potential outputs from a system for some potential or actual user of the system. The internal interfaces of a system or subsystem are typically not documented in an ICD, but rather in a system design document (such as a software design document).
Interface control documents are a key element of systems engineering
as they define and control the interface(s) of a system, and thereby bound its requirements.
is a form of ICD, in that it describes how to access the functions and services provided by a system via an interface. If a system producer wants others to be able to use the system, an ICD (or equivalent) is a worthwhile investment.
An ICD should only describe the interface itself, and not the characteristics of the systems which use it to connect. The function and logic of those systems should be described in their own design documents if required. In this way, independent teams can develop the connecting systems which use the interface specified, without regard to how other systems will react to data and signals which are sent over the interface. For example, the ICD must include information about the size, format, and what is measured by the data, but not any ultimate meaning of the data in its intended use by any user.
An adequately defined ICD will allow one team to test its implementation of the interface by simulating the opposing side with a simple communications simulator. Not knowing the business logic of the system on the far side of an interface makes it more likely that one will develop a system that does not break when the other system changes its business rules and logic. (Provision for limits or sanity checking should be pointedly avoided in an ICD.) Thus, good modularity and abstraction leading to easy maintenance and extensibility are achieved.
. ICDs are often present on "document-driven projects," but may be useful on agile projects
as well (although not explicitly named as such). An ICD need not be a textual document. It may be an (evolving) table of goes-intos and comes-out-ofs, a dynamic database representing each subsystem as a DB view, a set of interaction diagrams, etc.
ICDs are often used where subsystems are developed asynchronously in time, since they provide a structured way to communicate information about subsystems interfaces between different subsystem design teams.
Systems engineering
Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed over the life cycle of the project. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more...
and software engineering
Software engineering
Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software...
, describes the interface of interfaces to a system
System
System is a set of interacting or interdependent components forming an integrated whole....
or subsystem.
Overview
An ICD may describe- the inputs and outputs of a single system, e.g. "The Wikipedia Interface Control Document."
- the interface between two systems or subsystems, e.g. "The Doghouse to Outhouse Interface Control Document."
- the complete interface protocol from the lowest physical elements (e.g., the mating plugs, the electrical signal voltage levels) to the highest logical levels (e.g., the level 7 application layer of the ISO model), or some subset thereof.
The purpose of the ICD is to communicate all possible inputs to and all potential outputs from a system for some potential or actual user of the system. The internal interfaces of a system or subsystem are typically not documented in an ICD, but rather in a system design document (such as a software design document).
Interface control documents are a key element of systems engineering
Systems engineering
Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed over the life cycle of the project. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more...
as they define and control the interface(s) of a system, and thereby bound its requirements.
Characteristics
An application programming interfaceApplication programming interface
An application programming interface is a source code based specification intended to be used as an interface by software components to communicate with each other...
is a form of ICD, in that it describes how to access the functions and services provided by a system via an interface. If a system producer wants others to be able to use the system, an ICD (or equivalent) is a worthwhile investment.
An ICD should only describe the interface itself, and not the characteristics of the systems which use it to connect. The function and logic of those systems should be described in their own design documents if required. In this way, independent teams can develop the connecting systems which use the interface specified, without regard to how other systems will react to data and signals which are sent over the interface. For example, the ICD must include information about the size, format, and what is measured by the data, but not any ultimate meaning of the data in its intended use by any user.
An adequately defined ICD will allow one team to test its implementation of the interface by simulating the opposing side with a simple communications simulator. Not knowing the business logic of the system on the far side of an interface makes it more likely that one will develop a system that does not break when the other system changes its business rules and logic. (Provision for limits or sanity checking should be pointedly avoided in an ICD.) Thus, good modularity and abstraction leading to easy maintenance and extensibility are achieved.
Criticism
Critics of ICDs and systems engineering in general often complain of the emphasis on documentation. ICDs are often present on "document-driven projects," but may be useful on agile projects
Agile software development
Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams...
as well (although not explicitly named as such). An ICD need not be a textual document. It may be an (evolving) table of goes-intos and comes-out-ofs, a dynamic database representing each subsystem as a DB view, a set of interaction diagrams, etc.
ICDs are often used where subsystems are developed asynchronously in time, since they provide a structured way to communicate information about subsystems interfaces between different subsystem design teams.