ABSTRACT
When developing or discussing a system in any context (architecture, requirement, design, etc.), one must be aware of the level of abstraction that is being discussed. A system can be discussed in context anywhere between a system of systems and the component/element level. Determining these levels of abstraction for a system can sometimes be challenging but should be clearly defined so that everyone can use the same language regarding a particular instantiation of a system. For example, the air traffic control system contains many interacting systems. So it can be viewed as a system of systems, although the air traffic control system is a system within the overall transportation system (i.e., trains, planes, automobiles, etc.). This example indicates the importance of understanding the context in which a system is being designed and discussed. Just as an individual may participate as the role of mother, teacher, soldier, and coach, a single system can play multiple roles, such as system, module, and so forth. The system must be designed to fulfill all its roles, and knowing what the scope of the system is contributes to that goal. It is important to know the boundaries of the system for understanding what is within a system and what is outside the system. Therefore, one of the first steps when designing a system is to decide what level of abstraction applies to the system of interest.
