Functional Specifications: Their Importance and Modern Approaches

Introduction

In the development and implementation of IT applications (software systems), the creation of functional specifications is essential. However, for structural equipment (manufacturing equipment), opportunities to create functional specifications are limited. The reason for this is clear. While IT applications possess numerous functions, structural equipment fundamentally maintains a “1 process : 1 function : 1 system” relationship.

For example, the “tableting process” has only the “tableting function” and is executed by the “tablet press.” Similarly, the “granulation process” has only the “granulation function” and is executed by the “granulator.” Sterilization processes, filling processes, and others generally follow the same one-to-one relationship. Since 1 system = 1 function in this way, the creation of detailed functional specifications is typically not required.

Regulatory Framework in Japan

The “Guideline on Management of Computerized Systems for Manufacturers of Drug Products and Quasi-Drug Products” (Notification No. 1021-11 of the Pharmaceutical Safety and Environmental Health Bureau) issued by the Ministry of Health, Labour and Welfare (MHLW) on October 21, 2010, came into effect on April 1, 2012. Unlike User Requirements Specifications (URS) and Design Specifications (DS), this guideline does not explicitly specify detailed content requirements for Functional Specifications (FS).

During the public comment period for this guideline, the author advocated that content requirements for functional specifications should also be clarified. However, the response from the MHLW’s Pharmaceutical Safety and Environmental Health Bureau indicated that the current state was satisfactory. It is possible that since the members who created this guideline were primarily experts in structural equipment, there was insufficient awareness of the importance of functional specifications in complex software systems.

Position of Functional Specifications in the Guideline

The guideline presents requirements for functional specifications as follows:

4. Development Activities 4.4 Preparation of Documents Related to Functional Specifications

“The development manager shall have the supplier prepare and approve documents related to functional specifications (hereinafter referred to as ‘functional specifications’) that describe the specific functions and performance of the computerized system corresponding to the requirements described in the requirements specification.”

In other words, while the supplier creates the functional specification, the user company (pharmaceutical company, medical device company) is responsible for its review and approval. Therefore, the cover of a functional specification requires signatures from at least five people:

• Supplier side: Author, Reviewer, Approver
• User company side: Reviewer, Approver

Essential Role of Functional Specifications

Functional specifications detail and define the requirements described in the URS to a sufficient level as requirements for computerized system design that can be implemented. Functional specifications must be created based on the approved URS.

Typically, functional specifications are created through close consultation between the user and supplier during the requirements definition phase. In this process, the user explains the URS, and the supplier examines and proposes implementation methods from a technical perspective. In essence, functional specifications serve as an agreement (document with contractual characteristics) between the user and supplier.

Importantly, among the various specifications, functional specifications are the only document that both users and suppliers can understand. For users, design specifications (DS) and detailed design documents are often too technical and difficult to comprehend. On the other hand, functional specifications describe “what can be done (What)” and thus allow both parties to discuss in a common language without delving into technical details (How). Therefore, functional specifications are extremely important documents.

Role of Functional Specifications in Change Management

Even after system release, it is appropriate to use functional specifications as the basis for considering changes. Additionally, it is desirable to count the number of changes (change history) against the functional specification. This enables clear tracking of the system’s functional change history.

Ensuring Traceability

When creating functional specifications, it is important to develop a traceability matrix between the URS and functional specifications. This ensures that all user requirements are defined without omission in the functional specifications. By linking each URS requirement item to the corresponding functional specification item number, requirement coverage can be verified.

International Trends and Best Practices

GAMP 5 Second Edition (Published July 2022)

Internationally, GAMP (Good Automated Manufacturing Practice) 5, published by ISPE (International Society for Pharmaceutical Engineering), is widely recognized as the de facto international standard for computerized system validation. GAMP 5 Second Edition, published in July 2022, includes the following important updates:

Key Updates:

1. Emphasis on Critical Thinking: Newly established as Appendix M12, emphasizing risk-based appropriate judgment
2. Integration of Computer Software Assurance (CSA) Approach: Supporting the transition from traditional Computer System Validation (CSV) to more efficient and flexible CSA
3. Support for Agile Development Methodologies: Clear support not only for traditional waterfall (V-model) but also for iterative and incremental development methods (Appendix D8)
4. Integration of Requirements Specifications: Integration of previously separate URS (Appendix D1) and FRS (Functional Requirements Specification) to support agile development (consolidated into Appendix D1)
5. Support for Emerging Technologies:
   1. AI/Machine Learning (Appendix D11)
   1. Blockchain/Distributed Ledger Technology (Appendix D10)
   1. Cloud Computing
   1. Open Source Software
6. Infrastructure Management: Newly established as Appendix M11
7. Emphasis on Supplier Assessment: Leveraging vendor documentation and test results to reduce redundant work

FDA Computer Software Assurance (Final Version September 2025)

The U.S. Food and Drug Administration (FDA) issued the draft guidance “Computer Software Assurance for Production and Quality System Software” in September 2022 and published the final version on September 24, 2025. This guidance replaces Section 6 of the “General Principles of Software Validation” issued in 2002.

Four Steps of CSA:

1. Identification of Intended Use: Clarify which part of manufacturing or quality system each software function is used for
2. Determination of Risk-Based Approach: Assess the impact if software does not operate as intended
   1. High Process Risk: Direct impact on product quality or patient safety
   1. Not High Process Risk: Affects quality system but limited direct impact
3. Determination of Appropriate Assurance Activities:
   1. High Process Risk: Scripted testing (testing based on detailed procedures)
   1. Not High Process Risk: Unscripted testing (scenario testing, exploratory testing, etc.)
4. Establishment of Appropriate Records: Documentation including objective evidence (while avoiding excessive documentation)

Key Features:

