A system transforms its inputs into its outputs.

• The inputs must come from somewhere; in the systems perspective, they always come from some other system (in the form of that other system's outputs).
• Similarly, system outputs are made available to other systems (and become those other systems' inputs).
• The collection of all the inputs and outputs of a system define its interfaces.

Fig. 1: A schematic model of systems, interfaces, and boundaries.

In figure 1, we have a schematic model of how two systems “connect”¹⁾.

• Each system has interfaces (the small coloured boxes).
• Between the interfaces is the system boundary.
• For each interface in System 1, there is a corresponding interface in System 2; this is shown in figure 1 by corresponding colours.
• Each matching pair of interfaces represents one flow of mass, energy, or information across the boundary.
• So, two systems share one boundary across which many flows can occur, and each flow must have matching interfaces in each system.

Since systems are black boxes²⁾, we do not know or care how a system provides its interface; we only really care about the interface itself.

• For instance, so long as the “engine” of a car safely provides sufficient power to satisfy the needs of the driver and the other systems in the car, does it really matter if the engine is driven by internal combustion, or a fuel cell, or a Mr. Fusion? (Spoiler: no, it doesn't.)

In engineering design, we only care about three principal types of interfaces: mass, energy, and information. There are other types of interfaces that may concern other specialists, but we do not need to worry about them.

Interfaces are functional in nature, not behavioural. That is to say, they describe, in quantitative terms, the purpose for the input or output³⁾.

• For instance, if we consider our elevator example (e.g. as discussed in product systems), we can think of the various commands that a user might wish to send to the elevator system. We would phrase these commands not as pushing buttons, but rather by the intent behind pushing the buttons.

Interfaces let us describe what a system is supposed to do to be useful as an element of a larger system.

• An engine that cannot provide enough power to your car is useless.
• A computer that requires electricity at a difference voltage than that available is useless.
• An umbrella that does not sufficiently cover you is useless.
• A stapler than hurts your hand when you use it is useless.

These are just some examples of products with mismatched interfaces for the situations in which they are to be used.

• It doesn't matter how good the product is otherwise, if there is a mismatch or imbalance between the interface it provides and the interface expected by other systems, then that product is useless (if not harmful).
• Mismatched interfaces are a kind of flaw that can lead to interaction errors or product failures.

Furthermore, as we recurse down to lower, more detailed levels of a design project, each preceding level of user interface provides the foundation for the requirements we will need at the lower, more detailed levels.

• For instance, higher level user interfaces in the design of a kitchen blender (plus knowledge of various technologies and natural laws) will lead to requirements about the quality and quantity of electric energy that has to be accommodated by the blender's plug.

Finally, quantitative specifications of system interfaces will also be essential in the next stage of the design process (concept design) when we seek out ways to implement the functions that the systems have to provide, because the quantity of flow through an interface will help us decide what technologies we can use to implement those interfaces.

Since design is about solving existing problems (or improving identified imbalances), we can only specify interfaces when we know what systems will be interacting, and why they will interact. It is best, then, to first identify interacting subsystems, and then figure out exactly how those subsystems will interact, constrained by the requirements of the problem and the product strategy for the project.

Because of the richly interconnected nature of system interfaces, specifying them is a task that is best done as a team exercise, with everyone present.

Also, because systems are functional units, interface specification should be done before concept design, when embodiments are developed. (Indeed, coming up with good embodiments rather depends on there being well-defined system interfaces.)

Fig. 2: A system diagram of an elevator system just before starting to specify interfaces.

We specify interfaces on system diagrams, where we can graphically show the flows, in conjunction with supporting documentation. Assuming you have already identified what the inputs and outputs are to your overall system, there are three steps to specifying interfaces:

1. draw appropriate arrows on your system diagram,
2. quantify the interfaces, and
3. add any supporting documentation you think is necessary to explain your decisions.

Each of these is described below.

The first step is to draw arrows on your system diagram denoting the various flows.

Matter and energy can be neither created nor destroyed, so every bit of mass and energy that goes into your system must come out somehow. Information, on the other hand, can be completely “consumed” (or “created”) by a system.

Consider figure 2.

• On the left side you see the various inputs to the overall elevator system; on the right side, you see the various outputs from it.
• Since all of the functions of the elevator system are provided by one or more of its subsystems, every input arrow to the elevator must pass through at least one subsystem before exiting as an output.

The designer's job is to figure out how to route each flow through the subsystems till it comes out as an output.

There are two ways to figure out the routing of the flows through the system.

1. Go through each input in turn, deciding how best to route that input through the subsystems till it gets to one or more outputs.
2. Use your usage scenarios, situated use cases, and interaction error charts as guides. Step through each element of each scenario, case, or chart, deciding at each step what flows must exist within the system for the system to function, and drawing them in the system diagram.

You must use both methods to help ensure that you have identified all the significant flows.

Fig. 3: A relatively complete [[system diagram]] showing the principal interfaces between subsystems for an elevator.

One possible architecture for the elevator system is shown in figure 3.

• There are many possible architectures for any system. There is not just one right answer. Your job as designers is to find the best one you can, and to be able to justify that architecture.

Some notes on figure 3 are in order.

To keep the system diagram tidy, label each flow with a number ID, as in figure 3. You then use a separate sheet or sheets to describe each flow in detail.

Consider the user commands information input in figure 3. You can develop a complete list of every possible user command that any user, as exemplified by your personas and usage scenarios, could ever need to “tell” the elevator system.

• These commands must be functional in nature.
  • Push the “up” button would be incorrect, because it assumes you've already decided the elevator will have buttons.
  • Call the elevator to go up would be correct, because it describes the function (to “call” the elevator).
• These commands go to the User Interface subsystem for processing.
• The output of that processing is feedback to users, which must also be exhaustively defined.
• The exhaustive definitions are done in the next step, when you quantify the interfaces.

Consider the User Interface subsystem. In addition to receiving commands and produces feedback to users, it also sends commands to, and receives feedback from, the Control System.

• This two other flows not the same as user commands and feedback.
  • A user command might be implemented as the push of a button sending a small current to a particular port on an electronic board.
  • That board will likely then produces a different signal to the Control System electronics, one that the Control System interprets in a specific way. This information could be completely different from the information exchanged between the User Interface and the users.

Obviously, not all the details of the interfaces will be known at the beginning of the design process.

• The specification of interfaces will therefore change as the design evolves.
• One must be very careful not to over-specify the interface too early in the design process.
  • Every element of the specification is equivalent to making a decision, and every decision in a design must be justifiable.
  • Just choosing a specific format out of thin air for the commands is not acceptable; there must be a good reason for making that choice.
• One should nonetheless keep the latest and best information available for each interface, and revisit those specifications regularly to make sure it reflects the latest decisions you make about the design.

The electricity input splits three ways within the boundary of the elevator system.

• This means that the designers expect a single supply of electric power to be made available for the elevator, and that the elevator system itself will include components to divide the power safely among the three elements.
• If the split had been specified outside the boundary of the elevator system, then the designers would be specifying that they expect three distinct electrical supplies to be provided on site.
• This is a typical design decision that has implications for your workload, the deliverables of your project, and the extent of your responsibility both legally and, more importantly, ethically.

The mass inputs of air and people & cargo are kept separate because the designers expect to treat air differently from people and cargo.

The three kinds of waste energy output, heat noise friction, are treated as a single output because the designers' experience tells them that these waste energies will be comparable in quantity with respect to the behavioural limits of the system.

• If one or more of these outputs would have been expected to be significant, with respect to the behavioural limits of the system, then the designers would have had to specify separate outputs, to ensure that each waste energy source is handled properly and safely.
• They may yet discover that one or the other of these waste flows is in some way - perhaps ergonomically - so important that it needs to be treated separately; they will have to fix it later.

Given that each flow in a system diagram has a numeric ID, as in figure 3, we can now use a simple numbered list to exhaustively quantify each interface.

Since these interfaces will end up being the foundation of the requirements for the subsequent design of the subsystems, it is very important to quantify the interfaces as crisply as possible.

You may find that some of the interfaces have already been specified in the requirements for your design. In that case, you can just refer to the specific requirement; you should never duplicate information.

When we say “quantify” in engineering design, we are not only talking about quantities that have units, like “3 kg”. In design, quantities can be:

• real-life quantities, such as 30 kg/hr or 120V / 15A / 60 Hz;
• boolean values (true of false); or
• an exhaustive list of symbols denoting discrete entities (like a list of colours specified as RGB values, or our list of user commands for the elevator).

For instance, here is one possible specification of the user commands flow in figure 3 for the elevator system:

This list describes every possible function that a user could request of the elevator.

• Notice we identify the ID of the flow and give a brief textual summary.
• We say nothing about how those functions will be delivered to the user interface.
  • Buttons? Voice? Gestures? A weight sensitive pad on the floor that detects someone standing there for a time and automatically calls the elevator?
• This is not a “vague” specification. It is a very precise functional specification that says nothing about implementation.
• We are not at the point of the process where we decide how to implement these functions, so this is all we can reasonably specify at this stage.

Here is another example, this one for the electricity that powers the lifting system⁴⁾.

While this specification is more than what most student teams would generate, we include this to show the extent of the information that might be needed in real life⁵⁾. Some notes are in order:

• MOST IMPORTANTLY: This is NOT the power needed by the lifting system. This IS the power that is available from the electrical system.
  • This is all you get, because you cannot tell the people designing the building in which your elevator will work that you need more power. They will tell you what they can give you, and you have to design an elevator system that uses no more than that.
• The “cut-in” information indicates how often power can be turned on and off (when the motor is running or not). The duration indicates the amount of time you have to accelerate and decelerate the elevator.
  • This information was probably (hopefully!) determined based on ergonomics and human needs.
• Notice that the available voltage and amperage is given in triplets.
  • The low and high values are the minimum and maximum values that could occur during operation. You will have to design an elevator that is failsafe for that range. The middle value is the standard or steady-state value that you should expect to be the usual operating value.

See the Deliverables section of the PAS.

There are some particular hazards in defining interfaces.

The most significant is in knowing when to branch an input or output, and where to put the branch. Putting a branch within a system boundary implies that the designer of that system bears the responsibility of (and control over) that particular branch. Also, branching (or merging) implies a more physical confluence of the corresponding flows. Any such confluence requires careful thought (as in the example of merging the flows of air and people and cargo in our elevator design).

Another typical mistake is to overspecify an interface by grounding it in physical artifacts or properties that cannot be justified yet. For instance, if you are designing a car, and you have not been constrained to use gasoline to power the car, then it would be a mistake to define a gasoline flow into the car. It would be more appropriate to specify an energy input into the car, because while the car needs energy to work, you have not yet decided exactly how that will be done.