User Requirements Specifications (URS) in Pharmacovigilance

Introduction

The User Requirements Specification (URS) is one of the most important documents produced during Computerised System Validation. It defines what a computerised system must do to support the organisation's business processes while meeting regulatory, quality and operational requirements.

Every subsequent validation activity—including risk assessment, configuration, testing, traceability and final system acceptance—is ultimately based upon the User Requirements Specification. Consequently, deficiencies introduced within the URS frequently propagate throughout the entire validation lifecycle.

Within pharmacovigilance, a well-written URS ensures that computerised systems support activities such as Individual Case Safety Report processing, regulatory reporting, signal management, aggregate reporting, literature monitoring and quality management in a reliable, compliant and reproducible manner.

The objective of a URS is not to describe how software should be implemented. Instead, it defines what users require the system to achieve in order to support regulated pharmacovigilance activities.

This article explains the purpose of the User Requirements Specification, describes regulatory expectations, outlines the characteristics of well-written requirements and discusses how experienced validation professionals develop URS documents that remain useful throughout the system lifecycle.

Learning Objectives

After reading this article, you should be able to:

• explain the purpose of a User Requirements Specification;
• distinguish business requirements from technical design;
• understand regulatory expectations relating to the URS;
• recognise the characteristics of high-quality requirements;
• understand how the URS supports risk assessment and validation testing;
• identify common deficiencies identified during audits and inspections.

What Is a User Requirements Specification?

A User Requirements Specification (URS) is a controlled document that defines what users require a computerised system to do in order to support its intended business processes.

It represents the formal agreement between the business and the project team regarding the capabilities that the system must provide before it can be considered suitable for operational use.

Within Computerised System Validation, the URS forms the foundation upon which all subsequent validation activities are built. System design, configuration, risk assessment, testing, traceability and final acceptance should all be directly traceable to approved user requirements.

The URS should therefore describe organisational needs rather than technical implementation.

A Business Document Rather Than a Technical Document

One of the most common misconceptions is that the User Requirements Specification should describe how software will be built or configured.

This is incorrect.

The URS is fundamentally a business document.

It describes what users need the system to achieve rather than how developers or vendors will implement those requirements.

For example, a requirement stating:

"The system shall support electronic submission of Individual Case Safety Reports to EudraVigilance."

is appropriate for a URS.

In contrast:

"The system shall use XML schema version X.X and web service protocol Y."

describes implementation rather than business need and would normally belong within design or technical documentation.

Maintaining this distinction allows organisations to evaluate different software solutions without unnecessarily constraining implementation.

The Voice of the Business

The URS represents the voice of the business.

It captures the expectations of those responsible for performing regulated pharmacovigilance activities, including:

• pharmacovigilance operations;
• case processing;
• medical review;
• signal management;
• regulatory reporting;
• quality assurance;
• information technology;
• business process owners;
• system administrators.

The document should therefore reflect how the organisation intends to use the system rather than how the software supplier prefers to implement it.

Defining Intended Use

Every validation activity begins with intended use.

The User Requirements Specification provides the primary description of that intended use by defining:

• the business processes the system will support;
• the information the system will process;
• the users who will operate the system;
• the regulatory obligations the system must satisfy;
• the outcomes expected by the organisation.

Without a clearly defined intended use, meaningful validation cannot occur because there is no objective basis for determining whether the system is fit for purpose.

The Foundation of the Validation Lifecycle

Although numerous validation documents may be produced throughout the lifecycle of a computerised system, the User Requirements Specification occupies a unique position.

It influences:

• risk assessments;
• functional specifications;
• system configuration;
• validation protocols;
• test scripts;
• traceability matrices;
• user acceptance testing;
• final validation conclusions.

Errors, omissions or ambiguities introduced into the URS frequently propagate throughout the remainder of the validation project.

For this reason, experienced validation professionals devote considerable effort to developing and reviewing the User Requirements Specification before implementation begins.

Scientific Foundation

A User Requirements Specification does not describe software. It describes the regulated business capabilities that the software must provide to support safe, reliable and compliant pharmacovigilance activities.

Why the User Requirements Specification Is the Foundation of Computerised System Validation

The User Requirements Specification occupies a unique position within the validation lifecycle because every subsequent validation activity should be traceable to one or more approved user requirements.

Unlike testing, configuration or deployment, the URS defines the objectives that the entire validation project is intended to achieve. It establishes the benchmark against which system suitability, validation completeness and operational acceptance are ultimately evaluated.

For this reason, experienced validation professionals regard the URS as the single most important validation document.

The Starting Point for Validation

