9.2.2 Everything you wanted to know about interfaces, but were afraid to ask

Abstract

Some of the biggest problems in developing a system are at an interface. Some of the most critical requirements for every system that we build are interface requirements. Interface requirements cannot be written in a vacuum, both sides must participate. Yet how to write interface requirements is barely covered in the literature -and what is in the literature is not consistent. This paper will address some things you can do to get better interface requirements. Topics covered include: Understanding what constitutes an interface, how to identify interfaces, how to define and document interface definitions, what constitutes a good interface requirement, and where and how to document interface requirements. 132Examples of misunderstanding what an interface is and is not

Understanding Interface Criticality in Large Infrastructure Projects

“…This treatment of the interface as being a logical object rather than a physical object aligns with the idea of Interface Requirements being applied to the assets on either side of the interface, rather than to the interface itself (Wheatcraft 2010). Typically this means that Interface Requirements come in complementary pairs, with one asset owner being responsible for 'providing' something across the interface, and the other asset owner being responsible for 'receiving' it.…”

“…(Interface Management Implementation Guide 2014) • "a boundary where, or across which, two or more parts interact." (Wheatcraft 2010) • "reflect communications which take place within or between different parties in each project, with the purpose of transferring information or accomplishing a task." (Shokri 2014) • "a common boundary or interconnection between independent but interacting systems, organizations, stakeholders, project phases and scopes, and construction elements."…”

“…The difference in interface definitions above can be explained as concern about different levels of the hierarchy, with some focussed on the softer side (Wren 1967;Shokri 2014;Sanei & Smith 2019) and some with more emphasis on the harder side (Wheatcraft 2010;Pritesh & Konnur 2019;Complex Systems Integration in Railways 2020). Neither of these is necessarily incorrect, and the consideration of the softer interfaces makes sense if this is the starting point in identification of the interfaces.…”

“…There can be a significant difference in the definition of what constitutes an ICD on an infrastructure project, with alternative names or additional documents including: Interface Definition Documents, Interface Requirement Documents, Interface Definition Agreements and Interface Agreement Documents (Wheatcraft 2010). The important underlying need is a medium to document, and gain agreement on, interface details between interfacing (i.e.…”

Documentation-as-code for Interface Control Document Management in Systems of Systems: a Technical Action Research Study

“…On the other extreme, the document-centric one, ICDs are mostly textual documents created with propietary word processing and diagramming tools, which evolve as interfaces are identified, defined, documented, and modified over time [30]. This approach, despite the growing popularity of model-based ones as a response to its limitations, is still widely used in industry [3].…”