Functional, Design, and Configuration Specifications for Computerized Systems

Computerized system specifications translate approved user requirements into the functions, design, configuration, interfaces, calculations, reports, and technical components that will be built and verified.

The User Requirements Specification for Computerized Systems defines what the regulated business needs. Specifications explain how the selected solution will satisfy those needs.

Specifications should provide enough detail to:

• guide configuration or development;
• support design review;
• identify critical controls;
• define expected system behavior;
• support risk assessment;
• establish testable acceptance criteria;
• control changes; and
• document the released system.

The required specification set should reflect the system’s intended use, risk, software category, complexity, configuration, custom code, supplier documentation, interfaces, and migration scope.

Types of Computerized System Specifications

A system may require several related specifications.

These specifications may be separate documents or controlled sections of a combined specification. The format is less important than complete, understandable, approved, and traceable content.

A simple nonconfigured product may need limited site specifications. A highly configured or custom system may require detailed functional, design, interface, data, and code specifications.

The relationship between software type and required lifecycle evidence is explained in GAMP 5 Software Categories and Validation Strategy.

Functional Specifications

A functional specification defines how the system must behave to satisfy approved requirements.

It should describe:

• system functions;
• workflows;
• business rules;
• calculations;
• status transitions;
• required inputs;
• outputs;
• warnings;
• error handling;
• permissions;
• and expected responses.

A functional specification should be detailed enough to support configuration, risk assessment, and testing without unnecessarily prescribing the technical architecture.

For example, a URS may state:

The system shall prevent approval of a deviation until all required investigation activities are complete.

The functional specification may state:

When a user selects “Submit for Approval,” the system shall verify that root cause, impact assessment, corrective-action decision, and investigation conclusion are complete. If any required field is incomplete, the status shall remain “Investigation in Progress,” and the system shall identify each missing item.

The specification defines observable behavior that can be challenged during testing.

Workflows and Status Transitions

Workflow specifications should identify:

• workflow stages;
• permitted transitions;
• responsible roles;
• required data;
• approval conditions;
• rejection;
• return for correction;
• cancellation;
• reopening;
• escalation;
• and exceptional paths.

A status-transition table is often clearer than narrative text.

Workflow specifications should include conditions that prevent inappropriate transitions.

Testing should cover routine and exceptional paths. The test strategy is addressed further in Computerized System Risk Assessment and Test Strategy.

Business Rules

Business rules define the conditions governing system behavior. Examples include:

• mandatory fields;
• approval sequences;
• due-date calculations;
• escalation rules;
• specification selection;
• status restrictions;
• record-number generation;
• duplicate checks;
• segregation of duties;
• and permitted corrections.

Each rule should identify:

• trigger;
• condition;
• system action;
• exception;
• and expected result.

For example:

If a corrective action is classified as critical, the system shall require Quality approval before the action can be assigned an implementation status.

Avoid vague statements such as:

Critical corrective actions shall be handled appropriately.

The vague statement does not define the required control.

Design Specifications

A design specification describes the technical solution used to implement the functional requirements. It may address:

• system architecture;
• application components;
• services;
• databases;
• infrastructure;
• data model;
• interfaces;
• identity services;
• security zones;
• reporting services;
• backup services;
• monitoring;
• and custom code.

The design specification should identify the relationships and dependencies among these components.

Depending on system complexity, design documentation may include:

• architecture diagrams;
• component diagrams;
• data-flow diagrams;
• network diagrams;
• database designs;
• interface designs;
• custom-code designs;
• and infrastructure designs.

The design should be consistent with the approved system boundary established through Computerized System Validation Planning and Strategy.

Configuration Specifications

A configuration specification defines the settings and controlled values selected within a configurable product. Configured items may include:

• enabled modules;
• workflows;
• status values;
• roles;
• permissions;
• audit-trail settings;
• electronic-signature settings;
• code tables;
• master data;
• notifications;
• report parameters;
• calculation settings;
• retention settings;
• and interface schedules.

The specification should identify:

• configuration item;
• approved value;
• purpose;
• source requirement;
• owner;
• environment;
• and verification reference.

A configuration table may use the following structure:

Supplier default settings should not be accepted automatically. They should be assessed against intended use, security, data-integrity, and regulatory requirements.

Configuration Versus Customization

Configuration uses supported product settings to establish intended behavior. Customization introduces new or altered code outside standard configuration.

Examples of configuration include:

• enabling a module;
• defining a workflow;
• creating a role;
• selecting an audit-trail option;
• defining a code table;
• or configuring a standard report.

Examples of customization include:

• custom source code;
• custom scripts;
• custom functions;
• unsupported product modifications;
• custom interfaces;
• and complex custom reports.

The distinction matters because customization generally requires greater design detail, code control, review, testing, and maintenance.

The selected approach should also be consistent with the supplier strategy described in Computerized System Supplier Assessment and Evidence Leverage.

