An FTR is a software quality control activity performed by software engineers and others.

The objective of FTR is as follows:

1) Uncovering errors in the functions, logic or implementations for any representations of the software.

2) To verify that the software under review meets it's requirements.

3) Ensure that the software has been represented according to the predefined standards.

4) Achieve software that is developed in a uniform manner.

5) Making projects more manageable.

Normally you would want to keep the personnel included in the meeting to a minimum of who is required (around 3-5 people) - e.g (Review leader, 2-3 Reviewers), one of the reviewers would normally be the "recording" who's main objective is to write down all important issues brought up during the meeting.

In an ideal setting, every software engineering team should conduct formal technical reviews. Even with limited resources and where time is short, in the long run it will drastically reduce maintenance and upgrade cost.

By letting these issues through without formal technical reviews, all of the main objectives of an FTR will be missed which will potentially lead to compromised software for a number of reasons.

Now at the end of a review meeting, all attendees must decide on (1) accept the product without further modifications, (2) reject the product due to severe errors or (3) accept the product provisionally. After the decision is made, all attendees must complete a sign off indicating their participation in the review and their concurrence with the review team's findings.