When we are considering the quality of an encryption system, we assume the person trying to decode the message knows what the general procedure is and is looking at the ciphertext-- the only thing he does not have is the key. We also assume the person sending messages does not spend time trying to contrive a difficult-to-read message by using unusual words or letter frequencies-- the sender is counting on the system to provide all the needed security.
Usually one assumes the person trying to break the code is only working with the ciphertext. However, there are situations in which both plaintext and ciphertext of a previously encoded message are available. For example, I often keep encrypted versions of examinations on a mainframe computer, only decoding them just before having them printed, and deleting the plaintext file immediately afterward. If a student was able to look at my files, he could keep a copy of the encoded test and compare this with the test he took. As we will see, this may be very useful in decoding future tests.
[One countermeasure against this type of known-plaintext attack is to continually change keys, assuming an encryption using one key is not helpful on a different key. It can become difficult to keep track of the different keys in use, especially if they are long.]
A more demanding standard is that a code may be safe against a chosen-plaintext attack. We are imagining that the encryption is done by a machine, and that unauthorized persons may have access to the machine (although we assume they are only using it in the normal way, not allowed to take it apart).