Guidelines to Review Work products

Guidelines to review Work Products v1.0
Document Template Reference No: 1-3
Copyright © RASS Tools Limited, UK
Website: www.rasstools.com,
Doc Ref No: 1-6
Guidelines to review
Work Products
v1.0
Author: AshokKumar LalSingh
8 Dec 2009
Copyright Notice
The document “Guidelines to review work products” has been authored by Ashok Kumar LalSingh,
Director - RASS Tools Limited, UK.
RASS Tools Limited reserves all rights to modify this document and permit its uses. Use of this
document for the purpose other than personal reference is not permitted without the explicit
authorization from RASS Tools Limited. RASS Tools Limited will not be responsible for financial or any
other losses arising due to the unauthorised use of this document.

Guidelines to Review Work Products v1.0
Doc Ref No: 1-6
Page 2 of 19
Index
1 Introduction ........................................................................................................................................ 3
2 Definitions of Roles used during Review ............................................................................................ 5
3 Which Review method to use?........................................................................................................... 6
4 What are various aspects of reviews?................................................................................................ 7
5 What types of activities are performed during reviews?................................................................. 12
6 What skills are needed to perform reviews?.................................................................................... 13
7 How to record and report outcome of reviews?.............................................................................. 14
8 Sample Review Checklists................................................................................................................. 15
9 Glossaries.......................................................................................................................................... 18
10 Document Control............................................................................................................................. 19

Doc Ref No: 1-6
Page 3 of 19
1 Introduction
This document describes the guidelines to review work products or artifacts such as documents, designs,
software code, and reports etc. Reviewing of work products happens after the creation or change and before
the approval of the work product. Reviewing the work products is a required quality assurance activity.
Review impacts cost, performance and risk factors. It is critical for success as well as improvements in all
spheres of business and technical activities.
Review methods:
Different types of work product may require different types of review methods. Reviews may use formal or
informal methods.
Informal Review method:
Sending a document’s review request through an email is widely used as an informal review method. Formal
reviews should be preferred over informal reviews. Research studies indicate that formal reviews greatly
outperform informal reviews in cost-effectiveness. Informal reviews may often be time-wasting through lack of
focus. Therefore while conducting informal reviews; reviewers must be communicated with the review focus
for their part in the form of review checklist or a statement.
Formal Review methods:
The following methods of formal reviews are generally used.
• Peer To Peer Review
• Walkthrough Review
• Inspection Review
Peer to Peer Review: ‘Peer to Peer Review’ takes place within peers who are familiar with the work product
and related aspects. The peers are individual persons or members of a team. The peers may have expertise
(skills and experience) in different areas related to different aspects the work product. After the author or the
producer has declared the work product to be complete, one or more peers do the review. The reviewers
may consult other persons if they are in doubt or require additional information. At the end of the review, the
reviewer completes the Review Records Form (Doc Ref No: 1-7) and sends the same to the producer.
Walkthrough Review: Walkthrough Reviews are conducted through a presentation where at least Author or
Producer, Recorder and Reviewers are present. Author or producer may also be the recorder. Author or
producer makes the presentation. In case of software code, presentation need not be done literally reading
line by line, but it should be more of a paraphrasing the code being reviewed. In case of documents, author
or producer may explain concepts along with reading the document. Reviewers can interrupt as soon as they
have found a defect or needs additional information. Then the point for interruption is discussed. Recorder
notes the defect if all agrees to it.
Inspection Review: Inspection Review is similar to the ‘Walkthrough Review’ except the addition of a
Moderator to the review team. Moderator checks the preparedness for everyone. Recorder notes the defect
when signaled by the moderator i.e. an agreement among review team is not required. Rest review process
is the same as ‘Walkthrough Review’. Often ‘Root Cause Analysis of defects’ is also done after the review is
completed.
Further details on review methods is available in the following section 3

