Computer Systems Validation Part 4 –
User Requirement Specifications

In this article I will discuss the User Requirement Specifications or URS for short.
I will look at what should be included, what should not be included, who should contribute, and the language that should be used.
I will also provide some general advice on practical things to consider that the guidelines don’t mention!

Note for the discussion:

Historically it was considered good practice to have two requirement documents, the first a top-level User Requirements, and the second a much more detailed Functional Requirements.

Indeed, this distinction is still made in Validation ‘V’ models (see below) and should remain the optimal way for processes such as equipment qualification.

Where this approach is still valid for CSV, unless the system / change required is overly complex or the implementation involves a new GAMP Level 5 system, I personally have found it much easier to combine the two.

By having this single document, not only can we have everything in one place, but it makes the entire process much easier for potential vendors having the information to hand.

By structuring the URS correctly using specific system elements as headings (such as the main functionality, hardware, electronic security, data migration etc), it allows us to ensure all requirements are covered in a single document, while still ensuring all the relevant requirements map across the Validation ‘V.’

As a result, I will only refer to a single URS document throughout this article – but take this to mean that the term “URS” includes all levels of requirements.

CSV User Requirements

The problem with User Requirements is that quite often they are anything but that.

It is very easy to lift statements of system functionality from a vendor document / website and simply copy and paste those in. Job done.

However, these are not in any way the user requirements. They may very well tick the box in terms of what a system can do at a high level*, but these will often not be complete, or not reflect what is actually required.

* Take care with vendor claims of functionality – I have seen examples over the years where a system will not do what is stated by the vendor, or at least will not operate in the way a purchasing company will expect it to.

User requirements are most effective when they are collated by a stakeholder group of the relevant individuals and functions, even those who may not in the strictest sense be described as the ‘end user.’

The important thing here is that these are the people that know the job, know the implications of a new system, and understand the processes and Quality implications. Basically, these are the people that know what they need.

Note – the word ‘need’ here is not the same as the word ‘want’ – be aware that users may not always want what they actually need or will want things they absolutely do not need. It is important this distinction is recognised.

As an example, I audited a company once that had installed an HR system that included an elaborate bolt-one biometric access system module for their secure areas. So far so good.

The main issue came however when the staff working there couldn’t actually use it.

The system was bought not because this company needed it, but because the vendor had it as an option, and the HR person making the purchasing decision thought it was “a great idea” to use fingerprints to access different building areas. It would be secure, and they could monitor user traffic. The only problem was that operators were obliged to wear gloves in many of those areas and could not take them off…

In case you are interested, that particular company ended up using good old-fashioned mechanical keypads instead for secure access and the HR Department never got to electronically track movement fully across the site.

So, I would suggest that along with the obvious stakeholders, someone is included to have the job to sanity check the requirements, filter out anything that really is not needed – or at least flag these requirements on the URS as a low priority / low criticality “nice to have” – and consider the wider implications of those choices. These are not always easy conversations, but they are important!

And this point is a theme I have seen a number of times; where one department decides, usually for the right reasons, that the organisation requires some software / a change to existing software. They then go off and research, find a vendor and the application they think is right for them, make the contract, and the project is go.

Only then is the application assessed by the right people, at which point the dreaded “ummm, hang on a minute” conversation is had.

By this time, yes, a URS can be written, but the proverbial horse has not only bolted, it is halfway to the next town.

Who should be involved?

Ideally then the URS should be written before talking to vendors / developers and used as a tool for the discussions with them.

And for that to happen, the following stakeholder functions should be involved in the creation of the URS:

  • Functional SMEs / Technical Representatives
  • IT Representative
  • Quality
  • Validation / The Translator / The Sanity Checker

I list above the Translator, and I have briefly discussed this role in a previous post.

Someone involved in the project must be able to communicate effectively between the different functions to reinforce understanding, and this extends to the URS – where various authors will typically write in their own unique manner using terminology they understand. This ultimately means that someone may need to re-word some of the requirements into a form that can be more widely understood.

For instance the requirement:

“The application must increment the numerical key field counter using the Object. keys() method after each successful operation”

may well mean something important to the IT SME, but not really to anyone else.

In fact, something so specific as above may hinder the developer as they may wish to realise the requirement in a different way. A better way to write this may be:

