These resources are meant to provide sufficient understanding of preemptive testing to enable successful usage.

Recommended Implementation

I recommend a phased implementation starting with failure analysis. Start by reading the Home page, Trial Reports page, and all of the PT-Resources associated with Identifying Mistakes. See which test or production failures begin with defective requirements and why. If the number and impact of these failures are small, you should stop the trial. Otherwise continue to Checking Requirements as phase 2 and Composite Specs as phase 3.


Identifying Mistakes

Traditional testing (i.e., what you are doing now) focuses on detecting implementation defects (i.e., symptoms). Preemptive testing focuses on identifying mistakes made during the development of requirements, designs, and implementations (i.e., causes). The specific goal is to identify and mitigate the causes of major requirements defects.  Success requires trust and close cooperation between test and development.

Kathryn Schulz gives a wonderful TED talk on being wrong.


David Gelperin describes types of requirements

Types of reqts.pdf Types of reqts.pdf
Size : 470.714 Kb
Type : pdf

David Gelperin describes the causes and mitigations of defective requirements.

David Gelperin describes ways to identify mistakes .

Chapter 5 Identifying Mistakes.pdf Chapter 5 Identifying Mistakes.pdf
Size : 744.803 Kb
Type : pdf


Sample Questionnaire

Sample questionnaire.docx Sample questionnaire.docx
Size : 17.914 Kb
Type : docx


Tips on Building Trust - copied from the internet

Tips on Building Trust.pdf Tips on Building Trust.pdf
Size : 569.126 Kb
Type : pdf

Amy Edmondson describes the challenges of learning from failure.

Strategies for Learning from Failure.pdf Strategies for Learning from Failure.pdf
Size : 394.511 Kb
Type : pdf


Checking Requirements

David Gelperin describes requirements checking.

Chapter 6 Checking Requirements.pdf Chapter 6 Checking Requirements.pdf
Size : 696.987 Kb
Type : pdf

Composite Specs

A composite requirements specification is a set of different types of requirements with different specification formats. For example, specifying: (1) batch and happy-path interactive  functions with a user manual, (2) quality goals with a tailored quality model, (3) quality support functions with conditional logic formats and natural language, and (4) constraints and supplier attributes with natural language.

Composite specs should entail composite validation strategies, composite verification strategies, and composite requirements management platforms.  Composite specs should be the norm i.e., one size does not fit all (types of requirements).

Dan Berry describes the use of a user manual to specify batch and happy-path interactive functions.

David Gelperin describes a quality attribute model that can be tailored into quality attribute requirements.

Quality Goals.pdf Quality Goals.pdf
Size : 1831.324 Kb
Type : pdf


Dave's contact info

david AT clearspecs DOT com

cell  480-296-3559