Question 2 of 8

Question 2 (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part (a) — the Formal Technical Review. A Formal Technical Review (FTR) is a structured, planned meeting conducted by software engineers (and other stakeholders) to uncover errors in requirements, design, code or test artifacts as early as possible — the classic examples are walkthroughs and inspections. Its objectives are to find defects, to verify that the work product meets its requirements/standards, and to make the product more manageable, while also serving as a training vehicle for junior staff. Recommended constraints of the review meeting (Pressman, from Freedman & Weinberg's inspection practice) are:

• Small group size — 3 to 5 participants, kept intentionally small so everyone stays engaged.
• Advance preparation — every participant reads/studies the product beforehand (typically limited to a few hours of prep) so the meeting itself is not spent understanding the material.
• Time limit — the meeting is kept short, typically under two hours, to preserve concentration and defect-finding effectiveness.
• Focus on the product, not the producer — conducted in a non-judgemental tone; the review critiques the work, never the author.
• Issues are recorded, not resolved, in the meeting — a reviewer's job is to identify problems; fixing them is deferred to the author afterward, which keeps the meeting on schedule.

Part (b) — five review guidelines.

1. Review the product, not the producer. Phrase findings as neutral observations about the artifact ("this branch has no error path") rather than the author, so people stay open to having defects found in their work rather than becoming defensive.
2. Set and stick to an agenda, and maintain the review team's focus. A review that wanders into design debate or unrelated topics stops finding defects; a moderator keeps discussion converging on the artifact under review.
3. Limit debate and rebuttal. When a reviewer raises an issue, discuss it just long enough to confirm it IS an issue; do not resolve HOW to fix it in the meeting — that is design/rework, done afterward.
4. Enunciate problem areas, but don't attempt to solve every problem noted. The review's output is a list of defects/issues, not a redesign; solving them belongs to the author's follow-up.
5. Take written notes, and schedule follow-up where needed. A recorder captures every issue raised (issue list), and any product requiring extensive rework is scheduled for a second, focused review rather than trying to close it out in the same session.