One of the first tasks at the start of a project is to set the context and scope of the proposed application.

1. How much do we include in the system?
2. How does this system relate to other systems in our architecture?
3. Who plans to use this system?

All this could be described in a lengthy document. But, as the saying goes, a picture is worth a thousand words. This conviction helps explain the simplicity of the system notation, a mere rectangle with a name.

The system icon simply provides a context into and around which we place all the elements that influence the construction of the system.
Think of the system in terms of encapsulation, which asserts that to use an object, we need know only its interfaces, not its internal implementation. A system is like a class, in that each has a purpose and an interface. Each may be replaced or enhanced without affecting other entities as long as the purposes and interfaces remain unchanged.
The priority in defining the system is to define its purpose and the required interfaces. The purpose is the target of the project justification. The interfaces are the channels of communication between the actors outside the system and the system itself. Working inward from this fundamental requirement, we set the constraints for all subsequent modeling of the system's internal behavior.
In the next lesson, the actors who use a system will be discussed.