Separation of concerns (SoC) is a design principle in computer science and software engineering, it holds that a complex problem should be divided into distinct concerns — aspects or issues — that can be analyzed, addressed or managed individually, even when they belong to the same system. This allows focusing on one issue at a time, reducing cognitive load and complexity.

Separation of Concerns can be achieved in several ways: temporally (e.g., sequencing activities in a software lifecycle), by quality (e.g., treating correctness separately from efficiency ), by view (e.g., analyzing data flow separately from control flow) or by size (modularity)

Modularity is a specific application of concerns to system components (separation by size). In modular systems, each module encapsulates a single concern, and modules are designed, implemented, and understood in isolation before being composed into a larger system. While modularity is the most common and recognizable embodiment of SoC in code structure, the principle of Separation of concerns is broader. For example, separating requirements analysis from implementation in a project timeline, or separating functional from non-functional requirements in a specification, are valid forms of separation of concerns that do not necessarily require a modular design.

Edsger W. Dijkstra in his 1974 paper "On the Role of Scientific Thought", coined the term separation of concerns in relation to software qualities such as correctness and efficiency.

Carlo Ghezzi in his book "Fundamentals of software engineering" promotes Separation Of Concerns as the primary way to tackle the inherited complexity in software production.

Philippe Kruchten in his article "Architectural Blueprints—The “4+1” View Model of Software Architecture" used a model composed of five main views to address large architectures, essentially this is a view-based separation of concerns, where each view focus on a different aspect of the architecture.

According to Carlo Ghezzi, the main benefit of software modularity is that it allows the application of the separation of concerns principle to system components, or "modules." Module details can be addressed in isolation; furthermore, module integration is treated as a separate concern that deals with the overall characteristics of software modules and their relationships.

Laplante, Phillip also mentioned that separation of concerns can be applied in software design, coding, time, and software qualities.