Please see the first entry of the Requirements Management blog series here

Please see the second entry of the Requirements Management blog series here

So, you have a set of detailed safety requirements.  You have derived them down to a level of detail you feel spells out what the product must do to be safe.  Now what?

Well, of course you should give the requirements to the development team who plans and carries out the design and implementation phases of the project, but you should also give them to the project personnel who will be writing the Validation Test Plan and test cases.  The Validation Test Plan will identify the equipment, the personnel, and the training needed.  But more importantly, the test cases will be identified for each requirement to ensure that all requirements are met.  Each test case will test one aspect of the product for specific goals.  The test cases relate to requirements in that the goals of the test are determined based on the values in the requirements that they test.

Obviously, there is a mapping between the requirements and the test cases.  Multiple test cases could be testing one requirement.  Multiple requirements could be fully or partially tested by one test case.  This means there is a many to many mapping between requirements and test cases.  When there are more than just a few requirements, some could get overlooked (i.e., never tested).  The IEC 61508 standard has traceability requirements to ensure that this doesn’t happen.  This standard requires both the forward mappings, from requirements to validation tests, and the backward mappings, from validation test cases to requirements, to be documented and verified using a valid method.  This is required for all SIL capability levels (there are other software traceability requirements to be met for SIL 3, but let’s defer that discussion).  It is not important, from a Functional Safety Assessment point of view, whether a separate document (or database) is used, or if the requirements directly reference the tests used and the tests directly reference the requirements assessed.

The forward references ensure that all requirements are tested by at least one case and make it possible to determine all of the test cases for any given requirement.  The backward mappings provide the means to ensure that there are no tests that are no longer required (e.g., requirements were eliminated after the test was written).

Once one or more test cases are identified to validate a requirement, and the requirement has been mapped to the cases, the test steps are written.  The author must identify, among other information, the inputs, outputs, steps, and pass/fail criteria in order to write the test case.  Writing a test case is a creative process that necessitates that certain information to be available in the requirement.  If there is not enough information to write the test, the requirement is considered “not testable.”  If this is the case, the test author would return to the requirement author and ask for more information to be included, so that the validation test can be written.  Verifying that all requirements are covered by tests, through traceability, and that all requirements are testable by writing tests against them, goes a long way toward verifying the requirements.

Additionally, reviews could be held to critique the methods of testing, to improve the quality of the test approach and/or the test cases/steps.  These reviews could also lead to identification of needed requirements and/or more information for testing requirements.

Once the Validation Test Plan and Test Cases have been verified, you are ready to show that your device exhibits all of the behavior and attributes specified in your Safety Requirements.  Now all you need to do is design and implement the product!
I hope this series of blog entries has helped to bring requirements management into better focus with respect to the IEC 61508 requirements.