As you are in Engineering Answers, I think you are talking about some engineered system. You are talking about analysis. The basic idea is to divide the system up into functional blocks as you say, so that each group may be analysed separately. The approach works for a new system being designed, or one that you are trying to understand or repair. You only have to focus on the problem of the moment, not the whole picture.
It does need some understanding of what is there. If it is an electronic schematic by way of example, you could separate out the input, the output, any signal processing, power supplies, safety controls, user controls, displays. Often the schematic has functional blocks on different sheets, or the blocks may be labelled, have dotted lines drawn around them, or be in a coloured coded box. Another idea is to have separate explanatory "block diagrams". The technical manual is a further source of information. You might do some of these yourself.
You could alternatively split blocks up into various types of systems like analogue, digital, power. The inputs and outputs can be grouped according to what they do. Other ways might center on specific devices, like an analogue to digital converter, random access memory, non volatil memory, microprocessor, analogue signal processing, I/O devices. Integrated circuits make this easy, They are functional blocks in themselves.
SImilar ideas apply to software. There is often a specific sequence in each module - initialization, get the inputs, process the information, send it on to the outputs. The whole software system is broken down into easily understood groups and subgroups, which are further divided internally. Some examples are statements, objects, classes, modules, subroutines, interrupt service, controls, libraries. A good programmer makes these divisions in such a way that it helps with the understanding, as well as making parts reusable elsewhere. Just naming them properly helps. A name like "module A" doesn't help, but "graphics module" helps. We know that in there will be all sorts of graphics functions. This approach is generally called structured programming, as compared to spaghetti code, which is almost impossible to follow.
Another example is a car. The various parts are divided into functional groups, like engine, transmission, chassis. These are further divided into subsystems like cooling. lubrication, fuel.
Another concept is synthesis rather than analysis. This is combining rather than breaking down (applying knowledge for example). You build understanding by applying knowledge.
Some examples: We don't have to understand the maths library to know that it provides the maths, and to use it we just execute a maths statement. Similarly, we don't have to understand how the operating system puts data on the hard drive. We just use simple statements that read or write to a file, leaving it up to the system. Here the compiler has the knowledge to convert the statements of the programming language into object code, you don't need to know anything about object code.
A mathematical model (formula) or simulation process, a training course or a book has the knowledge to help understand or verify a design. Someone else provided the higher understanding. It tends to supplement analysis. Here is a chemistry example. A chemical compound can be synthesised by making it from other chemicals, or it can be analysed by decomposing it into those other chemicals.