Validation seeks to demonstrate that a computerised system is fit for its intended use.

However, before that question can be answered, the intended use itself must be defined clearly.

The User Requirements Specification provides this definition.

Without approved requirements, there is no objective basis for determining:

• whether the implemented system is complete;
• whether testing has been sufficient;
• whether regulatory expectations have been satisfied;
• whether the system is suitable for operational use.

Consequently, validation cannot begin meaningfully until the intended use has been documented.

The Foundation for Risk Assessment

Modern Computerised System Validation is based upon quality risk management.

Risk cannot be assessed without first understanding what the system is expected to do.

The User Requirements Specification therefore provides the context for identifying:

• critical business processes;
• patient safety risks;
• regulatory risks;
• data integrity risks;
• operational risks.

As the importance of a requirement increases, the level of validation assurance required generally increases.

Risk assessment should therefore be driven by approved user requirements rather than performed independently.

The Basis for System Design

Although the URS does not describe technical implementation, it establishes the framework within which technical design occurs.

Functional specifications, configuration documents and technical designs should all demonstrate how approved user requirements will be satisfied.

This separation between business requirements and technical implementation provides important flexibility.

Different software solutions may satisfy the same business requirement using very different technical approaches.

Validation should evaluate whether the requirement has been met rather than whether a particular technical design has been chosen.

The Basis for Validation Testing

Validation testing should demonstrate that approved user requirements have been implemented correctly.

Every important requirement should therefore be verified through appropriate objective evidence.

Testing should not simply demonstrate that software functions operate.

Instead, it should demonstrate that regulated business requirements have been satisfied.

This distinction is particularly important during inspections, where regulators frequently examine whether testing remains traceable to approved requirements.

Supporting Traceability

Traceability is one of the defining characteristics of a mature validation programme.

An effective validation package allows reviewers to follow each important requirement through:

• risk assessment;
• system design;
• configuration;
• testing;
• deviation management;
• final approval.

This traceability demonstrates that validation has been systematic, complete and scientifically justified.

Without a well-structured User Requirements Specification, effective traceability becomes difficult to achieve.

Supporting Change Control

Computerised systems evolve throughout their operational life.

Business processes change, regulatory requirements develop and software vendors release updates.

Whenever changes occur, organisations must determine whether existing validation remains adequate.

The User Requirements Specification provides the reference point for this evaluation.

By comparing proposed changes against approved requirements, organisations can determine:

• whether intended use has changed;
• whether additional validation is required;
• whether existing testing remains sufficient;
• whether regulatory risks have increased.

Consequently, the value of a well-written URS extends far beyond the initial implementation project.

Supporting Inspection Readiness

During inspections, regulators rarely review a User Requirements Specification in isolation.

Instead, they examine whether the URS provides a clear and traceable foundation for the entire validation programme.

Inspectors frequently assess whether:

• requirements are complete;
• requirements have been approved;
• testing demonstrates fulfilment of requirements;
• critical requirements received appropriate validation;
• changes remain consistent with the approved intended use.

A well-structured URS therefore strengthens confidence in the validation programme as a whole.

Scientific Foundation

The User Requirements Specification is not simply the first validation document. It is the reference against which every important validation decision—including risk assessment, testing, change control and final acceptance—should ultimately be justified.

Characteristics of High-Quality User Requirements

The quality of a User Requirements Specification is determined not by its length or level of technical detail but by the clarity with which it communicates the business needs of the organisation.

Well-written requirements reduce ambiguity, simplify validation, improve testing, support traceability and reduce the likelihood of costly changes during implementation.

Conversely, poorly written requirements frequently lead to misunderstandings, unnecessary rework, incomplete testing and regulatory deficiencies.

Although different organisations use different requirement templates, high-quality requirements share several common characteristics.

Requirements Should Be Clear

Each requirement should communicate a single business need using language that can be understood consistently by business users, system suppliers, validators and inspectors.

Ambiguous wording should be avoided.

For example, statements such as:

• "The system should be easy to use."
• "The system should process cases quickly."

do not define measurable expectations and may be interpreted differently by different reviewers.

Instead, requirements should describe the required business capability as precisely as possible.

Requirements Should Be Complete

The User Requirements Specification should describe all business capabilities necessary for the intended use of the system.

Common areas include:

• functional requirements;
• regulatory requirements;
• security requirements;
• reporting requirements;
• interface requirements;
• audit trail requirements;
• user management;
• backup and recovery;
• business continuity;
• data retention.

Incomplete requirements frequently result in missing functionality being identified only during implementation or testing.

Requirements Should Be Unambiguous

Each requirement should have only one reasonable interpretation.

