Requirements, Verification Protocol and Reports All in One Document

Mark Meer

Trusted Information Resource
Another idea I'm mulling over, and would appreciate feedback....

I'm considering creating design documents in such a way that, at the end of the design, the requirements, verification protocol and test-results are included in a single document, which is approved in stages.
(NOTE: this approach is probably only viable for relatively simple devices, and assumes all tests are done internally).

The idea is as follows:
  1. Stage 1. The document starts with a table(s) listing the design requirements. This gets approved.
  2. Stage 2. The document gets revised to add table columns to describe the verification instructions for each requirement. This gets approved.
  3. Stage 3. The document gets revised to add table columns to document test activities.

So, for example, a row in the table may evolve as follows:

Stage 1 (two columns per row):
ID: DR-2.3.1
Requirement: Total packaged system weight shall be less than 500g

Stage 2 (add the following columns):
Verification Method: Weight the packaged system using (equipment reference).
Acceptance Criteria: Measured weight is less than 500g.

Stage 3 (add the following columns):
EUT: Device TPS-1023
Tested By/Date: Joe Bloggs, 2014-09-29
Pass/Fail/NA: Pass
Notes/Observations: Measured weight: 472 grams

Advantages:
- Obvious traceability between requirements and verification activities.
- Only one document to maintain.

(potential) Disadvantages:
- This would be both a document and a record.

Thoughts? Is this approach viable/acceptable?
 

Jen Kirley

Quality and Auditing Expert
Leader
Admin
Hi Mark,

I see records that also contain instructions and criteria all the time. In fact, I support their premise because the needed information is where it's needed, when it's needed, and presumably current as the document would be getting multiple reviews throughout. What's not to like?
 

Mark Meer

Trusted Information Resource
I support their premise because the needed information is where it's needed, when it's needed...

My thoughts exactly. :)
In previous projects we've had:
1. A design requirements document
2. Several verification protocol documents
3. A test report record for each verification test set
4. A traceability matrix to ensure that all requirements in (1) have been verified by someone in (3) using the methods in (2).

At the end of the day it's a lot to maintain. Particularly when there are changes to a design requirement, nearly all the above needs to be updated.

Furthermore, the "traceability matrix" is a burdensome task in cross-referencing, which would be totally unnecessary if everything was all together in a single table...
 

scda0505

Registered
One thing you need to remember and watch out for with the "one document" approach is how much do you want to put in front of an auditor? The more information presented, the higher risk of generating questions. That's why I would suggest keep your "stage 3" seperate from your one document.

Have your design input requirement, verification method, and design output with a reference to your source of the results (verification report).

An auditor would more likely to spot check and ask for a few reports versus being able to review everything.
 

Helmut Jilling

Auditor / Consultant
One thing you need to remember and watch out for with the "one document" approach is how much do you want to put in front of an auditor? The more information presented, the higher risk of generating questions. That's why I would suggest keep your "stage 3" seperate from your one document.

Have your design input requirement, verification method, and design output with a reference to your source of the results (verification report).

An auditor would more likely to spot check and ask for a few reports versus being able to review everything.

NO, NO, NO...please do not build your system to hide things from an auditor... completely backward approach....


The auditor is there to help you be compliant to requirements, customer requirements, and to help you achieve improvement, better performance and customer satisfaction...by identifying areas which are not compliant or effective.


If you hide things from your auditor because he might say it is a finding, then you are short-circuiting this process. It would be like hiding things from your doctor because you are afraid he might say you are sick...why go to a doctor if you don't want to get well? Why do an audit if you don't want to improve?


If you do not have this kind of relationship with your auditor...then get abetter auditor....
 

matkins

Starting to get Involved
Mark,
Did you ever go further with this idea? If so, would you mind posting it? I'm looking for a means to document design gates and approvals for new and changed products. I like the idea of having it all in one document, showing the complete status of the project.
 

Mark Meer

Trusted Information Resource
For our new projects, we intend to do this, but presently I've got nothing to share.

The idea is however, as described.

Maintain a controlled spreadsheet that is you would add columns to at each stage.
Also, there is a process for revisioning the document:
- v0.x = requirements only stage
- vx.x = requirements + verification protocol stage
- Revision A (B, C, ....) = final design document (requirement+v.protocol+test-record)

So, for example, a single row of this project design document might look as follows:

Stage 1: Design Inputs
|| Req.ID || Design Requirement ||
| 1.2 | Device shall measure 2.4 (+/- 2) mm in diameter |

Stage 2: Verification Planning
|| Req.ID || Design Requirement || Verification Plan || Acceptance Criteria ||
| 1.2 | Device shall measure 2.4 (+/- 2) mm in diameter | Use calibrated calipers to measure the diameter| Diameter measures 2.4(+/-2) mm |

Stage 3: Verification Testing
|| Req.ID || Design Requirement || Verification Plan || Acceptance Criteria || Tested by/date || Equipment Used || EUT || Results ||
| 1.2 | Device shall measure 2.4 (+/- 2) mm in diameter | Use calibrated calipers to measure the diameter| Diameter measures 2.4(+/-2) mm | Jo Personnel, yyyy-mm-dd | (equipment reference) | Unit XXXX | Pass (measured 2.5 mm) |

...That's the idea anyway.
(P.S. hope you can understand my table syntax...pity you can't make proper tables on these forums...)
 
Top Bottom