Some SaaS providers claim their software is fully validated. That unfortunately, is too good to be true. But it is easy to get drawn in especially if the regulated company doesn’t have the knowledge/skills necessary to know that ‘validation’ performed by the SaaS provider does not ensure the system is fit for intended use.
Typically, when using SaaS, the regulated company should prepare a validation or test plan which describes how they will leverage the requirements specification and testing performed by the SaaS provider. It should also describe the configuration and user acceptance verification activities that will be performed to ensure the system is fit for intended use.
Ensuring a system is fit for intended use, typically means verifying the system does what it is required to do as specified in a user requirement specification (URS).
If the regulated company generates a URS, it can be difficult to map the user requirements to the SaaS providers requirement specification unless the requirements are grouped/organised around the business process. [See yesterday's post].
If a URS is generated by the supplier, it should be reviewed to ensure it reflects the intended use of the system - what the users require the system to do.
There are other pitfalls in Agile development and bad practices in writing User Stories that can make it difficult to determine if the User Stories cover all that the regulated company requires the system to do.
For example:
Just like a good requirement statement defines what is required and not how it is implemented, User Stories should focus on user needs, not how a function should be implemented.
Unfortunately over time, User Stories which define the user need, can get swamped by improvement and enhancement driven ‘technical stories’ describing how a function should work. This is bad practise.
Technical Stories are a legitimate way of driving enhancements where technical change is required – they are not bad in their own right. It is mixing up User Stories and Technical Stories which is bad practice.
It is good practice to:
- Keep User Stories focussed on the user, what they require and why they need it.
- Write Technical Stories if needed to provide detail of how the function is to be enhanced.
- Map Technical Stories to User Stories so that it is clear which User Stories are impacted by improvements or enhancements.
It might be useful to think of User Stories like requirements and Technical Stories as part of the system's design.
Read also: Risk-Based Approach for Computer Systems Validation
Resource Person: Kieran McKeever
 Validation in GxP Regulated Companies){kind=link}