Doc Ref No: 1-6
Page 4 of 19
Review Aspects:
All work products are not reviewed identically. Reviews may focus different quality assurance aspects for
different work products. These quality assurance aspects are combined into three main groups as given
bellow.
• Functional Aspects
• Technical Aspects
• Management Aspects
• Quality Standard Aspects
Functional Aspects: Here review focuses on the required functionality provided by the work product. Review
checks the adequacy of functionalities and missing functionalities. Reviewers may also suggest
improvements or alternative implementation ways for inadequacies of functionalities.
Technical Aspects: Here review focuses on work product engineering that may involve reviewing of design,
construction, testing and implementation aspects. Reviewers may also suggest improvements or alternative
implementation ways for inadequacies of functionalities.
Management Aspects: Management aspects of review is concerned mainly on management side of the
work product such as planning, resourcing and controlling costs, productivity, profitability and customer
service. Management aspects are reviewed before a work product is sent to the customer. Often
management aspects are part of the work product approval process. Reviews for management aspects can
be conducted in a formal meeting or just by one person.
Quality Standard Aspects: These review aspects focus on enforcing compliance with quality management
systems such as applying standards, following guidelines, identifying, analyzing and rectifying defects.
For further details on Review Aspects, please refer information in section 4.
Review Checklists:
Formal review methods require that all aspects of review are focused. Review checklists plays very important
role to help reviewers to focus attention, ask relevant questions and collect information about items included
in the checklists. Section 5 describes various review checklists for some of the work products.
Inadequate Reviews: Inadequate Reviews –
• may cause unexpected problems
• be very costly to rectify problems
• be the reason for failures
Take it seriously:
Reviews must be taken with seriousness. It is unavoidable and required activity. This guide will help you to
prepare for successfully doing reviews.

