10.1 Introduction
A system’s purpose defines why it exists—the reasons it might be built.
What the system is comes next. This is a high-level view of what the system is and will do—and not how it does those things.
The definition of what a system is starts by defining the boundary between the system and the rest of the world. There are things that are part of the system, which I will call the system’s scope. The rest of the world provides an environment in which the system operates. Interactions between the system and its environment take place at the boundary between them.
The things within the system’s scope are what is being built, and thus under the control of the team making the system. This includes the functions, behaviors, and qualities of the system that are visible from outside the system. These are interactions between the system and its environment across the boundary between the two. These interactions should fulfill the system’s purpose.
What is in the environment is not under the builders’ control. The team building the system should understand these things, but they can’t be changed.
The environment includes the things that interact with or use the system. This includes things that go in and out of the system, physical places where the system operates, and the ambient environment (atmosphere, electromagnetic forces, dust, vibration, or radiation). The environment also includes those who will use the system, and thus define the purpose for the system to exist.
A caution: the system’s scope covers what the system does, and does not address how the system does that. Matters of how the system is designed to meet its scope are separate.
10.2 Why scope and boundary matter
Building a system starts with working out the system’s scope. All of the specifications of the system are a refinement of the scope, and all of the design follows from that.
One will want to know how big the effort to build a system will be, at some point early in a project. This depends on knowing what the system will be.
Knowing what is in the environment—and thus not changeable by the team building the system—defines constraints on building the system.[1]
Finally, defining a system’s scope, boundary, and environment provides a way to check that the team understands the customer’s purpose properly by asking the customer to review the scope and boundary.
10.3 Content
The what of a system is the root of all the design of the system and its pieces. As discussed in the next chapter, the model of the whole system is the root of a hierarchy of component parts that define how the system is made. That chapter provides a model for how to define each component, including the system as a whole.
The team will use documentation of system’s scope and boundary over and over as they build the system, meaning that the information should be organized in artifacts that people can readily find and understand. (See Chapter 17 for discussion of what this implies.)
The system’s scope includes a few kinds of information: a concept, objectives, constraints, assumptions, and environment.[2]
A concept for the system provides a description of what the system will do. The concept is generally narrative, telling stories about the system. The concept should include major usage scenarios, for how the system’s customer will interact with the system and how the system will interact with its environment. I have often used a few diagrams to illustrate the concept. People looking at the concept should come away with an understanding of generally what the system will do and, equally important, what is not in the system’s scope.
Objectives (or goals) are a more organized way to present similar information. This takes the form of a list of the things people want out of the system: its behaviors or functions, and its properties. These will be general statements, and the process of developing a specification of the system will refine these into something more precise.
Constraints list limitations on acceptable system designs. The constraints do not establish what the system does, but only constrain how well it does those things. Many constraints relate to safety or security. For example, the system might need to meet some safety standard. Initial constraints will be general, and they will be refined as the system’s specification and design are worked out. Many constraints lead to analyses that work out in greater detail what these constraints imply.
The assumptions record information that affects how the system can be designed but that might be forgotten or might be missed. (This is similar to making objectives explicit or leaving them implicit.) This is often organized as a list. The assumptions guide later design decisions.
Finally, the environment lists information about the world in which the system will operate. The environment constrains how the system can operate or how it must be designed: to accommodate a certain level of vibration, for example, or that cellular radio coverage will be variable over a region where a vehicle will operate.
10.4 Using scope and boundary
The scope and boundary are a realization of the system’s purpose. The record of the scope should be traceable to the purpose. The team uses the scope and these traces to check that the definition of scope meets all of the system’s purpose, and that there aren’t significant parts of the scope that are not based on some part of the purpose.
The act of defining the system’s scope helps reveal the details of system’s purpose and constraints. Discussions with a customer or other stakeholder are usually informal and incomplete. The discussions result in notes and drawings, but they are rarely directly usable for working out the system’s specification. The tasks of working through records of those discussions and organizing a model of the system’s purpose will reveal ambiguities in what the customer has said, or gaps or inconsistencies. The team can then work with the customer to resolve those issues so that the definition of scope is more complete.
The team will use the definition of the system’s scope to document top-level specifications for the system, which then inform the system’s design and its decomposition into component parts.
As the project moves forward, the team will work out the design for high-level system properties such as safety, security, or reliability. The tasks that build the designs for these emergent properties (Section 12.4) begin with the definitions of what safety or security the system is expected to provide. Those definitions are part of the scope.