Requirements Review Peer Review Criteria

This checklist is tailorable to meet the needs and expectations unique to each project and used to complete a quality
review of a requirements work product. The problems, errors, or non-conformance items identified should be documented
on a Peer Review Feedback Form. Please reference the Quality Management Plan for additional information on the Peer
Review Process.

Requirements Review Criteria

Requirements Review

Item Problem Category & Type* Yes/No/Comments

1.0 Documentation
1.1 Typos - Typographical errors

1.1.1 Did the document successfully pass spelling & grammar review?
- [Please enter other criteria specific to your project]
Form and Format - Incorrect or inconsistent paragraph titling, indentation, list identifiers, type style, writing style, and
1.2 location of information are among the form and format problems covered by this type.

Does the cover page or document control log have the correct
1.2.1 information?
1.2.2 Is the version number properly utilized (e.g., Draft = Release_Draft #)?
Do the drafts have the version number correctly incremented from the last
1.2.3 document?
Do the dates on the document match (e.g., cover page and
1.2.4 header/footers)?
Does the document show where it is maintained (documents repository
1.2.5 and versioned)?
1.2.6 Was the correct template used to create the document?

Does the document contain all the information required by the template,
1.2.7 with any omitted or added sections approved beforehand?
1.2.8 Is the Table of Contents accurate and correctly formatted?
1.2.9 Are header/footers consistent throughout the document?
1.2.10 Is the document consistent in style and tone?
- [Please enter other criteria specific to your project]
Content - This type is the first type in which the conformance crosses over into the subjective realm. Obvious omissions
of information are entered. However, less obvious is the lack of sufficient detail to make the document understandable and
1.3 usable. This type is a common problem type for which the solution is not simple.

1.3.1 Does the document have any incorrect information?

1.3.2 Does the document have any obvious omission of information?

Does the document have any vague or insufficient details that would make
1.3.3 the document unusable?

©2004 Accenture. All Rights

Page 1 of 6 Date Printed: 03/29/2024
Reserved.
 Requirements Review Peer Review Criteria

Item Problem Category & Type* Yes/No/Comments

1.3.4 Will the target audience understand the document?

1.3.5 Are the use of jargons or abbreviations defined within the document?
- [Please enter other criteria specific to your project]
Quality Review Rejection - Similar to customer dissatisfaction, independent quality review rejections should be
1.4 recorded and sub-typed for later analysis.
Does the document or a section of the document need to be reviewed at a
1.4.1 later time due to the fact it was not ready for review?
- [Please enter other criteria specific to your project]

Requirements - are what functions to expect a system to perform and at what level of performance the functions are
2.0 desired. Good requirements are specific, measurable and attainable within the time given.

Interface - Problems of this type encompass hardware to software, software to software, and man to machine (also
2.1 referred to as user system) interface requirements.

Do the requirements specify all the technical interface constraints that

must be met (e.g., The application must be accessed via IE 4+ and
2.1.1 Netscape 4+ browsers)?
Do the requirements specify measurable objectives that describe the
speed of a system (e.g., 20,000 concurrent users should be able to be
2.1.2 supported on the system)?
- [Please enter other criteria specific to your project]
Data Definition - Problems of this type encompass improper definition of data base size and structure, critical
2.2 parameters, and limitations on data.
Do the requirements specify measurable objectives that describe any
2.2.1 critical parameters?
Do the requirements specify measurable objectives that describe any
2.2.2 limitations on data?
Do the requirements specify measurable objectives that describe the data
2.2.3 base size and structure?
- [Please enter other criteria specific to your project]
Functional Statement - Problems of this type cover inaccurate statement of the requirement, incorrect interpretation
2.3 of the requirements, failure to state a requirement, and omission of special processing limitations.

2.3.1 Are sentences and paragraphs kept short and concise?

Are the requirements written clearly so that they are easily understood by
2.3.2 the client/user?
Do the requirements specify what the user should be able to do on a
system (e.g., The user should be able to compare two products from the
2.3.3 same manufacturer)?

©2004 Accenture. All Rights

Page 2 of 6 Date Printed: 03/29/2024
Reserved.
 Requirements Review Peer Review Criteria

Item Problem Category & Type* Yes/No/Comments

Do the requirements specify the level of difficulty it should take for a user
to complete a task (e.g., The user should be able to return to the home
2.3.4 page from any other page on the site)?
Are the requirements documented as individual testable items? Note:
2.3.5 Avoid long narrative paragraphs containing more than one requirement.
Does a requirements statement use “and/or” or “etc."? This suggests that
2.3.6 several requirements have been combined into one.
Does each requirement contain a subject and predicate where the subject
is a user type or the system under discussion, and the predicate is a
2.3.7 condition, action or intended result?
2.3.8 Does the whole requirement specify a desired end goal or result?
Does each requirement form a complete sentence (not a bullet list of buzz
2.3.9 words, lists of acronyms, or sound bites on a slide)?

Are the requirements documented at a consistent level of detail, making

2.3.10 sure that a stated requirement does not contradict other requirements?

Are the requirements individually defined as necessary to the

system/application (i.e., if the requirement were to be removed or deleted,
2.3.11 a deficiency would exist that could not be fulfilled by other requirements)?
Can the requirements be verified through inspection, analysis,
2.3.12 demonstration or test?
- [Please enter other criteria specific to your project]

©2004 Accenture. All Rights

Page 3 of 6 Date Printed: 03/29/2024
Reserved.
Please Note: This checklist can be tailored to meet the needs of each project. It is used to address unique scenarios for each project and is used during initial

Automation Checklist
Automation Project Checklist

Item Problem Category & Type Yes/No Comments

1.0 Framework and Environment Setup

1.1 Automation Tool

1.1.1 Automation Tool is available with valid license for all Team members

1.1.2 Configuration is consistent across developer machines

1.1.3 Necessary add-ins are available/loaded to support the application

1.2 Quality Center or Test Script Repository

Project Folder is created within the repository for the application being
1.2.1 automated

1.2.2 Project Folder is accessible by automation team members

Approval for loading the scripts in the repository has been received by
1.2.3 Team Lead or resource designated by the Team Lead

1.2.4 QTP and/or other add-ins are loaded in Quality Center or repository

Proper Permissions (ie. read-write-delete) are granted for Quality Center

1.2.5 or chosen repository

1.3 Identification of a test cases for the automation

1.3.1 Is Regression suite consistent across the release?

1.3.2 Are test cases within the Regression suite valid?

Are there known changes in the functionality impacting the regression test
1.3.3 suite?
If there is a change in functionality in the regression test suite, has the
1.3.4 change request been shared with automation team?

1.3.5 How many test cases are planned for automation?

In the testcases selected for automation, have invalid test cases been
1.3.6 identified?

Has the manual time for executing the Regression suite been
1.3.7 documented? (Data prep, navigation sequence is consistent)

1.4 Time Sheets

1.4.1 Has time sheet tasks been added for all resources?

1.4.2 Are various stake holders aware of the Automation status?

If not, have status meetings been scheduled to communicate the status of
1.4.3 automating the application?

CopyRight http://www.LearnQTP.com/ Page 4 of 6 Date Printed: 03/29/2024

Item Problem Category & Type Yes/No Comments

1.5 Automation Test Script Creation

1.5.1 Is the Automation framework baselined?

1.5.2 Is the application team aware of the change in the framework?

1.5.3 Does the automation team have sufficient time to create the scripts?
If test data is not available for the application, has the automation team
requested the name of the contact person from which the data can be
1.5.4 requested?

1.5.5 Is Test Data reusable?

Is the Test Environment stable and consistent to allow for the creation of
1.5.6 test scripts?
Does Team Members have access to the application and full permission
1.5.7 to work within the application?
Has the contact person been identified to assist in restarting the
1.5.8 application during down time?

Has schedules for maintenance, installs, etc. been requested from the
application team? Planned application down time should be
communicated to every team member and saved on the shared drive
1.5.9 within the application folder.

Does automation team have contact information for the application's defect
1.5.10 resolution team?

1.5.11 Is database verification required?

1.5.12 Is the database accessible from the location where scripts are created?
Has automation resource followed the correct naming conventions for the
1.5.13 test scripts?
Has automation resource stored the automated test scripts in the correct
1.5.14 path?

Are scripts stored in Quality Center and has the QC Administrator been
1.5.15 informed?

1.5.16 Is Quality Center project configured with version control?

1.5.17 Are automation scripts pointing to the correct repository?

Has automation SME ensured that the automated test scripts follow the
1.5.18 coding standards of the project?

1.5.19 Have the automated test scripts been reviewed?

2.0 Test Execution

2.1 Application Interface
Are automation team members aware of the Application
2.1.1 Release/Build/Deploy date?
Does automation team have bandwidth to execute the automation test
2.1.2 scripts?
2.1.3 Is application stable for running and updating the automation suite?

CopyRight http://www.LearnQTP.com/ Page 5 of 6 Date Printed: 03/29/2024

Item Problem Category & Type Yes/No Comments

2.1.4 Has the contact persons been identified to resolve build instability issues?

Has the automation team received communication of builds (ie.

2.1.5 Releases)?

Is the Automation Team is aware of the defect repository for the

application being automated and understands the process for tracking
2.1.6 defects found during execution?
2.1.7 Is automation team aware of the steps for defect resolution?
2.1.8 Location exists that contains test results or reports from test runs?

3.0 Sign Off

Has automation team shared information on how the scripts are created,
3.1 the overall framework of the scripts and how the scripts are maintained?
As part of Hand-off, two documents have been delivered:
1) Documents of Automation scripts
2) Job aid to run the scripts
3.2
Has training been conducted to ensure the application team is able to
maintain the automated test scripts?
3.3

CopyRight http://www.LearnQTP.com/ Page 6 of 6 Date Printed: 03/29/2024