---
title: "Formal technical review; Garvin’s quality dimensions"
subject: "Software Engineering"
chapter: 9
key: "semester_5/software_engineering:ftr-garvin"
source: https://www.bctengineer.com/q/semester_5/software_engineering/ftr-garvin
site: BCT Engineering
---

# Formal technical review; Garvin’s quality dimensions

Software Engineering · Chapter 9: Quality management

- Asked in: 2068 Chaitra, 6+4 marks; year not given, 6+4 marks
- Video: [Garvin’s Quality Dimensions | Garvin’s Eight Quality Dimensions | SOFTWARE QUALITY](https://www.youtube.com/watch?v=AZd_EOj3aDI) — LearnEveryone
- Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_5/software_engineering/ftr-garvin
- Whole chapter: https://www.bctengineer.com/md/semester_5/software_engineering/chapter-9

## Question

How do you conduct formal technical review? Explain Garvin's quality dimensions.

## Short answer

A formal technical review (FTR) is a structured meeting of 3–5 people reviewing a small work product, with advance prep ≤2h and meeting ≤2h. Producer presents, reviewers raise issues, recorder logs them. Decision: accept, reject, or accept provisionally. Follow-up ensures fixes. Garvin’s quality dimensions for software: performance, features, reliability, conformance, durability, serviceability, aesthetics, and perceived quality.

## Answer

A **formal technical review (FTR)** is a planned, structured meeting in which a small group of software engineers examines a work product (SRS, design, code, test plan) to find errors early. Walkthroughs and inspections are the common types of FTR.

#### Conducting a formal technical review

**Constraints on the review meeting** (Pressman):
- 3 to 5 people take part.
- Each reviewer prepares in advance, but for no more than about 2 hours.
- The meeting itself lasts less than 2 hours.
- So the review covers a small, specific part of the product (for example one component's design or 200–300 lines of code), not the whole system.

**Roles**
- **Producer**: the developer who created the work product.
- **Review leader**: plans and chairs the meeting.
- **Reviewers** (2–3): examine the product and raise issues.
- **Recorder**: writes down every issue raised.

**Steps**
1. The producer tells the project leader that the work product is complete and ready for review.
2. The project leader contacts a review leader, who checks the product for readiness, makes copies and gives them to the reviewers.
3. Each reviewer studies the product for 1–2 hours and notes possible errors, often using a checklist.
4. In the meeting, the producer walks through the product and explains it. Reviewers raise issues; the recorder logs each one.
5. At the end, all participants decide to:
   - **accept** the product without changes,
   - **reject** it because of serious errors (another review is needed after correction), or
   - **accept provisionally** (minor errors must be fixed, with no further review).
6. Everyone signs off. The recorder produces a **review issues list** and a **review summary report** (what was reviewed, who reviewed it, what was found, the decision).
7. **Follow-up**: the review leader checks that every item on the issues list has been corrected.

```text
Producer --> Project leader --> Review leader
                                   |
                     copies to reviewers (prepare)
                                   |
                            Review meeting
                                   |
            Accept / Reject / Accept provisionally
                                   |
           Issues list + summary report --> Follow-up
```

**Review guidelines**
- Review the product, not the producer; keep criticism polite.
- Set an agenda and keep to it; limit debate and rebuttal.
- Point out problem areas, but do not try to solve every problem in the meeting.
- Take written notes; use checklists for each type of work product.
- Limit the number of participants and insist on advance preparation.
- Schedule time and resources for reviews, train reviewers, and review the early reviews to improve the process.

#### Garvin's quality dimensions

David Garvin proposed eight dimensions for judging the quality of a product. Pressman applies them to software:

| Dimension | Meaning | Example (mobile banking app) |
|---|---|---|
| Performance quality | Delivers the content, functions and features stated in requirements, giving value to the user | Fund transfer works correctly |
| Feature quality | Has features that surprise and delight first-time users | Pay by scanning a QR code |
| Reliability | Delivers all features without failure, available when needed | Rarely crashes, no downtime at month end |
| Conformance | Follows relevant standards and design/coding conventions | Meets bank security standards and UI guidelines |
| Durability | Can be maintained or corrected without unintended side effects | A bug fix does not break other screens |
| Serviceability | Can be maintained or corrected in an acceptably short time | Support fixes a reported bug within a day |
| Aesthetics | Has elegance, a pleasing look and flow | Clean, consistent screens |
| Perception | User's view, shaped by reputation and past experience | A trusted bank's app is assumed to be good |

Garvin's dimensions show that quality is multi-dimensional: some (reliability, conformance) can be measured objectively, while others (aesthetics, perception) are subjective but still matter to users.

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. Which matches Pressman's constraints for an FTR?
   A. 10 to 15 people, a full-day meeting
   B. 3 to 5 people, preparation up to about 2 hours each, meeting under 2 hours
   C. One person, no preparation
   D. Whole team, meeting of 8 hours
   Answer: B. FTRs use a small group (3-5), limited preparation and a short meeting covering a small part of the product. (Key point: FTR meeting constraints)

2. Which is NOT a possible decision at the end of an FTR?
   A. Accept without changes
   B. Reject due to serious errors
   C. Accept provisionally
   D. Ignore the issues list
   Answer: D. The team accepts, rejects or accepts provisionally; the issues list must be followed up, not ignored. (Key point: FTR decisions)

3. A bug fix that does not break other screens illustrates which Garvin dimension?
   A. Aesthetics
   B. Conformance
   C. Perception
   D. Durability
   Answer: D. Durability means the software can be maintained or corrected without unintended side effects; serviceability is about the time taken. (Key point: Garvin durability vs serviceability)

4. Which Garvin dimension means following standards and design/coding conventions?
   A. Conformance
   B. Reliability
   C. Feature quality
   D. Performance quality
   Answer: A. Conformance is adherence to relevant standards and conventions, such as bank security standards and UI guidelines. (Key point: Garvin conformance)

## Related in Software Engineering

- [Objectives of FTR; cleanroom software engineering](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Aftr-cleanroom) — Software Engineering, chapter 9

## Related in other subjects

- [Definitions and dimensions of quality](https://www.bctengineer.com/question.md?key=semester_6%2Findustrial_engineering_and_management%3Adefinitions-and-dimensions-of-quality) — Industrial Engineering and Management, chapter 8
- [Contract procurement performance review](https://www.bctengineer.com/question.md?key=semester_7%2Fict_project_management%3Aprocurement-performance-review) — ICT Project Management, chapter 13
- [Ethics and need for code of conduct](https://www.bctengineer.com/question.md?key=semester_8%2Fengineering_professional_practice%3Aethics-why-code-of-conduct) — Engineering Professional Practice, chapter 2
- [Proposal for computer lab: title, technical, cost](https://www.bctengineer.com/question.md?key=semester_5%2Fcommunication_english%3Aproposal-computer-lab-parts) — Communication English, chapter 6, asked 2×
