Frequently Asked Question
Decompose the product into functions before choosing physical solutions. Express functions with a verb and object, identify inputs and outputs, and distinguish constraints from desired performance.
Generate multiple concepts by varying energy flow, material, architecture, actuation, joining, and manufacturing route. Preserve rejected concepts and reasons so the team does not repeatedly revisit the same dead ends.
Traceable product-development method
Product-development work should connect the customer need to a measurable requirement, design output, manufacturing control, and objective evidence. For Functional Decomposition and Concept Generation, define the function, stakeholders, inputs, constraints, failure risks, verification or validation method, acceptance criterion, and accountable owner. Keep assumptions and unresolved risks visible instead of hiding them in status language.
This is a prioritization aid, not a physical law. Use the project’s approved rating definitions and treat safety, regulatory, and single-point risks explicitly.
Worked example
If a seal requirement is leakage below 1.0 mL/min, the evidence plan should identify the production-intent seal, pressure and temperature cycle, measurement resolution, sample size, acceptance rule, and disposition for an outlier. “Tested” is incomplete without those details. A design change that alters the seal interface should trigger impact review of requirements, DFMEA, verification, PFMEA, and control plans.
Gate discipline: make the reviewed configuration, decision, open action, owner, due date, and residual risk explicit.
Engineering check
For Functional Decomposition and Concept Generation, maintain traceability from requirement to risk, design output, evidence, and approval. Record the configuration, acceptance criterion, test or analysis conditions, open actions, and residual risk. A method is not complete when the document is filled in; it is complete when the evidence supports the decision and affected controls are updated.