Roles and Permissions

Role and permission specifications should define what each role can:

• view;
• create;
• modify;
• delete;
• approve;
• sign;
• configure;
• administer;
• export;
• and report.

The specification should address:

• least privilege;
• segregation of duties;
• administrator independence;
• privileged accounts;
• service accounts;
• emergency access;
• and restricted functions.

A role-permission matrix may be used.

Technical administrator access should not automatically permit routine modification of GMP records.

Detailed identity and privilege controls are covered in User Access, Privileged Accounts, and Electronic Signatures.

Audit-Trail Configuration

The specification should define which events generate audit-trail records and what information must be captured. Relevant events may include:

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

The specification should define:

• event;
• user identity;
• date and time;
• previous value;
• new value;
• reason for change;
• record reference;
• security;
• availability;
• filtering;
• export;
• and retention.

For example:

For changes to approved specification limits, the system shall retain the previous value, new value, user identity, date and time, reason for change, and associated change-control reference.

Audit-trail settings should be included in the controlled configuration baseline. Audit-trail design and review are addressed further in Audit Trails, Data Changes, and Review Controls.

Code Tables and Master Data

Code tables and master data may control:

• product names;
• material codes;
• test methods;
• specifications;
• units;
• sites;
• departments;
• equipment;
• suppliers;
• workflow classifications;
• deviation categories;
• and approval rules.

Specifications should identify:

• authoritative source;
• data owner;
• required fields;
• permitted values;
• units;
• status;
• effective date;
• version;
• approval;
• and change control.

Master data should not be treated as informal setup information when it affects regulated processing or decisions.

The specification should also define whether master data will be:

• entered manually;
• migrated;
• imported;
• synchronized;
• or maintained through an interface.

Data Specifications

A data specification defines how regulated data and metadata are represented. It may identify:

• data objects;
• fields;
• data types;
• lengths;
• formats;
• units;
• precision;
• mandatory fields;
• relationships;
• unique identifiers;
• status;
• ownership;
• and retention.

For example:

Data specifications should preserve the context required to interpret a record.

FDA’s Data Integrity and Compliance With Drug CGMP guidance emphasizes reliable and accurate data throughout the data lifecycle.

Calculation Specifications

Calculation specifications should define:

• formula;
• inputs;
• constants;
• units;
• conversion factors;
• sequence of operations;
• precision;
• rounding;
• missing values;
• invalid values;
• boundary conditions;
• error handling;
• displayed result;
• and downstream use.

For example:

Percentage recovery shall be calculated as the measured quantity divided by the reference quantity multiplied by 100. Intermediate values shall retain full available precision. The displayed result shall be rounded to one decimal place.

Calculations should be traceable to an approved scientific or mathematical basis.

Custom calculations require independent verification and testing of:

• normal values;
• minimum and maximum values;
• values at acceptance limits;
• rounding boundaries;
• zero;
• blank inputs;
• and invalid inputs.

Spreadsheet-based calculations may also require controls described in Spreadsheets and End-User Applications in GMP Operations.

Report Specifications

A report specification should define:

• report purpose;
• authorized users;
• data source;
• selection criteria;
• filters;
• sorting;
• calculations;
• units;
• precision;
• status;
• approval information;
• format;
• export;
• and retention.

A report should identify the data and status represented at the time of generation.

For example:

The monthly open-deviation report shall list record number, site, department, owner, classification, current status, due date, and days overdue for all deviations not in a closed or cancelled status.

For critical reports, the specification should identify:

• authoritative source;
• completeness controls;
• excluded records;
• data refresh timing;
• and reconciliation needs.

A formatted report is not necessarily the complete electronic record. The underlying data, metadata, audit trails, signatures, and processing history may remain in the source system.

Interface Specifications

An interface specification defines how data move between systems. It should address:

• source and destination;
• authoritative data source;
• transfer direction;
• trigger;
• frequency;
• endpoints;
• message or file format;
• field mapping;
• units;
• precision;
• transformation;
• authentication;
• service accounts;
• acknowledgments;
• rejected records;
• duplicates;
• retries;
• reconciliation;
• logging;
• monitoring;
• and recovery.

The interface should define expected behavior for both successful and failed transfers.

For example:

If a laboratory result message fails validation, the interface shall reject the message, record the reason, notify the designated support group, and prevent partial creation of the destination record.

Detailed interface controls are covered in Computerized System Interfaces and Data-Transfer Controls.

Exception Handling

Specifications should define how the system responds to abnormal or incomplete conditions. Exceptions may include:

• missing data;
• invalid data;
• duplicate transactions;
• unavailable services;
• failed interfaces;
• calculation errors;
• unauthorized actions;
• expired certificates;
• storage limitations;
• and interrupted processing.

For each relevant exception, define:

