Interface control document
   HOME

TheInfoList



OR:

An interface control document (ICD) in
systems engineering Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design, integrate, and manage complex systems over their enterprise life cycle, life cycles. At its core, systems engineering util ...
and software engineering, provides a record of all interface information (such as drawings, diagrams, tables, and textual information) generated for a project. The underlying interface documents provide the details and describe the interface or interfaces between
subsystems A system is a group of interacting or interrelated elements that act according to a set of rules to form a unified whole. A system, surrounded and influenced by its environment, is described by its boundaries, structure and purpose and expressed ...
or to a
system A system is a group of Interaction, interacting or interrelated elements that act according to a set of rules to form a unified whole. A system, surrounded and influenced by its environment (systems), environment, is described by its boundaries, ...
or subsystem.


Overview

An ICD is the umbrella document over the system interfaces; examples of what these interface specifications should describe include: * The inputs and outputs of a single system, documented in individual SIRS (Software Interface Requirements Specifications) and HIRS (Hardware Interface Requirements Specifications) documents, would fall under "The Wikipedia Interface Control Document." * The interface between two systems or subsystems, e.g. "The Doghouse to Outhouse Interface" would also have a parent ICD. * 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 An application layer is an abstraction layer that specifies the shared communications protocols and Interface (computing), interface methods used by Host (network), hosts in a communications network. An ''application layer'' abstraction is speci ...
of the OSI model) would each be documented in the appropriate interface requirements spec and fall under a single ICD for the "system". The purpose of the ICD is to control and maintain a record of system interface information for a given project. This includes 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 documented in their respective interface requirements specifications, while human-machine interfaces might be in a
system design Systems design interfaces, and data for an electronic control system to satisfy specified requirements. System design could be seen as the application of system theory to product development. There is some overlap with the disciplines of system an ...
document (such as a
software design document A software design description (a.k.a. software design document or SDD; just design document; also Software Design Specification) is a representation of a software design that is to be used for recording design information, addressing various de ...
). Interface control documents are a key element of
systems engineering Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design, integrate, and manage complex systems over their enterprise life cycle, life cycles. At its core, systems engineering util ...
as they control the documented interface(s) of a system, as well as specify a set of interface versions that work together, and thereby bound the requirements.


Characteristics

An
application programming interface An application programming interface (API) is a way for two or more computer programs to communicate with each other. It is a type of software interface, offering a service to other pieces of software. A document or standard that describes how t ...
is a form of interface for a software system, 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 and interface specs (or their equivalent) is a worthwhile investment. An ICD should only describe the detailed interface documentation 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 requirements and design documents as needed. 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 and associated interface documentation 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 interface 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 interface requirements specification.) Thus, good modularity and abstraction leading to easy maintenance and extensibility are achieved.


Criticism

Critics of requirements documentation and systems engineering in general often complain of the over-emphasis on documentation. 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.


References

{{reflist Application programming interfaces Systems engineering