3.2 A Formal Technical Review (FTR)

	Formal design reviews, variously called "design reviews", "DRs" and "formal technical reviews (FTR)", differ from
	all other review instruments by being the only reviews that are necessary for approval of the design product.

	Without this approval, the development team cannot continue to the next phase of the software development
	project.

	Formal design reviews may be conducted at any development milestone requiring completion of an analysis or
	design document, whether that document is a requirement specification or an installation plan.

A list of common formal design reviews are:

DPR - Development Plan Review

PDR - Preliminary Design Review

DDR - Detailed Design Review

DBDR - Data Base Design Review

VDR - Version Description Review

OMR - Operator Manual Review

SMR - Support Manual Review

3.2 A Formal Technical Review (FTR)

TRR - Test Readiness Review

TPR - Test Plan Review

FTR is a software quality assurance activity performed by software engineers.

	Each FTR is conducted as a meeting and is considered successful only if it is properly planned, controlled and
	attended.

	The obvious benefit from formal technical reviews, walkthroughs, is the early discovery of software defects so
	that each defect may be corrected prior to the next step in the software engineering process.

The of FTR objectives are:

To uncover errors in function, logic, or implementation for any representation of the software.

To verify that software meets its requirements.

To ensure that software representation meets predefined standards.

To achieve software development in a uniform manner.

To make projects more manageable.

3.2 A Formal Technical Review (FTR)

In the sections that follow, guidelines are presented as a representative formal technical review.

The Review Meeting

Every review meeting should abide by the following constraints:

		Between 3 and 5 people should be involved in the review; advance preparation should occur but should
		require no more than 2 hours of work for each person.

		The duration of the review meeting should be less than 2 hours. Rather than attempting to review the entire
		design, walkthroughs are conducted for modules or for small groups of modules.

The review meeting is attended by the review leader, all reviewers, and the producer.

		The focus of the FTR is on a product- a component of the software. The producer organizes a "walk through"
		the product, explaining the material, while the reviewers raise issues based on their advance preparation.
		When errors are discovered, the recorder notes each.

		At the end of the review the attendees decide whether to accept the product or not, with or without
		modifications.

3.2 A Formal Technical Review (FTR)

Review Reporting and Record Keeping

	During the FTR, the reviewer actively records all issues that have been raised. Finally, a review summary report
	is produced. It answers 3 questions:

What was reviewed?

Who reviewed it?

What were the findings and conclusions?

It is important to establish a follow-up procedure to ensure that items on the issues have been corrected.

Review Guidelines

	Guidelines for the conduct of formal technical reviews must be established in advance, distributed to all
	reviewers, agreed upon, and then followed.

The following are examples of the guidelines:

		Review the product, not the producer: the review leader should conduct the review meeting to ensure
		that the proper tone and attitude are maintained.

Set an agenda and maintain it:FTR must keep on track and on schedule.

3.2 A Formal Technical Review (FTR)

		Limit debate and rebuttal: when an issue raised by a reviewer, there may not be universal agreement on
		its impact. Rather than spending time debating the question, the issue should be recorded for further
		discussion off-line.

		Enunciate problem areas, but don't attempt to solve every problem noted: the solution of a problem
		can often be accomplished by the producer alone with the help of only one other individual.

Take written notes: It is important to take notes to be reviewed and accessed by other reviewers.

		Limit the number of participants and insist upon advance preparation: keep the number of people to
		the necessary minimum.

		Develop a checklist for each product that is likely to be reviewed: checklist helps the review leader to
		structure the FTR meeting and helps each reviewer to focus on important issues. Checklists should be
		developed for analysis design, code and documents.

		Allocate resources and time schedule for FTRs: Reviewers should be as a task during the software
		engineering process.

3.2 A Formal Technical Review (FTR)

Conduct meaningful training for all reviewers: all reviewers should have a formal training.

		Review your early reviews: Debriefing can be beneficial in uncovering problems with the review process
		itself.

Review Checklists

Checklists are used to assess products that are derived as part of the software development process.

These are examples according each phase of software.

System Engineering phase: a system specification is prepared

Are major functions defined in unambiguous fashion?

Are interfaces between the system elements defined?

Have performance bounds been established?

Has the best alternative been selected?

Is the solution technically feasible?

Has a mechanism for system validation and verification been established?

Is there consistency among the system components?

3.2 A Formal Technical Review (FTR)

Software Project Planning phase: a software project plan is prepared

Is software scope unambiguously defined and bounded?

Are resources adequate for the scope?

Are resources readily available?

Have risks in all important categories been defined?

Is a risk management plan in place?

Is the basis for cost estimation reasonable?

Software Requirements Analysis phase: preparing requirements specification

Is information domain analysis complete, consistent, and accurate?

Is problem partitioning complete?

Are external and internal interfaces properly defined?

Does the model properly reflect data objects, their attributes and relations?

Are all requirements traceable to system level?

3.2 A Formal Technical Review (FTR)

Has prototyping been conducted for the user?

Are requirements consistent with schedule, resources, and budget?

Are validation criteria complete?

Software Design phase: preliminary design reviews

Are the software requirements reflected in the architecture

Are interfaces defined for all necessary modules?

Is the data structure consistent with the information domain?

Is the data structure consistent with the requirements?

Has maintainability been considered?

Is the algorithm logically correct?

Is the interface consistent with the architectural design?

Is the logical complexity reasonable?

Are local data structures properly defined?

Is design detail amenable to the implementation language?

3.2 A Formal Technical Review (FTR)

Software Coding phase: source code

Has the design been properly translated into code?

Has proper use of language conventions been made?

Is there compliance with coding standards for the language style?

Are data types and data declarations proper?

Have all the items on the design walkthrough checklist been reapplied?

Software Testing phase: test plan

Have major test phases properly been identified?

Are major functions demonstrated early?

Is the test plan consistent with the overall project plan?

Are test resources identified and available?

Has traceability to validation criteria been established as part of the software requirements analysis?

3.2 A Formal Technical Review (FTR)

Maintenance phase: test plan

Have side effects associated with change been considered?

Has the change, once made, been documented and reported?

Have appropriate FTRs been conducted?

Has a final acceptance review been conducted?