SlideShare una empresa de Scribd logo
1 de 19
Descargar para leer sin conexión
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
Document Template Reference No: 1-3
Copyright © RASS Tools Limited, UK
Website: www.rasstools.com,
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
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
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
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
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.
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
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
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
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
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
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.
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
Page 8 of 19
Review aspect What to focus during the Review?
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.
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
Page 9 of 19
Review aspect What to focus during the Review?
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
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
Page 10 of 19
Review aspect What to focus during the Review?
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
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
Page 11 of 19
Review aspect What to focus during the Review?
management objectives support of management objectives.
Table 4
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
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
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
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.
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
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.
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
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?
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
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
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
Page 17 of 19
• Transactions (locking, recovery, restart)
• Update/Retrieval
• Access control
Table 5
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
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
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
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

Más contenido relacionado

La actualidad más candente

Webinar: Europe's new Medical Device Regulations (MDR)
Webinar: Europe's new Medical Device Regulations (MDR)Webinar: Europe's new Medical Device Regulations (MDR)
Webinar: Europe's new Medical Device Regulations (MDR)EMERGO
 
Human factors and ergonomics society 20120311
Human factors and ergonomics society 20120311Human factors and ergonomics society 20120311
Human factors and ergonomics society 20120311Jones Wu
 
Software engineering srs library management assignment
Software engineering srs library management assignmentSoftware engineering srs library management assignment
Software engineering srs library management assignmentRajat Mittal
 
ISO 13485:2016 Revisions Webinar
ISO 13485:2016 Revisions WebinarISO 13485:2016 Revisions Webinar
ISO 13485:2016 Revisions WebinarDQS Inc.
 
SOA Fundamentals
SOA  FundamentalsSOA  Fundamentals
SOA Fundamentalsabhi1112
 
ISO 27001 management clause 7 support - by software development company in india
ISO 27001 management clause 7 support - by software development company in indiaISO 27001 management clause 7 support - by software development company in india
ISO 27001 management clause 7 support - by software development company in indiaiFour Consultancy
 
Iso 14971 2019
Iso 14971 2019Iso 14971 2019
Iso 14971 2019Suhas R
 
University management software
University management softwareUniversity management software
University management softwarevinodhini1
 
Software development plan template
Software development plan templateSoftware development plan template
Software development plan templateRina Wijaya
 
Abbott overview medical device human factors standards
Abbott overview medical device human factors standardsAbbott overview medical device human factors standards
Abbott overview medical device human factors standardsJones Wu
 
Future of EU In Vitro Diagnostics Regulation
Future of EU In Vitro Diagnostics RegulationFuture of EU In Vitro Diagnostics Regulation
Future of EU In Vitro Diagnostics RegulationErik Vollebregt
 
Steps to iso 27001 implementation
Steps to iso 27001 implementationSteps to iso 27001 implementation
Steps to iso 27001 implementationRalf Braga
 
Project report college information management system on Advanced Java
Project report college information management system on Advanced JavaProject report college information management system on Advanced Java
Project report college information management system on Advanced JavaRishabh Kumar ☁️
 
DevOps to DevSecOps Journey..
DevOps to DevSecOps Journey..DevOps to DevSecOps Journey..
DevOps to DevSecOps Journey..Siddharth Joshi
 
Student biometric identification srs
Student biometric identification srsStudent biometric identification srs
Student biometric identification srsHassaan Afzal
 

La actualidad más candente (20)

Webinar: Europe's new Medical Device Regulations (MDR)
Webinar: Europe's new Medical Device Regulations (MDR)Webinar: Europe's new Medical Device Regulations (MDR)
Webinar: Europe's new Medical Device Regulations (MDR)
 
Human factors and ergonomics society 20120311
Human factors and ergonomics society 20120311Human factors and ergonomics society 20120311
Human factors and ergonomics society 20120311
 
Software engineering srs library management assignment
Software engineering srs library management assignmentSoftware engineering srs library management assignment
Software engineering srs library management assignment
 
ISO 13485:2016 Revisions Webinar
ISO 13485:2016 Revisions WebinarISO 13485:2016 Revisions Webinar
ISO 13485:2016 Revisions Webinar
 
IEEE 12207
IEEE 12207IEEE 12207
IEEE 12207
 
SOA Fundamentals
SOA  FundamentalsSOA  Fundamentals
SOA Fundamentals
 
