User requirements specification
| Document id | CS-VAL-02 |
| Title | User requirements specification |
| Version | 1.0 |
| Applies to | Countersign 1.0.0 |
| Status | Template supplied with the software; to be completed, reviewed and approved by the regulated user |
Approval of the completed document:
| Role | Name | Signature | Date |
|---|---|---|---|
| Prepared by | |||
| Reviewed by | |||
| Approved by (quality assurance) |
1. Purpose and use
This document states what the organisation needs from the system, independent of how the software provides it. The 15 requirements below are the generic user requirements Countersign was built against; their identifiers and wording are those of requirements.json and must stay unchanged so that the generated traceability matrix keeps matching. Tailor by marking each one as applicable or not, by adding the specifics of your use in the tailoring column, and by adding your own requirements in section 4.
Each requirement is met by functional requirements described in the functional specification; the matrix shows which, and which test verifies each.
2. Process overview (complete)
| Item | Entry |
|---|---|
| Process the system supports | |
| Record types (business names) | |
| Hierarchy (what sits under what; groupings) | |
| Options (settings) that are inherited, if used | |
| Who writes, who approves, per record type | |
| Regulatory requirements on these records |
3. Generic user requirements
Priority: M = mandatory for the intended use, D = desirable, N = not applicable (give the reason).
3.1 Records and configuration
| Id | Requirement | Rationale | How to tailor | Met by | Priority (M/D/N) | Your specifics |
|---|---|---|---|---|---|---|
| UR-01 | The system holds records of the types our business needs, with the fields we define, without programming. | The business, not a programmer, decides what a record contains; a configured product is easier to validate than custom code | List your record types and fields; state field rules you rely on (required, unique, ranges, patterns, references). Check that the eight field types (text, long text, number, integer, yes/no, date, selection, reference) are enough; there are no attachments, calculated fields or free-form tables | FR-CFG-01, FR-CFG-05, FR-VAL-01 to FR-VAL-07 | ||
| UR-08 | Settings can be defined once and set at any level of the hierarchy; for every record it is clear which value applies and where it comes from. | Settings repeated per record drift apart; one definition with overrides at defined levels keeps them consistent and explainable | State whether you use options at all. If so, list the levels and the order in which a group and a parent are consulted (field order in the configuration decides) | FR-OPT-01 to FR-OPT-07 | ||
| UR-12 | Changes to the system's own configuration are controlled, attributable and part of the record of actions. | The configuration decides who may do what; changing it is a change to the validated system | Name who may apply a configuration change and who reviews. Note that the change is made with the command-line tool and that the reviewer is named, not signed in (see risk assessment, R-21) | FR-CFG-02, FR-CFG-03, FR-CFG-04, FR-CFG-06 |
3.2 Workflow, versions and lifecycle
| Id | Requirement | Rationale | How to tailor | Met by | Priority (M/D/N) | Your specifics |
|---|---|---|---|---|---|---|
| UR-02 | No change to a record takes effect until a second, authorised person has approved it. | Independent review before a change takes effect is the core control against error and unilateral change | State which roles approve which record types. The rule is fixed: the approver must differ from the author and the confirmer of that version and must hold the approve permission. If you need more than two people, or approval by a specific function for specific changes, that is not built in: add a requirement and a procedural control | FR-WF-01 to FR-WF-09 | ||
| UR-03 | Every version of every record is kept, and the approved version stays in effect until its successor is approved. | The history must show what was valid at any time, and a pending change must not disturb what is in effect | State how long versions must be kept (the software never deletes them; retention of the database is yours) | FR-VER-01, FR-VER-02, FR-VER-03 | ||
| UR-09 | Records can be taken out of use without losing their history. | Obsolete records must stop being used but stay available for review | Decide when you retire (kept visible, out of effect) and when you remove (hidden from lists, kept in the audit trail). Nothing is physically deleted | FR-LIFE-01 to FR-LIFE-04 |
3.3 Audit trail and integrity
| Id | Requirement | Rationale | How to tailor | Met by | Priority (M/D/N) | Your specifics |
|---|---|---|---|---|---|---|
| UR-04 | Every action is recorded with who did it, when, what changed from what to what, and why; the record of actions cannot be changed or deleted. | Attributable, contemporaneous, complete records of change are required by data integrity expectations | State who reviews the audit trail and how often. Note that the reason is mandatory for step back, retire, remove, configuration change and changing an approved record, but optional when creating a record or editing a draft; require it by procedure if you need it there | FR-AUD-01 to FR-AUD-04, FR-STO-04 | ||
| UR-05 | Any alteration of the record of actions, by anyone including administrators, can be detected. | Database administrators can bypass application controls; alteration must at least be evident | State where the head hash is anchored outside the administrators' reach and how often (see data integrity, section 7). Without anchoring, removal of the newest entries is not evident after a restart | FR-INT-01 to FR-INT-06 | ||
| UR-14 | The system can be monitored and verified by its operators, and stops accepting changes if its record of actions is damaged. | A damaged audit trail must stop further changes and be noticed quickly | Name the monitoring that polls /api/health, the alert recipients and the schedule for countersign verify |
FR-OPS-01 to FR-OPS-07 |
3.4 Access and signatures
| Id | Requirement | Rationale | How to tailor | Met by | Priority (M/D/N) | Your specifics |
|---|---|---|---|---|---|---|
| UR-06 | People can only do what their role allows, per record type and per level. | Authority checks limit who can write and approve | Write the role and permission matrix. Note that this requirement covers writing and approving only: every signed-in person can read every record and the whole audit trail. If read access must be restricted, restrict who can sign in, or do not use this system for that data | FR-ACC-01, FR-ACC-02, FR-ACC-03 | ||
| UR-07 | People are identified by our identity provider; an approval is an electronic signature that requires the person to have authenticated recently. | Identity belongs in one place under the organisation's account controls; a signature must be attributable to a person who was demonstrably present | Name the identity provider, the sign-in method and the maximum sign-in age for a signature. Decide whether a recent sign-in at the identity provider meets your interpretation of an electronic signature's execution (see Part 11 and Annex 11 mapping, 11.200) | FR-SIG-01 to FR-SIG-10 |
3.5 Storage, migration, export, interface
| Id | Requirement | Rationale | How to tailor | Met by | Priority (M/D/N) | Your specifics |
|---|---|---|---|---|---|---|
| UR-10 | The data is kept in a database we operate, safely shared by several application servers. | The data must be under the organisation's own backup, access and retention controls and tolerate more than one server | Name the database and the number of application servers. Several servers require PostgreSQL | FR-STO-01 to FR-STO-05 | ||
| UR-11 | Records can be brought over from the system we use today, with their origin recorded and the transfer reconciled. | Legacy records must arrive complete, traceable to their source and reconciled | Delete if nothing is migrated. Otherwise name the source system, the mode (imported as approved there, or created and confirmed for approval here) and who signs the reconciliation | FR-MIG-01 to FR-MIG-08 | ||
| UR-13 | The record of actions and the records can be exported in open formats. | Inspection copies and archives must not depend on the application | State the formats you need for inspection and archive (JSON, JSON Lines, CSV are available; there is no PDF or print layout) | FR-EXP-01, FR-UI-06 | ||
| UR-15 | The user interface shows the state of every record truthfully and guides people through the workflow. | People act on what the screen tells them; it must not mislead | State the browsers in use and the language users need (the engine's refusal messages exist in English only) | FR-UI-01 to FR-UI-08 |
4. Requirements of the organisation (add)
Number your own requirements UR-U-01 onwards so they cannot collide with the catalogue. Each needs a verification: a PQ scenario, a procedure, or an existing functional requirement.
| Id | Requirement | Rationale | Priority | Met by (FR, configuration, procedure) | Verified by (protocol and case) |
|---|---|---|---|---|---|
| UR-U-01 | |||||
| UR-U-02 | |||||
| UR-U-03 | |||||
| UR-U-04 | |||||
| UR-U-05 |
Typical additions: availability and recovery time; retention period; number of concurrent users; response times; specific field rules; the reason for change on every edit; specific reports; language; accessibility.
5. Assumptions
| No. | Assumption |
|---|---|
| A-1 | The organisation operates an identity provider that issues unique, non-reused identifiers per person and enforces its password and multi-factor policy |
| A-2 | Role assignments in the identity provider are requested, approved and reviewed under a procedure |
| A-3 | The server path is used: a database operated by the organisation, not the demo path |
| A-4 | Server clocks are synchronised to a reliable time source |
| A-5 | The database is backed up and restores are tested |
| A-6 | Administrators of the server, the database and the identity provider are trained, named and few, and hold no author or approve role in the application |
| A-7 | Users reach the application only over TLS |
| A-8 | The head hash is anchored outside the reach of the database administrators at a defined interval |
| A-9 | Users are trained and accountable for actions under their sign-in |
6. Exclusions and known limits
These are things the software does not do in version 1.0.0. If you need one of them, add a requirement in section 4 and decide how it is met outside the software.
| No. | Not provided | Consequence |
|---|---|---|
| X-1 | Read restrictions per record, record type or role | Every signed-in person can read everything, including the whole audit trail |
| X-2 | A password or other credential entered in the application at the moment of signing | A signature relies on a recent sign-in at the identity provider |
| X-3 | Retention, archiving and disposal functions | Export and database backup are the means; periods and media are yours |
| X-4 | Logging of read access, of refused commands and of failed sign-ins | Refused commands write nothing to the audit trail; use web-server and identity-provider logs |
| X-5 | Time from a trusted time-stamping authority | Entry times come from the application server's clock |
| X-6 | Attachments, calculated fields, free-form tables, record-to-record workflows beyond the three stages | Model within the eight field types or use another system |
| X-7 | More than one approver, or approval routing by content | One approval by any person holding the approve permission who is not the author or confirmer |
| X-8 | Notifications (e-mail or otherwise) of pending approvals | People see pending items in the application |
| X-9 | Automatic sign-out after inactivity; revocation of a running session | A session ends at sign-out or after COUNTERSIGN_SESSION_HOURS (default 8); role changes apply at the next sign-in |
| X-10 | Printed reports and PDF output | CSV and JSON exports; browser printing is not a designed function |
| X-11 | Refusal messages in languages other than English | Train accordingly |
| X-12 | A built-in tool to repair a damaged audit trail | Recovery is restore from backup and investigation |