The Review Meeting
Each review meeting should be held considering the following constraints- Involvement of people:
- Between 3, 4, and 5 people should be involved in the review.
- preparation should occur, but it should be very short that is at the most 2 hours of work for every person.
- The short duration of the review meeting should be less than two hours. Given these constraints, it should be clear that an FTR focuses on specific (and small) parts of the overall software.
At the end of the review, all attendees of FTR must decide what to do.
- Accept the product without any modification.
- Reject the project due to serious error (Once corrected, another app needs to be reviewed), or
- Accept the product provisional (minor errors are encountered and should be corrected, but no additional review will be required).
The decision was made, with all FTR attendees completing a sign indicating their participation in the review and their agreement with the findings of the review team.
Review reporting and record-keeping:
- During the FTR, the reviewer actively records all issues that have been raised.
- At the end of the meeting all these issues raised are consolidated and a review list is prepared.
- Finally, a formal technical review summary report is prepared.
A review summary report answers three questions:
- What was reviewed?
- Who reviewed it?
- What were the findings and conclusions?
Formal Technical Review (FTR) in Software Engineering
Formal Technical Review (FTR) is a software quality control activity performed by software engineers. It is an organized, methodical procedure for assessing and raising the standard of any technical paper, including software objects. Finding flaws, making sure standards are followed, and improving the product or document under review’s overall quality are the main objectives of a formal technical review (FTR). Although FTRs are frequently utilized in software development, other technical fields can also employ the concept.