ISO 27001 management clause 7 support - by software development company in india
ISO 27001 management clause 7 support - by software development company in indiaISO 27001 management clause 7 support - by software development company in india
ISO 27001 management clause 7 support - by software development company in india
 
Iso 14971 2019
Iso 14971 2019Iso 14971 2019
Iso 14971 2019
 
University management software
University management softwareUniversity management software
University management software
 
Software development plan template
Software development plan templateSoftware development plan template
Software development plan template
 
Online banking
Online bankingOnline banking
Online banking
 
Cloud computing
Cloud computing Cloud computing
Cloud computing
 
Abbott overview medical device human factors standards
Abbott overview medical device human factors standardsAbbott overview medical device human factors standards
Abbott overview medical device human factors standards
 
Future of EU In Vitro Diagnostics Regulation
Future of EU In Vitro Diagnostics RegulationFuture of EU In Vitro Diagnostics Regulation
Future of EU In Vitro Diagnostics Regulation
 
IEC 62304 Action List
IEC 62304 Action List IEC 62304 Action List
IEC 62304 Action List
 
Steps to iso 27001 implementation
Steps to iso 27001 implementationSteps to iso 27001 implementation
Steps to iso 27001 implementation
 
Project report college information management system on Advanced Java
Project report college information management system on Advanced JavaProject report college information management system on Advanced Java
Project report college information management system on Advanced Java
 
DevOps to DevSecOps Journey..
DevOps to DevSecOps Journey..DevOps to DevSecOps Journey..
DevOps to DevSecOps Journey..
 
GHTF Group 1
GHTF  Group 1GHTF  Group 1
GHTF Group 1
 
Student biometric identification srs
Student biometric identification srsStudent biometric identification srs
Student biometric identification srs
 

Destacado

Portal suradnici-u-učenju-1-2
Portal suradnici-u-učenju-1-2Portal suradnici-u-učenju-1-2
Portal suradnici-u-učenju-1-2Emilija Polonijo
 
comparing education than&now
comparing education than&nowcomparing education than&now
comparing education than&nowgabby220
 
Material didáctico: Nombre de en inglés
Material didáctico: Nombre de en inglésMaterial didáctico: Nombre de en inglés
Material didáctico: Nombre de en inglésgennyjm
 
Spot fitness power point pitch
Spot fitness power point pitch Spot fitness power point pitch
Spot fitness power point pitch Marshall Nash
 
Empreendedorismo Criativo - O Mundo Mudou - Sessão com G. Lito
Empreendedorismo Criativo - O Mundo Mudou - Sessão com G. LitoEmpreendedorismo Criativo - O Mundo Mudou - Sessão com G. Lito
Empreendedorismo Criativo - O Mundo Mudou - Sessão com G. LitoGuilherme Lito
 
นำเสนอธาลัสซีเมียใหม่ 1
นำเสนอธาลัสซีเมียใหม่ 1นำเสนอธาลัสซีเมียใหม่ 1
นำเสนอธาลัสซีเมียใหม่ 1Thayacup
 
Sae Ahq Troy Mich Useful Info
Sae Ahq Troy Mich Useful InfoSae Ahq Troy Mich Useful Info
Sae Ahq Troy Mich Useful Inforedcedarmedia
 
Migrating a US Army Application to the Cloud | AWS Public Sector Summit 2016
Migrating a US Army Application to the Cloud | AWS Public Sector Summit 2016Migrating a US Army Application to the Cloud | AWS Public Sector Summit 2016
Migrating a US Army Application to the Cloud | AWS Public Sector Summit 2016Amazon Web Services
 
Conf decisiones 2.0
Conf decisiones 2.0Conf decisiones 2.0
Conf decisiones 2.0ort
 

Destacado (14)

Portal suradnici-u-učenju-1-2
Portal suradnici-u-učenju-1-2Portal suradnici-u-učenju-1-2
Portal suradnici-u-učenju-1-2
 
comparing education than&now
comparing education than&nowcomparing education than&now
comparing education than&now
 
Re
ReRe
Re
 
Material didáctico: Nombre de en inglés
Material didáctico: Nombre de en inglésMaterial didáctico: Nombre de en inglés
Material didáctico: Nombre de en inglés
 
Spot fitness power point pitch
Spot fitness power point pitch Spot fitness power point pitch
Spot fitness power point pitch
 
Empreendedorismo Criativo - O Mundo Mudou - Sessão com G. Lito
Empreendedorismo Criativo - O Mundo Mudou - Sessão com G. LitoEmpreendedorismo Criativo - O Mundo Mudou - Sessão com G. Lito
Empreendedorismo Criativo - O Mundo Mudou - Sessão com G. Lito
 
