The purpose of problem analysis is to define the resources that support the problem domain.
The scope of problem analysis includes the purpose and the interfaces of the classes that represent these resources. So far, you have the classes and their purpose.
But what method do you use to justify the interfaces for these resources?
Interaction diagrams provide a tool for translating use cases into a sequence of communication between specific objects.
This communication then translates directly into the object interfaces. The result is an explicit justification for the interfaces you define for each problem domain class.

As a result of decomposition, software is divided into parts, the meaning of which depends on the paradigm and decomposition. The parts may be modules, abstract data types, packages, or other concepts recognized by the paradigm or the language. The principle of abstraction requires that each part has its interface and its implementation clearly separated from each other. Encapsulation is the principle of exposing only the interface and hiding the implementation of a part of software. In other words, the environment of a part cannot access the implementation, but only its interface.
The interface of a part is specified as something that the part offers to its environment as a contract, or the obligation that the part promises to fulfill at any time. The implementation, however, is something that is private to the part, and that is assumed to be modifiable without affecting external parts. If another external part of the software relies only on the interface of the part, the external part remains stable if the implementation of the latter part changes, because the contract specified by the interface must still be satisfied. Let us imagine that a programmer changes the implementation of the part, assuming that other external parts do not rely on the assumptions posed in that implementation. If an external part violates the encapsulation by relying on the assumptions made in the implementation, that external part will fail after the modification in the former part. This is one of the most frequent causes of errors in traditional software approaches that do not enforce encapsulation.
Encapsulation can be achieved through discipline, by obeying coding rules posed by programmers themselves. However, this approach is highly error-prone. It is crucial, therefore, that the language formally define the rules of encapsulation, and that the modeling tool or compiler check possible violations, in order to avoid errors.
In short, encapsulation is yet another concrete technique that supports the general principle of loose coupling of software parts. It ensures that software parts cannot arbitrarily make interconnections other than as allowed by their contracts. Consequently, it is again a general software engineering principle, not strictly associated with object orientation. However, as with abstraction, the object paradigm has recognized it as one of its fundamental concepts supported by almost all OO programming and modeling languages and methods. It can be supported at very different levels and by different formalisms.