User Requirements Specification for Computerized Systems

A User Requirements Specification (URS) defines what a computerized system must do to support its intended business and GxP use. Intended use, system boundaries, and GxP relevance should first be established through Computerized System Types, Intended Use, and GxP Classification.

The URS should describe required capabilities, controls, records, performance, and operating conditions from the user and process perspective. It should not attempt to reproduce the supplier’s product description or prematurely define the technical design.

A useful URS provides the basis for:

• system selection;
• supplier evaluation;
• configuration and design;
• risk assessment;
• testing;
• traceability;
• release;
• change control; and
• periodic review.

The URS should be detailed enough to support objective verification but concise enough to remain understandable to process owners, users, technical personnel, validation personnel, and Quality.

Begin with Intended Use

Requirements should be derived from the approved intended use and business process. Before writing individual requirements, define:

• the process supported;
• principal users;
• regulated functions;
• records created or maintained;
• decisions supported;
• system boundaries;
• interfaces;
• operating environment; and
• important exclusions.

For example:

The system will be used by Quality personnel to initiate, investigate, review, approve, and retain deviation records supporting GMP operations. It will control workflow status, required approvals, due dates, electronic signatures, audit trails, and record retention.

This intended-use statement establishes the context for individual requirements.

A requirement should not be included merely because a function is available in a supplier’s product. It should represent a genuine business, regulatory, data-integrity, technical, or operational need.

URS Scope

The URS should address the complete computerized system as used by the organization, not only the application software. Requirements may apply to:

• application functions;
• configured workflows;
• data and metadata;
• calculations;
• reports;
• interfaces;
• user access;
• electronic records;
• electronic signatures;
• infrastructure services;
• performance;
• backup and recovery;
• migration;
• support;
• and lifecycle control.

The level of detail should reflect the system’s intended use, complexity, risk, novelty, supplier model, and configuration.

The scope and required deliverables should align with the approved Computerized System Validation Planning and Strategy.

Business Requirements

Business requirements define the process outcomes the organization needs the system to support.

Examples include:

• manage deviations from initiation through closure;
• maintain approved product specifications;
• manage laboratory samples and results;
• control material status;
• support batch-record review;
• schedule calibration and maintenance;
• generate product-quality reports;
• and retain regulated records.

Business requirements should describe the required capability without attempting to define detailed technical implementation.

Acceptable:

URS-BUS-001: The system shall support initiation, investigation, review, approval, and closure of GMP deviation records.

Unacceptable:

The system shall improve the deviation process.

The unacceptable statement is subjective and does not define the required process capability.

Functional Requirements

Functional requirements define the actions the system must perform. They may address:

• record creation;
• data entry;
• calculations;
• searches;
• status changes;
• approvals;
• notifications;
• scheduling;
• exception handling;
• report generation;
• and record retrieval.

Acceptable:

URS-FUN-004: The system shall prevent a deviation record from entering the approval stage until all mandatory investigation fields are complete.

Unacceptable:

The system shall have complete deviation functionality.

The acceptable requirement identifies the condition and expected system behavior. The unacceptable requirement cannot be verified objectively.

Workflow Requirements

Workflow requirements define how records, tasks, and decisions move through the process.

They should address, as applicable:

• workflow stages;
• permitted status transitions;
• required approvals;
• role-based actions;
• task assignment;
• due dates;
• escalation;
• rejection;
• return for correction;
• reopening;
• cancellation;
• and exceptional paths.

For example:

URS-WFL-007: Only users assigned the Quality Approver role shall be permitted to change an investigation from “Pending Approval” to “Approved.”

Workflow requirements should include relevant exceptional paths. Testing only the routine path may leave rejection, cancellation, reopening, or overdue processing uncontrolled.

Data and Metadata Requirements

Data requirements define what information the system must create, receive, process, maintain, transfer, and retain. They should identify:

• required data elements;
• data types;
• units;
• precision;
• mandatory fields;
• permitted values;
• authoritative data sources;
• relationships;
• status;
• ownership;
• and retention.

Metadata requirements should define the contextual information needed to understand and reconstruct a record.

Relevant metadata may include:

• record identifier;
• user identity;
• creation date and time;
• modification date and time;
• approval status;
• version;
• instrument or equipment identifier;
• method;
• units;
• reason for change;
• and source system.

For example:

URS-DAT-012: Each test result shall retain the result value, unit, specification version, analyst identity, entry date and time, and approval status.

Data requirements should distinguish original data, calculated data, reported data, and transferred copies.

Calculation Requirements

Calculation requirements should define:

