Why review a (sub)product?

The DOT model describes many different activities and almost all activities result in a temporary or definitive partial product. This may involve documentation, but also, for example, a diagram, code, analysis or storyboard. These are the so-called stepping stones. They are the transfer of information from one research area to another. It is therefor communication.

Every person makes mistakes, even the most experienced technician has blind spots. In fact, experienced professionals are aware of how likely it is that they are missing something.

That's why we review each other's work. It is sometimes called the 'four eyes principle'. Two persons see more than one. It is supporting your team mates, "have look at it".

But there is also a less informal aspect to it. Documents are written to communicate something. And the target group must understand the text and be able to work with it.

A few examples:

• The client must agree with the purpose, budget, scope and preconditions of a project described in the project plan.
• The team members must understand how the planning is set up and what is expected of them.
• In larger projects, all software developers must understand the requirements because they have implement them.
• In the same larger project, the testers must define acceptance tests and therefore the requirement specification must also be clear enough for them.
• Anyone who has had to work with someone else's code can confirm it: clear code with clear comments prevents many mistakes. But the author of the code can no longer clearly see what is obvious and what needs commentary.

A final reason to review each other's work is that colleagues in a project get to know each other's work. Very useful because all the components team members make must be integrated into one product. Gaining knowledge and improving quality in the same activity.