Connect981 – Content Dev

RSC Topic: Requirements Management

  • Normative requirements

    Normative requirements are mandatory rules, criteria, or conditions that are specified in a standard, regulation, contract, or controlled procedure and that must be fulfilled to claim conformance or to meet an agreed obligation.

    In regulated and manufacturing environments

    In industrial and regulated manufacturing settings, normative requirements commonly arise from:

    • External standards (for example, aerospace, quality, or cybersecurity standards)
    • Regulatory and statutory requirements
    • Customer contracts and technical specifications
    • Internal policies, standard operating procedures (SOPs), and work instructions that have been formally approved

    Operationally, normative requirements show up as specific, testable statements such as:

    • Required inspection or test steps in MES routes or digital travelers
    • Data fields that must be captured in an electronic DHR, batch record, or as-built record
    • Controls that must exist for traceability, document control, or cybersecurity
    • Documented review, approval, and record-keeping steps in quality workflows (for example, NCR, CAPA, MRB)

    In quality and compliance systems, normative requirements often serve as the basis for audits, gap assessments, and evidence collection. Failing to meet a normative requirement typically triggers nonconformance handling, corrective actions, or contract discussions.

    Normative vs. informative content

    Many standards distinguish between:

    • Normative requirements: Mandatory “shall” or “must” statements that define what is required for conformance.
    • Informative content: Explanatory text, guidance, and examples that help interpretation but are not themselves mandatory.

    For implementation teams, mapping each normative requirement to specific controls, workflows, system behaviors, or records is a common practice to support traceability and audit readiness.

    Common confusion

    • Normative requirements vs. best practices: Best practices are recommended approaches; normative requirements are obligations that must be met if the organization claims to follow a given standard, regulation, or contract.
    • Normative requirements vs. internal preferences: Internal preferences or conventions only become normative requirements when they are formally documented, approved, and placed under change control.

  • Characteristic Ballooning

    Characteristic ballooning is the practice of marking each inspectable requirement on an engineering drawing or model-based definition with a unique identifier, often shown as a numbered balloon or bubble. The identifier links the requirement to inspection records, measurement results, and quality documentation.

    In manufacturing, characteristic ballooning is commonly used for first article inspection, in-process inspection planning, source inspection, and supplier quality review. A balloon may identify a dimension, tolerance, note, material requirement, finish callout, process requirement, or other verifiable characteristic.

    The purpose is to create a clear cross-reference between the design requirement and the evidence that it was checked. For example, a numbered dimension on a drawing may correspond to the same characteristic number in an AS9102 Form 3 or an inspection report.

    Characteristic ballooning should not be confused with measurement itself. Ballooning identifies and organizes the characteristics to be verified; it does not prove conformity unless it is linked to accepted inspection results and supporting records.

  • regulatory requirements

    Regulatory requirements are mandatory rules, obligations, and constraints established by governmental or other recognized regulatory authorities that an organization must follow to operate legally and compliantly. In industrial and manufacturing environments, these requirements typically affect product design, production processes, facility operations, data handling, and documentation.

    What regulatory requirements include

    Regulatory requirements commonly refer to:

    • Applicable laws and regulations, such as those governing product safety, environmental impact, worker protection, data privacy, and export controls.
    • Binding rules from regulatory agencies, such as directives, rules, or guidance that are treated as mandatory within a jurisdiction.
    • Mandatory standards or technical regulations that have been referenced by law or regulation and therefore become compulsory.
    • Required approvals and licenses, including conditions attached to permits, product registrations, or operating licenses.

    In regulated manufacturing sectors (for example, pharmaceutical, medical device, food and beverage, aerospace, or automotive), regulatory requirements often define how products are developed, validated, produced, released, labeled, stored, and traced, as well as how records and electronic systems are controlled.

    Operational meaning in industrial and manufacturing systems

    In day-to-day operations, regulatory requirements are translated into internal processes and controls so that they can be implemented, monitored, and demonstrated during inspections or audits. This typically involves:

    • Requirements capture: Identifying all applicable regulations for a product, site, process, or IT/OT system, and documenting them in requirements specifications or risk assessments.
    • Procedures and work instructions: Converting regulatory rules into standard operating procedures (SOPs), digital work instructions, and system configurations.
    • System configuration: Implementing controls in MES, LIMS, SCADA, ERP, and quality systems so that electronic records, signatures, traceability, and access controls align with regulatory expectations.
    • Evidence and recordkeeping: Maintaining accurate, retrievable records that show regulatory requirements are being met, including batch records, deviation reports, change records, and validation documentation.
    • Change management: Assessing the impact of process, product, or system changes on regulatory requirements and updating documentation, validation, and training accordingly.

    Relationship to other types of requirements

    Within a requirements hierarchy, regulatory requirements are one category among several, which may include:

    • Customer requirements: Contractual or specification-based expectations from customers.
    • Internal requirements: Company policies, engineering standards, and procedural rules not mandated by a regulator.
    • Interface or technical requirements: Constraints driven by equipment, IT/OT integration, or standards for interoperability.

    Regulatory requirements are distinct in that they originate from external authorities and are not optional for compliant operation within a given jurisdiction.

    Common confusion

    • Regulatory requirements vs. standards: Many standards are voluntary, but they can become regulatory requirements if cited by law or regulation. Without that legal linkage, conformance to a standard is usually not a regulatory obligation.
    • Regulatory requirements vs. best practices: Industry best practices may align with regulatory expectations but are not themselves legal requirements unless embedded in regulations or binding guidance.
    • Regulatory requirements vs. quality requirements: Quality management systems often include both regulatory and non-regulatory requirements. Meeting internal quality targets does not guarantee that all regulatory obligations are satisfied.

    Tie-back to ISO 9000 “requirement” concept

    Within the ISO 9000 family, a “requirement” is a need or expectation that is stated, generally implied, or obligatory. Regulatory requirements are the subset of requirements that are obligatory because they arise from laws, regulations, or binding regulatory rules. In practice, organizations identify these requirements, integrate them into their quality and operational systems, and maintain traceability from the external regulation to internal controls, records, and changes.

  • requirements

    Requirements are documented needs, obligations, or expectations that specify what a system, product, process, or organization must achieve or comply with. In industrial and regulated manufacturing environments, requirements are the formal basis for design, production, quality control, and compliance activities.

    What requirements typically include

    In manufacturing and industrial operations, requirements commonly refer to:

    • Technical and product requirements: Specifications, drawings, tolerances, materials, performance criteria, and functional characteristics that a product or component must meet.
    • Process and procedural requirements: Defined steps, methods, parameters, and controls for how work is performed (for example, standard operating procedures, work instructions, process recipes).
    • Regulatory and standards requirements: Applicable laws, regulations, and external standards that must be met (for example, industry standards, safety codes, or quality management requirements).
    • Customer and contract requirements: Commitments agreed in contracts, purchase orders, statements of work, or customer-specific specifications.
    • System and software requirements: Functional and non-functional needs for MES, ERP, SCADA, or other OT/IT systems that support operations.

    Requirements are usually traceable documents or records. They are referenced throughout the lifecycle, from design and planning through production, inspection, release, and change control.

    Operational role of requirements

    In day-to-day operations, requirements commonly serve to:

    • Define criteria for acceptance or rejection of materials, components, and finished goods.
    • Provide the reference point for inspections, tests, and in-process checks.
    • Guide how work instructions and recipes are authored and updated.
    • Support traceability from customer or regulatory expectations down to plant-floor actions.
    • Enable impact analysis when changes are proposed to products, processes, or systems.

    Relationship to nonconformities

    A nonconformity is typically defined relative to requirements. An issue is considered a nonconformity when there is objective evidence that an established requirement has not been met. Without a clear, documented requirement, it is more difficult to classify a deviation as a formal nonconformity.

    Common confusion

    • Requirements vs. specifications: A specification is a detailed form of requirement, often focused on measurable technical or process criteria. “Requirement” is the broader term and can include specifications, procedures, and contractual or regulatory obligations.
    • Requirements vs. design: Requirements state what needs to be achieved, while design describes how those requirements will be met. Mixing the two can reduce clarity, especially for traceability and change control.
    • Requirements vs. policies: Policies are high-level organizational rules or intentions. Requirements are more specific and actionable, and are often directly testable or verifiable.

    Requirements in OT/IT and MES contexts

    For manufacturing IT and OT systems, requirements commonly cover data capture, traceability, system interfaces, security controls, and support for regulatory records. Functional and non-functional system requirements guide configuration and validation of MES, ERP, LIMS, and related systems that support compliant operations.

  • Stakeholder Alignment

    Core meaning

    Stakeholder alignment commonly refers to the state in which all relevant stakeholders share a clear, compatible understanding of the objectives, constraints, priorities, and expected outcomes of a project, process, or decision.

    In industrial and manufacturing contexts, this usually involves coordination between operations, quality, maintenance, engineering, IT/OT, supply chain, finance, and regulatory or compliance roles.

    Characteristics of stakeholder alignment

    Stakeholder alignment typically includes:

    – **Shared objectives**: Agreement on what success means (for example, reducing batch release time, improving OEE, or meeting a new regulatory requirement).
    – **Common assumptions**: A consistent understanding of scope, constraints, timelines, and available resources.
    – **Compatible priorities**: Explicit reconciliation of competing goals (such as throughput vs. changeover frequency vs. validation effort).
    – **Role clarity**: A clear view of who is accountable, responsible, consulted, and informed across organizations or departments.
    – **Coherent decision criteria**: A common basis for trade‑off decisions, such as quality risk, safety impact, or cost of non‑compliance.

    When these elements are present, stakeholders are said to be “aligned” even if they do not agree on every detail; disagreement is escalated and resolved within a shared framework rather than through conflicting actions.

    Use in manufacturing and regulated operations

    In industrial and regulated environments, stakeholder alignment is often referenced in connection with:

    – **System implementations**: MES, LIMS, ERP, data historian, or OT network projects, where operations, quality, validation, and IT must agree on requirements and constraints.
    – **Process changes and continuous improvement**: Lean, Six Sigma, or deviation/corrective action initiatives, where production, quality, and engineering need a shared view of problem definition and target state.
    – **Regulatory and quality activities**: Establishing a common understanding of how to interpret standards, internal procedures, and risk assessments across QA, production, and technical functions.
    – **Cross‑site or global programs**: Standardizing work, master data, recipes, or batch records across plants, where local site leadership and central functions must align on what will be standardized vs. left flexible.

    In workflows, stakeholder alignment is often established or checked through workshops, steering committees, requirements reviews, documented approvals, RACI definitions, and formal governance bodies.

    Boundaries and what it is not

    Stakeholder alignment:

    – **Is not the same as consensus**: Stakeholders may accept a direction they did not personally prefer, as long as the decision‑making process and rationale are understood.
    – **Is not only communication**: Communicating a decision does not guarantee alignment; the term implies mutual understanding and acceptance of how objectives and constraints translate into actions.
    – **Is not limited to executives**: It includes subject matter experts, end users, and support functions whose work is affected by the initiative, not just sponsors.
    – **Is not a formal certification status**: It is a descriptive term for organizational and project state, not an audited or accredited condition.

    Common confusion and misuse

    Stakeholder alignment is sometimes confused with:

    – **Stakeholder engagement**: Engagement focuses on involvement and participation (for example, workshops or surveys). Alignment focuses on the resulting coherence of objectives and priorities.
    – **Change management**: Change management covers activities to guide people through change. Alignment is one desired outcome of those activities, but not the full discipline.
    – **Top‑down mandate**: A directive from leadership can be a starting point, but the term “alignment” usually implies that affected parties have had an opportunity to understand, clarify, and reconcile their perspectives.

    Using the term precisely helps distinguish between involving stakeholders, communicating decisions, and actually reaching a shared, operationally usable understanding.

  • flowdown

    Flowdown commonly refers to the controlled passing of requirements from one level of a contract or organization to lower levels, such as from a customer to a prime contractor and then to suppliers and sub-tier suppliers.

    In industrial and regulated manufacturing environments, flowdown is used to ensure that all applicable requirements are clearly communicated and traceable throughout the supply chain and internal operations.

    What flowdown includes

    Flowdown typically covers:

    • Customer and contractual requirements, such as quality clauses, inspection and test expectations, and documentation needs.
    • Regulatory and standards-based requirements, for example references to aerospace or defense standards, export control obligations, or industry-specific quality standards.
    • Technical and configuration requirements, including drawings, specifications, revisions, key characteristics, and special process instructions.
    • Compliance and reporting obligations, such as nonconformance reporting, FAI/AS9102 expectations, record retention, and traceability.

    These requirements are usually embedded in purchase orders, contracts, supplier quality requirements, work orders, or internal procedures so that every party performing work is working to the correct and current expectations.

    Operational meaning in manufacturing

    Operationally, flowdown is about how requirements are translated into day-to-day activities. Examples include:

    • A prime aerospace customer specifying that AS9102 FAI is required, and the manufacturer flowing that requirement down to its machining and special-process suppliers.
    • An OEM including export control language that is then flowed down to any supplier handling controlled technical data or hardware.
    • Drawing revision changes being reflected in ERP/MES, work instructions, and supplier purchase orders so that all production uses the correct revision.

    Digital systems such as ERP, MES, PLM, and supplier portals are often used to manage and document flowdown, helping maintain configuration control, version governance, and traceable acknowledgment of requirements.

    Flowdown in aerospace and regulated supply chains

    In aerospace and other highly regulated sectors, flowdown is a key part of demonstrating that customer and regulatory requirements are consistently applied across multiple tiers of suppliers. For example, the applicability of AS9102 first article inspection, special process approvals, or record retention periods is frequently established by customer contracts and then flowed down to relevant internal processes and external suppliers.

    What flowdown is not

    • It is not limited to quality requirements; it can include commercial, schedule, and technical conditions, though quality and compliance are most emphasized in regulated manufacturing.
    • It is not the same as casual communication; effective flowdown is controlled, documented, and traceable to specific contract or regulatory sources.
    • It is not a guarantee of supplier compliance; it is the mechanism used to communicate what compliance is expected.

    Common confusion

    • Flowdown vs. delegation: Flowdown is about communicating requirements; delegation is about assigning authority or decision-making. A company can delegate some tasks without changing the underlying requirement flowdown.
    • Flowdown vs. internal procedures: Internal procedures describe how an organization works. Flowdown links specific customer or regulatory requirements into those procedures and into supplier documents.

    Connection to the source context

    In the context of AS9102 and first article inspection, flowdown describes how a customer or prime manufacturer formally includes AS9102 and related requirements in contracts, purchase orders, or quality clauses so that suppliers know when and how to perform and document first article inspections.

  • Ballooning and characteristics

    Ballooning and characteristics commonly refer to the practice of marking engineering drawings or models with numbered “balloons” and defining each unique, inspectable requirement as a discrete characteristic. This is widely used in first article inspection (FAI), production inspection, and ongoing quality control in regulated manufacturing such as aerospace.

    What ballooning is

    Ballooning is the process of visually annotating an engineering drawing or 3D model so that every requirement that must be verified is identified with a unique reference number (the balloon). Each balloon typically corresponds to a specific line item in an inspection report.

    In practice, ballooning may include:

    • Dimension callouts (linear, angular, GD&T features)
    • Notes and specifications that require verification (material, finish, treatments)
    • Hole sizes, locations, patterns, and thread details
    • Form, fit, and function requirements that can be inspected
    • Referenced standards or process requirements that must be confirmed

    Ballooning can be performed manually on paper, in 2D CAD/PDF, or through digital tools that link the balloons directly to a characteristic database or FAI software.

    What characteristics are

    Characteristics are the individual, measurable or otherwise verifiable requirements extracted from the drawing or model and associated with a balloon number. In AS9102 and similar frameworks, these are often called inspection characteristics or product characteristics.

    A characteristic definition usually includes:

    • The balloon or item number
    • Description of the requirement (for example, diameter of hole, surface finish)
    • Nominal value and tolerances, or acceptance criteria
    • Units of measure
    • Associated drawing zone or reference
    • Type of characteristic (for example, key, critical, major, minor) when applicable
    • Planned inspection method and frequency where defined

    Characteristics provide the structure needed to build inspection plans, first article inspection forms, and ongoing in-process or final inspection records.

    Role in AS9102 and FAI

    In aerospace, ballooning and characteristics are tightly linked to AS9102 first article inspection:

    • The ballooned drawing defines the complete set of product requirements that must be verified.
    • Each ballooned item is translated into a characteristic line on the AS9102 Form 3 (characteristic accountability and verification list) or equivalent digital record.
    • Inspection results, tools used, and any nonconformances are recorded per characteristic, enabling traceable evidence of conformance to drawing requirements.

    Digital FAI systems typically use structured characteristic data to automate form population, result capture, and traceability back to specific drawing requirements and revisions.

    Operational use in manufacturing systems

    In day-to-day operations, ballooning and characteristics may feed multiple systems:

    • PLM/CAD: Source of the design, where requirements originate.
    • FAI or quality systems: Store and manage the characteristic list, inspection results, and evidence.
    • MES: Use characteristics to drive in-process inspection steps and operator checks.
    • ERP/QMS: Reference characteristics for nonconformance records, deviations, and certificates of conformance.

    Consistent ballooning and characteristic definitions help align what is designed, what is manufactured, and what is inspected across different systems and locations.

    Common confusion

    • Ballooning vs. general markup: Ballooning is a structured, numbered system tied to inspection characteristics, not just informal comments or highlights on a drawing.
    • Characteristics vs. process parameters: Characteristics are typically product requirements on the drawing or model. Process parameters (for example, machine settings) may be controlled and recorded, but are not always defined as characteristics unless they appear as specific requirements.
    • Characteristics vs. critical characteristics only: While some organizations focus on key or critical characteristics, ballooning and characteristic listing usually cover all inspectable requirements, not only the critical subset.

    Relation to digital FAI preparation

    When preparing for advanced digital FAI capabilities, manufacturers often focus on cleaning and standardizing ballooning practices and characteristic data. This can include using consistent numbering rules, ensuring every inspectable requirement is captured as a characteristic, and structuring the data so it can be exchanged between PLM, ERP, MES, and quality systems without rework.

  • requirement

    A requirement is a stated or implied need, expectation, or condition that must be fulfilled by a product, process, system, or organization. In industrial and regulated environments, requirements provide the formal basis for design, operation, verification, and audit of manufacturing and quality systems.

    Scope and types of requirements

    In manufacturing and operations, the term commonly includes:

    • Customer requirements: Specifications, drawings, contracts, and service expectations defined by external or internal customers.
    • Regulatory and statutory requirements: Laws, regulations, and official rules that apply to products, processes, facilities, data, and records.
    • Standards and internal policies: Company procedures, work instructions, engineering standards, and quality system rules.
    • Technical and interface requirements: Functional, performance, safety, cybersecurity, interoperability, and integration needs across OT and IT systems.
    • Process and quality requirements: Tolerances, control limits, inspection criteria, data recording rules, and traceability expectations.

    Requirements may be explicitly documented or implied by customary practice, contracts, or applicable regulations. For operational control and audits, organizations typically treat requirements as documented, version-controlled items.

    Operational use in industrial and quality systems

    Requirements appear across the lifecycle of manufacturing systems and products, including:

    • Requirements definition and capture: Gathering and formalizing needs from customers, standards, regulations, and internal stakeholders.
    • Requirements management: Organizing, reviewing, approving, baselining, and version-controlling requirements, often in dedicated tools or within PLM, MES, or ERP-connected systems.
    • Requirements allocation: Decomposing and assigning high-level requirements to subsystems, processes, equipment, software, and suppliers.
    • Requirements traceability: Linking requirements to designs, risk assessments, control plans, work instructions, test methods, validation protocols, and production records.
    • Requirements verification and validation: Demonstrating that each requirement is implemented correctly and that the overall solution meets intended use, often using tests, inspections, simulations, or process capability studies.
    • Change control: Assessing and controlling changes to requirements, including impact on design, qualification, production, documentation, and training.

    In regulated contexts, clarity about which requirements apply, where they are documented, and how they are met is central to audits and investigations.

    Relationship to ISO 9000 concepts

    In quality management, the term commonly refers to a need or expectation that is stated, generally implied, or obligatory. Within a quality management system, this spans customer contract clauses, regulatory rules, internal procedures, and technical specifications that an organization must consider and control. Making requirements explicit, assigning ownership, and maintaining evidence of conformity are key parts of quality and compliance workflows.

    What a requirement is not

    • It is not the same as a task; a task is an activity, while a requirement is a condition or expectation that tasks help satisfy.
    • It is not just a goal or aspiration; a requirement is something that must be fulfilled under defined conditions.
    • It is not automatically a design solution; it describes what is needed, not necessarily how to implement it.

    Common confusion

    • Specification vs requirement: A specification is usually a detailed document that contains many requirements and supporting information such as rationale, background, or examples. A requirement is a single need or condition, often expressed as an atomic statement.
    • User story vs requirement: In software or MES development, user stories describe desired behavior from a user perspective, while requirements may be more formal, structured, and testable statements that can trace directly to verification evidence.
    • Regulation vs requirement: Regulations are external rules set by authorities. Specific requirements are how an organization interprets and implements those rules within its processes, systems, and documentation.