The 5 Fundamentals of GMP Requirements Tracking

If you already know these seven things about GMP, then it's time to dive into the five fundamentals of GMP requirements tracking.

If you hear GMP Documentation, Traceability Documents, Requirement Specs or something of that nature, then the topic is probably requirement tracking documentation for good manufacturing practices.

So, you start with some requirements. A solution is developed to meet those requirements. You must have a way to confirm that each requirement was met (testable) and then document how the requirement was met and that it was tested (traceable).

There are many ways to accomplish these goals. However, after years of implementation, improvement, and collaboration across industries, there are certain standards of practice which are very clear and highly effective.

These are the five fundamental documents of GMP requirement tracking:

1. Requirement Specification (RS)

It could be a User Requirement Specification, a Software Requirement Specification, or something else, but the core purpose is always the same.

A requirements specification defines the problem at hand. Maybe a company needs to stand up its first ever manufacturing line for a novel product. Or, minor updates are required for an existing line. Either way, there is a specific problem to be solved which defines the scope of the effort.

An RS should focus on the problem at hand, and avoid beginning to design the system or specify specific functions. The RS should contain everything that the implementer or designer needs to create the solution.

2. Functional Specification

To meet the requirements, what should the system do?

This document doesn't discuss how to make the system do these things, just what it must do.

3. Design Specification

The design specification describes how the solution is implemented, how it accomplishes the functions, and how it ensures that the functions meet the needs of the requirements specification

4. Testing Protocol

Each test should address a requirement, and each requirement must be tested.

The testing protocol is step-by-step instructions to verify that all requirements are met. The testing protocol should be written so that someone who isn't on the development team could follow the script and successfully determine if the test passed or not.

5. Traceability Matrix

The format of this document varies most out of all five documents. In fact, it's not always a dedicated document. Sometimes, the goal of traceability is accomplished by embedding references into each of the four previous documents.

In some implementations, this will be a controlled document with the same level of tracking as the other four. It may be automatically generated by requirements tracking software, or it may be an excel document. The purpose of the traceability matrix is to connect requirements, functions, and tests.

It should make clear that:

• All requirements are tested
• All functions address a requirement
• All design implementations address a function
• All tests address a requirement

The distinctions between requirements, functions, and design specifications are tricky but important. When these distinctions are murky, the documents serve little purpose other than to record what happened. When the distinctions are strong, the documentation process can guide the customer and developer into a better, more appropriate solution.

Example

Here's an example that illustrates some differences between requirements, functions, and design specifications:

We at the DMC Boston office consume a lot of seltzer. We've decided that we require a seltzer delivery robot. So, I start to write out my Requirements.

1. I require a robot to deliver seltzer to me.

But, systems engineer, Tom wisely points out, "Do we really require that it's a robot? Or could a different solution work?"

We agree that a robot is not explicitly required. So, we have some example Requirements:

1. The system shall deliver seltzer to specific employees in response to requests.
2. The system shall be available to deliver seltzer any time within the hours of 8 am to 6 pm.

The system must perform certain functions to make this happen. We should take care to avoid designing the system yet. So, I still shouldn't say anything about it being a robot or not, since this isn't a requirement.

Here are some Functions that relate to Requirement 1:

1. The system shall allow a specific employee to request a seltzer.
2. The system shall deliver the seltzer to the desk of the employee who requested it.
3. The system shall deliver the seltzer within 5 minutes of the request.

Once all the Functions are specified, we can design the system!

We get to talking, and I bring up robots again. But, Tom has a great point. We could train a dog to deliver seltzer, and it would meet all of our current requirements, and accomplish all our functions.

"Oh, no," I say, "I love this idea, but it appears we were missing some requirements."

I add to our Requirements list:

3. The system must not cause allergic reactions.
4. The system must not require outdoor bathroom breaks.

We make and release a new version of our requirements and functional documents (for traceability) and reevaluate our functions. Now, we're aligned on design. Some of our design specs for Requirement 1, Function 1 are:

1. The system shall use a Slack bot to allow employees to request a seltzer.
   • 1.1 Any time a user posts any message in a Slack channel dedicated to the purpose, the system shall deliver a seltzer to the desk of the employee.
2. The system shall receive a list that associates desk IDs with employee names using a SQL Server database.

And so on. Finally, when we go to test, a test protocol might look something like:

Test for Design Spec 1.1, Function 1, Requirement 1 - Borrow a coworker's computer. Send one message that says "give pls" into the dedicated slack channel.

Expected result: The system delivers a single seltzer to the desk of the employee that sent the message within one minute.

We perform the test, recording the date and whether it passed or failed. If it fails, we can update our system, release a new version, and repeat the test.

And that's the long and short of requirements tracking for GMP.

Contact DMC if you'd like help with a project today.