Karsten on the Business of Software et al.

And even Gamma et al. say, to describe a pattern you need:

  1. The pattern name.
  2. The problem that describes when to use a pattern.
  3. The solution which provides an abstract description of the design problem and its solution using necessary and affected elemnts like classes etc. (###  redundancy here? why again the design problem ###).
  4. The consequences are the results and trade-offs of applying the pattern. The consequences are most important for somebody who likes to compare patterns for solving a specific problem.

Another point is, that very often a pattern based approach is used or is relevant to identifying the problem: E.g. if you like to discuss the Value Object/Data Transfer Object Pattern, you'd like to mention problems that lead to the use of the Session Fassade or, additionally the Composite Entity.

I would therefor suggest to always think of a pattern based approach to identify the problem and to describe the solution.