How (tool, methodology) to ensure traceability from requirements through TOR to code up and down?

Question

Project management

Situation: There are several logically related levels of documentation + code.
For example:
1. Analytical note (AZ) describing what and why the program should do, (generates technical specifications (what to write to the programmer), user instructions.)
2. Terms of reference (TOR) generates code,
3. User instructions for the system (maybe basis for operator courses / simplified instructions for specific operations)
5. code
6. Test case (born on the basis of instructions and AZ)
Each document has 50-200 pages, well, the code is not new, but inherited, so it is generally unmeasured.
Suppose we stumbled upon a problem while checking the test case. Is there some kind of documentation processing/storage system, a working methodology for organizing documentation that will allow us to reach the necessary sections of the instruction / analytical note / those tasks that should be analyzed if we know the location of the failure in the test case?
Preferably, of course, everything is under version control with the ability to mark "consistent" (when the documentation, by our assumption, is consistent) versions, and roll back to them if necessary.

Answer 1

1. There are systems for working with requirements. Specially tailored for this. As a rule, under Windows. But they are NOT plain text formats. For example, here's an approach: https://en.wikipedia.org/wiki/Software_configurati... (and in particular https://en.wikipedia.org/wiki/Rational_ClearCase_UCM )
2. You can use single sourcing technical documentation ( DocBook, DITA) with the construction of the entire scheme of work. You will need: a person who will do all this and a budget for this business.
I must say right away that in both cases the pleasure is not cheap. And not the fact that item 1 will be cheaper than item 2
PS I suppose that test cases are still understood as test cases.

Answer 2

As paradoxical as it sounds, improving traceability of requirements will not lead to improved quality. Let's just say that's my statement :)
The very concept of writing AZ and TK has lost its relevance. The processes of coordination, approval and planning take up too much invaluable and expensive time. My recipe does not claim to be universal, but for my purposes it worked and works great. The method has already been described by Western authors, but, as we all understand, the methodology in its pure form is not used anywhere, but its own specific impurities are always added or vice versa, something is removed. This method can be called "Rapid Prototyping", the prerequisites for such a method are that people perceive visual (graphic) concepts hundreds of times faster than text descriptions, so if you make quick graphic prototypes (1-2 days) and start a chain approval, then feedback can be received in the same 1-2 days, then 1 day for aggregation and preparation of a short description of 1-3 pages, instead of 15 as before. After agreement, the stage of preparing the specification for developers (1 day).
The creation of universal prototype models is also encouraged, for example, which describe some standard features without being tied to functionality, so at the stage of testing and preparing test cases / test plans for specific functionality, "standard" behavioral features are taken into account, which leads to an overall improvement in quality.
Another very effective tool for treating any sores in software is following ISO 9001 practices, in particular, collecting feedback from customers, holding quality advice, monitoring processes within the organization (how well they are performed, etc.). This is a global topic, but if you wish, you can master it.
PS To create quick prototypes, you can use different software, but I liked Balsamiq the most. To describe the requirements, there is also Rational RequisitePro ( www.caseclub.ru/articles/requisite.html) , a more global tool with Aris process modeling, but I think that this is already an old school and these tasks should be solved using the method described above.
PS In order to have an understanding, everything I wrote about worked for the number of developers from 15 to 120, otherwise you never know where you have thousands :)