Separate from the Software Application URS a Platform Requirements Specification (PRS) should be defined. The PRS should consider the users operational requirements, e.g., 24/7 global access by telephony, the software supplier’s technical requirements…and IT operational needs. (p. 153)
A good Platform Requirements Specification (PRS) answers a number of basic questions related to the server and network infrastructure required to deliver a Software Application to the regulated end user’s work process. The PRS is all about the technology view and is prepared by the IT staff.
- What are the software supplier’s technical requirements for server, network, and other infrastructure or software? How do these requirements map to the current IT configuration available to the end user’s work process? Are new equipment or upgrades required? Are new internal or external network nodes or licenses required?
- How will IT have to rework the configuration to support new data or automation flows in the new software work process, e.g., new specialty equipment communications, increased load of global versus local users 24/365, multi-language Help Desk, etc.?
- Are there specific regulations that apply to the work, the data, or the system itself, e.g. 21 CFR Part 11 or EU GMP Annex 11? How does this Software Application fit into the IT Disaster Recovery process and testing?
- What types of data must the system back up? How frequently? When and for how long must the data be archived? What is the capacity for this archive?
- What are the system admin and user roles and privileges for the data and the application?
- When do the users need to have an installed and qualified (IQ) Platform system available to them for PQ testing? Platform = new application installed on configured server and required infrastructure.
Note that these questions focus on the bits and bytes of technology for the software and infrastructure. The IT staff MUST drive the PRS development, BUT the IT staff needs a good URS to give them the full picture of what the operational application will require for server, network, and infrastructure services at go-live and ongoing throughout its production use.
A standard approach to creating a PRS document is to organize related requirements in tables where each requirement has a unique identifier, a platform focused description, and a way to test for it as an installed system. Having a column for IT Staff Test Topics is essential to ensure that the Platform has only real testable requirements. If it can’t be tested, it is a “wish” and not a “requirement.”
|Unique ID||Platform Requirement Title & Description||IT Staff Test Topics|
One or multiple tables can be used to address the questions asked above. The key to a good PRS is knowing the impact of new software on the current configuration in IT. In the end, one can add a fourth column to the tables to record the Test Script IDs and this will make an instant Trace Matrix for IQ.
Next Month: Software Supplier Requirements – PRD/MRS/FRS
SDLC Requirements Phase Input: Product requirements from Sales; Product Management; Customers; Software Bugs List. Output: Product Requirements Document (PRD) or Market Requirements Specification (MRS). PRD/MRS then converted to Functional Requirements Specification (FRS). (p. 214)