• mathematical method;
• required inputs;
• units;
• constants;
• conversion factors;
• precision;
• rounding;
• treatment of missing values;
• error conditions;
• and displayed result.

For example:

URS-CAL-003: The system shall calculate percentage recovery as the measured quantity divided by the reference quantity multiplied by 100. The displayed result shall be rounded to one decimal place without changing the precision used in subsequent calculations.

Avoid requirements such as:

The system shall calculate recovery correctly.

The word “correctly” does not define the required formula, inputs, precision, or rounding. Critical calculations should be traceable to an approved scientific, mathematical, or regulatory basis.

Spreadsheet-based calculations and end-user applications may require additional controls described in Spreadsheets and End-User Applications in GMP Operations.

Security and Access Requirements

Security requirements should define required controls without unnecessarily prescribing a product. They may address:

• unique user accounts;
• authentication;
• role-based access;
• least privilege;
• segregation of duties;
• administrator access;
• service accounts;
• remote access;
• session control;
• failed login handling;
• account suspension;
• and periodic access review.

Acceptable:

URS-SEC-002: The system shall require each user to authenticate with a unique account before accessing GMP records.

Potentially inappropriate design statement:

The system shall use Microsoft Entra ID.

The second statement names a specific technical solution. It may belong in an architecture or design specification unless use of that platform is a mandatory business or corporate constraint.

Where a specific technology is mandatory, the requirement should explain the underlying need or constraint:

URS-SEC-003: The system shall integrate with the organization’s approved enterprise identity service to support centralized user provisioning and account deactivation.

The design specification may then identify Microsoft Entra ID as the selected solution.

Detailed identity, privileged-access, and signature controls are addressed in User Access, Privileged Accounts, and Electronic Signatures.

Audit-Trail Requirements

Audit-trail requirements should identify which activities must be recorded. They may include:

• record creation;
• data modification;
• deletion;
• invalidation;
• status changes;
• approval;
• electronic signatures;
• reprocessing;
• master-data changes;
• configuration changes;
• and privileged activity.

A useful audit-trail requirement should define the required content.

For example:

URS-ADT-005: For changes to approved GMP data, the system shall record the user identity, date and time, affected field, previous value, new value, and reason for change.

Additional requirements may address:

• audit-trail security;
• availability;
• search;
• filtering;
• export;
• retention;
• review;
• and time synchronization.

Avoid broad statements such as:

The system shall have a compliant audit trail.

Compliance cannot be verified without defining the events, content, controls, and review capabilities required. Audit-trail event capture, security, review, and exception handling are covered further in Audit Trails, Data Changes, and Review Controls.

Electronic-Signature Requirements

Electronic-signature requirements should define:

• where signatures are required;
• permitted signers;
• signature meaning;
• authentication;
• signature manifestation;
• signature-to-record linking;
• prevention of unauthorized use;
• and effect on record status.

For example:

URS-ESG-004: When approving a deviation, the system shall require the signer to reauthenticate and shall record the signer’s printed name, date and time, and the meaning “Approved.”

Where electronic records and signatures are used to meet applicable regulatory requirements, the URS should reflect the outcome of the system’s Part 11 assessment.

21 CFR 11.10 identifies controls for closed systems used to create, modify, maintain, or transmit electronic records.

Interface Requirements

Interface requirements should define what must be transferred and how successful transfer will be confirmed.

They should address:

• source system;
• destination system;
• transfer direction;
• authoritative source;
• transferred data;
• mapping;
• units;
• precision;
• frequency or trigger;
• acknowledgments;
• rejected records;
• duplicate handling;
• retries;
• reconciliation;
• security;
• and monitoring.

For example:

URS-INT-006: The interface shall transfer approved laboratory results from LIMS to the enterprise resource planning system and shall prevent unapproved results from being transmitted.

LIMS means Laboratory Information Management System.

The URS should define the required business outcome. Detailed message formats, field mappings, ports, protocols, and middleware configuration normally belong in interface or design specifications.

Interface mapping, acknowledgments, rejected transactions, reconciliation, and end-to-end testing are addressed in Computerized System Interfaces and Data-Transfer Controls.

Reporting Requirements

Reporting requirements should define:

• report purpose;
• users;
• required content;
• selection criteria;
• filters;
• sorting;
• units;
• precision;
• status;
• approval information;
• generation frequency;
• format;
• export;
• and retention.

For example:

URS-RPT-008: Authorized Quality users shall be able to generate a monthly report listing open deviations by site, department, owner, due date, and current status.

Avoid requirements such as:

The system shall provide all necessary reports.

Each required report or report capability should be identifiable and testable.

Performance, Availability, and Capacity Requirements

Performance requirements should contain measurable acceptance criteria.

Acceptable:

URS-PER-002: The system shall display an individual deviation record within five seconds for at least 95 percent of requests under the approved normal operating load.

Unacceptable:

The system shall respond quickly.

Availability requirements should define:

• required operating hours;
• planned downtime;
• service level;
• high-availability needs;
• failure notification;
• and permitted outage duration.

Capacity requirements may address:

• users;
• concurrent users;
• records;
• transactions;
• file sizes;
• data growth;
• interfaces;
• and retention period.

For example:

URS-CAP-003: The production environment shall support 300 named users and at least 75 concurrent users without exceeding the approved response-time criteria.

Performance, availability, and capacity values should be based on an understood business need rather than arbitrary targets.

Backup, Restoration, and Recovery Requirements

Backup requirements should identify what must be protected, including:

• application data;
• metadata;
• audit trails;
• configuration;
• attachments;
• reports;
• and supporting records.

Requirements may define:

• backup frequency;
• retention;
• protected copies;
• encryption;
• backup monitoring;
• restoration;
• recovery-point objective;
• recovery-time objective;
• and disaster-recovery testing.

For example:

URS-BCK-004: The system shall support restoration of application data, metadata, audit trails, attachments, and configuration from an approved backup.

Where business needs justify defined recovery objectives:

URS-REC-002: Following declaration of a recoverable production outage, the system shall be restored within eight hours using data no more than four hours old.

The selected backup product, storage platform, and recovery architecture belong in technical specifications.

Retention and Retrieval Requirements

Retention requirements should define:

• record types;
• retention period;
• readable format;
• metadata retention;
• audit-trail retention;
• attachments;
• record relationships;
• search;
• retrieval time;
• export;
• and controlled disposition.

For example:

URS-RET-003: The system shall retain completed deviation records, associated attachments, electronic signatures, and audit trails for the approved retention period and shall preserve their relationship throughout retention.

The URS should not state a retention period unless it is supported by the applicable regulatory, legal, business, or records-management requirement.

Migration Requirements

Migration requirements define what the organization expects to preserve when records are transferred from a legacy source.

They may address:

• included records;
• excluded records;
• field mapping;
• transformations;
• metadata;
• status;
• audit trails;
• signatures;
• attachments;
• relationships;
• reconciliation;
• exception handling;
• and source-system disposition.

For example:

URS-MIG-006: Migrated deviation records shall retain their original record identifier, status, creation date, approval date, owner, attachments, and relationship to associated corrective actions.

The detailed migration method, scripts, tools, and execution sequence belong in migration specifications and plans.

Regulatory Requirements

Regulatory requirements should identify applicable obligations and translate them into system capabilities.

Relevant sources may include:

• predicate-rule record requirements;
• 21 CFR Part 11;
• drug CGMP requirements;
• company quality standards;
• records-retention requirements;
• and data-integrity controls.

For drug-manufacturing systems, 21 CFR 211.68 addresses computer or related systems, authorized changes, and risk-based verification of inputs and outputs.

Avoid a single requirement such as:

The system shall comply with all applicable regulations.

The URS should define the specific capabilities needed to support compliance, such as access control, audit trails, record protection, accurate copies, retention, and electronic signatures.

Operational Requirements

Operational requirements define what is needed to use and support the system after release. They may address:

• configuration management;
• user administration;
• master-data management;
• monitoring;
• incident handling;
• support;
• maintenance;
• patching;
• training;
• business continuity;
• change control;
• periodic review;
• archival;
• and retirement.

For example:

URS-OPS-004: Authorized administrators shall be able to export the approved configuration settings needed to support configuration review and disaster recovery.

Operational requirements are often omitted when the URS focuses only on business functions. This can leave critical support, recovery, and lifecycle needs undefined.

Requirements Versus Design Solutions

A user requirement defines what is needed. A design specification explains how the selected system will satisfy that need.

Approved requirements are translated into implementation detail through Functional, Design, and Configuration Specifications for Computerized Systems.Premature design statements can:

• restrict supplier competition;
• conceal the actual business need;
• prevent evaluation of alternative solutions;
• and make verification difficult.

A design constraint may be appropriate in the URS when it represents a genuine mandatory condition, such as:

• an approved enterprise platform;
• required corporate identity service;
• required hosting location;
• prohibited technology;
• compatibility with an existing validated system;
• or mandatory security standard.

