There exists some confusion surrounding the relationship between Interface Requirement Documents (IRDs) and Interface Control Documents (ICDs) when defining requirements. This fact is of little surprise to us. In fact, we have done a lot of research in this area and found that there is NO consistency and agreement on how various organizations manage interfaces. Let me explain….
For existing systems, how another system can interface to the existing system should have been already documented. This could be in an ICD or a Technical Data Package.
When two systems are in development, the definition of the interfaces evolve with the design. There is a variety of document names used to document the definition: Evolutionary Interface Control Documents (ICDs), Interface Requirement Documents (IRDs), Interface Requirement Specs (IRSs), Interface Agreement Documents (IADs), Interface Document Agreements (IDAs), Data dictionaries, software development kits, etc. The name is not as important as the content.
Interface definition documents, no matter what the name, should contain only definitions – no “shall” statements!! They are agreements and statements of fact (often identified through the use of “will”). Whether you use “will” or “is” depends on where in the design process you are.
Interface requirements belong in the system requirements set no matter what you call the document. These are the “shall” statements that drive the design and must be verified. A proper interface requirement points to the definition, no matter where defined.
To illustrate the common issues and different viewpoints on interfaces in general and specifically IRDs and ICDs, see the example below given in one of the responses in an online discussion group where this interface management quandary was the topic:
Typical IRDs interface requirements for simple systems:
“1. The motor shall provide mechanical power to the pulverizer through a common shaft.
2.The pulverizer shall accept mechanical power from the motor through a common shaft.
A related ICD will discuss rotational speed, torque, flanges, splines, etc. The ICD will also discuss which side of the interface provides interface hardware like flanges, bolts, nuts.”
This example illustrates why we hate the concept of an IRD as as discussed above. The use of the “R” meaning “requirements” in the IRD title confuses the issue. By using “shall”, each statement is a requirement on one of the interacting system – yet the requirement is not in that system’s requirement document. We feel the IRD is a useless document that contains ambiguous requirements that do not point to the interface definitions – making the statements unverifiable.
We advocate that you include in the ICD (or other interface definition type document – the name doesn’t really matter as long as the document contains only definitions) the detailed definitions and have the interface requirements for both interacting systems included in each of the system’s requirement document point to the common definitions in the ICD.
For example:
Included in the ICD:
1. The mechanical power provided by the motor to the pulverizer will have the characteristics shown in Table xx.xx. Table xx.xx then would define rotational speed, torque, etc.
2. The motor will mechanically connect to the pulverizer through a common shaft as shown in ICD drawing xx.yy. Drawing xx.yy then would contain the information about the interface hardware like shaft, flanges, splines, bolts, nuts, etc.
In the motor requirement document we would have the following interface requirements that point to the agreed-to definitions in the ICD:
1. The motor shall provide to the pulverizer the mechanical power having the characteristics defined in ICD Table xx.xx.
2. The motor shall connect to the pulverizer as shown in ICD drawing xx.yy.
In the pulverizer requirement document we would have the following interface requirements that point to the same agreed-to definitions in the ICD:
1. The pulverizer shall operate using the motor mechanical power having the characteristics defined in ICD Table xx.xx.
2. The pulverizer shall connect to the motor as shown in ICD drawing xx.yy.
Using this approach, all of each system’s requirements will be in one document – their document. Each system is responsible for verifying their interface requirements, maintaining traceability, etc. just as they would for any other system requirement.
For this approach to work, both systems need to work together under the management of a lead Systems Engineer responsible for both systems. All must agree on the definitions in the ICD and both interacting systems need to include the corresponding interface requirements in their requirement document. The interface requirements should trace to each other, a common definition in the ICD, and a common parent.
The parent system will have a drawing showing all the internal interfaces. Each of the interfacing systems will contain a context or boundary diagram showing their external interfaces. The ICD can contain these interface drawings as well.
These drawings establish the fact the interfaces exist. The ICD defines the interactions (nature of the interaction) which include what each system looks like at the interface, what the characteristics are of the thing crossing the interface, and the media involved in the interaction.
The system requirement document then makes it all happen by including the interface requirements that, when implemented, result in the two systems to interact as agreed to.
I go into a lot more detail on managing interfaces in my paper “Everything you wanted to know about interfaces, but were afraid to ask.” I presented this paper at INCOSE several years ago.