นำเสนอธาลัสซีเมียใหม่ 1
นำเสนอธาลัสซีเมียใหม่ 1นำเสนอธาลัสซีเมียใหม่ 1
นำเสนอธาลัสซีเมียใหม่ 1
 
แผนที่ 8 การนำไปใช้ 1
แผนที่ 8 การนำไปใช้ 1 แผนที่ 8 การนำไปใช้ 1
แผนที่ 8 การนำไปใช้ 1
 
Sae Ahq Troy Mich Useful Info
Sae Ahq Troy Mich Useful InfoSae Ahq Troy Mich Useful Info
Sae Ahq Troy Mich Useful Info
 
Migrating a US Army Application to the Cloud | AWS Public Sector Summit 2016
Migrating a US Army Application to the Cloud | AWS Public Sector Summit 2016Migrating a US Army Application to the Cloud | AWS Public Sector Summit 2016
Migrating a US Army Application to the Cloud | AWS Public Sector Summit 2016
 
Pres3
Pres3Pres3
Pres3
 
Nutricionenteralyparenteral
NutricionenteralyparenteralNutricionenteralyparenteral
Nutricionenteralyparenteral
 
Conf decisiones 2.0
Conf decisiones 2.0Conf decisiones 2.0
Conf decisiones 2.0
 
1. lmp 13 al 24 de marzo.
1. lmp  13 al 24 de marzo.1. lmp  13 al 24 de marzo.
1. lmp 13 al 24 de marzo.
 

Similar a Guidelines to Review Work products

Chapter 3 Static Techniques
Chapter 3 Static TechniquesChapter 3 Static Techniques
Chapter 3 Static TechniquesZetryan Satria
 
03. static techniques
03. static techniques03. static techniques
03. static techniquesTricia Karina
 
Static techniques
Static techniquesStatic techniques
Static techniqueseva khasana
 
Chapter Three Static Techniques
Chapter Three Static TechniquesChapter Three Static Techniques
Chapter Three Static Techniqueselvira munanda
 
Testing 1 static techniques
Testing 1 static techniquesTesting 1 static techniques
Testing 1 static techniquesMini Marsiah
 
Static techniques
Static techniquesStatic techniques
Static techniquesargawanda
 
Improving quality through software inspections
Improving quality through software inspectionsImproving quality through software inspections
Improving quality through software inspectionsgeorge_ionita
 
static techniques
static techniquesstatic techniques
static techniquesaidil fitra
 
Static nopri wahyudi
Static nopri wahyudiStatic nopri wahyudi
Static nopri wahyudiNopriwahyudi
 
Ch 5 - Requirement Validation.pptx
Ch 5 - Requirement Validation.pptxCh 5 - Requirement Validation.pptx
Ch 5 - Requirement Validation.pptxbalewayalew
 
Testing & implementation system 3-wm
Testing & implementation system 3-wmTesting & implementation system 3-wm
Testing & implementation system 3-wmWiwik Muslehatin
 
CHAPTER 1 BASIC CONCEPTS AND PRELIMINARIES
CHAPTER 1 BASIC CONCEPTS AND PRELIMINARIESCHAPTER 1 BASIC CONCEPTS AND PRELIMINARIES
CHAPTER 1 BASIC CONCEPTS AND PRELIMINARIESSamruddhi Sheth
 

Similar a Guidelines to Review Work products (20)

Chapter 3 Static Techniques
Chapter 3 Static TechniquesChapter 3 Static Techniques
Chapter 3 Static Techniques
 
3.static techniques
3.static techniques3.static techniques
3.static techniques
 
Bab 3
Bab 3Bab 3
Bab 3
 
Static techniques
Static techniquesStatic techniques
Static techniques
 
03. static techniques
03. static techniques03. static techniques
03. static techniques
 
Static techniques
Static techniquesStatic techniques
Static techniques
 
Chapter Three Static Techniques
Chapter Three Static TechniquesChapter Three Static Techniques
Chapter Three Static Techniques
 
Testing 1 static techniques
Testing 1 static techniquesTesting 1 static techniques
Testing 1 static techniques
 
Static techniques
Static techniquesStatic techniques
Static techniques
 
Improving quality through software inspections
Improving quality through software inspectionsImproving quality through software inspections
Improving quality through software inspections
 