The reason for the constraint should be documented.

Writing Testable Requirements

A testable requirement should identify:

• the required actor or user;
• the required action;
• the relevant condition;
• the expected result;
• and measurable acceptance criteria where needed.

A useful pattern is:

The system shall [perform an observable action] when [defined condition], producing [measurable result].

Requirements should avoid subjective words such as:

• adequate;
• appropriate;
• easy;
• flexible;
• fast;
• robust;
• seamless;
• user-friendly;
• and compliant.

If such a quality is important, it should be translated into an observable or measurable condition.

Acceptable and Unacceptable Requirements

One requirement should generally express one controlled need. Combining several unrelated functions into one requirement makes approval, risk assessment, testing, and traceability difficult.

Unique Identification

Each requirement should have a stable, unique identifier. A structured identifier may indicate the requirement category:

• URS-BUS-001 — business;
• URS-FUN-001 — functional;
• URS-DAT-001 — data;
• URS-SEC-001 — security;
• URS-ADT-001 — audit trail;
• URS-INT-001 — interface;
• URS-PER-001 — performance;
• and URS-OPS-001 — operational.

The identifier should remain stable throughout the lifecycle. A deleted requirement should not be renumbered and reused for a different purpose.

The requirement record should preserve its status and history.

Requirement Ownership

Each requirement should have an accountable owner. Ownership should reflect the subject:

• process owners own business and workflow needs;
• data owners own critical data and retention needs;
• Quality owns or approves relevant compliance requirements;
• cybersecurity owns or approves security standards;
• Information Technology owns technical service requirements;
• records management owns retention requirements;
• and system owners coordinate the complete URS.

A supplier may help refine wording or confirm feasibility but should not define the organization’s regulated needs without appropriate user and Quality input.

Prioritization

Prioritization distinguishes mandatory requirements from desirable features. A simple model may use:

Priority should not replace risk assessment. A requirement may be operationally desirable but still control a significant risk once implemented.

Prioritization can support:

• supplier selection;
• configuration decisions;
• phased implementation;
• deviation assessment;
• and release decisions.

Mandatory requirements should not be silently deferred because the selected product cannot satisfy them. The organization should define an alternative control, modify the process, customize the system, or reject the solution.

Requirement criticality should also inform the Computerized System Risk Assessment and Test Strategy.

Review and Approval

The URS should be reviewed by representatives who understand:

• the business process;
• GxP requirements;
• data and records;
• system architecture;
• security;
• support;
• and validation.

Approval should confirm that the requirements are:

• necessary;
• clear;
• consistent;
• feasible;
• testable;
• uniquely identified;
• appropriately prioritized;
• and aligned with intended use.

Conflicting requirements should be resolved before design or configuration progresses. Approval of the URS does not freeze all requirements permanently. It establishes the controlled baseline from which changes are assessed.

Requirements Traceability

Each approved requirement should trace forward to the evidence that demonstrates its implementation and verification. Traceability may connect the requirement to:

• risk assessment;
• functional specification;
• configuration specification;
• design specification;
• supplier evidence;
• test case;
• deviation;
• procedure;
• training;
• and release approval.

Backward traceability should confirm that configuration and tests relate to an approved requirement, risk control, or technical need.

Requirements that are removed, deferred, partially implemented, or accepted through an alternative control should remain documented with their disposition and rationale.

Lifecycle connections among requirements, risk controls, specifications, supplier evidence, tests, deviations, and release are addressed in Requirements Traceability and Validation Evidence.

Change Control

Changes to approved requirements should be controlled. The change assessment should consider:

• reason for change;
• affected business process;
• GxP impact;
• affected risk controls;
• design and configuration impact;
• supplier impact;
• data and migration impact;
• testing;
• traceability;
• procedures;
• training;
• and release timing.

Changes may result from:

• clarified business needs;
• revised regulations;
• supplier limitations;
• new interfaces;
• workflow changes;
• security requirements;
• defects;
• or expanded intended use.

Requirements should also be reviewed during significant system changes and periodic review to confirm that they remain current.

Practical URS Outcome

A useful URS allows an independent reviewer to understand:

• what the business needs;
• which users and processes are involved;
• which records and decisions are regulated;
• which functions and controls are required;
• how data must be created, protected, transferred, retained, and recovered;
• what performance and availability are expected;
• which requirements are mandatory;
• who owns each requirement;
• and how each requirement can be verified.

The URS should define the required destination without prescribing every step of the technical route. Design, configuration, supplier documentation, risk assessment, and testing then establish how those user needs are implemented and verified.