2.1
Systems, boundaries, stakeholders, and operating context
Why this lesson matters
A component can meet its drawing and still fail the product if its boundary, environment, or interactions were misunderstood.
Learning objectives
- Define and distinguish System boundary and Stakeholder.
- Apply the lesson method to the worked systems, boundaries, stakeholders, and operating context case.
- Evaluate evidence, uncertainty, and AI-assisted output before making a claim.
Readiness check
Before continuing, explain what decision this topic supports and name one upstream source that must be controlled.
Check your response
A sound answer names a specific engineering decision, its configuration, and a controlled requirement, model, dataset, interface, or standard that constrains the work.
Core idea
A system is a set of interacting elements organized to achieve an outcome. The analyst chooses a boundary for a purpose, then documents external actors, flows, lifecycle states, and environmental conditions that cross it.
Key concepts
| System boundary | The declared separation between the system of interest and its external context. |
|---|
| Stakeholder | A person or organization with needs, constraints, responsibilities, or consequences related to the system. |
|---|
| External interface | A controlled exchange of matter, energy, information, force, or responsibility across the boundary. |
|---|
| Operational scenario | A time-ordered account of how the system is used in a stated environment. |
|---|
Step-by-step explanation
- Name the outcome before decomposing hardware.
- Draw the system of interest and list external actors, neighboring systems, operators, maintainers, and environments.
- Record what crosses each boundary: loads, heat, fluid, power, commands, data, hazards, and maintenance actions.
- Create nominal, off-nominal, maintenance, transport, and end-of-life scenarios.
- Review the boundary whenever a requirement or interface appears to have no owner.
Worked example
Define the system context for an electric radiator fan assembly. The motor, impeller, shroud, controller, vehicle power, radiator airflow, mounting structure, technician, and road environment all matter.
- 1
Set the system of interest to the fan assembly: motor, impeller, shroud, and local controller.
- 2
Treat vehicle power, commands, radiator, mounts, surrounding air, technician, and road environment as external context.
- 3
List exchanges: 12 V power, speed command, current/status data, reaction loads, airflow, heat, vibration, debris, and service access.
- 4
Write scenarios for hot idle, cold start, blocked inlet, connector replacement, and vehicle vibration.
Result. The context exposes requirements that a fan-only performance curve misses: connector limits, mount loads, debris tolerance, thermal soak, diagnostics, and service access.
Independent check. Every external flow and lifecycle scenario has an owner and at least one requirement, assumption, or planned analysis.
Common misconceptions
| Misconception | Correction |
|---|
| The system is the hardware in the box | People, software, procedures, facilities, and external systems may be essential to the achieved capability. |
|---|
| A tool output closes the question | A result remains a candidate until its inputs, method, configuration, uncertainty, and relevance have been checked. |
|---|
Diagnostic questions
Is a boundary a physical wall?
Not necessarily. It is an analytical and responsibility boundary chosen for the engineering purpose.
What would make this work reproducible?
Controlled inputs, method or code, versions, assumptions, outputs, and a stated interpretation tied to the decision.
Practice ladder
BasicDraw a context diagram for a hand drill and label five boundary exchanges.
IntermediateExplain how the boundary changes if the fan controller is moved from inside the assembly to the vehicle ECU.
AdvancedBuild three off-nominal scenarios and show which stakeholders experience each consequence.
AI-assisted engineering task
Ask AI to propose missing stakeholders and off-nominal scenarios for the fan context, with a reason for each candidate.
How to prove the AI output yourself
- Check candidates against the product lifecycle and actual organizational responsibilities.
- Reject invented interfaces and unsupported environmental limits.
- Obtain domain-owner review for safety and maintenance scenarios.
Retrieval and spaced review
Answer closed-notes today, then again after 1, 3, 7, and 30 days.
Define System boundary.
The declared separation between the system of interest and its external context.
What role does Stakeholder play here?
A person or organization with needs, constraints, responsibilities, or consequences related to the system.
What must a reviewer be able to reconstruct?
Every external flow and lifecycle scenario has an owner and at least one requirement, assumption, or planned analysis.
End-of-lesson summary
A system is a set of interacting elements organized to achieve an outcome. The analyst chooses a boundary for a purpose, then documents external actors, flows, lifecycle states, and environmental conditions that cross it.
Student notes
Keep one context diagram current. When a new load, signal, person, or environment appears, add it before editing downstream models.
Recommended readings
Instructor notes
Use a familiar product and repeatedly change the system boundary. Students should see that boundaries are purposeful choices with consequences.
2.2
From stakeholder needs to functional and physical architecture
Why this lesson matters
Jumping from a vague need to a preferred component hides alternatives and creates requirements that describe the solution before the problem is understood.
Learning objectives
- Define and distinguish Stakeholder need and Functional architecture.
- Apply the lesson method to the worked from stakeholder needs to functional and physical architecture case.
- Evaluate evidence, uncertainty, and AI-assisted output before making a claim.
Readiness check
Before continuing, explain what decision this topic supports and name one upstream source that must be controlled.
Check your response
A sound answer names a specific engineering decision, its configuration, and a controlled requirement, model, dataset, interface, or standard that constrains the work.
Core idea
Stakeholder needs express desired outcomes. Requirements make verifiable obligations. Functional architecture describes what transformations must occur; physical architecture allocates those functions to interacting elements.
Key concepts
| Stakeholder need | An outcome or capability desired by a stakeholder, expressed without pretending it is already a verified requirement. |
|---|
| Functional architecture | A structured account of required functions, flows, and behavior independent of a final physical solution. |
|---|
| Physical architecture | The arrangement of physical, software, and human elements that realize allocated functions. |
|---|
| Allocation | A traceable assignment of a function, requirement, or constraint to an implementing element. |
|---|
Step-by-step explanation
- Clarify the stakeholder and operational problem in context.
- Transform needs into measurable system requirements with rationale and verification intent.
- Identify input-output transformations such as move coolant, reject heat, sense temperature, and control flow.
- Explore alternative physical allocations before selecting pump, fan, valve, sensor, and controller concepts.
- Trace the selected architecture back to needs and forward to element requirements and evidence plans.
Worked example
A battery test rig must keep a cell fixture below 45 °C during a 500 W transient. The team is choosing between forced air and a pumped liquid loop.
- 1
State the need: safe, repeatable cell testing without exceeding the fixture temperature limit.
- 2
Define functions: acquire heat, transport heat, reject heat, sense temperature, command flow, and protect on fault.
- 3
Create two physical allocations: heat sink plus fan, or cold plate plus pump, radiator, and controller.
- 4
Compare allocations using heat capacity, pressure drop, noise, leak risk, maintenance, and control response, not preference alone.
Result. The functional view preserves what must be achieved while the physical trade study selects how. Requirements can then be allocated without losing the stakeholder outcome.
Independent check. Every selected physical element realizes a required function or constraint, and every required function has an implementing element.
Common misconceptions
| Misconception | Correction |
|---|
| Architecture is a parts list | Architecture includes functions, behavior, interfaces, allocation, and rationale, not only components. |
|---|
| A tool output closes the question | A result remains a candidate until its inputs, method, configuration, uncertainty, and relevance have been checked. |
|---|
Diagnostic questions
Should a requirement name a pump?
Only when the architecture or external constraint legitimately fixes that solution; otherwise state the required performance.
What would make this work reproducible?
Controlled inputs, method or code, versions, assumptions, outputs, and a stated interpretation tied to the decision.
Practice ladder
BasicSeparate the need, function, and component in six statements about a bicycle brake.
IntermediateBuild a function-to-component allocation table for the liquid cooling concept.
AdvancedPropose a third architecture and identify which assumptions must change before it can compete fairly.
AI-assisted engineering task
Ask AI to generate alternative function allocations for the cooling rig. Require it to separate functions, candidate elements, assumptions, and new risks.
How to prove the AI output yourself
- Check energy and mass conservation across every proposed architecture.
- Reject alternatives that violate fixed interfaces or stakeholder constraints.
- Run a human trade study with explicit criteria and uncertainty.
Retrieval and spaced review
Answer closed-notes today, then again after 1, 3, 7, and 30 days.
Define Stakeholder need.
An outcome or capability desired by a stakeholder, expressed without pretending it is already a verified requirement.
What role does Functional architecture play here?
A structured account of required functions, flows, and behavior independent of a final physical solution.
What must a reviewer be able to reconstruct?
Every selected physical element realizes a required function or constraint, and every required function has an implementing element.
End-of-lesson summary
Stakeholder needs express desired outcomes. Requirements make verifiable obligations. Functional architecture describes what transformations must occur; physical architecture allocates those functions to interacting elements.
Student notes
Use three columns in notes: need, function, physical realization. If one sentence mixes all three, rewrite it.
Recommended readings
Instructor notes
Do not reward large diagrams. Reward clear transformations, allocations, and traceable rationale.
2.3
Interfaces as controlled engineering agreements
Why this lesson matters
Many integration failures occur between well-designed components because geometry, loads, data, ownership, or operating states were not jointly controlled.
Learning objectives
- Define and distinguish Interface and Interface control.
- Apply the lesson method to the worked interfaces as controlled engineering agreements case.
- Evaluate evidence, uncertainty, and AI-assisted output before making a claim.
Readiness check
Before continuing, explain what decision this topic supports and name one upstream source that must be controlled.
Check your response
A sound answer names a specific engineering decision, its configuration, and a controlled requirement, model, dataset, interface, or standard that constrains the work.
Core idea
An interface definition is a bilateral agreement about what crosses a boundary, in what units, direction, range, coordinate frame, timing, quality, and responsibility. Interface verification must test both sides together.
Key concepts
| Interface | A shared boundary and the controlled exchanges across it. |
|---|
| Interface control | The process and record used to establish, review, change, and verify interface definitions. |
|---|
| Compatibility | The ability of connected elements to exchange required flows without violating limits. |
|---|
| Interface state | The configuration or operating condition that changes allowed exchanges, such as installed, disconnected, faulted, or serviced. |
|---|
Step-by-step explanation
- Name both sides and an accountable owner on each side.
- Specify physical geometry, coordinate frames, tolerances, loads, energy, material, signals, protocols, timing, and environment as applicable.
- State ranges and worst-case combinations, not isolated nominal values.
- Define assembly, inspection, operation, fault, maintenance, and disconnection states.
- Control changes jointly and verify compatibility with integrated tests or analyses.
Worked example
A pump outlet joins a heat-exchanger inlet through a bolted flange. Both use a 40 mm nominal bore, but drawings use different datums and one pressure rating is absolute while the other is gauge.
- 1
Create one interface identifier linking the two controlled ports.
- 2
Align datum and coordinate definitions, bolt pattern, gasket surface, material compatibility, and assembly torque.
- 3
Normalize pressure basis, temperature range, proof load, allowable leakage, and transient combinations.
- 4
Plan fit inspection, pressure proof, and leak testing on the assembled interface.
Result. Nominal bore agreement was insufficient. The controlled interface resolves reference frames and pressure semantics before hardware is joined.
Independent check. A supplier on either side can implement and verify its half without private assumptions about the other side.
Common misconceptions
| Misconception | Correction |
|---|
| Matching names imply compatibility | The same label can hide different units, datums, ranges, protocols, or definitions. |
|---|
| A tool output closes the question | A result remains a candidate until its inputs, method, configuration, uncertainty, and relevance have been checked. |
|---|
Diagnostic questions
Who verifies an interface?
Both element owners contribute, and the integrated product verifies the shared behavior.
What would make this work reproducible?
Controlled inputs, method or code, versions, assumptions, outputs, and a stated interpretation tied to the decision.
Practice ladder
BasicList interface fields for a bolted motor-to-gearbox connection.
IntermediateFind five ambiguities in an interface that says only '40 mm flange, 6 bar'.
AdvancedDesign an interface change process that prevents one supplier from releasing a unilateral bolt-pattern revision.
AI-assisted engineering task
Ask AI to review an interface table for missing units, directions, ranges, states, or ownership. Require row-level citations.
How to prove the AI output yourself
- Compare every flag to the controlled interface definition.
- Run dimensional and coordinate-frame checks independently.
- Have both interface owners resolve the final issue list.
Retrieval and spaced review
Answer closed-notes today, then again after 1, 3, 7, and 30 days.
Define Interface.
A shared boundary and the controlled exchanges across it.
What role does Interface control play here?
The process and record used to establish, review, change, and verify interface definitions.
What must a reviewer be able to reconstruct?
A supplier on either side can implement and verify its half without private assumptions about the other side.
End-of-lesson summary
An interface definition is a bilateral agreement about what crosses a boundary, in what units, direction, range, coordinate frame, timing, quality, and responsibility. Interface verification must test both sides together.
Student notes
For every interface value, write quantity, unit, reference frame or basis, range, state, source, and owner.
Recommended readings
Instructor notes
Give each student half an interface specification with deliberate semantic mismatches, then let pairs integrate.
2.4
Verification, validation, technical reviews, and decisions
Why this lesson matters
Verification and validation answer different questions. Confusing them lets a product conform to the wrong need or appear useful without meeting its specification.
Learning objectives
- Define and distinguish Verification and Validation.
- Apply the lesson method to the worked verification, validation, technical reviews, and decisions case.
- Evaluate evidence, uncertainty, and AI-assisted output before making a claim.
Readiness check
Before continuing, explain what decision this topic supports and name one upstream source that must be controlled.
Check your response
A sound answer names a specific engineering decision, its configuration, and a controlled requirement, model, dataset, interface, or standard that constrains the work.
Core idea
Verification asks whether specified requirements were satisfied by the realized system. Validation asks whether the realized system fulfills stakeholder needs in its intended environment. Reviews examine readiness and risk; they do not create evidence merely by occurring.
Key concepts
| Verification | Objective confirmation that specified requirements have been fulfilled. |
|---|
| Validation | Confirmation that the system fulfills stakeholder needs for intended use. |
|---|
| Technical review | A structured examination of maturity, evidence, risks, decisions, and readiness for a stated gate. |
|---|
| Decision criterion | A predeclared rule or threshold used to compare alternatives or determine readiness. |
|---|
Step-by-step explanation
- Map each approved requirement to a verification method and success criterion before testing.
- Design validation scenarios from stakeholder use, including representative environments and users.
- Collect evidence at the responsible product level, not only at convenient component levels.
- Prepare reviews around entry criteria, unresolved risk, evidence maturity, and explicit decisions.
- Record conditions, dissent, actions, owners, and due dates so a gate is not mistaken for unconditional approval.
Worked example
A powered lifting actuator passes bench tests for 5 kN load, speed, and current. Operators then find that the manual release cannot be reached when the actuator is installed in the machine.
- 1
Classify the 5 kN, speed, and current tests as verification evidence against specified performance requirements.
- 2
Classify installed emergency release as a validation failure if stakeholder use and access were not adequately represented.
- 3
Trace the failure to missing or weak accessibility requirements and an incomplete operational scenario.
- 4
Do not relabel the bench test as invalid. It answered its verification question but not the broader validation question.
Result. The actuator can be verified against its bench requirements and still fail validation in intended use. The corrective action changes requirements, architecture, and test scenarios.
Independent check. Each evidence item names the exact requirement or stakeholder need, configuration, environment, method, result, and disposition.
Common misconceptions
| Misconception | Correction |
|---|
| Passing verification proves the right product was built | It proves specified requirements were met. Validation is needed to judge intended stakeholder use. |
|---|
| A tool output closes the question | A result remains a candidate until its inputs, method, configuration, uncertainty, and relevance have been checked. |
|---|
Diagnostic questions
Can one test support both V and V?
Yes, if it is designed and interpreted against both specified requirements and representative use needs, with each claim explicit.
What would make this work reproducible?
Controlled inputs, method or code, versions, assumptions, outputs, and a stated interpretation tied to the decision.
Practice ladder
BasicClassify eight activities as verification, validation, both, or neither.
IntermediateWrite separate verification and validation plans for a portable hydraulic jack.
AdvancedDesign review entry and exit criteria for releasing the actuator redesign after the accessibility failure.
AI-assisted engineering task
Ask AI to classify a mixed evidence list as verification, validation, review input, or unsupported claim, with rationale and target requirement or need.
How to prove the AI output yourself
- Check definitions before accepting labels.
- Verify each evidence item against the stated target and configuration.
- Have the responsible engineer approve final gate disposition.
Retrieval and spaced review
Answer closed-notes today, then again after 1, 3, 7, and 30 days.
Define Verification.
Objective confirmation that specified requirements have been fulfilled.
What role does Validation play here?
Confirmation that the system fulfills stakeholder needs for intended use.
What must a reviewer be able to reconstruct?
Each evidence item names the exact requirement or stakeholder need, configuration, environment, method, result, and disposition.
End-of-lesson summary
Verification asks whether specified requirements were satisfied by the realized system. Validation asks whether the realized system fulfills stakeholder needs in its intended environment. Reviews examine readiness and risk; they do not create evidence merely by occurring.
Student notes
Write V&V as two columns: requirement satisfied, stakeholder need fulfilled. Never use the words interchangeably.
Recommended readings
Instructor notes
Use product-level examples. Students already know equation checking; the learning objective is lifecycle verification and stakeholder validation.
LAB 2
Lab 2: Build and interrogate a traceability matrix
Lab objective
Represent need-to-requirement, requirement-to-function, and requirement-to-verification links, then detect missing coverage.
Engineering context
The cooling-rig architecture from Lesson 2.2 needs a traceability review before concept selection.
Input data
- Two stakeholder needs
- Four system requirements
- Four verification activities
- Typed trace links
Step-by-step task
- Create node dictionaries and typed links.
- Construct a requirement-by-verification matrix.
- Report requirements with no planned verification and tests with no target requirement.
- Trace one requirement upstream to a need and downstream to evidence.
Python code
needs = {"NEED-01": "Keep the cell fixture safe", "NEED-02": "Run repeatable tests"}
requirements = {
"REQ-01": "Fixture temperature <= 45 degC",
"REQ-02": "Remove 500 W for 120 s",
"REQ-03": "Temperature sample interval <= 1 s",
"REQ-04": "Leakage shall be zero during the proof test",
}
verifications = {"VER-01": "thermal transient test", "VER-02": "calorimetric test",
"VER-03": "data-rate inspection", "VER-04": "pressure proof"}
links = [
("NEED-01", "derives", "REQ-01"), ("NEED-01", "derives", "REQ-04"),
("NEED-02", "derives", "REQ-02"), ("NEED-02", "derives", "REQ-03"),
("VER-01", "verifies", "REQ-01"), ("VER-02", "verifies", "REQ-02"),
("VER-03", "verifies", "REQ-03"), ("VER-04", "verifies", "REQ-04"),
]
matrix = {rid: {vid: 0 for vid in verifications} for rid in requirements}
for source, relation, target in links:
if relation == "verifies":
matrix[target][source] = 1
for rid, row in matrix.items():
print(rid, row, "covered=" + str(any(row.values())))
orphan_tests = [vid for vid in verifications
if not any(source == vid and relation == "verifies"
for source, relation, target in links)]
print("Orphan tests:", orphan_tests)
Explanation of code
Step 1 create node dictionaries and typed links. Step 2 construct a requirement-by-verification matrix. Step 3 report requirements with no planned verification and tests with no target requirement. Step 4 trace one requirement upstream to a need and downstream to evidence.
Expected output
Four covered requirements and an empty orphan-test list.
Interpretation
Coverage is necessary but not sufficient. A wrong or weak link can produce a full matrix, so link rationale and review still matter.
Common errors
- Treating every relationship as verifies
- Counting a link without checking semantic relevance
- Losing direction between source and target
Extension tasks
- Add functions and physical elements
- Export the matrix to CSV
- Detect needs with no derived requirement
Reflection questions
- Can 100% matrix coverage still be poor traceability?
- Which link types should be allowed?
- Who approves a trace link?