Words such as:

• appropriate;
• adequate;
• efficient;
• user-friendly;
• flexible;
• robust;

may appear meaningful but are difficult to interpret objectively unless accompanied by measurable acceptance criteria.

Reducing ambiguity improves consistency during configuration, testing and inspection.

Requirements Should Be Testable

Every requirement should be capable of objective verification.

Reviewers should be able to answer the question:

"How will we demonstrate that this requirement has been satisfied?"

If no practical verification method exists, the requirement should be revised until objective evidence can be generated.

Testable requirements support efficient validation and reduce disagreement during user acceptance.

Requirements Should Be Traceable

Each requirement should possess a unique identifier and remain traceable throughout the validation lifecycle.

Traceability should extend from:

• the approved requirement;
• associated risk assessments;
• design documentation;
• configuration;
• validation testing;
• deviations;
• final approval.

Effective traceability demonstrates that every important business requirement has been evaluated appropriately.

Requirements Should Be Implementation Independent

The User Requirements Specification should describe what the organisation requires rather than how the supplier should implement the solution.

For example:

"The system shall maintain a complete audit trail for safety data."

is a user requirement.

Conversely:

"The system shall use database technology X with audit module Y."

describes implementation and should normally be documented elsewhere.

Maintaining implementation independence provides flexibility when selecting or upgrading software solutions.

Requirements Should Be Necessary

Every requirement included within the URS should support a genuine business, regulatory or operational need.

Requirements that add little value increase validation effort, complicate testing and may unnecessarily constrain future system changes.

Experienced validation professionals therefore challenge each proposed requirement by asking:

"Why is this capability necessary?"

Only requirements that support the intended use of the system should be retained.

Requirements Should Be Proportionate to Risk

Not all requirements have equal significance.

Requirements relating to expedited reporting, audit trails, user access control, electronic signatures or regulatory submissions generally require greater attention than requirements relating to administrative convenience.

Understanding this distinction supports modern risk-based validation by ensuring that validation effort is directed towards requirements that are most important for patient safety, data integrity and regulatory compliance.

Requirements Should Describe One Concept

Each requirement should describe a single business capability.

Combining multiple expectations within a single requirement complicates testing and traceability.

For example:

"The system shall perform duplicate detection, generate regulatory submissions and archive completed cases."

contains several independent requirements.

Separating these into individual statements improves clarity, traceability and verification.

Writing Requirements for the Future

Well-written requirements remain useful throughout the operational life of the system.

They should therefore describe enduring business needs rather than temporary technical solutions.

By focusing on intended use instead of implementation, organisations create User Requirements Specifications that continue to support change control, upgrades, supplier transitions and future validation activities.

Scientific Foundation

High-quality requirements communicate business needs clearly, objectively and independently of technical implementation. They provide the stable foundation upon which risk assessment, system design, validation testing and lifecycle management are built.

Types of User Requirements

A comprehensive User Requirements Specification should describe every significant capability that users require from the computerised system.

Although organisations may organise their requirements differently, most pharmacovigilance URS documents contain similar categories of requirements.

Grouping related requirements improves completeness, facilitates review and supports traceability throughout the validation lifecycle.

Business Requirements

Business requirements describe the business objectives that the computerised system must support.

These requirements explain why the system is needed rather than how it will operate.

Examples include:

• support global pharmacovigilance operations;
• enable timely processing of Individual Case Safety Reports;
• support compliance with global regulatory reporting obligations;
• facilitate signal management activities;
• maintain inspection readiness.

Business requirements provide the context for all subsequent functional and technical requirements.

Functional Requirements

Functional requirements describe the activities that users expect the system to perform.

Within pharmacovigilance, examples include:

• create and process Individual Case Safety Reports;
• support MedDRA coding;
• manage product dictionaries;
• perform duplicate detection;
• generate expedited regulatory reports;
• support literature case processing;
• maintain workflow status;
• generate aggregate safety reports;
• record medical assessments.

Functional requirements generally represent the largest section of the User Requirements Specification.

Regulatory Requirements

Computerised systems used within pharmacovigilance must support compliance with applicable regulatory obligations.

Examples of regulatory requirements include:

• maintenance of complete audit trails;
• retention of regulated records;
• support for electronic regulatory submissions;
• compliance with electronic record requirements;
• controlled user access;
• electronic signatures where applicable;
• preservation of data integrity.

These requirements ensure that the implemented system supports the organisation's regulatory responsibilities.

Data Integrity Requirements

Reliable pharmacovigilance depends upon complete, accurate and traceable data.

Accordingly, the URS should define requirements relating to:

