The notion of force generalizes the kinds of criteria that software engineers use to justify designs and implementations. For example, in the classic study of algorithms in computer science, the main force to be resolved is efficiency (time complexity). However, patterns deal with the larger, harder-to-measure, and conflicting sets of goals and constraints encountered in the development of every artifact you ever create. For example:
Completeness and correctness of solution
Static type safety, dynamic type safety
Multithreaded safety, liveness
Fault tolerance, transactionality
Efficiency: performance, time complexity, number of messages sent, bandwidth requirements
Space utilization: number of memory cells, objects, threads, processes, communication channels, processors, ...
Policy dynamics: Fairness, equilibrium, stability
Modularity, encapsulation, coupling, independence
Extensibility: subclassibility, tunability, evolvability, maintainability
Reusability, openness, composibility, portability, embeddability
... other ``ilities'' and ``quality factors''
Understandability, minimality, simplicity, elegance.
Error-proneness of implementation
Coexistence with other software
Impact on/of development process
Impact on/of development team structure and dynamics
Impact on/of user participation
Impact on/of productivity, scheduling, cost
Ethics of use
Human factors: learnability, undoability, ...
Adaptability to a changing world
Medical and environmental impact
Social, economic and political impact
... other impact on human existence
It is usually impossible to analytically ``prove'' that a solution optimally resolves forces. (In fact, it is hard to define the notion of ``proof'' here, or even to see what use such a proof would have.) On the other hand, it is all too easy to come up with ``just-so'' stories that provide wrong or deceptive rationales for solutions. Even the most concientious pattern authors sometimes don't fully understand why a solution works as well as it does, or appreciate its full range of applicability.
For these reasons, the patterns community expects that arguments be backed up with:
Until such evidence is provided, a pattern is sometimes called a proto-pattern -- a candidate for being a pattern.