In this example, the first item relies on the fact that there is a test step that sends the entire message at once. The second item must deal with a system design that enables the user to configure individual elements on the voltage ramp. Thus, in the end, the ATP steps must cover the requirements, but the specific ATP step(s) chosen to cover a particular requirement reflect(s) the design of the system as well, which is why the design should be done prior to writing the ATP.
By writing the requirements in the leftmost column of a table and each ATP step in a column of that table, you can trace coverage by marking an element of the table (matrix) when the ATP step validates a specific requirement. When the entire matrix has 1 or more marks in every column, each requirement can be traced to one of more ATP steps.
Check for Changes
Many years ago, I learned an important lesson when developing systems subject for FDA regulations. It’s not enough to check that the system covers the requirements. It is also very important that the system is validated against the chance that a requirement is covered in potentially unexpected and invalid ways.
You never want the system to create a false positive.
As a simple example, suppose you run the 1-to-1 ATP step above and find that the system runs correctly. You might also run the same step with values of 2 V to 5 V over 3 seconds and find that the XML has the same content as before, suggesting that the 2 V input apparently is being ignored and the default value of 0 V is always being used. Thus, a good ATP changes inputs over a range to assure that an expected output is not simply a fluke.