A system model is a representation of an existing entity using systems principles.
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.
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.
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).
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:
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.
Fig. 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:
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:
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:
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.