What engineer enjoys writing Software Development Life Cycle (SDLC) documents, such as a Software Requirements Specification or SFMEA?  I have yet to meet one that has the passion to sit and document the requirements.

While there are numerous purposes and reasons for documenting the requirements, the greatest value is in the process that leads up to the documentation: stakeholders discussing user requirements, Harm and Hazard Analysis (H&HA), and how to define SMART requirements and design specifications, as well as coming to a consensus and mitigating risk.  The documentation is a by-product of the collective dialogue.

Prior to robust software development infrastructure, Microsoft Word™ and spreadsheets were the common tools used for documenting the Source of Truth, which is the official version of the requirements and specifications.  Developers would code with the given table of requirements and used code management systems to compile the specifications.  The document and code existed in siloes, and the documents were controlled through Document Control Systems.  Under these traditional circumstances, the Software Failure Mode and Effect Analysis (SFMEA) can be mismanaged at times in the following common ways:

  • The engineer at their desk determines the risk levels and mitigation, with minimal conversation or collaboration with stakeholder, thus missing the opportunity for a discussion.

or (conversely)

  • The SFMEA is generated after all the code is written and the engineer utilizes their memory as they collaborate with stakeholders to document the requirements.

As organizations develop templates and instructions on how to generate quality software, the SDLC documents are often seen as a paper exercise (and, thus, lose the value in the process) while engineers view the “documentation” as a necessary requirement for regulators, which brings next to no value.  This leads engineers to document the intent of the code at a high level after-the-fact, rather than the actual process, with the belief that the level will be detailed enough for non-technical stakeholders and that technical stakeholders who need details will go into the code to “figure it out.”

Such a dichotomy is unnecessary in modern software development as Software Development Infrastructure platforms (SDIs) have matured to support both the Source of Truth and design control mechanisms.  Mature SDIs with collaboration features enable stakeholders to virtually collaborate throughout the software lifecycle, beginning with defining and managing user requirements to tagging requirements with the relevant H&HA.  This allows developers to have the detailed specifications at their fingertips with links to the user requirements and H&HA.  Most SDIs allow code to be linked to the detailed specification task activities, enabling complex many-to-many or many-to-one interdependencies and the ability to score the code’s risk level.  The test steps and acceptance criteria can be defined with all of the relevant information as the code is being developed.  Test management modules provide semi- or fully automated regression test suites.  This means that testers can utilize the H&HA, test criteria, and FMEA risk information to generate the test plan, procedures, and scripts that are used to ensure that the product does not regress.  Additionally, modern SDIs are built with dashboards and Kanban views so the development and test status can be transparently viewed by the collaborative stakeholder community in real-time.

With modern SDIs, organizations need to define their procedures for collaboration, development, and test activities to ensure that the right stakeholders evaluate the right level of information at the right time.

Version control is built into SDIs, with release version tags allowing for the quick assembly of old code versions to verify issues in production and evaluate whether the risk for specific code has changed over time.  Linking field issues “bugs” to the code for corrective action simplifies determining whether it is a “Potential Impact to Patient Safety.”  This is the ideal result for post-market surveillance to influence FMEA, to become a continuous process improvement.

Most SDIs include a report function.  Reports can be generated to provide e-paper documents, as needed, so that the SDI allows developers to create the necessary “documentation” in a format that brings the necessary information to the developer’s and tester’s fingertips for considering and managing the design control.

This means that both the traditional paper methodology and SDIs can be compliant approaches to design control, with the right procedures and instructions to be developed based on the needs of the organization.

What is right for your organization?  The answer is:  It depends.  The rate of software releases, the complexity of the code, and the ability to leverage the infrastructure to GMP applications are just some factors to consider.

Lachman Consultants can help you determine what is right for your organization and help develop processes and procedures to be complaint and bring both the greatest efficiency and ROI.  Please contact us for an assessment.