Doc Ref No: 1-6
Page 5 of 19
2 Definitions of Roles used during Review
The following Table 1 describes the roles required to perform formal reviews.
Role Role Definition
Author or Producer Author or Producer is an individual or a team of individuals who have created
the work product. The following are some of the responsibilities of an Author
or a Producer ensures readiness of work product for review, assists
moderator in planning for review, prepares for briefing in overview meeting,
fixes all defects identified, resolves all issues raised during Review, provides
process metrics to moderator.
Moderator Moderator is the person who organizes/controls the review meetings, selects
reviewers and assign roles, ensures work product readiness, schedules the
review meeting, ensures adherence to review objectives, determines work
product partitioning requirements, schedules overview meeting, ensures
receipt of required information by participants, ensure individual preparation
before logging meeting, triggers defect logging for the recorder, ensures
consensus on defects/issues logged, determine disposition of work product,
collects process metrics and distribute results ((Size, effort and defect data,
along with defect analysis) and determines need for updating any checklists.
Reviewer Reviewer is responsible for scrutinizing the document or the work product
under review, verifying its completeness and correctness make suggestions
and observations during the meeting ensuring active participation.
Reader Reader is a person who reads the document or the work product in the
Review meetings.
Recorder Recorder documents the issues discussed during the meeting in the form of
an action list. In case of Peer Review meetings the Recorder also documents
the defects observed during the review meeting. The Recorder will Record
defect after consensus is reached or on signal from Moderator, read back
recorded defect for verification, ensure information logged is clear, complete
and correct.
Table 1

Doc Ref No: 1-6
Page 6 of 19
3 Which Review method to use?
The following Table 2 shows some of the review activities performed under each type of reviews.
Objectives of Review Peer To
Peer
Review
Walkthroug
h Review
Inspection
Review
Manageme
nt Review
Check omissions, adequacy and defects √ √ √ √
Provide alternatives and improvements √
Check conformance to standards/
specifications
Examine issues of following guidelines
√ √
Check if the work product is suitable for
release
√
Collect data for process improvement √
Table 2
The Table 3 shows the work products and which review may be used on the work products.
Work Product Name Peer To
Peer
Review
Walkthrou
gh Review
Inspection
Review
Managem
ent
Review
Business Processes, Forms, Templates,
Guidelines, Standards and similar
documents
√ √ √ √
Program or Project estimates, plans and
schedules
√ √ √ √
Requirements or Statement of Work √ √
Functional Specifications and Acceptance
Test Plans
√ √ √
Test Cases √
Software Code √
Design Documents √ √
Table 3

Doc Ref No: 1-6
Page 7 of 19
4 What are various aspects of reviews?
The following Table 4 gives describes the details of review aspects. Please note. This is not a complete list.
You can use this list to create the review checklist for a work product. Section 5 describes review checklists
for few work products. You can improve over these checklists by using information on review aspects.
Review aspect What to focus during the Review?
Compliance with contractual
requirements
The main focus of this review aspect is the
Statement of Work (SOW) and the Contract.
• Contractual requirements are part of the SOW.
• Standards and specifications included by
reference in the contract.
Completeness A document or product may be in process and not
yet completed at the time of the review. Because of
this, the reviewer must judge whether the degree of
completeness at a particular time is adequate.
At every stage of document development, all
required sections and section headers should be
present. Completeness of paragraph content
depends upon when the required information is, or
should be, known. Criteria that may apply,
depending on the document, include identified and
appropriate –
• intent and purpose of the document
• document audience
• timeframes
• contact information
• reviews and approvals
The sources of information to assist in making this
determination include associated documentation on
planning and execution.
Functionality
Aspects
Appropriate content for
intended audience
A document is targeted at an audience, and its
review must focus on how well it is able to meet the
needs of the targeted audience. If there are
guidelines, reviewers must use the guidelines.
However, the reviewers may be required to make
judgment as to whether the material provided is
suitable for the intended audience.
For example, an application user may not need
design details which are critical for development and
support personnel.

Doc Ref No: 1-6
Page 8 of 19
Technical adequacy Understanding of Technical adequacy at times may
be complex and require technical knowledge and
skills. In general reviewers may cover the following:
• Are there violation of known facts or principles
• Consistent with approaches known to be
successful
• Well researched or based on proven prototypes
• Well thought out, not thrown together
• Make sense both technically and practically
Technical Feasibility Feasibility is the degree to which plans,
requirements, or design can be implemented given
the state of the art, schedule and resource
constraints, available tools, techniques, and other
factors.
An additional consideration is that items that are
feasible in isolation may not be feasible when taken
together. Each item must therefore be evaluated in
the context of accompanying items.
Technical
Aspects
Traceability Traceability means that the document being
reviewed is in agreement with any predecessor
documents. Traceability has three criteria:
• The document fully implements the applicable
stipulations of a predecessor document
• All material in a subsequent or lower-level
document has its basis in the predecessor
document, that is, no untraceable material has
been introduced
• The two documents do not contradict one
another.
plus
• A referenced section contains the information or
otherwise fully implements the applicable
stipulations indicated in the reference,
• All material in a lower-level or detailed section of
the document has its basis in the predecessor
sections, that is, no untraceable material has
been introduced
• The sections of the document do not contradict
one another.

Doc Ref No: 1-6
Page 9 of 19
Testability of requirements A requirement is considered to be testable if an
objective, feasible test can be designed to determine
whether the requirement is met by the solution. An
example of an untestable requirement is “The
module shall be composed of small units that
execute as quickly as possible.” A testable
requirement would state “The module shall be
composed of units each smaller than 500 lines of
executable code, and each executing in under 10
microseconds.”
Adequate test coverage of
requirements
This factor applies to test planning documents.
Questions to be asked include:
• Is every requirement addressed by at least one
test?
• Have test cases been selected for an “average”
situation as well as for “boundary”
• Situations such as minimum and maximum
values?
• Have “stress” cases been selected, such as out-
of-bounds values?
• Have meaningful combinations of inputs been
selected?
• Are test cases efficient in that they do not test
the same feature over and over?
Support of enterprise
architectures
This factor evaluates the document’s agreement
with such defined strategies and models. Questions
to be asked is ‘Does it agree with defined enterprise
views and support/align with the data and
application architecture?’.
Adherence to documentation
standards
This factor identifies appropriate and applicable
documentation standards and required or
recommended document formats and assesses
adherence to these. In most cases required format
for document is the template for a document type.
Other sources are project or contractor-proposed
formats and special contract-specified formats.
Evaluation should be relatively straightforward
based upon the applicable guidance.
Quality
Assurance
Aspects
Consistency The document being evaluated does not contradict
itself or with references in either content or style.
Criteria for consistency include:
• All statements must be compatible,
• A given term must have the same meaning
throughout,
• A given item or concept must be referred to by
the same name or description throughout, and
• The level of detail and presentation style must

Doc Ref No: 1-6
Page 10 of 19
be the same throughout.
Readability, comprehensibility
and general understandability
The ease with which the document can be
comprehended.
Criteria include:
• Use of generally accepted rules of grammar,
capitalization, punctuation, symbols, and
notation
• Non-standard terms, phrases, acronyms, and
abbreviations are defined
• The level of complexity is appropriate to the
intended audience
• The material being presented can be interpreted
in unique way
Use of appropriate
requirement, design, or coding
techniques
A contract may describe exceptions or
augmentations to the techniques that have been
approved. The statement of work (SOW) may also
expand upon, clarify, or change the technique to be
used. These sources should be the basis for
determining the techniques to be used and for
evaluating compliance.
Appropriate level of detail Level of detail is a subjective factor whose
evaluation must be based on the intended use and
audience of the document. A document can err in
either direction: a document that is supposed to
provide an overview might be too detailed and a
document that is supposed to provide details might
be too high-level. Review of the applicable
documentation plan, document descriptor, and other
documents of the same type may aid in determining
whether the level of detail is appropriate.
Allocation of sizing, timing, or
resources
• The total of the allocated amounts is within the
overall allocation.
• Do the allocations seem realistic and feasible?
• Do the allocations take into account the
demands on each unit component, or do they
seem to be mere mechanical allocations, such
as dividing available resources by number of
units?
• Are the allocations based on prototyping and
other analysis, or just on guesswork?
Adequacy of proposed tools,
facilities, procedures, or
resources
This review factor applies to planning documents.
Evaluation requires judgment as to whether the
proposed items will be adequate to fulfill their
intended purpose. A useful evaluation technique is
comparison with past projects, when possible.
Management
Aspects
Alignment with the Documents will be evaluated for adherence to, and

Doc Ref No: 1-6
Page 11 of 19
management objectives support of management objectives.
Table 4

Doc Ref No: 1-6
Page 12 of 19
5 What types of activities are performed during reviews?
The activities performed during reviews depend upon the work product and the review method used. The
following is the partial list of generic activities that may be performed during reviews.
• Read the original and referenced documents and records
• Explain concepts with relevant examples with facts and figures
• Check for information required for checklist items and complete the checklist
• Discuss issues from various angles and aspects
• Logging observations about omissions, inconsistencies, deviations and defects
• Cross checking with references, standards and guidelines
• Validate financial and other vital figures
• Refer issues to experts or authorities external to the review team and get their views
• Do root cause and other analysis such as reconciliation
• Suggesting alternate ways and improvements
• Prepare and submit review reports and update review records

Doc Ref No: 1-6
Page 13 of 19
6 What skills are needed to perform reviews?
Looking at the information in section 4, it is obvious that review focus has large scope. To perform reviews
one must have adequate skills required by various review aspects. As a single person is most likely not to
have all of the skills, more than one reviewer or a review team is required where a member of review team
can focus of a particular set of review aspects.
The following are the broad classification of skills from reviews perspective.
• Functional
• Technical
• Quality Assurance
• Managements
Functional Expertise: Functional expertise refers to the skills and experience in particular functional areas.
People with these skills are often called business analysts or simply analysts, accountants, consultants,
subject matter experts etc. People in executive roles and functional heads may also qualify for functional
expertise.
Technical Expertise: Technical expertise refers to the skills and experience in science and engineering
related functional areas such as analysis, design, construction, testing, implementation, maintenance and
support. People with these skills are often called engineers, technician, system analysts, architects,
designers, technical consultants, subject matter experts etc. People in executive roles and technical heads
may also qualify for technical expertise.
Quality Assurance Expertise: Quality assurance expertise refers to the skills and experience in one or
more quality systems and process improvement methodologies such as ISO, SCI-CMM, Six Sigma, Business
Process Re-engineering etc. People with these skills are often called quality analyst, auditors, inspectors,
quality consultants etc. People in executive roles quality assurance and quality assurance heads may also
qualify for technical expertise.
Management Expertise: Management expertise refers to the skills and experience in managing functional
and technical areas. People with these skills are often called executives, managers, administrators, heads,
management experts etc.
Along with type of expertise, the level of expertise is important consideration for being a reviewer. Right type
and level of expertise will ensure successful reviews.

Doc Ref No: 1-6
Page 14 of 19
7 How to record and report outcome of reviews?
Outcome of review is recorded in various ways depending upon the work product under review. All reviews
must complete the Review Records form (Doc Ref No: 1-7) and if required, document root cause analysis,
alternatives and improvements.

Doc Ref No: 1-6
Page 15 of 19
8 Sample Review Checklists
The following are few sample checklists for specific work products. The checklists given here are yet not
comprehensive and will be updated in due course. We have yet not created a template for the review
checklist. We intend to create a one page checklist common to all work product and one page checklist
specific to the work product.
Work Products Checks to do during the Review
Business Processes,
Guidelines, Standards,
Templates, Forms and
documents based on the
templates
• Has the document been created using a template?
• Has the Guidelines for Documents Authoring been followed?
• Has the spell checker been run?
• Is the document complete with all sections?
• Has something been omitted such as procedure or a concept?
• Do you have any concern about the validity of concepts and procedures?
• Is the document detailed and easy to understand?
• Are the referenced documents’ references correct?
• Are there any contradictions at the Entry and Exit stage of the process?
• Are there any violations of Policies and Business Rules?
• Will it improve the existing process?
• Have the related other documents also updated in case of a change?
• Is training required to implement the new process or the changes?
• Are there any implementation problems?
•
All types of Project Plans,
Estimates and Schedules
• Is the project scope clear and well defined?
• Is the start and end date clear?
• Is the list of Control and Configuration items been prepared?
• Is the list of the current team members maintained?
• Are the resources suggested in the Resource Plan/Training plan suggested
along with Proposal available and are they adequate? (If required)
• Are Roles and responsibilities of all the team members have been defined?
• Is the frequency of Project Status Review defined?
• Is the method of communication with the client clear?
• Are details of Onsite Contact person have been given?
• Is H/W and S/W development environment defined?
• Is Familiarization procedure mentioned?
• Is delivery procedure mentioned?
• Is deemed acceptance criteria defined?
• Is workflow explained?
• Is Change Request procedure defined?
• Is project having any deviations?
• If Yes, List of deviations (Deviation document) has been maintained?
• Are milestones, delivery schedule and deliverables maintained?
• Is the Project team members training Plan prepared? (if required)
• Is the procedure for status reporting clear?
• Does it cover timesheet analysis, Link failures, Server problems, etc.
• Is Acceptance Criteria clear?
• Is Risk Management Plan prepared?
• Is project end procedure mentioned?
Is Inter group co-ordination activities defined?
Software Requirements • Are the requirements complete, consistent, accurate and testable?
• Are external and internal interfaces properly identified and defined?
• Are the requirements traceable to system level agreed and approved?

Doc Ref No: 1-6
Page 16 of 19
• Are security & performance requirements defined?
• Are system constraints and assumptions documented?
• Are validation/acceptance criteria complete?
• Is acceptance criteria clearly defined?
Functional Specifications
(FS)
• Is the template for FS used?
• Is FS detailed enough?
• Is FS unambiguous & traceable to requirements?
• Are all requirements covered in FS?
• Are flow charts/diagrams correct & self-explanatory?
• Are cross-references to flow charts/diagrams, sections correct?
• Are there any Critical/High Risk deliverables such as screens /queries/
reports that will be used by highest authority (e.g. CEO) at the customer
end?
System Design • Are Design Specification & System Test Plan detailed?
• Is Design Specification traceable to Functional Specification?
• Is design modular?
• Are requirements reflected in the architecture?
• Are modules∗
functionally independent?
• Are interfaces defined for modules and external system?
• Is data structure consistent with requirements?
• Has maintainability been considered?
• Does the algorithm accomplish the desired function?
• Is the algorithm logically correct?
• Is the interface consistent with the logical design?
• Have error handling methods been specified?
• Are local data structures been properly defined?
• Is design detail amenable to implementation language?
• Is required performance achievable within the constraints imposed by the
suggested system environment?
• Are all boundary conditions, error conditions identified & addressed in
Design Specification?
• Is Database/Files integrity maintained?
• Is volume of processing for all tables/files identified?
• Have performance issues/implications been examined and assessed? If
yes, please note aspects reviewed.
Test Cases General
• Traceability to requirements
• Boundary conditions : (Loops, Range/discrete values)
• Condition branches
• Initialization/Default values
• Computation (overflow, underflow, precision, rounding)
User Interface
• Look and feel/Screen Layout
• Reports (Layout, sort order, Page/control totals)
• Error/Exception handling
• Messages (Grammar, Spelling, Informative)
Database/File
• Triggers

Doc Ref No: 1-6
Page 17 of 19
• Transactions (locking, recovery, restart)
• Update/Retrieval
• Access control
Table 5

Doc Ref No: 1-6
Page 18 of 19
9 Glossaries
The glossary entries in this section are specific to this document. ……
Abbreviation Description
DCR Document Change Request
Info Information
MS Microsoft
Proc Process
SOW Statement of Work
CEO Chief Executive Officer
H/W Hardware
S/W Software
FS Functional Specifications
GDL Guidelines
FRM Form

Doc Ref No: 1-6
Page 19 of 19
10 Document Control
Access Control and Distribution
This is a controlled document. It is available in MS Word versions which can be printed.
Its access is controlled as per the document management process.
Approved by
Name Designation Date Signature
Ashok Kumar LalSingh Director, RASS Tools Ltd.
Released by
Name Designation Date Signature
Ashok Kumar LalSingh Director, RASS Tools Ltd.
Reviewed by
Name Designation Review Requirement
Changes Summary Log
Issue No Date Changed by Changes summary
1 08/12/2009 Ashok Kumar LalSingh First release

Guidelines to Review Work products

More Related Content

What's hot (20)

Viewers also liked (13)

Similar to Guidelines to Review Work products (20)

More from Ashok Kumar (11)

Guidelines to Review Work products