Fil Salustri's Design Site

Site Tools


System Model

A system model is a representation of an existing entity using systems principles.

What is a system model?

You model what already exists, and design what doesn't exist yet. So a system model is a systems-based representation of a complex existing entity, meant to document its function and help understand its operation.

Read about systems before proceeding with this page.

Why do we develop system models?

If we intend to design a complex entity that will interact with other entities, we will benefit by using system design methods. If we use system design methods to design an entity, then it makes sense to also use systems principles to model the current, “as-is” situation to maintain consistency in how we think about the problem we have to solve.

When/Where do we use system models?

System models are most useful when trying to understand the current, “as-is” situation that we want to improve by designing a new intervention. You want to understand quite deeply the current situation so that you can more reliably and crisply describe specific shortcomings in it; these are the shortcomings that you will address with your new design intervention.

As such, system models are an important part of the process of developing the overall requirements of your new design.

To develop a good system model, you will need a reference design, and a good understanding of your users (i.e., user groups and personas), plus overall goals (typically derived from a design brief).

  • TODO Domain of problems that succumb.
  • TODO Describe unbalanced forces that can be addressed.
  • TODO Inputs: what's needed to generate concept / execute method.
  • TODO Examples of typical situations.

How do we develop system models?

General method

Make sure you read about systems before continuing.

You generally won't be able to develop a finely detailed system model, but that's okay. It's more important to understand the main features of the current situation than its minutiae, especially in scholastic settings.

Furthermore, remember that system models are functional in nature - they must describe function of entities in the situation, not structure.

A suitable system model for an existing situation will include:

  • the major systems within the reference design,
  • the major co-systems of the reference design, with which the reference design will interact, and
  • all the most significant flows of mass, energy, and information - both desirable and undesirable - between those system elements.

You will need to develop a system diagram that includes the systems listed above, and specify the system interfaces between the elements in that diagram. The diagram and interface specification constitute the deliverables of a system model for our purposes.

Example: system model for a stapler

upload.wikimedia.org_wikipedia_commons_thumb_2_2d_swingline-stapler.jpg_512px-swingline-stapler.jpgFig. 1: A conventional stapler (by Evan-amos (Own work) [Public domain], via Wikimedia Commons")

Consider the design of a stapler; assume figure 1 is our reference design. Since structure does not matter when developing systems models for our purposes, we need to intuit what functionality we can from images and other information we can about this stapler.

Given that the stapler itself is a system in our model, we can infer - i.e., just think it through logically by looking up information about staplers and thinking about how users would actually use such a stapler - the following function subsystems:

  • structural system: in charge of supporting and resisting internal and external physical loads.
  • loading system: a way to add fresh staples to the stapler.
  • stapling system: a way to apply a staple to a set of papers.
  • storage system: a way to store staples within the stapler before use.
  • user interface: a way for a user to “activate” and provide power to the stapler to do its job.

Notice how each of these systems describe what they do, and make no reference to the structures/parts/assemblies needed. The point of the system model is to capture only the function of the reference design.

Besides these systems, there are co-systems - other systems outside the stapler that will interact with it. The nature of these systems will be different depending on the kinds of situations implied by the design brief. For instance, the co-systems to be modelled if your goal is to design a way of fastening papers at the loading dock of a warehouse will be different than the co-systems if the situation is “for home-office use.”

If we assume the design brief is focussed on home-office use, then some of the significant co-systems could be:

  • desk or coffee table on which the stapler will be used;
  • the user's children, who may decide to “use” the stapler for atypical purposes;
  • spare staples stored in a desk drawer to be used to refill the stapler;
  • mugs of coffee, glasses of wine or beer in the vicinity of the stapler;
  • laptop computer;
  • stacks of paper;
  • a certain amount of light from lighting and from windows;
  • the principal human adult user; and
  • cushy, overstuffed furniture near where the stapler will be used.

Depending on the nature of the design brief, many other co-systems might exist. It's up to you to decide, justify, and verify to the best of your ability that you have captured the important co-systems.

Notice that the co-systems can be described structurally - only the reference design must be described functionally. The reason for this is that we are not designing the co-systems; they are assumed to exist and are beyond all your control. So you can describe them structurally, and to whatever level of detail is needed, without concern.

Finally, you need to specify the system interfaces between the co-systems, the stapler system, and its subsystems. This means you have to quantify the amounts of mass, energy, and information that pass between systems.

Some of the interfaces for our stapler could well be described as follows:

  • Standard No. 56 staples in 4“ rows will be added by the human user to the stapler.
    • The staples will come from a box of staples in a desk drawer, and be inserted into the storage system via the loading system.
  • Staples can “exit” the stapler properly (binding sheets together) or improperly (broken; bent the wrong way; multiple staples per use;…).
    • Staples will move from the storage system, through the stapling system, and leave the stapler attached to sheets of paper.
  • A maximum of 15 sheets of 20 lb paper will “enter” the stapler system loosely and “exit” it fastened together.
    • Paper will arrive (via the user) to the stapling system, and exit from the stapling system once they have been stapled.
  • The human user will exert a force on the stapler (defined by an ergonomic analysis of the 5% of appropriate users, which can be easily looked up in standard ergonomics books).
    • The force travels from the user, through the structural system, to the stapling system, back out to the structural system and out into whatever the stapler is resting on.
  • Strain energy that will pass through the stapler when being used, as applied by the human, into the desk or coffee table on which the stapler is resting. This is directly calculable from the input force of the human user.
    • See the previous point.
  • Coffee/beer/wine can spill onto the stapler from a nearby glass or mug. The quantity will range from 4 oz (for wine) up to 16 oz (for beer); coffee will likely be between these two values, but may include cream and sugar.
    • Liquids will enter every system of the stapler, and then either flow out of those systems or evaporate and leave behind solid residues in every system.

One would finally prepare a system diagram showing all the system elements, and a system interface specification detailing the flows.

Exercise for the reader Determine the co-systems of our reference design stapler if it is to be used at the loading dock of a warehouse, as well as the interface specifications for the interactions of those co-systems and the stapler's subsystems.


TODO Describe consequences and counter-indications.

design/system_model.txt · Last modified: 2020.03.12 13:30 (external edit)