Now the operational requirements reflect the philosophy of, Secure by Design, Secure by Default, and Secure in Deployment. These reflect that philosophy that has been for many years, the holy grail of secure development programs. It ensures that security is designed in that in doing so, it will operate as a fully integrated member and set of controls that collaborate with the operational program instructions, and that it is not disrupted or disabled when implemented. In other words, it becomes more of a business enabler than the oft-perceived impediment that so many see as the case.

As it works properly, it ensures that the operational environment is properly prepared and ready to receive any form of processing within its capabilities. Part of this will be to capture the operational requirements in a Requirements Traceability Matrix or RTM. During the development cycle, this becomes a tracking mechanism that records and assists development teams in the ability to trace requirements from source to implemented form. And once it becomes operational, it traces back to those for doing troubleshooting and problem resolution.

It gives us the ability to authenticate any of our requirements sources. This is especially important when we're attempting to authenticate and trace a regulatory requirement. It validates our integration success because knowing the requirement, knowing its source, allows us to demonstrate how it works when it works successfully and that the compliance requirement contained therein is achieved. It helps us verify completeness of build and correctness of operation by documenting the requirements and then giving us the vehicle whereby we can verify correct performance and validate that the expected result was achieved. It further enables identification and tracking of any deviation.