“The displayed transaction counter is updated after each successful operation”

One of the repeated golden rules is that you should never let an IT Person write a URS.

While this is true up to a point, maybe the rule would be better off written as “you should never let an IT person write all of the URS.” You may well need input from the IT expert at some point to describe constraints (for instance, the system has to run on a certain Operating System and be compatible with the AntiVirus application), minimum hardware requirements (especially when servers are involved), load considerations etc.

Language of the URS

Creating the URS may seem like a simple case of “listing what we require,” and many organisations see the document as just that. However, this approach is missing a golden opportunity to make the whole validation project not only better structured but also easier to manage and complete.

It is important to remember when compiling the user requirements to think about the “V” model – where the requirements map across the ‘V’ to the actual system testing itself:

(A GAMP Level 4 Validation ‘V’ – showing the direct link between the URS and the Functional Testing)

Critical then to making the URS, and by extension the whole validation exercise, successful is the wording used.

Think about how the testing scripts will look. Well-written URS points, in a narrative form, can almost be picked up as is and turned into testing texts.

This is a fundamental part of validation, but one thing that is too often overlooked in the rush to “get something out there.”

For instance, here is an example of a less-than ideal requirement:

Product Master Details

  • In Manufacturing Module
  • Product Reference
  • Product Name
  • Product Type
  • etc

This text, although understood by the user, not only lacks detail, but due to the ambiguous nature of the way it is written, it would allow a developer free reign in realisation.

Working as a team with the SME can allow much better wording as follows:

Product Master Details

  • The system must have a means to manage Product Master Data within the Manufacturing Module
  • Each Product must have a unique Product Reference code, which is an 8-digit alphanumeric field, where the first 2 characters must be letters. This is a required field.
  • Each product must have a name field, which is free text with a maximum of 28 characters
  • The system must have a Product Type field, derived from a drop-down menu with the following limited options:
    • Type A
    • Type B
    • Type C
  • Only users with Administration Level access rights can add, modify or delete product master data
  • And so on…

By writing them in this narrative way, a vendor has no ‘wriggle-room’ for interpretation, and subsequently generating the functional positive and negative test scripts becomes very straightforward as a result.

Also notice the use of the word “must” rather than “should.”

Although the words are often used and indeed meant synonymously, they are not the same, and I have seen some developers take the word “should” to mean “optional.”

The content of the URS

So, what should the contents of the document be?

I have found that having a template that covers all eventualities for all systems helps users ensure that everything they could possibly need to consider is included.

One way to look at the headings typically needed in a URS would be to use the following three headings:

  • Functional Requirements
  • Non-Functional Requirements
  • Hardware / Server Requirements

But this approach rather over-simplifies the scope.

An alternative is to consider the heading as:

  • Inputs
  • Outputs
  • Processes
  • Performance
  • Controls

And although these may work well ultimately for a developer, it is not always that easy for an SME to think in these terms.

I therefore recommend a middle ground approach, where all bases are covered with enough scope for both SME and technical input. Additionally, the regulated quality critical elements are given their own headings to ensure they also are considered and covered.

The headings would therefore fall into:

  • Application Functionality
  • Non-Application Functionality
  • Hardware
  • Connections to Other Systems / Equipment (Software and Hardware)
  • Business Continuity Management
  • Data Considerations
    • Definition and Integrity
    • Required Fields and Configuration
    • Calculations
    • Migration
    • Archiving
  • Outputs and Reports
  • Quality Critical Considerations
    • Electronic Security
    • Physical Security
    • User Roles
    • Audit Trails
    • Electronic Signatures
    • Backup and Restore
  • Training Provision

I have found that these set of headings will ensure that all business and regulatory requirements get considered – and of course where there are no requirements for a particular heading, it can simply be made “N/A.”

Additionally, these headings, if used as a collective set, will ensure that things that should not be in the URS do not get included.

Although it is tempting to put absolutely everything one can think of in, some of the things that should not be put into a URS include:

  • Anything that would otherwise be in a contract such as payment, costs, and business terms
  • Further details of standards and accreditations
    • i.e. if you state that a vendor needs to have an ISO27001 accreditation, you do not then need to list what this entails
  • How the requirements are to be realised (unless there is a regulatory condition to do so)

Additional considerations:

There are some other things to think about when creating a URS:

  • With any new system, or when considering an alternative system, take the opportunity to go back to basics and use some critical thinking to consider how you want things to work, rather than attempting to build in legacy processes which may no longer be considered best practice and/or fit for purpose.
  • Add workflows – simple flowchart diagrams describing the process and data flows through a system.

I have found these particularly useful for highlighting to vendors (and indeed colleagues) where specific actions or decisions have to take place within a process.

A good example of this was an artwork design and approval system – which required very defined stages needing electronic signatures by specific job functions at very exact points.

This could have been written long-hand in the URS text but was much easier to describe and explain in a more visual medium (and the flowchart fed nicely into an end-to-end test at the OQ stage).

  • Mocked-up screen layouts are an effective way of describing User Interface (the ‘UI’ i.e. what the user sees on the screen) requirements
    • And are a good way of relieving the developer of any idiosyncratic creative design freedom opportunities…
  • When stating OS and browser requirements, try to avoid stating things like “the system must function correctly under the latest version of Windows.”

This is because, of course, the latest version today may become the previous version tomorrow.

Instead, therefore try to include version numbers as a minimum requirement – based on current use

  • Where the system has Critical Processing Parameters (CPPs), but these are unknown, ensure the requirements describe the controls limits inside which the CPPs must sit
Computer Systems Validation

Finally, in this section, we need to Return to one of the Four Horseman of the Validation Apocalypse, namely WAR – User Requirements and Scope Drift.

Any normal development process involves a certain amount of change from the original requirements

Additional requirements may be considered later in the project cycle. It is possible that some initial requirements will not ultimately be required. And it is possible (and altogether likely when Agile Development methods are used) that some requirements will naturally change in scope during development. I will discuss System Development in a future blog.

BUT the above is not considered Scope Drift, just a natural process.

Scope Drift occurs when a project is ongoing and then someone decides that they want the system to also do something else – at which point the development process is maddeningly reset to zero while a whole new element is considered, explored, investigated, discussed, thought about, designed and then finally added.

This obviously delays everything, and, even worse, can then be compounded by someone else jumping in to add yet another component function. I have seen projects balloon alarmingly at certain critical points, even to the extent that the original reason for having the system in the first place ends up being lost in the muddle.

At some point therefore a decision has to be made to ‘cut-off’ any further discussion regarding new functionality and run with what you have.

Ultimately do not worry about the URS needing to change. The URS is a living document and can be updated and re-issued with a later revision number, or ongoing changes can be picked up within the Design Qualification documentation without negatively impacting on the validation effort.

Changes from the original URS do however need to be recorded somewhere…

CSV User Requirements

What about a URS for system updates?

All of the above discussion is really centred around new systems. But what about systems requiring an update? Why would these require a URS?

The answer is they don’t necessarily. But sometimes they do. Let me explain.

If a commercially and widely available system is having a standard update provided by the vendor, then it is entirely possible that there will be no need for an internal URS, as the update is whatever changes the vendor updates the system with. This can be dealt with using the vendor Release Notes and the associated Risk Assessment.

It is also possible that the vendor will create and provide a URS for their own documentation set, and this can be used as further supporting evidence.

However, if new functionality is required by the customer for an existing system, then a URS should be created. Just ensure the scope of the URS is limited to the new requirements only. Don’t include all existing functionality as that can easily make the scope of the validation exercise much greater than it needs to be.

To summarise

Always remember that the URS should ultimately be the tool to drive the validation, and much more than just a means to an end.

The URS document, while not always given the care and attention it deserves, if done correctly and in enough detail should be the cornerstone of the validation effort.

A well-written and comprehensive URS can almost write the functional testing to come later and can ensure that a system does ALL of what the business needs it to.

BUT (and this is a statement that can be used across the validation effort), never lose sight of why we are actually validating a system in the first place, i.e. to ensure Quality – or that the system is Fit for Purpose and that we formally record this in the Pharmaceutical Quality System.

In the next entry in this series, I will discuss Risk Assessments and how they need not be as repeatedly arduous and hard work as some companies choose to make them.

To find out how we can help your organisation with your Computer Systems Validation and Data Integrity needs please get in touch at or to read more about our CSV services, please click here.

Read all posts in this series:

Neil Rudd
2024-01-22T09:48:19+00:00January 18th, 2024|
Go to Top