Requirements state, clearly and exactly, the functions the regulated company expects of the system and the functions and facilities to be provided, driven by business process needs, developed top-down from product and process understanding, critical quality attributes and regulatory requirements, with the approach defined at planning and the extent and detail commensurate with risk, complexity and novelty, from requirements in purchasing documentation for a low-risk commercial system to layered requirements and functional specifications for a complex custom one; requirements may be based on an available solution but are reviewed and tailored to intended use, may be developed incrementally with backlog items as the requirements specification under Agile, and may be held in tools. Requirements address applicable GxP regulations by highlighting the quality-critical aspects rather than stating unverifiable generalities, are specific, measurable, achievable, realistic and testable or meet INVEST, unambiguous, clear, precise and self-contained, consider design constraints, define interfaces, support traceability, provide a basis for testing and supplier selection, are prioritized as mandatory, beneficial or nice to have, use consistent naming with unique identifiers, version control and change history, link to business process steps and give the supplier a definitive statement. The process owner owns the business requirements. Typical contents are an introduction with contractual status, related documents, assumptions and a referenced data flow diagram with the primary record defined; an overview with background, impact, scope and applicable regulations; operational requirements covering functions including calculations with scientific sources, configurability limits, quantitative performance, safety, security, audit trails, electronic signatures, outputs and error handling, data including record definitions, primary record, critical data ranges, required fields, relationships, validation checks, migration, editing, backup, capacity, retention, archiving, readability and security, technical requirements, interfaces with users, equipment and other systems and their data, timing, protocols, error handling and security, nonfunctional attributes such as availability with recovery objectives, support and maintainability, and environment; constraints; life cycle requirements for the supplier including development standards, testing, deliverables, information available on request for inspection, training and support; a glossary; and acceptance and change with approvers including the process owner, system owner and quality unit and reapproval through change management. Design, implementation, deadlines, cost and organization are out of scope. Requirements capture is managed by an experienced individual or product owner, uses planned interviews with open questions, observation of the current process without duplicating it, workflow analysis and use cases, and focused workshops, and avoids ambiguity, unused functionality, scope creep outside change control and multiple requirements in one statement.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.