There are two times during a project when the scope is defined. The high-level scope is defined in the up-front project definition process. These scope statements help establish the boundaries of the project. The more detailed scope is defined when you gather business requirements. If you think of scope as a box, the high-level scope would be used to define the size and shape of the box. The requirements would then fill up the insides of the box.
One of the first places to look for your high-level scope definition is the project objectives. All projects build things and the objectives are achieved through the creation of one or more deliverables. Listing the deliverables tells the reader what your project will deliver and by implication, what it will not deliver. This is the place to start when describing your scope boundaries. If you do not include anything else in your high-level scope section, at least list your deliverables. Since the sponsor will approve your project definition document, these should be the external deliverables that the sponsor understands. Don't include the internal deliverables that are only needed by your project team.
The deliverables tell you "what" your project is producing. Once you have your deliverables listed, start asking other "what" questions to determine other aspects of scope. This includes what types of data are needed, what company locations are involved, what major capabilities need to be included in the project, what types of business processes are affected, etc.
As a point of clarity and contrast, you can also identify out-of-scope conditions by describing what deliverables will not be created, what organizations will not be impacted, what features and functions are not included, etc. Of course, there are an infinite number of out-of-scope statements. For the purposes of scope definition, you want to include only those statements that help define the project boundary and touch upon related areas that the reader may have questions about. For instance, if you were installing financial software, you might state that a new Accounts Payable package is in scope, but the related Purchasing System is out of scope. This would make sense since the Purchasing and Accounts Payable processes are related and there may be questions as to whether the Purchasing System was in scope. You would not have to list every other system as out of scope--just the ones that the reader might have questions about.
It's also a good practice to document those organizations that are in scope and those related organizations that are out of scope. The readers of the project definition document can then determine more easily if their organization is impacted or expected to assist. This exercise can also help the sponsor decide if a steering committee should be created with representatives of these organizations.