Hello, and welcome to the first lesson in the program-setup module. Before designing any plastic geometry, running draft analysis, or creating a BOM, you need a defensible definition of what the component is required to achieve. In automotive work, an informal brief rarely arrives as a clean engineering specification. It may mix customer expectations, styling intent, program targets, supplier preferences, regulations, standards, and incomplete package information.
This module establishes the discipline that makes the three later component projects controllable: turning such inputs into requirements, linking them to verification and standards, managing assumptions, and reviewing decisions through a simulated PLM workflow. In this lesson, you will translate a component brief into measurable functional, regulatory, environmental, packaging, appearance, and manufacturing requirements—without prematurely locking in a particular CAD solution.
From a brief to an engineering baseline
A brief is an expression of need. A requirement is a controlled, testable statement of what the system or component must do or be.
Consider an assumption-based brief for the first course project:
Design an injection-molded enclosure for a high-voltage ECU in a Rivian-built Amazon Electric Delivery Van. The enclosure must protect electronics in a vehicle environment, fit an allocated electronics-bay space, permit connector and service access, achieve the agreed ingress-protection target, and be practical for automotive-volume manufacture. Visible external surfaces must meet the agreed under-hood appearance level.
This is useful direction, but it is not yet an engineering specification. It leaves important questions unanswered:
- What electronics must be protected, and against which loads or contaminants?
- Which exact allocated volume and keep-out zones apply?
- Which ingress code, test method, mounting orientation, and pass criteria apply?
- What constitutes acceptable connector access?
- What production volume, material family, surface specification, and manufacturing capability are assumed?
- Which standards and regulations are applicable, and which are merely references to investigate?
A design engineer’s first task is not to “fill gaps” with confident guesses. It is to distinguish four different things:
| Item | Meaning | How to manage it |
|---|---|---|
| Stakeholder need | Desired outcome, often qualitative | Preserve the original wording and source |
| Requirement | Measurable, approved design input | Give it an ID, rationale, owner, and verification plan |
| Assumption | A working proposition used before confirmed data is available | Record its source, confidence, owner, and due date |
| Design decision | Chosen method for meeting a requirement | Control it in CAD, a design record, or change process |
For example, “the ECU housing shall use PA66-GF30” is usually not an appropriate first-level requirement. It is a proposed implementation. A more solution-neutral requirement could state:
The ECU enclosure material shall retain the required structural, sealing-support, electrical-isolation, and environmental performance throughout the approved service environment.
After a material trade study, PA66-GF30 may become an approved design decision—or a controlled lower-level material requirement if the customer or a governing specification truly mandates it.
The distinction matters because a requirement should define the boundary of acceptable solutions, not silently select one before alternatives have been evaluated.
An Introduction to Requirements | Systems Engineering, Part 4
Watch “An Introduction to Requirements | Systems Engineering, Part 4” from MATLAB. It introduces the structure of a requirement, the major requirement types, and the practical reasons to reject vague, compound, or implementation-led statements.
Begin with requirement anatomy, focusing on the linked description, rationale, and verification method. Then watch requirement types for the distinction between function, performance, and constraints. Finish with quality checks, especially the examples of ambiguous, compound, and overly prescriptive requirements. Translate “toaster” mentally into an automotive molded component: the reasoning transfers directly.
A sound requirement normally answers five questions:
-
Who or what is responsible?
Usually the component: “The ECU housing,” “The door carrier,” or “The HVAC outlet assembly.” -
What must it do or be?
Use “shall” and a clear verb: support, prevent, provide, withstand, fit, permit, limit. -
Under what conditions?
Define the vehicle state, temperature range, mounting condition, load case, orientation, or use scenario where needed. -
How well?
State a value, unit, tolerance, class, allowed condition, or reference to a controlled criterion. -
How will compliance be demonstrated?
Plan test, analysis, inspection, or demonstration while writing the requirement.
The final point is decisive. “The housing shall be durable” cannot be verified. “The housing shall survive vehicle vibration” is better, but still incomplete until the applicable profile, mounting condition, duration, and pass criteria are specified.
Read the brief as a set of requirement domains
Requirements are not only functional. A component can perform its nominal function and still fail the vehicle program because it does not fit, cannot be assembled, violates a legal constraint, looks unacceptable, or is impossible to produce repeatably.
SEBoK’s categories—function/performance, fit/operation, form, quality, and compliance—provide a useful general framework. For automotive component work, we will use a more practical working breakdown that makes the sources of requirements visible.
System Requirements Definition - SEBoK
Read “System Requirements Definition” from the Systems Engineering Body of Knowledge. It explains the move from stakeholder needs to measurable technical requirements and provides a useful way to organize requirement categories and attributes.
In the section “Transforming Needs to System Requirements,” read the explanation of needs and requirements. Focus on the distinction between an external stakeholder view and the developer’s technical view, while retaining attention on what the system must achieve. Then read the full “Categorizing Requirements” section, especially the category framework. Compare its Function/Performance, Fit/Operational, Form, Quality, and Compliance categories with the automotive-oriented domains used below. Finally, in “Use of Attributes,” study the discussion of rationale and verification attributes, then review Table 2. Notice that a good statement is only one part of a managed requirement record.
1. Functional requirements: what the component must accomplish
Functional requirements describe the component’s intended behavior or contribution to the vehicle. For a plastic ECU housing, relevant functions include:
- enclosing and retaining the ECU electronics;
- supporting the PCB and connectors;
- providing an environmental barrier;
- transmitting structural loads from the unit to vehicle mounting points;
- enabling installation and removal.
A weak brief statement might say:
The housing must protect the ECU.
That statement hides several distinct functions. “Protect” could mean retain the PCB, exclude water, resist stone impact, preserve electrical isolation, or prevent unauthorized service access. Decompose it.
For example:
- ECU-FUN-001: The ECU enclosure assembly shall retain the installed PCB, connectors, sealing components, and specified internal hardware throughout the approved vehicle operating environment.
- ECU-FUN-002: The ECU enclosure assembly shall provide a continuous environmental barrier between the external vehicle environment and the protected internal volume, except at approved venting interfaces.
- ECU-FUN-003: The ECU enclosure assembly shall permit removal and replacement of the ECU assembly using the approved service-tool envelope without removal of adjacent components identified as non-service items.
Notice that these are still incomplete if the approved environment, hardware, or service envelope has not been defined. That incompleteness must be visible as a controlled open item, not buried inside a vague phrase.
2. Regulatory and compliance requirements: what the product must conform to
A requirement is not automatically regulatory just because it cites an ISO document. Standards may be contractual, customer-imposed, technically informative, or genuinely necessary to demonstrate regulatory compliance. The standards register in a later lesson will classify this properly.
At this stage, identify each candidate obligation and capture:
- issuing body and document identity;
- revision or edition;
- applicable market and vehicle configuration;
- applicable clauses or test conditions;
- the component’s compliance obligation;
- required evidence.
For example, a requirement should not say merely:
The enclosure shall comply with ISO 16750.
ISO 16750 is a family of automotive environmental-condition and test documents, not one universal acceptance number. Applicability depends on location, mounting, and the selected test conditions.
A better structure is:
ECU-ENV-004: The ECU enclosure assembly shall meet the vibration exposure and acceptance criteria defined by the applicable approved environmental test profile for its declared electronics-bay mounting location.
The requirement’s source attribute might cite the relevant approved standard clause, customer environmental profile, and mounting assumption. Its verification record then specifies the vibration fixture, ECU configuration, test axes, duration, functional monitoring, and post-test acceptance criteria.
For this course, the EDV context is deliberately assumption-based. Do not describe any requirement as a Rivian or Amazon requirement unless you have a controlled, public, and applicable source. Instead label it clearly:
- Customer assumption
- Program engineering assumption
- Candidate standard requirement
- Confirmed contractual requirement
This protects both technical credibility and future change control.
3. Environmental requirements: the conditions of survival and function
Environmental requirements express the environments imposed on the component during operation, storage, transport, manufacture, and service. Automotive components experience far more than a single “operating temperature.”
Typical environmental dimensions include:
- temperature extremes and cycling;
- humidity and condensation;
- splash, dust, wash exposure, or immersion;
- vibration and mechanical shock;
- road salt, cleaners, oils, coolant, and other chemicals;
- UV exposure for exterior or sunlit interior components;
- electrical and electromagnetic conditions where the component’s function requires them;
- storage, shipping, handling, and installation conditions.
A useful separation is:
- Environmental condition: what is imposed.
- Required response: what the component must retain or avoid.
- Acceptance criterion: what evidence proves success.
For instance:
ECU-ENV-010: Following the approved thermal-cycling exposure, the ECU enclosure assembly shall show no crack, loss of sealing-land continuity, fastener-interface damage, or reduction in specified ingress-protection performance.
That is structurally stronger than “the housing shall withstand thermal cycling,” because it defines what failure looks like. The exact exposure must come from an approved profile; until then, it belongs in an open assumption or a placeholder requiring closure.
4. Packaging and interface requirements: fitting into a larger system
Packaging is not merely an outer bounding box. It includes physical fit, interfaces, access, clearances, motion, harness routing, assembly sequence, and ownership boundaries. Most late CAD changes originate here.
The interface boundary diagram below emphasizes that a component boundary can involve physical, electronic, electrical, hardware, software, environmental, and human-machine interactions. For mechanical design, this is a reminder to consider more than surfaces that touch.
For an ECU housing, interfaces might include the vehicle mounting structure, low- and high-voltage connectors, harness paths, adjacent components, service tools, thermal paths, a vent, the PCB, and assembly fasteners.
Write packaging requirements around observable interface conditions:
ECU-PKG-002: The ECU enclosure assembly shall remain within the released installation envelope and shall not intrude into the released keep-out volumes for adjacent vehicle parts throughout the declared assembly and service-removal motions.
ECU-PKG-006: The connector interface shall provide the minimum approved harness bend clearance and connector-latch access in the installed vehicle condition.
ECU-PKG-009: The vehicle mounting interface shall locate the ECU enclosure assembly relative to the approved vehicle datum scheme using the specified mounting features.
These statements will eventually require controlled CAD data: vehicle datums, interface-control models, space envelopes, harness data, and service-tool geometry. Before that data exists, record the package as an assumption with a confidence level. Do not replace missing data with a nominal dimension that looks authoritative.
5. Appearance requirements: turning “looks good” into acceptance criteria
Appearance requirements are particularly important for the door trim carrier and HVAC outlet, but they are relevant even for an under-hood enclosure if exposed surfaces have identification, texture, or cosmetic constraints.
“Premium appearance” and “no visible defects” are stakeholder language, not complete requirements. Appearance must define the evaluation system:
- viewing distance;
- viewing angle;
- illumination type and intensity;
- surface region or zone;
- approved texture, color, gloss, grain, or master sample;
- allowed and prohibited defect types;
- sample size or inspection method where appropriate.
A more measurable requirement, appropriate only once its parameters are approved, might be:
TRIM-APP-003: Under the approved appearance-evaluation condition, the Class-A surface zones identified on drawing XXX shall exhibit no visible sink, read-through, flow mark, weld line, scratch, contamination, or color mismatch exceeding the approved surface master acceptance criteria.
The requirement is not made objective simply by mentioning “approved criteria.” The linked criterion must itself be controlled, available to the supplier and inspector, and sufficiently specific. For the later door-trim project, this will connect directly to rib placement, wall thickness, gate strategy, material selection, mold flow, and a defined zero-visible-defect evaluation method.
6. Manufacturing requirements: requirements on repeatable realization
Manufacturing requirements define the capability to produce the design reliably, economically, safely, and at the needed scale. They should reflect the program’s production intent without dictating arbitrary tooling details.
For an injection-molded component, topics often include:
- intended manufacturing process;
- production volume and launch timing;
- material specification and approved-regrind policy where applicable;
- cycle-time or cost target;
- draft, wall-thickness, and feature constraints;
- allowable undercuts and tooling complexity;
- gate-vestige zone;
- tooling and process capability evidence;
- identification, traceability, and marking;
- inspection and quality-control expectations.
Compare these two statements:
- Overly prescriptive: “The ECU base shall have two tunnel gates on its long side.”
- Requirement-led: “Gate vestige shall be confined to the drawing-defined non-cosmetic gate zones and shall not interfere with sealing, mounting, connector interfaces, or assembly.”
The second statement controls the product need. Mold-flow analysis and supplier tooling expertise can determine whether a tunnel gate, edge gate, valve gate, or a different strategy is best. A gate type becomes a controlled design decision once selected.
A practical manufacturability requirement can be stated as:
ECU-MFG-005: The molded base and cover shall be designed for removal from the approved primary mold-pull direction without damage to functional surfaces, except where approved side actions are documented in the tooling concept.
This requirement prepares the later CAD activities: defining tooling direction, draft, parting lines, shutoffs, and side actions.
A disciplined conversion method
Use the following method whenever you receive a new component brief. It is deliberately tool-independent: it works in a spreadsheet today and maps cleanly to a requirements-management or PLM system later.
Step 1: Preserve and classify the original input
Copy the brief statement into a controlled source log. Record who supplied it, its date, document revision, and whether it is a customer statement, technical standard, regulation, internal target, supplier constraint, or engineering assumption.
Do not rewrite the original in place. The original wording is evidence of intent; the derived requirement is your interpretation of that intent.
Step 2: Ask the analysis questions
For each input, ask:
- Purpose: What vehicle or user outcome does this support?
- System boundary: Is this a requirement for the vehicle, assembly, component, or a subfeature?
- Scenario: Under what operating, misuse, service, transport, or manufacturing condition does it apply?
- Measure: What quantity, condition, class, or observable criterion distinguishes pass from fail?
- Source: Where does each threshold originate?
- Verification: Can test, analysis, inspection, or demonstration prove it?
- Conflict: Does it compete with another requirement, such as low mass versus impact performance, or styling thickness versus packaging clearance?
- Unknown: What must be confirmed before it can become an approved requirement?
This analysis often turns one brief statement into several requirements. That is correct. A need such as “protect the electronics in all weather” likely decomposes into water ingress, dust ingress, chemical exposure, vibration, thermal cycling, and electrical-isolation requirements.
Step 3: Write one atomic “shall” statement
An atomic requirement contains one independently verifiable obligation. Avoid connecting multiple obligations with “and,” “or,” or vague qualifiers such as “suitable,” “robust,” “user-friendly,” “minimize,” and “high quality.”
| Weak statement | Why it fails | Improved approach |
|---|---|---|
| The cover shall be strong, light, and waterproof. | Three different obligations; no values or methods. | Split structural, mass, and ingress requirements. |
| The door carrier shall have excellent appearance. | Subjective and undefined. | Specify appearance zones and controlled inspection conditions. |
| The HVAC outlet shall be easy to operate. | “Easy” has no pass criterion. | Specify operating force, motion range, and user condition. |
| The housing shall use six bosses and four screws. | Dictates a concept rather than the need. | Define retention, load, service, and assembly requirements; select fastener count during design. |
| The part shall comply with all automotive standards. | Unbounded, not applicable, impossible to verify. | Identify applicable standards, clauses, and evidence. |
Step 4: Add attributes that make the statement useful
A requirement database is more than a numbered list. At minimum, create these fields:
| Attribute | Purpose |
|---|---|
| Requirement ID | Stable, unique identifier, such as ECU-PKG-002 |
| Title | Short searchable label |
| Requirement statement | The atomic “shall” statement |
| Category | Functional, regulatory, environmental, packaging, appearance, or manufacturing |
| Source | Brief, standard clause, customer input, analysis, assumption, or decision record |
| Rationale | Why the requirement exists and why the value was selected |
| Parent need | The higher-level need it supports |
| Owner | Responsible engineering function |
| Verification method | Test, analysis, inspection, demonstration, or combination |
| Acceptance criterion | Explicit evidence needed for pass |
| Status | Draft, under review, approved, obsolete, or superseded |
| Open issue / assumption link | What must be resolved, if applicable |
This is not administrative overhead. These fields are what allow a future engineer, quality reviewer, supplier, or change-control board to understand why a dimension exists and what must be re-evaluated when it changes.
SYS.2 System Requirements Analysis | Automotive SPICE
Watch the selected parts of “SYS.2 System Requirements Analysis | Automotive SPICE” from UL Solutions – Software Intensive Systems. Although its examples emphasize system and software contexts, its treatment of stakeholder requirements, feasibility, and change impact is directly relevant to component development.
Watch stakeholder inputs to see why customer wishes alone are not a complete requirement set: standards, norms, and regulations must be assessed too. Then study requirement analysis, focusing on feasibility, testability, technical interactions, risk, cost, and timing. Finish with traceability value for the role of links in consistency checks and later change-impact assessment.
Worked example: converting an ECU-housing brief
The table below demonstrates the conversion process. The numerical values are intentionally marked as illustrative program assumptions, not facts about any Rivian vehicle, Amazon vehicle program, or supplier requirement. In a real project, each would need a controlled source and approval.
| Brief language | Requirement category | Example measurable requirement | Verification and acceptance |
|---|---|---|---|
| “Protect ECU electronics from vehicle exposure.” | Functional / environmental | ECU-ENV-001: The installed ECU enclosure assembly shall meet the approved ingress-protection acceptance criteria following exposure in the declared installed orientation. | Environmental test and post-test inspection. Pass condition: no ingress or functional degradation beyond the approved criteria. |
| “Fit in the electronics bay.” | Packaging | ECU-PKG-001: The ECU enclosure assembly shall remain within the released package envelope defined by interface model revision [TBD]. | CAD interference analysis. Pass condition: no interference with controlled keep-outs at declared build conditions. |
| “Allow harness connection and service.” | Packaging / serviceability | ECU-PKG-005: The installed ECU enclosure assembly shall provide access to each connector latch and fastener within the approved service-tool and hand-access envelopes. | Digital mock-up and physical demonstration. Pass condition: each listed operation can be completed without removing non-service parts. |
| “Survive fleet-duty temperatures.” | Environmental | ECU-ENV-006: The ECU enclosure assembly shall meet the approved functional and physical acceptance criteria after the declared temperature exposure profile for its installation location. | Environmental test. Pass condition: no defined damage, loss of seal, loss of retention, or specified functional failure. |
| “Meet enclosure standards.” | Regulatory / compliance | ECU-CMP-002: The ECU enclosure assembly shall satisfy the applicable clauses of the approved ingress-protection specification identified in the standards register. | Compliance review plus test report. Pass condition: approved test evidence linked to the relevant clauses. |
| “Keep external surfaces acceptable.” | Appearance | ECU-APP-001: External surfaces designated as customer-visible shall conform to the approved texture, color, marking, and defect-acceptance criteria. | Inspection against approved appearance standard. Pass condition: all designated zones accepted. |
| “Support automotive-volume molding.” | Manufacturing | ECU-MFG-003: The base and cover shall be manufacturable by the approved injection-molding process without unapproved side actions or nonconforming draft conditions. | Tooling-concept review and draft analysis. Pass condition: approved tooling concept and analysis evidence. |
| “Keep cost and mass controlled.” | Manufacturing / form | ECU-FRM-001: The ECU enclosure assembly mass shall not exceed the approved mass allocation of [TBD] g in the released configuration. | CAD mass-properties analysis and production-part measurement. Pass condition: both values are at or below allocation. |
Several features are worth noticing.
First, the table does not invent an IP code, thermal range, mass target, vehicle package, or standard clause. Where those inputs are unknown, it identifies the missing approval rather than fabricating a number. A number with no source is not a requirement; it is an unlabelled assumption.
Second, the verification method is planned immediately. This is how you reveal weak requirements early. If you cannot describe what evidence would demonstrate compliance, rewrite the statement or identify the missing decision.
Third, a requirement may belong to more than one conceptual category, but assign one primary category to support sorting and ownership. Its relationships can capture the cross-domain effect. For example, a gasket-compression requirement will influence sealing performance, stack-up tolerances, material selection, fastener preload, groove geometry, tooling variation, and validation.
Verification language: prove it, do not merely assert it
Four primary verification methods are used throughout this course:
| Method | Appropriate evidence | Automotive component example |
|---|---|---|
| Test | Measured data from a controlled procedure | Ingress test of a mounted ECU enclosure |
| Analysis | Calculation, simulation, tolerance stack, or CAE result | FEA assessment of a mounting boss under shock load |
| Inspection | Examination of geometry, documents, or production parts | Check of a drawing, molded-part dimensions, or marking |
| Demonstration | Observed operation, usually with limited measurement | Demonstration of HVAC vane motion and service access |
Verification answers: Did we meet the stated requirement?
Validation is different: Does the assembled product fulfill the stakeholder’s intended use in the intended environment? A connector may meet a specified access dimension in CAD, yet a technician wearing gloves may still find service impractical. Both the requirement and the use case then deserve review.
[PDF] Requirements and Testing - NASA
Read the selected material from NASA’s “Requirements and Testing” webinar. The examples are not automotive-specific, but the writing rules and distinction between verification methods are broadly applicable to engineering requirements.
In the early requirements-writing material, read the writing and quality checklist. Use it as a final review checklist for every statement you create. Then, in the later verification material, read verification versus validation. Continue through the four verification methods, and consider which one is the earliest credible evidence for each example ECU requirement.
A pre-baseline review checklist
Before approving a first requirement baseline, review the set—not just individual statements.
For every requirement, confirm that it is:
- Necessary: linked to a stakeholder need, applicable standard, approved target, or risk treatment.
- Atomic: one obligation that can be independently verified.
- Unambiguous: interpreted consistently by design, quality, manufacturing, supplier, and test teams.
- Measurable and verifiable: has a planned method and explicit pass condition.
- Feasible: technically achievable within package, cost, timing, and manufacturing constraints.
- Solution-appropriate: states what is needed, not an arbitrary “how,” unless the implementation is explicitly mandated.
- Traceable: linked upward to source and later downward to CAD, drawing features, test cases, DFMEA entries, and release evidence.
- Consistent: does not conflict with another requirement or use a different datum, unit, environmental condition, or revision of a standard.
- Controlled: has an owner, status, source revision, and an agreed path for resolving open items.
At this early program stage, it is acceptable—and preferable—to have open items. Mark them openly, for example:
Open assumption A-014: The ECU package envelope is based on an assumed electronics-bay model. Confidence: low. Owner: vehicle packaging. Closure required before PDR baseline.
Do not convert that uncertainty into a false release. A useful requirements baseline tells the team both what is known and what must be resolved before design commitment.
Practical workflow for your course record
Create a spreadsheet or controlled requirements document with one tab called Component Brief and Requirements. Start with these columns:
- Source ID
- Original brief statement
- Requirement ID
- Category
- Atomic requirement statement
- Rationale and source of value
- Assumption or open issue link
- Owner
- Verification method
- Acceptance criterion
- Maturity status
Use an ID pattern that remains meaningful across the course:
ECU-FUN-xxx,ECU-ENV-xxx,ECU-PKG-xxxDTR-APP-xxx,DTR-MFG-xxxHVAC-FUN-xxx,HVAC-PKG-xxx
Avoid encoding a revision in the ID. A requirement may be revised from Version A to Version B, but its stable identifier enables traceability and change-impact review.
For the simulated EDV program, establish a visible label for every source-derived item:
- Publicly supported information
- Course assumption
- Candidate standard or regulation
- Approved project requirement
- Design decision
That simple discipline will keep later CAD, DFMEA, drawing, test, and ECO records intellectually honest.
A component brief becomes engineering work only when it is converted into a coherent set of measurable requirements with sources, rationale, ownership, and a credible way to prove compliance. Functional requirements state intended capability; regulatory and compliance requirements establish applicable obligations; environmental requirements define the conditions of use; packaging requirements control interfaces and access; appearance requirements define objective acceptance conditions; and manufacturing requirements ensure the design can be realized repeatedly.
Most importantly, do not hide uncertainty. Record assumptions explicitly, avoid invented values, separate requirements from design choices, and ensure each requirement can ultimately be verified by test, analysis, inspection, or demonstration.
Next, you will build a requirements traceability matrix that links each approved requirement to its verification method, acceptance criterion, and evidence. That matrix will become the backbone connecting the brief to CAD, drawings, validation, supplier deliverables, release, and later engineering changes.
Can't find a good explanation? Sign up and we'll make it for you
Sign up