• data accuracy;
• data completeness;
• prevention of unauthorised modification;
• audit trail generation;
• version control;
• record retention;
• recovery following system failure.

These requirements support confidence in the quality of safety information used for regulatory decision-making.

Security Requirements

Computerised systems should protect confidential information while allowing authorised users to perform their responsibilities.

Typical security requirements include:

• role-based access control;
• user authentication;
• password management;
• account lockout;
• privileged user management;
• encryption where appropriate;
• logging of security events.

Security requirements should reflect both organisational policies and applicable regulatory expectations.

Interface Requirements

Many pharmacovigilance systems exchange information with other applications.

Examples include interfaces with:

• EudraVigilance;
• safety databases;
• literature monitoring platforms;
• reporting systems;
• document management systems;
• Product Information systems;
• quality management systems.

The URS should describe the required business outcomes of these interfaces without prescribing the technical implementation.

Reporting Requirements

Reporting capabilities are often critical to pharmacovigilance operations.

Examples include:

• regulatory submission reports;
• compliance metrics;
• workload reports;
• quality indicators;
• signal management reports;
• audit trail reports;
• management dashboards.

Reporting requirements should define the business information required by users rather than the technical method used to generate reports.

Performance and Availability Requirements

The User Requirements Specification should describe the expected operational performance of the system.

Examples include:

• acceptable response times;
• expected system availability;
• maximum planned downtime;
• support for peak processing periods;
• scalability requirements.

Performance expectations should be proportionate to the criticality of the business processes supported.

Business Continuity and Disaster Recovery Requirements

Pharmacovigilance activities continue even during unexpected system failures.

The URS should therefore include requirements relating to:

• backup procedures;
• restoration of data;
• disaster recovery capability;
• continuity of critical pharmacovigilance activities;
• recovery time objectives where appropriate.

These requirements support organisational resilience while protecting patient safety and regulatory compliance.

Future-Proofing Requirements

Computerised systems frequently remain operational for many years.

Accordingly, the URS should consider future organisational needs, including:

• regulatory changes;
• organisational growth;
• additional products;
• increased reporting volumes;
• new interfaces;
• system upgrades;
• evolving business processes.

Anticipating future requirements helps reduce unnecessary redevelopment while supporting long-term maintainability.

Scientific Foundation

A well-structured User Requirements Specification addresses every important aspect of the regulated business process. By defining business, functional, regulatory, security, data integrity and operational requirements separately, organisations create a comprehensive foundation for successful Computerised System Validation.

How to Write High-Quality User Requirements

Writing effective user requirements is both a technical and professional skill. A well-written requirement should communicate a business need so clearly that different reviewers independently reach the same understanding of what the system is expected to achieve.

The objective is not to produce lengthy documentation but to create requirements that can be implemented, tested, reviewed and maintained throughout the operational life of the computerised system.

Experienced validation professionals therefore devote significant effort to requirement quality before configuration or software development begins.

Begin with the Business Process

Requirements should originate from the regulated business process rather than the capabilities of a particular software product.

Before writing individual requirements, organisations should understand:

• the business process being supported;
• the users who will perform the process;
• applicable regulatory obligations;
• patient safety considerations;
• data integrity expectations;
• operational risks.

Understanding the business process helps ensure that requirements describe genuine organisational needs rather than software features.

Use Clear and Consistent Language

Requirements should be written using language that is simple, precise and objective.

Each requirement should communicate one expectation using terminology that is understood consistently by business users, software suppliers, validators and inspectors.

Where possible:

• use consistent terminology throughout the document;
• define abbreviations before use;
• avoid unnecessary technical language;
• avoid subjective wording.

Consistency improves review, testing and long-term maintenance.

Use Mandatory Language Appropriately

Many organisations adopt standard terminology when writing requirements.

Typical conventions include:

• shall — mandatory requirement;
• should — recommended requirement;
• may — optional capability.

For regulated pharmacovigilance systems, mandatory business and regulatory requirements should normally use shall.

Consistent use of requirement language reduces ambiguity and simplifies interpretation during validation and inspection.

Write One Requirement at a Time

Each requirement should describe a single business capability.

For example, instead of writing:

"The system shall process Individual Case Safety Reports, generate expedited reports and maintain audit trails."

consider separating this into three independent requirements.

This approach improves:

• traceability;
• testing;
• change control;
• impact assessment;
• future maintenance.

Atomic requirements are considerably easier to validate than compound statements containing multiple expectations.

Avoid Ambiguous Language

Certain words frequently appear in poorly written requirements because they cannot be interpreted objectively.

Examples include:

