How do you define and validate user requirements and functional specifications in GAMP 5?

Interesting comment from Charlie below about relevance of the GAMP acronym. It is true that even one instance of "Good Automated Manufacturing Practice" isn't called out inside GAMP 5 2nd edition. Would love to learn more about this - hopefully Charlie write about this in detail- it will help all to clarify about GAMP since the scope has been into areas such as medical devices, clinical , GLP etc as called out in her comment below.

Anyone who says GAMP5 doesn't stand for Good Automated Manufacturing Practices is trying to change how the language works and should give up. The entire internet says GAMP means Good Automated Manufacturing Practices. The very people GAMP5 is targeted to are conditioned to understand that anything that is a G-P stands for Good "something" practices. ISPE should have changed the name. They have had plenty of opportunities to do so.

In GAMP 5, user requirements specification (URS) defines system functionalities. Validation involves stakeholder engagement through interviews and reviews. Functional specification (FS) translates requirements into detailed system functionalities. Validation of FS ensures alignment with user needs through reviews and walkthroughs. Traceability, change control, and risk management are integral for maintaining compliance throughout the process.

The inaugural adoption of GAMP 5 in regulatory compliance history symbolizes innovation, perseverance, and industry evolution. It marked a pivotal moment, signifying the onset of a new era in computerized system validation, as organizations globally embraced the latest guidelines from the International Society for Pharmaceutical Engineering (ISPE). During the initial phase, meticulous planning and strategizing were paramount. The team drew insights from GAMP 5 guidelines, meticulously analyzing existing validation procedures to identify areas for improvement and alignment with the new standards. Despite the daunting nature of the task, the team approached it with unwavering determination.

Good Automated Manufacturing Practice (GAMP) is a set of guidelines for manufacturers and users of automated systems in the pharmaceutical industry. Developed by the International Society for Pharmaceutical Engineering (ISPE), GAMP provides a framework for achieving and maintaining regulatory compliance. It emphasizes a risk-based approach to validating automated systems to ensure that they are fit for purpose, reliable, and meet regulatory requirements. GAMP is crucial for ensuring the quality, safety, and efficacy of pharmaceutical products, providing a standardized methodology for system validation across the industry.

Points Addressed by GAMP 5 Risk Management Approach: helping organizations focus their efforts on critical areas that have the most significant impact on product quality and patient safety. Efficiency and Flexibility: By tailoring the validation efforts based on the complexity and risk of the systems. Lifecycle Management: ensuring ongoing compliance and quality management from inception to retirement. Harmonization with Global Standards: as alluded above, GAMP 5 aligns with international standards and regulatory expectations. Quality Management: GAMP5 encourages a quality-focused approach to the selection, implementation, and management of computerized systems.

From a Risk-Based Approach,GAMP 5 emphasizes a risk-based approach to CSV, placing greater importance on identifying and mitigating risks associated with computerized systems. Overall, GAMP 5 represents an evolution in CSV practices, with a stronger emphasis on risk-based approaches, lifecycle considerations, streamlined documentation, and integration with other industry standards. It aims to provide a more flexible and efficient framework for validating computerized systems in regulated industries. In contrast, GAMP 4 follows a more traditional approach to validation, which may not prioritize risk assessment to the same extent.

GAMP 5, released in 2008, introduced significant improvements over GAMP 4. The key difference lies in the approach: GAMP 4 focused more on procedural and documentation aspects, while GAMP 5 emphasizes a risk-based approach. GAMP 5 encourages leveraging existing good practice documentation and systems and focuses on scalability and flexibility to adapt to various system complexities and criticalities. It promotes the concept of "good practice" rather than "best practice," aiming to be pragmatic and scalable to different project sizes and scopes. This shift has made GAMP 5 more adaptable and efficient in managing and validating automated systems.

GAMP 5 2nd Edition has combined the appendices for URS and FS into Appendix D1 - Specifying Requirements. The Requirements Specification (RS) is an essential deliverable in computer system validation. It identifies what the users require the system to do and enables verification that the system is fit for intended use. It is useful to organise requirements in the order which the functionality is used. For example: - Access control - System setup / Administration - Study set up (if applicable) - Data acquisition - Controls for data integrity (e.g. audit trails) - Calculations / data transformations - Output / reporting This helps with requirements management and subsequent activities including functional risk assessment and testing.

