Validating software requirements

06 Sep

We outline an industrial study involving the specification of real-time monitoring systems, wherein we demonstrate that enaction of the state-based use cases highlighted important dependency issues that had not been revealed within standard use cases.The FDA (Food and Drug Administration) and IEC (International Electrotechnical Commission) requirements for validation of your manufacturing and quality system software can conjure up a lot of questions.This term has shown to be a good and pragmatic guideline.Users of computer systems can use the same term for computer systems.This paper addresses the inadequacy of use cases for expressing intra-use case and inter-use case dependencies.We present a state-based approach for facilitating explicit consideration of such dependencies in use case descriptions, and a support tool is described, which provides enaction of the state-based use cases to support validation.The pharmaceutical company is obliged to identify all raw data associated with GMP decisions (e.g., batch release) and determine which format (paper or electronic) to maintain data in.The integrity of the electronic record must be assured if raw data are to be maintained in electronic format. About the Author Henrik Johanning is CEO and senior partner, Genau & More; John Lee is executive director, Pharma Net Inc., former FDA Investigator; Christian Hemming is QA Manager, QAtor A/S; Lise Christensen is QA Director, CMC Biologics A/S.

validating software requirements-3

Summary From a strategic point of view, validating computer systems is an ever-increasing activity in the pharmaceutical industry as technology continuously automates former manual and paper-based processes.

Computer software, as part of the computer system, dictates the hardware on which to be executed.

The software categorization typology in GAMP5 ranges from infrastructure “used-by-millions” software (category 1) such as antivirus software, operating systems (e.g., Windows, Linux, Unix, etc.), and databases (e.g., MS SQL, Oracle), to non-configured software with a large user base (category 3) such as firmware and MS Office applications, to customized software (category 5) (i.e., software characterized as being one of a kind such as most process controllers, scripts, macros, and data interfaces).

This rather simple notion proves useful as it simplifies an initial complex and, for some users, volatile concept.

From an internal-external perspective, verification practices (e.g., validation strategy, proper risk assessment, establishment of design, user requirements, and subsequent verification of requirements) must be processed and reported internally to verify the intended use of the software.