A URS says what your study needs the data system to do, in testable sentences. It drives vendor selection, supplier assessment and user acceptance testing. This guide gives you the structure, sample requirements with IDs and priorities, and a way to keep it short enough to finish.
Free sandbox · No credit card · 21 CFR Part 11 aligned
Purpose, scope and study context
Users and roles
Data capture and form requirements
Data quality, queries and review
Audit trail, signatures and access control
Exports, archiving and integration
Supplier, validation and support
Traceability matrix to UAT scripts
Filled in at UAT
What a good EDC URS does
The document
A user requirements specification is the sponsor's statement of what the computerised system must do for this study. In the validation model that GAMP 5 popularised, it is the first document in the chain: requirements lead to specifications, specifications to configuration, and configuration to testing that proves each requirement is met. The vendor writes the functional and design specifications for the product. You write the URS, because only you know your protocol, your people and your risks.
That ownership matters for regulators too. 21 CFR 11.10(a) asks for validation of systems to ensure accuracy, reliability and consistent intended performance, and the EMA guideline on computerised systems expects the sponsor to stay responsible for validation even when the supplier does most of the work. A clear URS is the cheapest way to show you decided what "intended performance" meant before you bought anything. Our computer system validation guide and the GAMP 5 EDC validation page cover the rest of the chain, and the EDC validation checklist covers what to confirm after you choose.
A second, quieter benefit is speed. Teams without a URS tend to run vendor demos by whatever the salesperson shows, then discover at UAT that a required behaviour was never discussed. A two-page URS written before the first demo turns every demo into the same exam.
Sample requirements
These are written the way a URS line should read: one need, one verb, testable. Priority uses M (must), S (should) and C (could). Delete what your study does not need and add what it does.
| ID | Requirement | Pri | How you verify it |
|---|---|---|---|
| URS-ROL-01 | Users must sign in with individual accounts; shared accounts are not permitted. | M | UAT: attempt shared login; review user list. |
| URS-ROL-02 | Access must be limited by role, and a blinded user must never receive treatment-arm values. | M | UAT: log in as each role; try export and AE form. |
| URS-ROL-03 | Site staff must see only their own site's participants. | M | UAT: two sites, one coordinator each. |
| URS-CRF-01 | The study team must build and change forms without programmer help, and approved forms must be locked for live use. | M | UAT: build, approve, try to edit. |
| URS-CRF-02 | The system must support skip logic, required fields, ranges and calculated fields shown read-only during entry. | M | UAT: each rule type with a pass and a fail value. |
| URS-CRF-03 | Repeating data such as concomitant medications and labs must be capturable as repeating rows. | S | UAT: enter three rows, edit the second. |
| URS-DQ-01 | Out-of-range entries must raise a query automatically and show it to the right person. | M | UAT: enter an out-of-range value. |
| URS-DQ-02 | Monitors must be able to mark source data verification per field and see what remains. | S | UAT: SDV five fields, filter open. |
| URS-AT-01 | Every change to clinical data must record who, when, old value, new value and reason, and the record must not be editable by users. | M | UAT: change a value, read the trail, try to edit it. |
| URS-AT-02 | The audit trail must be exportable in a readable form for inspectors. | M | UAT: export and open in a spreadsheet. |
| URS-SIG-01 | Electronic signatures must be unique to one person, show the meaning of the signature and be linked to the record signed. | M | UAT: sign, view signature manifest. |
| URS-EXP-01 | Data must be exportable as CSV or Excel with a data dictionary, filtered by site and date. | M | UAT: export and compare to entered values. |
| URS-EXP-02 | Statistical hand-over datasets should be producible in the standard your statistician uses. | S | UAT: statistician opens the file. |
| URS-SEC-01 | Data must be encrypted in transit and at rest, and hosted in the region the protocol and consent state. | M | Supplier documents plus audit. |
| URS-SUP-01 | The supplier must provide documentation to support our validation and notify us of changes that affect the study. | M | Document request before contract. |
Sample wording only. Adjust to your protocol, risk assessment and SOPs. This is not legal or regulatory advice.
Take ten of your must-have lines into the free sandbox and test them with practice data: build a form, trip an edit check, change a value, read the audit trail, run an export. It is the quickest way to learn which of your requirements are real.
Writing it
Most weak URS documents fail in one of three ways. They list features copied from a vendor brochure, they bury the five requirements that matter among fifty that do not, or they use words nobody can test, such as "user friendly", "flexible" or "robust". The fix is a short routine you apply to every line.
Read the protocol schedule and ask what the system must do for each visit, form and role. Then list what would hurt participants or the endpoint if data were wrong, missing or seen by the wrong person. Those risks decide which lines are "must" and how deeply you test. A trial with a primary endpoint calculated from three measurements needs calculated-field and range requirements. A blinded trial needs masking requirements, see blinded and unblinded roles in EDC. A decentralised trial needs participant-facing requirements that a clinic-only study does not.
Use "must" for mandatory, "should" for desirable. Avoid "and" joining two needs, because half-met requirements are hard to score. Give each line an ID that never changes, even if the line is deleted, so the traceability matrix stays stable across versions.
If FDA-regulated data will go into a submission, cover the controls in 21 CFR Part 11 (validation, audit trail, signatures, access) and read our Part 11 compliance checklist. If you recruit in the EU, add lines drawn from the EMA guideline, see the EMA computerised systems guideline guide. If you are unsure how the two differ, Annex 11 versus Part 11 explains it. Keep these lines tied to a regulation reference in a comment column so a reviewer can see why they exist.
Requirements about the vendor (change notification, support response, documentation, hosting) are as important as screen behaviour, and they are verified by documents and audit, not by clicking. Pair this URS with the EDC vendor audit checklist and the vendor security questionnaire so each supplier line has an evidence source.
The process
A small team can do this in a few working days.
One author, one reviewer from QA or data management, and the sponsor or PI as approver. Record version and date from the first draft.
Phase, design, number of sites, countries, participant-facing parts (ePRO, eConsent), blinding, and which data are critical to the endpoint.
Investigator, coordinator, monitor, data manager, statistician, blinded and unblinded staff, participant. This produces most of your access requirements.
Data capture, quality, audit trail and signatures, access, exports, security, supplier. Add a priority and a verification method to each line.
Use the must-haves as pass or fail and the rest as weighted. The EDC buyer scorecard template and EDC procurement checklist give a place to record the result.
Turn each requirement into a test step, record pass or fail and keep the matrix with your validation file. See EDC UAT in a sandbox.
What this looks like in Capture
Capture is a self-serve platform, so you can check requirements yourself instead of waiting for a sales demo. Every feature is available in the free sandbox, with no credit card and no time limit.
Requirements
48
Must-haves
31
Tested
27
Before you approve
Run these checks before the document is signed.
Write the UAT step in the margin. If you cannot, rewrite.
State the need so any supplier can answer it.
At least a third of lines are not "must", otherwise nothing is prioritised.
Part 11, Annex 11, EMA guideline or GCP references noted for the lines that come from them.
Primary endpoint and safety data have stricter lines than convenience fields.
Blinded, unblinded, monitor, participant and read-only roles are covered.
Notification of releases, support, hosting region, exit and export.
Version, date, author, reviewer, approver. Keep the old versions.
Protocol amendments change requirements; say who updates the URS and re-tests.
After go-live
A URS is not shelf-ware. When the protocol is amended, a new form is added or a new role is created, ask whether a requirement changed and whether a test must be repeated. Systems where the study team can amend the build themselves make this cheaper, because there is no change order to wait for, see protocol amendments without change orders. Before launch, use the EDC go-live checklist to confirm every must-have is proven.
This page is general guidance, not a regulatory requirement for a document with this exact name. Your sponsor or institution may use a different template or title. Follow your own SOPs where they differ.
A URS is the sponsor's written statement of what a computerised system must do for a specific study, expressed as testable requirements. It is the starting point for vendor selection, supplier assessment and user acceptance testing.
The sponsor or the study team writes it, because it depends on the protocol, the roles and the risks. The vendor supplies its own specifications and test documentation, which you assess against your URS.
Proportionate to risk. A single-study academic or early-phase team can often cover the essentials in 40 to 80 testable lines. Larger or higher-risk programs need more detail in the areas that touch critical data and participant safety.
No regulation names a document called a URS. The expectation is that systems are validated for intended use and that the sponsor stays responsible, which a URS is a common and efficient way to demonstrate. Follow your sponsor's SOPs.
Mark must-haves as pass or fail, score the rest, and test the must-haves hands-on. A free sandbox lets you check requirements yourself rather than relying on a demo script.
Each requirement maps to one or more UAT steps in a traceability matrix. Passed and failed steps are recorded and kept with the validation file.
Capture provides 21 CFR Part 11-aligned controls, and enterprise customers receive documentation to support sponsor validation and UAT. Validated use remains a shared responsibility with the sponsor, so ask for the document list in writing.
Keep exploring
Computer system validation for EDC
The validation chain this URS starts.
GAMP 5 EDC validation
Sponsor versus vendor roles.
EDC validation checklist
What to confirm after you choose.
EDC UAT sandbox environment
Run your URS as test scripts.
EDC buyer scorecard template
Score vendors against must-haves.
Clinical trial EDC RFP template
Send the URS with your RFP.
21 CFR Part 11 compliance checklist
Source of the control lines.
FDA electronic systems guidance guide
The FDA Q&A your URS should reflect.
Free sandbox with every feature. No credit card, and you pay only when you go live with real participants.