Hello
Here are my thoughts:
IQ - make sure you have the correct power and any other requirements for the sensors (brackets, installed correctly, etc). This would include verification of the calibration of the sensors. You are validating that the sensors have what they need to work correctly, this means everything they need to do the job in your process. This also includes Preventative Maintenance, Calibration frequencies, etc... all this should be documented and the proof of this documented in the IQ.
What I would then do is have the accuracy of the sensors documented and a statement supporting that the sensor is sensitive enough for your needs. In my company we have a general 4 to 1 rule where the accuracy of the sensors needs to be 4x the tolerance that is allowable. In other words if I have to have the temperature accurate to +/- 1C then I would need a sensor accurate to at least 0.25C for the sensor to be acceptable. I would prove this by the calibration and manufacturer specification of the sensor. What you are trying to avoid is the situation where your process range is, say, +/- 1C and your sensor only accurate to +/- 1C so your process is not sensitive enough to detect when you're out of your process window.
I cannot comment on pH, I have not had to measure this but I can envision it being handled the same way. If you need +/- 0.2 pH then your sensor must be accurate enough to detect to this level.
I would OQ the sensors by inserting faults into the system. I am assuming your process alarms when there are hi/low temperatures or pH readings. I would insert cases where the sensor detects a high and low value (out of your acceptable process window) and validate that the process acts as it is supposed to when it encounters a fault. I would run multiple iterations of this for each, depending on your company statistical guidelines. You are testing not only that the sensor is detecting the fault condition but that the sensor communicates to the process and the process will handle it correctly.
I would then PQ the process to validate the whole thing is working correctly.
For the HMI - this is potentially more complicated - are you making quality decisions based on the HMI or are you just using it for informational purposes? If you are making quality decisions of the product based on the HMI then you are in for much fault insertion and proof that the HMI is reading your sensors correctly. If the HMI information is just for informational purposes I would document this and move on.