Help Required - URS Article

GOOD VALIDATION PRACTICE (cGVP)
1

Hi All,

I am in the process of writting an article for askaboutvalidation entitled

“How to create a bulletproof URS”

It would be fantastic if you could include your own tips in this thread so I can include them in my article which will be published on this site.

The more input I receive the better the article will become.

Thanks in advance for your help.

2

I’ll get the ball rolling…

Requirements may be developed internally by the supplier (in the case of product development).

Requirements also may be provided by customers for a configured product, custom application, or a service.

3

We deal with external clients and typically end up helping them rewrite their URSs. Some of the common issues we address include:

  • multiple requirements in a single statement (makes verification difficult, at best) - using bullet lists helps clarify / individualize
  • requirements stated as “should” and desirable features stated as “shall” - these have to be scrubbed to determine what true requirements are - note that standardizing use of “shall” for requirements really helps clear matters
  • requirements stated in a non-verifiable manner - use of nebulous verbiage such as “support” always requires clarification
  • inadequate linkage to parent specifications (if any) - leads to missing or incorrect functionality

These are pretty fundamental, but as chandra stated, maybe gets the ball rolling (a bit faster).

4

Another one is

Changes to requirements should be controlled. Changes to subsequent specification documents that affect the requirements should lead to an update of the requirements.

Keep them coming…

5

A few from me then:

    Phrases like "must comply to GMP" - impossible to meet or test Ditto any similar for GAMP, 21 CFR Part 11 etc confusion about whether the URS is a validation document, a contractual one, a project one or any mix of these telling the supplier how to do it, not what the user actually wants it to do writing in targets which simply cannot be met (usually engineering tolerances) writing in that the supplier is responsible for the validation (!)

    and so on.

Great list of things here from everyone - we obviously have some common issues.

Thanks for the input!

6

Excellent point I have encountered this a number of times and wondered how to test these.

Have you any suggestions as to how these can be handled.

7

too much verbage, specifications not adequately defined. I’d rather have a list of tabulated specs ranging from construction to final performance requirements that can actually be tested, as opposed to scouring lines and lines of text to extract what I need…