In the context of NPS software validation, you have a variety of options. The actual choice you make ought to be spelled out in a validation plan document. Some organizations do proscribed activities by
procedure, but it is pretty much a uniform expectation that for NPS validations there be some sort of Validation Report (typically concluding with a statement "this software system is validated for its intended use"), and I can't imagine generating a unique Report without a unique Plan. YMMV.
Some personal disclosures:
I have a personal distaste for adopting the tenets and terminology of Process validation (IQ/OQ/PQ) to NPS software validation. Many organizations do this; I think it demonstrates a lack of both experience and understanding.
I believe the "V-model" for validation leads to more confusion that clarification. The OP does not mention the V-model specifically, but the implied mapping between "high level requirements" (i.e. URS) and "PQ" (and mapping FRS to OQ) has the aroma of V-Model thinking.
Within the regulated medical device industry, the need for NPS validation (such as it is) is two-fold:
- The possible effects of the NPS on patients and users is understood (via risk analysis) and the risk are suitably controlled,
- The system meets the intended needs of the organization (for the entire life of the NPS system).
A relatively simple robust model of (initial) NPS validation to determine that the system meets its intended use (sidestepping planning, risk assessment) is:
- Establish the requirements for the system (This is typically from the Intended Use, any necessary controls identified from Risk Analysis, and "user requirements")
- If necessary, decompose the high-level user requirements into specific functional requirements and design choices which will satisfy the high-level requirements
- analyze the design choices and challenge the specific functional requirements (most users of NPS won't set out to explicitly challenge the software, they just want it to work)
- allow typical users to exercise the software in their typical ways to make sure that (as implemented) it is meeting their needs.
Traceability between these items should be established. Systems where you have no control over the detailed implementation may not even require steps 2 and 3 (if the risk to patients/users is low enough).
You can assign TLA (two/three-letter acronyms) to the various artifacts, but it isn't important what you call them... provided you aren't sowing confusion. Keep in mind that manufacturers of pharmaceuticals and manufacturers of medical devices don't agree (by consensus!) on the meanings of OQ and PQ, even in the context of Process Validation!