• adequate;
• appropriate;
• efficient;
• flexible;
• user-friendly;
• robust;
• rapid;
• intuitive.

Unless these terms are clearly defined, different reviewers may interpret them differently.

Where measurable expectations exist, they should be stated explicitly.

Make Requirements Verifiable

Every requirement should be capable of objective verification.

When reviewing a requirement, validation teams should ask:

"How will we demonstrate that this requirement has been satisfied?"

If no clear answer exists, the requirement should be revised.

Verifiable requirements simplify validation planning and reduce disagreements during testing and user acceptance.

Maintain Independence from Technical Design

The User Requirements Specification should describe business outcomes rather than technical implementation.

For example:

Good requirement

"The system shall maintain a complete audit trail for all modifications to regulated pharmacovigilance data."

Design statement

"The system shall use database trigger technology to populate an audit table."

The first statement belongs within the URS because it describes the required business capability.

The second describes implementation and belongs within design documentation.

Maintaining this distinction allows technical solutions to evolve without altering the underlying business requirement.

Number Every Requirement

Each requirement should possess a unique identifier.

Unique numbering supports:

• traceability;
• testing;
• deviation management;
• change control;
• periodic review;
• inspection readiness.

Stable identifiers remain valuable throughout the lifecycle of the computerised system, particularly when software is upgraded or revalidated.

Review Requirements Before Validation Begins

Correcting poorly written requirements during implementation is considerably more expensive than correcting them during document review.

Accordingly, User Requirements Specifications should undergo multidisciplinary review involving representatives from:

• pharmacovigilance;
• quality assurance;
• information technology;
• validation;
• system administration;
• regulatory affairs where appropriate.

Early review improves completeness, consistency and scientific quality while reducing downstream validation effort.

Examples

The following examples illustrate the difference between effective and ineffective requirements.

The improved examples describe specific business capabilities that can be reviewed, tested and maintained throughout the validation lifecycle.

Scientific Foundation

High-quality requirements describe business needs clearly, objectively and independently of technical implementation. Every requirement should communicate one verifiable expectation that contributes directly to the intended use of the computerised system.

Regulatory Expectations for User Requirements Specifications

Although regulatory authorities rarely prescribe the exact format of a User Requirements Specification, international guidance consistently expects regulated organisations to define their business requirements before implementing or validating a computerised system.

A well-developed User Requirements Specification demonstrates that the organisation understands the intended use of the system and has established objective criteria against which system suitability can be evaluated.

Modern regulatory guidance increasingly emphasises lifecycle management, quality risk management and scientifically justified validation activities rather than prescriptive documentation.

Regardless of the validation methodology adopted, the User Requirements Specification remains one of the most important documents supporting these objectives.

GAMP 5 Second Edition

The ISPE GAMP 5 Second Edition promotes a science-based and risk-based approach to Computerised System Validation.

Within this framework, the User Requirements Specification defines the intended use of the system and establishes the foundation for supplier assessment, risk management, system design, testing and acceptance.

GAMP encourages organisations to produce documentation that is proportionate to system complexity and regulatory risk while maintaining clear traceability between approved requirements and objective validation evidence.

Rather than viewing the URS as a standalone document, GAMP considers it an integral component of the entire system lifecycle.

FDA Computer Software Assurance (CSA)

The FDA's Computer Software Assurance (CSA) guidance reinforces the principle that validation activities should focus on generating meaningful assurance rather than excessive documentation.

Within the CSA approach, user requirements continue to define the intended business capabilities of the system.

However, validation effort should concentrate on requirements that affect:

• patient safety;
• product quality;
• data integrity;
• regulatory compliance.

This approach encourages organisations to distinguish critical business requirements from lower-risk operational features, allowing validation resources to be directed where they provide the greatest value.

EU Annex 11

Annex 11 of the European Union Good Manufacturing Practice Guidelines requires regulated organisations to demonstrate that computerised systems remain suitable for their intended use throughout their operational lifecycle.

Although Annex 11 does not prescribe the structure of a User Requirements Specification, its expectations regarding validation, risk management, supplier oversight and lifecycle management all depend upon clearly defined system requirements.

A well-developed URS therefore provides an essential foundation for demonstrating compliance with Annex 11 principles.

Good Pharmacovigilance Practices

Within pharmacovigilance, Good Pharmacovigilance Practices require organisations to maintain quality systems capable of supporting reliable pharmacovigilance activities.

Computerised systems performing regulated pharmacovigilance functions should therefore support:

• accurate processing of safety data;
• reliable regulatory reporting;
• maintenance of audit trails;
• protection of confidential information;
• preservation of data integrity;
• appropriate governance and oversight.