Static techniques
Static techniquesStatic techniques
Static techniques
 
static techniques
static techniquesstatic techniques
static techniques
 
Static nopri wahyudi
Static nopri wahyudiStatic nopri wahyudi
Static nopri wahyudi
 
Ch 5 - Requirement Validation.pptx
Ch 5 - Requirement Validation.pptxCh 5 - Requirement Validation.pptx
Ch 5 - Requirement Validation.pptx
 
Static techniques
Static techniquesStatic techniques
Static techniques
 
Static techniques
Static techniquesStatic techniques
Static techniques
 
Testing & implementation system 3-wm
Testing & implementation system 3-wmTesting & implementation system 3-wm
Testing & implementation system 3-wm
 
Static techniques
Static techniquesStatic techniques
Static techniques
 
CHAPTER 1 BASIC CONCEPTS AND PRELIMINARIES
CHAPTER 1 BASIC CONCEPTS AND PRELIMINARIESCHAPTER 1 BASIC CONCEPTS AND PRELIMINARIES
CHAPTER 1 BASIC CONCEPTS AND PRELIMINARIES
 
Static techniques
Static techniquesStatic techniques
Static techniques
 

Más de Ashok Kumar

Project controls
Project controlsProject controls
Project controlsAshok Kumar
 
E pmo governance 20190630
E pmo governance   20190630E pmo governance   20190630
E pmo governance 20190630Ashok Kumar
 
Buy to let property investment roi
Buy to let property investment   roiBuy to let property investment   roi
Buy to let property investment roiAshok Kumar
 
E pmo governance 20130624
E pmo governance   20130624E pmo governance   20130624
E pmo governance 20130624Ashok Kumar
 
E pmo governance 2013
E pmo governance   2013E pmo governance   2013
E pmo governance 2013Ashok Kumar
 
Process_Modeling
Process_ModelingProcess_Modeling
Process_ModelingAshok Kumar
 
MIC sme overview
MIC sme overviewMIC sme overview
MIC sme overviewAshok Kumar
 
Documents Control Process
Documents Control ProcessDocuments Control Process
Documents Control ProcessAshok Kumar
 
Project Schedule Development Guidelines
Project Schedule Development GuidelinesProject Schedule Development Guidelines
Project Schedule Development GuidelinesAshok Kumar
 
Project Management Plan Template
Project Management Plan TemplateProject Management Plan Template
Project Management Plan TemplateAshok Kumar
 

Más de Ashok Kumar (11)

Project controls
Project controlsProject controls
Project controls
 
E pmo governance 20190630
E pmo governance   20190630E pmo governance   20190630
E pmo governance 20190630
 
Buy to let property investment roi
Buy to let property investment   roiBuy to let property investment   roi
Buy to let property investment roi
 
E pmo governance 20130624
E pmo governance   20130624E pmo governance   20130624
E pmo governance 20130624
 
E pmo governance 2013
E pmo governance   2013E pmo governance   2013
E pmo governance 2013
 
RASS HR
RASS HRRASS HR
RASS HR
 
Process_Modeling
Process_ModelingProcess_Modeling
Process_Modeling
 
MIC sme overview
MIC sme overviewMIC sme overview
MIC sme overview
 
Documents Control Process
Documents Control ProcessDocuments Control Process
Documents Control Process
 
Project Schedule Development Guidelines
Project Schedule Development GuidelinesProject Schedule Development Guidelines
Project Schedule Development Guidelines
 
Project Management Plan Template
Project Management Plan TemplateProject Management Plan Template
Project Management Plan Template
 

Guidelines to Review Work products

  • 1. 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.
  • 2. 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 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
  • 3. 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 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
  • 4. 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 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.
  • 5. 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 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
  • 6. 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 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
  • 7. 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 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.
  • 8. 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 Page 8 of 19 Review aspect What to focus during the Review? 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.
  • 9. 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 Page 9 of 19 Review aspect What to focus during the Review? 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
  • 10. 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 Page 10 of 19 Review aspect What to focus during the Review? 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
  • 11. 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 Page 11 of 19 Review aspect What to focus during the Review? management objectives support of management objectives. Table 4
  • 12. 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 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
  • 13. 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 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.
  • 14. 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 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.
  • 15. 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 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?
  • 16. 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 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
  • 17. 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 Page 17 of 19 • Transactions (locking, recovery, restart) • Update/Retrieval • Access control Table 5
  • 18. 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 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
  • 19. 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 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