How Should Non-Functional Requirements Be Captured and Validated for a GxP Veeva Vault System?

AI-assisted research and drafting · Practitioner reviewed by Rohith Karanam Sreedhar · 24 September 2026

ⓘ Library content is researched and drafted with AI assistance and reviewed by a Navata practitioner before publication. For original analysis and long-form practitioner perspectives, visit Navata Insights →

LIB-019 already sets out how to write a testable functional requirement: a specific business rule, a defined input, an expected output. Non-functional requirements do not fit that shape as cleanly, and validation packages routinely either skip them or write them so vaguely, "the system should be reliable", that they cannot actually be tested or failed. That gap matters because a system can pass every functional test and still be operationally unfit if it cannot sustain expected load, cannot be accessed when the business needs it, or does not actually enforce the access boundaries the security model assumes.

Define the non-functional requirement categories that actually apply

Illustrative non-functional requirement categories for a GxP Veeva Vault system include:

Performance: response time and throughput under realistic, not best-case, usage, particularly for workflow steps that sit on a critical business path such as a batch release approval.
Availability: the uptime and planned-maintenance-window expectations the business process can actually tolerate, distinct from whatever general uptime figure a supplier publishes.
Access-control robustness: confirmation that the security model actually enforces the separation it claims to, not merely that permission sets exist, but that a user without a permission genuinely cannot perform the restricted action.
Capacity and scalability: whether the configuration and its dependent integrations continue to behave correctly as record volumes or concurrent-user counts grow, rather than only at go-live scale.
Recoverability and continuity: whether the service, integrations and regulated process can recover within the time and data-loss tolerances the process requires.
Integrity, retention and retrievability: whether records remain complete, protected, retained and retrievable for the required period.
Interoperability, where applicable: whether interfaces and dependent systems continue to exchange and interpret data correctly under the conditions the process relies on.

Not every category applies to every system with equal weight; the point is that each should be deliberately considered and either specified or explicitly scoped out with a stated reason, rather than silently omitted.

Make a non-functional requirement testable

Within its stated scope of production and quality management system software for medical devices, FDA's Computer Software Assurance guidance sets out a risk-based approach to selecting assurance activities appropriate to software risk and intended use. It is not a general pharmaceutical GMP requirement; the risk-based logic is used here as supporting practice for deciding how rigorously to test a non-functional requirement. A testable non-functional requirement needs three things a vague one lacks: a specific measurable condition (a response time threshold, not "fast"), a defined test method that can actually produce a pass/fail outcome against that condition, and a named owner accountable for the requirement being met. "The system should be secure" is not testable. "A user without the QA Reviewer permission set cannot transition a batch record to Approved" is testable, has a defined method (attempt the action with a test user lacking the permission and confirm it is blocked), and has an owner (the security model owner).

Route responsibility using the application/infrastructure split

EU GMP Annex 11 draws a structural line between the application, which must be validated, and the supporting IT infrastructure, which must be qualified. That line is the practical answer to who evidences which non-functional requirement. A requirement that depends on the underlying hosted infrastructure Veeva operates, raw platform availability, underlying compute capacity, is evidenced primarily through supplier qualification documentation, not through the organisation independently load-testing infrastructure it does not control. LIB-058 addresses in detail who qualifies that infrastructure on a multi-tenant SaaS platform and what evidence that qualification should produce; this article does not repeat that ground.

What remains squarely the organisation's own responsibility, even on a fully supplier-managed platform, is validating that its own configuration correctly uses whatever the infrastructure provides: that the security model it configured actually enforces access-control robustness, that workflow performance is acceptable given the organisation's own configuration choices and integration load, and that the business-tolerable availability window is actually compatible with the supplier's published maintenance schedule. Those are configuration and process questions the organisation answers itself, not infrastructure questions it defers to the supplier.

Apply proportionate rigour, and reassess at each release

ICH Q9(R1) is explicit that the formality of quality risk management should be commensurate with the level of risk, complexity and criticality of the decision. A performance requirement on a rarely used reporting screen does not need the same rigour as one on the critical path of a batch disposition workflow; state that proportionality decision rather than applying a single testing standard uniformly or, worse, applying none at all because a uniform standard felt disproportionate everywhere.

Non-functional requirement evidence is not a one-time, go-live artefact. At each platform release, assess whether the release can affect an applicable non-functional requirement and re-establish only the evidence that the impact assessment shows is affected, rather than automatically repeating every NFR test.

Sources

U.S. Food and Drug Administration, Computer Software Assurance for Production and Quality Management System Software.
European Commission, EudraLex Volume 4, Annex 11: Computerised Systems.
International Council for Harmonisation, ICH Q9(R1): Quality Risk Management.

Navata practitioner view

A validation package with a thorough functional requirements matrix and a single line reading "system shall be reliable and performant" tells me the team thought carefully about business logic and did not think about operations at all. I would want to see access-control robustness tested as an explicit negative case, someone without the permission genuinely attempting and failing the restricted action, not inferred from the existence of a permission set in a configuration screenshot. I would also want a stated position on where the application/infrastructure line sits for each non-functional requirement, because "the supplier handles availability" is only a defensible answer where the organisation can point to the supplier qualification evidence that actually says so, not where it is simply assumed.