Managing interfaces is a key part of any systems engineer’s job. I recommend that at the beginning of a project, the lead SE name a person to be the “Interface God or Goddess”. This person will chair the Interface Working Group (IWG) and focus on interface management throughout the product development lifecycles. Having this role clearly defined is an importance aspect to being able to deliver a winning product.
Because of the importance of identifying, defining, developing interface requirements, and managing these activities, interfaces need to be a prime concern of the project System Engineer, lead Software Engineer, Business Analysis, or anyone else involved in developing requirements.
Systems are part of other systems, are made up of subsystems, and interact with other systems at the same level of the architecture, no matter what level your system of interest (SOI) is at. This applies to simple as well as complex systems, hardware systems, software systems, and hybrid hardware/software systems. These interactions between your system and others are interfaces.
Identifying interfaces helps you to define your system’s boundaries. Identifying interfaces also helps you understand the dependencies your system has with other systems and dependencies other systems have with your system. Failing to identify an interface can have unpleasant repercussions on your project and is a common reason for products that fail to meet stakeholder expectations. Missing or incorrectly defined interfaces are often a major cause of cost overruns and product failures.
Identifying interfaces helps you ensure compatibility between your system and other systems you need to interact with. Many projects neglect to identify and control their interfaces until testing. The first encounter with the results of this oversight often occurs when people find out that they cannot connect test equipment to their system to perform the tests. Worse yet, think of the problems when you turn your system over to operations and a missing interface is discovered such that your system can not function or another system depending on your system can’t function. By identifying and managing your external interfaces early, you are identifying key drivers for your product that must be addressed in your system requirements.
Identifying interfaces also helps to expose potential problem areas and risks to your project. There are often existing systems that you have to interface with that are established and cannot change – this might be a problem for you – it might not, but you need to know. There may be systems that you have to interface with that don’t currently exist that are being developed in parallel with your system. How can you develop requirements for your system when you don’t know what your interfaces are or the characteristics of those interfaces? You need to know any issues associated with your interfaces early so that you can ensure compatibility with existing systems or work with the other developing system to jointly define the interfaces so you are compatible.
Serious problems can and do arise at interfaces due to the inherent risks associated with a system’s interfaces. Because the interfaces represent systems outside your control, your system is vulnerable at your interfaces. If an interface is not well understood, not defined, or is subject to change, your system will be impacted. There is also the threat of someone outside your system impacting your system’s performance – either intentionally or unintentionally. There is an old saying “If you want to sabotage someone’s system, do it at an interface.”
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. I will send a copy to whoever wants one. Just email me directly at: email@example.com
Comments to this blog are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.Tags: compatibility, identifying interfaces, interface definiitons, interface requirements, Interface Working Group, interfaces, requirement risk, system boundary