Avoid unnecessary repetitions. The multiple representation of identical facts generates excessive maintenance effort when changes are made and, on top of that, makes the documentation more difficult to use.

In the case of redundancy, the chances are quite high that facts are described slightly differently in one place than in other places. This confuses readers: Are these differences intentional or an oversight? Which of these places can I rely on and which rather not?

Why then do we restrict this tip already in the title with the phrase “if possible” and do not demand absolute freedom from redundancy? The reason lies in the reading comfort: In some places you want to convey facts to your readers “as a whole”.

Examples for avoiding redundancy:

Example 1: req42 section 6 (quality requirements) is mainly intended for qualities that should apply to several functional requirements. You want to write down such quality requirements only once, and then link them to all the functions to which they apply..

Example 2: You only need Chapter 10 (Team Structure) if you have multiple teams. If you have already described the team members in Chapter 2 (Stakeholders), you should definitely not repeat this in Chapter 10..

So: Allow redundancy only where it increases reading comfort or comprehension.