Slide 196 of 262
This is the representation which everyone and their brother uses to represent a ‘standard’ document structure. It is supposed to represent the dependence of one on the other. I will admit that often when I see this I think it should be placed up-side down because I see the ‘Quality Manual’ or Systems Manual as the foundation upon which the others are based. This representation, to me, better relays the understanding of the quantity of documents in a particular level. This ‘normal’ representation also is easier to follow as the requirements flow down which seems easier to comprehend than if the representation flows up - but maybe this is just my being used to the ‘normal’ representation.
You should note that there is a level or tier 5 in my documentation pyramid which is not on ‘normal’ representations. I include this level / tier because every company has ‘ad hoc’ documentation of some sort from time to time. For example, a process engineer may have a temporary (ad hoc) document to gather some specific information about a process for analysis. The documentation is not part of the ‘normal’ process, but… The operator (or whoever) is taking data. Was the operator trained for this? Is there a procedure or is the form ‘self evident’? Just a few thoughts.
Typical Documentation Tiers
We ensure flow down of requirements from the top down