• Least Burdensome Approach: Focus on necessary and sufficient verification activities
• Leveraging Vendor Information: Utilize ISO 13485 certification, vendor test documentation, quality management system assessments
• Use of Electronic Records: Leverage digital records such as system logs and audit trails, reducing duplication of paper documents and screenshots
• Support for Cloud Services: Clarification of IaaS, PaaS, SaaS
• Application to AI/ML Tools: CSA application when used in manufacturing and quality systems

Modern Practice of Functional Specifications

Considering the above international trends, the position and content of functional specifications are also evolving:

Functional Specifications in Agile Development

Instead of creating large traditional functional specification documents, the following approaches are recommended:

• Iterative Specification Creation: Create and approve functional specifications incrementally in sprint units
• Tool-Based Management: Maintain functional specifications within requirements management tools (e.g., Jira, Azure DevOps), minimizing paper documentation
• User Stories/Acceptance Criteria: Use user stories and acceptance criteria instead of traditional detailed functional descriptions
• Living Documentation: Continuously updated specifications rather than static documents

However, the following are mandatory as regulatory requirements:

• Prioritization of requirements (based on impact on patient safety, product quality, data integrity)
• Evidence of approval and review (including electronic signatures)
• Maintenance of traceability

Application of Critical Thinking

When creating functional specifications, critical thinking should be applied in the following areas:

1. Is this function truly necessary?: Identify functions that truly impact patient safety, product quality, and data integrity
2. What is the appropriate level of detail?: Excessively detailed specifications reduce maintainability
3. Is the verification method appropriate?: Determine the verification level commensurate with the risk
4. Response to changes: Balance between flexibility and control

Minimum Content of Functional Specifications

Even in modern approaches, functional specifications should include the following information:

Item	Description	Purpose
System Overview	System purpose, scope of application, overview of key functions	Understanding the big picture
Intended Use	Specific purpose of use in GxP operations	Basis for risk assessment
Functional Requirements	Detailed operation, input/output, business flow of each function	Standard for implementation
Non-Functional Requirements	Performance, security, availability, compatibility	Ensuring system quality
Interface Specifications	Integration with other systems, data exchange formats	Ensuring integration
User Roles and Permissions	Access control, electronic signature requirements	Security and compliance
Data Integrity Requirements	How ALCOA+ principles are applied	Ensuring data reliability
Audit Trail	Information to be recorded, retention period	Responding to regulatory requirements
Backup and Recovery	Data protection strategy	Business continuity
Traceability Matrix	Correspondence with URS	Proof of requirement coverage

Necessity of Functional Specifications for Structural Equipment

As stated in the original argument, detailed functional specifications are typically unnecessary for structural equipment (manufacturing equipment) due to their single-function nature. However, functional specifications or similar documents may be necessary in the following cases:

1. Equipment with Complex Control Systems: For example, equipment with multi-stage process control and automatic adjustment functions
2. Equipment with Data Recording and Management Functions: Equipment that generates electronic records (when 21 CFR Part 11 compliance is required)
3. Integration with Other Systems: When integrating with MES, LIMS, ERP, etc.
4. Highly Automated Equipment: Industry 4.0, IoT-compatible equipment

In these cases, functional specifications are needed not for the mechanical function of the equipment itself, but for the control software and data management systems.

Latest Industry Trends

Relationship with Data Integrity

In recent years, regulatory authorities have emphasized data integrity. Functional specifications should clearly describe how ALCOA+ principles (Attributable, Legible, Contemporaneous, Original, Accurate + Complete, Consistent, Enduring, Available) are implemented.

Cloud-Based Systems

SaaS (Software as a Service) systems are increasing. In this case:

• Understanding the Shared Responsibility Model is important
• Document user-specific configurations and customizations as functional specifications based on supplier-provided functional specifications (product documentation)
• Ensure consistency with Service Level Agreements (SLA)

AI/Machine Learning Systems

For systems including AI/ML, a different approach from traditional deterministic systems is required:

• Management of model training data and validation data
• Model version control
• Continuous monitoring requirements
• Ensuring explainability
• Bias assessment

These special requirements should also be included in functional specifications.

Conclusion and Future Prospects

Functional specifications are important documents that form a common understanding between users and suppliers and ensure that systems operate as required. While the 2010 Japanese guideline does not specify detailed requirements, in practice they should be created with appropriate content and level of detail, referring to international standards (GAMP 5 Second Edition) and the latest regulatory trends (FDA CSA).

Modern approaches include:

1. Risk-Based: Not requiring the same level of detail for all functions
2. Critical Thinking: Focusing on truly necessary content
3. Agile-Compatible: Flexible document management supporting iterative development
4. Lean Documentation: Necessary and sufficient documentation, elimination of redundancy
5. Digital-First: Maximum utilization of electronic records

While applying these principles, basic quality assurance requirements such as traceability, approval processes, and change management must be maintained.

The creation and management of functional specifications is not merely regulatory compliance but an important activity directly connected to project success, system quality, and ultimately patient safety and product quality assurance. The practice of functional specifications will continue to evolve in response to technological innovation and changes in regulatory requirements.

References and Regulatory Documents:

1. Ministry of Health, Labour and Welfare “Guideline on Management of Computerized Systems for Manufacturers of Drug Products and Quasi-Drug Products” (October 21, 2010, Notification No. 1021-11)
2. ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition), July 2022
3. FDA “Computer Software Assurance for Production and Quality System Software” Final Guidance, September 24, 2025
4. FDA “General Principles of Software Validation” (2002)
5. 21 CFR Part 11 – Electronic Records; Electronic Signatures
6. ICH Q9 Quality Risk Management
7. PIC/S Annex 11 – Computerised Systems
8. ISPE GAMP® Good Practice Guide: Data Integrity