More generally speaking, in GAMP 5, the URS asks, What is this system intended to do? Whereas the functional specifications or system design specifications identify the settings and configurations of the software to achieve the user requirements.

The revision of GAMP 4 to GAMP 5 is no longer relevant for this article. GAMP 5 2nd edition was published in 2022. The article could be improved by referring to the latest updates and the reasons why they have been made.

In process control systems, there's no doubt that the URS for Automation, for GAMP 5, goes through a lifecycle of sorts because of optimized system architecture, a changed scenario or maybe a batch management strategy that was introduced in pharma projects. With digitalization ever expanding its influence, they create a welcome URS change with the intended use being captured.

When it comes to a URS, the key consideration is that their level of detail and complexity need to be commensurate with the level of risk, complexity and novelty of the system. Eg for a LIMS with thousands of rules, I’d always suggest adding a line for each complex requirement (eg rules), as making the URS high-level makes traceability more difficult as a single requirement such as “system must have rules” (which I have actually seen) will then align to thousands of system rules, making the URS reference useless for traceability, the script will therefore need to use the design doc reference, and the RTM will be a mess, with potentially thousands of script steps against a single requirement. Negative testing needs to also be considered.

Requirement Specification documents are key deliverable in validation of any software. GAMP5 second edition clearly defines the Requirement Specification strategies and responsibilities for create in different project methodologies like lean and agile. User/SME/Product owner is responsible for create requirements specification and where process owner is responsible for global process requirements specification. While creating requirement specification documents follow the key principles as SMART S- Specific M- Measurable A- Achievable R- Realistic T- Testable Each requirement should be Specific and check with as unambiguous, Clear, Precise, Self-contained. #addcomments #requirements #specification #csv #sdlc #gamp

The URS is a critical document that defines what the system should do from the user's perspective. It includes detailed descriptions of functional, performance, regulatory, and business requirements. Creating a comprehensive URS involves gathering input from all stakeholders, including end-users, quality assurance, regulatory affairs, and IT. The URS should be clear, concise, and testable. Validation of the URS involves ensuring that all requirements are complete, unambiguous, and verifiable. It serves as a baseline for designing, developing, and validating the system, ensuring that it meets the intended use and regulatory expectations.

In Gamp 5 User Requirements are still expected to be "Measurable" and "specific enough for testing" (unambiguous, clear, precise). Without good user requirements any subsequent quality assurance activities are performed against unknown specifications.

One of the most noticeable difference between GAMP 4 and GAMP 5 is the way functional specifications of any automation process or control strategies are defined. In GAMP 5, FS goes into the game very early before validation and becomes a prime beacon for risk and criticality assessments and quality control.

Functional Specification documents is one of key document to define the clear business process functions, data workflows to verify fit for intended use by executing verifications testing as OQs. Functional specification is subset of URS, depends on category of software FS prefixed to specific business process and where complex and customs software functional specification is prepared based on business process. #addcomments #gamp #csv #functional #specification

The Functional Specification (FS) translates the user requirements into detailed functional requirements that developers and engineers can use to build the system. It describes how the system will perform its functions, including hardware, software, interfaces, and interactions. The FS should align with the URS and provide detailed technical specifications to guide development and configuration. Validation of the FS ensures that all user requirements are addressed, and the proposed solutions are feasible, compliant, and testable. It involves reviewing and approving the FS with stakeholders, ensuring that it accurately reflects the intended system functionality and regulatory requirements.

During recent CSV implementation under GAMP 5, the need for system-defined error messages in functional requirements arose. Drawing from our vast experience spanning over 80 qualifications, I emphasized a risk-based approach, linking the decision to system criticality and validation needs. While functional requirements govern system functionality, error handling is crucial. Integrating error messages in operational qualification (OQ) tests assures system behavior alignment. Balancing regulatory compliance with adaptability is crucial. Sometimes, referencing error-handling in higher-level documents proves more suitable.

Incorporate risk assessments, develop a traceability matrix, engage stakeholders, implement change control, maintain thorough documentation, and provide training. These steps ensure robust, compliant automated systems that meet user needs.