To get a better understanding, one needs to familiarize oneself with
- how the whole V-model works and what the terminology is, and
- how the testing according to these standards really works.
To that end, I suggest checking the ASPICE manual (version 3.1), especially check Annex D (at least in version 3.1) is quite illustrative. Also, professionally developing with ASPICE usually means, that there is someone available for the engineers to consult with (typically this should be the role of a Quality Manager).
The idea behind the V-model is top-down design, where (very crudely said) first the requirements are gathered and analysed, then architecture is created, and smallest elements of architecture are then described by detailed design. Typically all this goes without coding (as in writing actual code that will be executed, be it in compiled or interpreted way). Only the very last step of the left-hand side of the V, the detailed design is implemented in a particular programming language and the final "binary" is created (quotes are intentional as there is a historical bias towards compiled languages, but you can think of putting together all the necessary source files in an interpreted language as the "creation of binary image" if you will).
As part of this process, each software element will end up being linked to some requirements. Some requirements may be covered by multiple independent parts in the code, some pieces of code may cover multiple requirements.
Now for the testing: important is the distinction between the object being tested and the test specification (in your words the WHAT).
The object is always the binary. Depending on the level of the test in question, it may be smaller (unit tests), bigger (integration tests) or complete binary of all the software being developed (qualification tests).
The test specification is derived from the software description on each particular level your test is running:
unit tests verify that the binary (units) behave according to the detailed design. This thus means testing the low-level algorithms. For compiled language (assume C), the most basic test (or better even prerequisite) is "Did the source file compile into an object file?"
Of course, that is only the first step, but this is the level of complexity unit tests work on.
Integration tests verify that the binary (several units integrated together) behave according to the architecture (as the name suggests, important here is the communication among the components and whether they are correctly assembled together). One thing that typically gets tested is correctness of APIs through which individual units communicate. Prerequisite: "Did all the object files link correctly into a library?"
Architectures also often include e.g. a dynamic view (timing etc.), so there are lots of various kinds of tests.
Qualification tests verify whether the whole software fulfils the requirements. Only here you are actually testing the requirements, since those are for the software as a whole.
This said, I think the core of your question could be answered like this: Software units are traced to requirements, but unit and integration tests do not test requirements. It wouldn't even be reasonably possible - there rarely is a 1:1 correspondence between requirements and units. The reason behind it is, that the actual units do not depend on requirements only neither directly - they are influenced by the architecture and other constraints, which may appear because of many reasons (architecture/design decisions between several options, additional standards, hardware/system limitations).
As a side note: this whole process idea seems often menacing to new programmers, and often is frowned upon as way-too-much-overhead, but somehow it has been proven in practice. There is a reason why certain industries (aerospace, railway, automotive, healthcare) demand it. Once peoples' lives are at stake, the rules of the game are different from the "more usual" programming (commercial personal software, games, web applications).