• detection;
• system response;
• user notification;
• technical logging;
• record status;
• retry behavior;
• escalation;
• recovery;
• and reconciliation.

The system should not fail silently or leave records in an ambiguous state.

Exception handling should be included in risk assessment and negative testing.

Infrastructure Specifications

Infrastructure specifications define the environment required to support the application. They may include:

• servers;
• virtual machines;
• operating systems;
• databases;
• networks;
• storage;
• identity services;
• time synchronization;
• middleware;
• backup agents;
• monitoring;
• certificates;
• cloud services;
• capacity;
• and availability.

The specification should define required versions, configurations, dependencies, security controls, and service levels where these affect intended use.

Application specifications should reference qualified shared services rather than duplicate every infrastructure requirement.

The boundary between infrastructure qualification and application validation is explained in IT Infrastructure Qualification for GMP Computerized Systems.

Custom-Code Specifications

Custom code should have sufficient design information to support development, review, testing, maintenance, and recovery. The specification may define:

• component purpose;
• architecture;
• inputs and outputs;
• algorithms;
• data structures;
• dependencies;
• interfaces;
• error handling;
• security;
• logging;
• configuration;
• deployment;
• and rollback.

Source code should be:

• uniquely versioned;
• stored in a controlled repository;
• subject to access control;
• reviewed;
• tested;
• related to approved requirements;
• and included in release management.

Code review should focus on critical logic, calculations, data handling, security, failure handling, and regulated records.

Design Review

Design review should confirm that the proposed solution:

• satisfies approved requirements;
• addresses identified risks;
• maintains the system boundary;
• protects data integrity;
• supports required security;
• handles exceptions;
• provides adequate capacity and availability;
• supports backup and recovery;
• and can be tested and maintained.

Review participants may include:

• process owner;
• system owner;
• Information Technology;
• supplier;
• validation;
• cybersecurity;
• data owner;
• and Quality.

Review depth should reflect risk and complexity.

Open design issues should be documented, assigned, resolved, and approved before the affected component is released.

Specification Approval

Each specification should identify:

• document owner;
• version;
• status;
• applicable system and release;
• linked requirements;
• reviewers;
• approvers;
• and effective date.

Approval should confirm that the specification is:

• complete;
• accurate;
• internally consistent;
• technically feasible;
• traceable;
• testable;
• and suitable for controlled implementation.

Supplier documents may be accepted or referenced when they adequately describe the implemented solution. Site-specific configuration, interfaces, custom components, and operational controls should remain documented.

As-Built Configuration Baseline

The as-built configuration baseline records the exact approved state released for operational use. It should identify, as applicable:

• application and module versions;
• enabled functions;
• workflows;
• status rules;
• roles and permissions;
• audit-trail settings;
• electronic-signature settings;
• reports;
• notifications;
• code tables;
• master data;
• calculations;
• custom code;
• interface versions;
• service accounts;
• certificates;
• database and middleware versions;
• infrastructure references;
• and approved deviations.

The baseline may consist of:

• approved specifications;
• configuration exports;
• controlled screenshots;
• system-generated reports;
• deployment records;
• code-repository tags;
• infrastructure records;
• and release documentation.

The format should allow the organization to determine what was approved and released.

Baseline Control

The baseline should be:

• uniquely identified;
• approved;
• protected;
• backed up;
• retrievable;
• updated after approved changes;
• compared with the operating state where appropriate;
• and retained through system retirement.

The baseline supports:

• production release;
• change-impact assessment;
• incident investigation;
• disaster recovery;
• periodic review;
• environment comparison;
• and system reconstruction.

A specification that describes the intended configuration but does not reflect the released system is not an adequate as-built baseline.

Traceability and Change Control

Specifications should trace back to approved requirements and forward to verification evidence. Traceability should connect:

• user requirement;
• risk control;
• functional behavior;
• design component;
• configuration item;
• test case;
• deviation;
• and release status.

Further guidance is provided in Requirements Traceability and Validation Evidence.

Changes to approved specifications should be assessed before implementation.

The assessment should consider:

• affected requirements;
• affected risks;
• data and record impact;
• configuration;
• interfaces;
• custom code;
• testing;
• regression scope;
• migration;
• procedures;
• training;
• and baseline updates.

Post-release changes should follow Computerized System Change Control, Patching, and Revalidation.

Practical Specification Outcome

A complete specification set should allow an independent reviewer to understand:

• how the system is expected to behave;
• how workflows and business rules are implemented;
• which settings and values are approved;
• how data, calculations, reports, and interfaces operate;
• how roles, permissions, and audit trails are configured;
• how exceptions are handled;
• which technical components support the system;
• what custom code exists;
• how the design was reviewed;
• and what exact system state was released.

Specifications should not exist only to satisfy a document list. They should provide the controlled technical bridge between approved user needs and objective verification of the implemented system.