The User Requirements Specification should define these expectations before implementation begins.

ICH Q9(R1) and Quality Risk Management

ICH Q9(R1) establishes quality risk management as a fundamental principle of pharmaceutical quality systems.

Application of quality risk management begins with understanding what the computerised system is expected to accomplish.

The User Requirements Specification therefore provides the context necessary for identifying:

• critical business processes;
• hazards;
• potential failure modes;
• risk control measures;
• validation priorities.

Without clearly defined requirements, meaningful quality risk management becomes significantly more difficult.

Common Regulatory Expectations

Although regulatory documents differ in terminology and scope, several common expectations emerge.

Regulators generally expect User Requirements Specifications to:

• define the intended use of the system;
• reflect genuine business needs;
• support quality risk management;
• provide a foundation for validation;
• remain traceable throughout the lifecycle;
• support change control;
• facilitate objective verification.

Collectively, these expectations promote scientifically justified validation while ensuring that computerised systems continue to support patient safety, data integrity and regulatory compliance.

Regulatory Expectations Continue Throughout the Lifecycle

Approval of the User Requirements Specification does not conclude its regulatory significance.

Throughout the operational life of the system, the URS continues to support:

• periodic review;
• impact assessments;
• software upgrades;
• supplier changes;
• revalidation activities;
• retirement planning.

Consequently, organisations should regard the URS as a controlled lifecycle document rather than a document created solely to support initial implementation.

Regulatory Insight

Regulators rarely assess a User Requirements Specification in isolation. Instead, they evaluate whether approved business requirements provide a clear, traceable and scientifically justified foundation for the entire validation programme throughout the operational life of the computerised system.

Common Mistakes When Writing User Requirements Specifications

Many validation difficulties originate long before software configuration or testing begins. They arise because the User Requirements Specification fails to describe the organisation's true business needs clearly, completely or objectively.

A poorly written URS frequently leads to inappropriate software selection, unnecessary customisation, incomplete testing, ineffective traceability and costly project delays. More importantly, deficiencies introduced into the URS often propagate throughout the entire validation lifecycle because every subsequent validation activity depends upon approved user requirements.

Recognising these common mistakes helps organisations develop User Requirements Specifications that support efficient implementation, effective validation and long-term lifecycle management.

Confusing Business Requirements with Technical Design

One of the most frequent mistakes is describing how the system should be implemented rather than what the business requires.

For example, a requirement stating that a particular database technology, programming language or software architecture must be used usually describes technical implementation rather than business need.

The User Requirements Specification should instead define the capability required by the business, leaving technical implementation to the Functional Specification, Design Specification or supplier documentation.

Maintaining this distinction provides greater flexibility when evaluating different software solutions and simplifies future upgrades.

Copying Vendor Documentation

Another common mistake is reproducing supplier brochures, software manuals or marketing material within the User Requirements Specification.

Vendor documentation describes the capabilities of a specific product.

The URS should instead describe the capabilities that the organisation requires, regardless of which software supplier ultimately provides the solution.

Developing requirements independently of vendor products helps ensure that software selection remains objective and driven by business needs.

Writing Ambiguous Requirements

Ambiguous requirements create uncertainty during implementation and testing because different reviewers may interpret the same statement differently.

Examples include requirements containing words such as:

• appropriate;
• efficient;
• intuitive;
• user-friendly;
• flexible;
• robust;
• rapid.

Unless these terms are supported by measurable acceptance criteria, they should generally be avoided.

Clear, objective language reduces misunderstanding and improves consistency throughout validation.

Combining Multiple Requirements

Each requirement should describe one business capability.

Requirements containing several unrelated expectations are difficult to review, difficult to test and difficult to trace.

For example:

"The system shall perform duplicate detection, generate regulatory submissions and archive completed cases."

describes three separate capabilities.

Separating these into individual requirements improves clarity, testing and change management.

Writing Requirements That Cannot Be Tested

Every requirement should be capable of objective verification.

Requirements that cannot be demonstrated through inspection, testing or documented evidence provide little value during validation.

Before approving a requirement, reviewers should ask:

"How will we demonstrate that this requirement has been satisfied?"

If no clear answer exists, the requirement should be revised.

Omitting Regulatory Requirements

Some User Requirements Specifications focus primarily on business functionality while overlooking regulatory expectations.

Common omissions include requirements relating to:

• audit trails;
• electronic records;
• user access management;
• data retention;
• security controls;
• data integrity;
• business continuity;
• disaster recovery.

Failure to identify these requirements early may result in significant redevelopment during later stages of the project.

Excessive Detail

