"The overall process for designing a user interface begins with the creation of different models of system function (as perceived from the outside). The human- and computer-oriented tasks that are required to achieve system function are then delineated; design issues that apply to all interface designs are considered; tools are used to prototype and ultimately implement the design model; and the result is evaluated for quality."

--Roger S. Pressman

Formal Definition and Control of Interfaces

For elements of a system to cooperate in solving a problem, they need to interact. This interaction is called an interface. Interfaces can take many forms. Examples include software, hardware, and user interfaces. Wherever there is interaction, there is an interface that should be described.

In a very real sense an interface is like a bridge. It is a mechanism for transporting things from one place to another. In this case, the "places" that are cooperating are elements of the system. The thing being transported is information. If a bridge is to transport cars over a river, a great of analysis goes into its development. The volume and form of the objects that will cross the bridge are considered in determining how strong and how wide it should be. If people are going to walk or bike over the bridge, special protections are put in place to accommodate them. Once the bridge is built, the limits are clearly posted, so users understand the limitations. Development of an interface follows similar steps.
 
The importance of agreeing to and documenting interfaces has been recognized for years. Over time, specific guides have been developed to facilitate the process of documenting interfaces so that they can be more easily understood. Two data item descriptions (DIDs) that delineate how interfaces should be documented are DI-IPSC-81434, and DI-IPSC-81436). While these DIDs are no longer required as compliance documents in contracts they provide valuable information about how to completely and accurately define an interface.
Just as in the case of a bridge, communication among all the users of a bridge is essential. Because it is difficult to change the design of a bridge after it is started, extensive analysis and information gathering meeting are held before work begins. Similarly, a mechanism must be provided for collecting information on and discussing the requirements.

Interface documents are critically important to all aspects of system development and should be placed under tight configuration control. In addition, each interface specification should undergo a formal inspection before being accepted by CM. A baseline interface must be agreed upon before beginning implementation activities and changes to the interface requires concurrence by all interface owners prior to being made.
 
Project managers must monitor development progress of interfacing systems and identify their key milestones. Where possible, progress of external interfacing systems should not be on a project's critical path. If this can not be avoided, this risk factor must be carefully managed. Implementation schedules and activities must be closely coordinated.
Application external interfaces, interfaces with middleware and operating systems, and interfaces of COTS products integrated into the application should comply with applicable public, open API standards and data interoperability standards unless there is a compelling reason to do otherwise. Each COTS software product should be carefully analyzed, independent of the vendor, for the proprietary features of its interfaces. Often, there is a conflict between the desire to use COTS and the need for interoperability between system. These issues must be carefully weighed in the system design, the selection of COTS/GOTS products and the reuse of legacy code.

top

---