Other Considerations

Sources of regulatory requirements

In our work with companies in regulated industries, we have found that “regulatory requirements” do not always come from regulations. Sometimes they come from calcified organizational policies that have lagged behind regulations.

We worked with one life sciences company that enforced design traceability—tracing features through to the specific software modules affected. We analyzed which of the development process requirements were mandated by the FDA and which were required by the company’s regulatory group. We were able to eliminate about one-third of the design documentation, which was not mandated by the FDA and was essentially useless.

We have found requirements being treated as regulatory requirements that come from a company’s experience with client audits rather than from any regulatory agency. We’ve also seen that sometimes documentation requirements come from software capitalization rules rather than regulatory requirements.

Overall, I suggest that you be sure to understand the sources of your regulatory requirements. Have a discussion with your regulatory groups to understand which are real regulatory requirements and which are the regulatory group’s opinion about what is needed for clients or for financial practices. You can then make decisions about the necessity of carrying forward your company’s historic documentation requirements into your current development efforts.