Although requirements should be sufficiently detailed to support validation, excessive technical detail may unnecessarily constrain implementation.

The objective of the URS is not to describe every screen, database table or software algorithm.

Instead, it should define the business capabilities that the implemented solution must provide.

Appropriate separation between requirements and technical design improves maintainability while supporting future system changes.

Inadequate Stakeholder Involvement

A User Requirements Specification developed by a single department rarely reflects the needs of the entire organisation.

Effective URS development should involve representatives from:

• pharmacovigilance operations;
• medical review;
• quality assurance;
• regulatory affairs;
• information technology;
• validation;
• system administration;
• business process owners.

Early multidisciplinary review improves completeness, identifies conflicting expectations and reduces downstream project risk.

Failure to Consider the Entire System Lifecycle

Some User Requirements Specifications focus exclusively on system implementation while overlooking activities performed after go-live.

Requirements should also consider:

• change control;
• periodic review;
• system maintenance;
• supplier support;
• backup and recovery;
• disaster recovery;
• archival;
• retirement.

Considering the complete lifecycle produces User Requirements Specifications that remain valuable long after implementation has been completed.

Failing to Prioritise Requirements

Not every requirement has the same impact on patient safety, data integrity or regulatory compliance.

Treating all requirements as equally important may result in validation effort being distributed inefficiently.

Organisations should distinguish critical requirements from those that primarily improve operational efficiency, allowing validation activities to remain proportionate to business and regulatory risk.

Professional Insight

Most validation problems do not arise because software fails to perform correctly. They arise because organisations failed to define clearly what the software was expected to do before implementation began. A carefully developed User Requirements Specification remains the most effective method of preventing these problems.

Inspection Perspective

Regulatory inspectors rarely review a User Requirements Specification simply to confirm that the document exists. Instead, they evaluate whether the URS provides a robust and traceable foundation for the entire Computerised System Validation programme.

An effective URS demonstrates that the organisation understood its business processes before implementing the computerised system and that validation activities were planned against clearly defined business objectives rather than software functionality alone.

Consequently, inspectors frequently assess the quality of the URS indirectly by examining its relationship with risk assessments, system configuration, validation testing, change control and ongoing lifecycle management.

What Inspectors Look For

During inspections, reviewers typically seek objective evidence that the User Requirements Specification:

• clearly defines the intended use of the system;
• reflects regulated pharmacovigilance business processes;
• includes applicable regulatory requirements;
• addresses patient safety and data integrity;
• has undergone appropriate review and approval;
• remains under document control;
• supports complete traceability throughout the validation lifecycle.

A well-constructed URS enables inspectors to understand why the system exists, what it is expected to achieve and how the organisation determined that those expectations were satisfied.

Traceability Is Frequently Examined

Inspectors commonly evaluate whether approved requirements can be traced throughout the validation package.

For important business requirements, organisations should be able to demonstrate clear links between:

• the approved requirement;
• quality risk assessments;
• functional or design specifications;
• configuration where appropriate;
• validation testing;
• documented deviations;
• corrective actions where necessary;
• final acceptance.

Incomplete traceability may indicate that important business capabilities were not adequately verified.

Intended Use Must Be Consistent

One area frequently examined during inspections is whether the intended use described within the User Requirements Specification remains consistent with the implemented system.

Inspectors may compare the URS with:

• system configuration;
• operational workflows;
• standard operating procedures;
• training materials;
• actual system use.

Significant differences may indicate uncontrolled scope changes or inadequate change management.

Evidence of Multidisciplinary Review

Because computerised systems support multiple regulated activities, inspectors often expect evidence that the User Requirements Specification was developed collaboratively.

Depending upon the scope of the system, contributors may include representatives from:

• pharmacovigilance operations;
• medical review;
• quality assurance;
• information technology;
• validation;
• regulatory affairs;
• system administration;
• business process ownership.

Broad stakeholder involvement improves completeness while demonstrating appropriate organisational governance.

Common Inspection Findings

Inspection findings relating to User Requirements Specifications frequently include:

• incomplete definition of intended use;
• ambiguous or subjective requirements;
• missing regulatory or data integrity requirements;
• inadequate stakeholder review;
• poor traceability between requirements and testing;
• undocumented changes to approved requirements;
• obsolete or uncontrolled URS versions;
• insufficient consideration of lifecycle activities.

Many of these findings originate during project planning and remain unresolved throughout the operational life of the system.

Inspection Readiness Begins with the URS

Inspection readiness should not begin immediately before a regulatory inspection.

Instead, organisations should maintain User Requirements Specifications as controlled lifecycle documents that continue to reflect the intended use of the validated system.

Whenever major changes occur, organisations should evaluate whether the approved User Requirements Specification remains accurate and whether additional validation activities are required.

Maintaining an accurate and current URS throughout the system lifecycle provides confidence not only during inspections but also during upgrades, supplier changes, periodic reviews and system retirement.

Inspection Insight

Inspectors rarely ask whether a User Requirements Specification exists. They ask whether it demonstrates a clear understanding of the regulated business process and whether the entire validation programme can be traced back to those approved business requirements.

How an Experienced CSV Lead Thinks About a User Requirements Specification

Experienced Computerised System Validation professionals rarely begin by asking which software product will be implemented.

Instead, they begin by understanding the regulated business process that the computerised system is expected to support.

For them, the User Requirements Specification is not simply the first validation document. It is the document that captures the business problem the organisation is attempting to solve and establishes the objectives against which the success of the entire validation programme will ultimately be judged.

They Think About Business Processes Before Software

Experienced validation professionals understand that software exists to support regulated business activities.

Consequently, they first seek to understand questions such as:

• Which pharmacovigilance process will this system support?
• Which users will perform the process?
• Which regulatory obligations depend upon the system?
• Which decisions will be based upon the information it generates?
• Which failures could affect patient safety or regulatory compliance?

Only after these questions have been answered do they begin defining user requirements.

They Think in Terms of Intended Use

Rather than documenting every available software feature, experienced CSV Leads continuously ask:

"What does the organisation actually need this system to do?"

They recognise that validation demonstrates fitness for intended use—not fitness for every possible capability provided by the software.

This approach prevents unnecessary complexity, reduces validation effort and produces User Requirements Specifications that remain relevant throughout the operational life of the system.

They Challenge Every Requirement

Experienced professionals recognise that every additional requirement increases configuration effort, validation effort, testing effort and long-term maintenance.

Accordingly, they challenge each proposed requirement by asking:

• Why is this capability necessary?
• Does it support a regulated business process?
• Is it required for patient safety?
• Is it required by regulation?
• Can it be objectively verified?
• Will it remain relevant throughout the system lifecycle?

Requirements that cannot be justified are often removed before implementation begins.

They Think About Validation While Writing Requirements

Experienced validation professionals understand that today's requirement becomes tomorrow's test script.

Consequently, while writing each requirement they mentally ask:

• How will this be tested?
• What objective evidence will demonstrate compliance?
• Can the requirement be traced throughout the validation lifecycle?
• Will an inspector understand this requirement several years from now?

Thinking about validation during requirement development significantly improves the quality of the final validation package.

They Consider the Entire Lifecycle

Experienced CSV Leads do not write User Requirements Specifications solely for implementation projects.

Instead, they consider how the document will support:

• software upgrades;
• supplier changes;
• periodic reviews;
• change control;
• revalidation;
• inspections;
• system retirement.

A high-quality User Requirements Specification continues to provide value long after the initial implementation has been completed.

They Think Like Inspectors

Experienced professionals regularly review their User Requirements Specifications from an inspection perspective.

Typical questions include:

• Does this document clearly describe the intended use of the system?
• Could an independent reviewer understand why each requirement exists?
• Are regulatory expectations adequately represented?
• Can every critical requirement be traced through validation?
• Would the available documentation justify confidence in the implemented system?

This perspective promotes validation programmes that remain inspection ready throughout the lifecycle of the system.

They Focus on Clarity Rather Than Volume

Experienced validation professionals understand that the quality of a User Requirements Specification is not determined by the number of pages it contains.

A concise, well-structured document describing genuine business requirements provides significantly greater value than a lengthy document containing duplicated, ambiguous or unnecessary requirements.

Their objective is therefore not to produce the largest User Requirements Specification, but the clearest one.

Professional Reflection

Experienced CSV professionals recognise that successful validation begins long before testing starts. It begins with a clear understanding of the regulated business process and a carefully written User Requirements Specification that accurately describes what the organisation needs the computerised system to achieve.

Key Takeaways

The User Requirements Specification is the foundation of every Computerised System Validation programme. It defines the intended use of the computerised system and provides the benchmark against which system suitability, validation completeness and operational acceptance are evaluated.

A well-written URS describes business needs rather than technical implementation, supports quality risk management, facilitates validation testing and provides traceability throughout the system lifecycle.

Ultimately, the quality of the User Requirements Specification strongly influences the quality of the entire validation programme. Clear, complete and verifiable requirements reduce implementation risk, simplify lifecycle management and provide confidence that computerised systems continue to support safe, reliable and compliant pharmacovigilance activities.