3.1
Requirement quality through a mechanical bracket example
Why this lesson matters
Ambiguous requirements cannot be objectively verified and invite each discipline to solve a different problem.
Learning objectives
- Define and distinguish Requirement and Rationale.
- Apply the lesson method to the worked requirement quality through a mechanical bracket example 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 useful requirement identifies the subject, required outcome, measurable condition, operating context, and applicable constraints. It is necessary, feasible, singular enough to verify, and traceable to a legitimate source.
Key concepts
| Requirement | A verifiable statement of an obligated capability, performance, interface, quality, or constraint. |
|---|
| Rationale | Why the requirement exists and what decision or need it protects. |
|---|
| Fit criterion | The objective rule and conditions used to judge compliance. |
|---|
| Requirement attribute | Metadata such as identifier, owner, source, priority, status, revision, and verification method. |
|---|
Step-by-step explanation
- Identify the subject and the stakeholder or parent source.
- Replace subjective words with measurable quantities only after confirming intent.
- State load case, environment, configuration, reference frame, and duration where they affect meaning.
- Separate combined obligations if they require different evidence or owners.
- Perform necessity, feasibility, unambiguity, verifiability, and traceability reviews.
Worked example
Weak statement: 'The bracket should be lightweight, strong, and easy to manufacture.' The controlled need is to support an avionics box during a specified limit-load case and fit a milling cell.
- 1
Do not choose arbitrary numbers. Obtain allocated mass, load, displacement, material, and process constraints from the system trade study.
- 2
Write BRK-001: 'The bracket mass shall not exceed 0.50 kg in the released manufacturing configuration.'
- 3
Write BRK-002: 'Under the LC-07 limit load of 2.0 kN applied at interface I-2, the bracket shall have positive margin against the approved yield allowable.'
- 4
Write BRK-003: 'The bracket shall be producible with the approved 3-axis milling process without undercut features, verified by manufacturing review.'
Result. One vague preference becomes three controlled obligations with distinct evidence. Numeric limits remain traceable to allocation and rationale.
Independent check. An independent team can design a verification method without asking what lightweight, strong, or easy means.
Common misconceptions
| Misconception | Correction |
|---|
| Every requirement needs shall | Grammar helps, but quality depends on legitimate intent, measurable semantics, context, feasibility, and traceability. |
|---|
| A tool output closes the question | A result remains a candidate until its inputs, method, configuration, uncertainty, and relevance have been checked. |
|---|
Diagnostic questions
May an engineer invent a missing threshold?
No. Flag the missing allocation and return it to the responsible decision owner.
What would make this work reproducible?
Controlled inputs, method or code, versions, assumptions, outputs, and a stated interpretation tied to the decision.
Practice ladder
BasicIdentify five defects in 'The pump shall operate efficiently in all conditions.'
IntermediateRewrite the pump statement after being given flow, pressure, temperature, and efficiency allocations.
AdvancedReview whether positive margin is sufficiently precise, including allowable basis, failure modes, uncertainty, and load combinations.
AI-assisted engineering task
Ask AI to flag ambiguity, unverifiable language, compound clauses, missing units, and missing context. Require it to suggest questions before rewrites.
How to prove the AI output yourself
- Confirm every proposed threshold against an authoritative source.
- Have the requirement owner review meaning and feasibility.
- Draft the verification method and check that it can produce an objective result.
Retrieval and spaced review
Answer closed-notes today, then again after 1, 3, 7, and 30 days.
Define Requirement.
A verifiable statement of an obligated capability, performance, interface, quality, or constraint.
What role does Rationale play here?
Why the requirement exists and what decision or need it protects.
What must a reviewer be able to reconstruct?
An independent team can design a verification method without asking what lightweight, strong, or easy means.
End-of-lesson summary
A useful requirement identifies the subject, required outcome, measurable condition, operating context, and applicable constraints. It is necessary, feasible, singular enough to verify, and traceable to a legitimate source.
Student notes
Keep the original statement, defect diagnosis, clarification questions, approved rewrite, rationale, and planned verification together.
Recommended readings
Instructor notes
Grade question quality before rewrite quality. Students should learn not to fabricate precision when stakeholder intent is missing.
3.2
Decomposition, allocation, and typed trace links
Why this lesson matters
Decomposition can quietly change meaning. Typed links and conservation checks help preserve intent across system, subsystem, and component levels.
Learning objectives
- Define and distinguish Decomposition and Allocation.
- Apply the lesson method to the worked decomposition, allocation, and typed trace links 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 child requirement must contribute to its parent without omitting obligations or creating contradictions. Trace links should state semantics such as derives, satisfies, verifies, refines, or informs, not merely 'related to'.
Key concepts
| Decomposition | Breaking a higher-level obligation into lower-level obligations whose combined satisfaction supports the parent. |
|---|
| Allocation | Assigning responsibility for an obligation or budget to one or more elements. |
|---|
| Typed link | A directional relationship with declared semantics between two identified artifacts. |
|---|
| Budget | A conserved or managed quantity such as mass, power, pressure loss, error, or reliability apportioned across elements. |
|---|
Step-by-step explanation
- State the parent requirement and its acceptance conditions.
- Choose a decomposition logic: function, physical element, operating mode, or managed budget.
- Write child requirements with explicit responsibility and interface conditions.
- Check completeness, overlap, contradiction, and budget conservation.
- Create directional links with rationale and owner approval.
Worked example
A cooling assembly mass limit is 4.0 kg. The current allocations are radiator 2.1 kg, fan 0.8 kg, pump 0.7 kg, hoses 0.5 kg, and coolant 0.3 kg.
- 1
Sum allocations: 2.1 + 0.8 + 0.7 + 0.5 + 0.3 = 4.4 kg.
- 2
The allocation violates the parent by 0.4 kg before uncertainty or margin.
- 3
Do not mark each child valid in isolation. Rebalance the budget or change the parent through an approved trade.
- 4
Link each child as derived from the mass parent and record the allocation rationale and current estimate.
Result. A traceable decomposition exposes an infeasible architecture early. Link completeness without budget consistency would have hidden the defect.
Independent check. Children jointly cover the parent scope and numerical budgets close with declared margin and uncertainty.
Common misconceptions
| Misconception | Correction |
|---|
| A parent is satisfied when every child passes | Only if the decomposition is complete, consistent, and semantically sufficient for the parent. |
|---|
| A tool output closes the question | A result remains a candidate until its inputs, method, configuration, uncertainty, and relevance have been checked. |
|---|
Diagnostic questions
What is wrong with 'related to'?
It does not tell a reviewer whether one artifact derives, satisfies, verifies, refines, or merely informs another.
What would make this work reproducible?
Controlled inputs, method or code, versions, assumptions, outputs, and a stated interpretation tied to the decision.
Practice ladder
BasicDecompose a 100 W power budget across four elements and check the sum.
IntermediateChoose typed links among need, requirement, function, component, model, test, and decision.
AdvancedHandle a requirement satisfied jointly by two redundant pumps without double-counting capability.
AI-assisted engineering task
Ask AI to propose link types and identify potential budget gaps, with exact artifact IDs and arithmetic shown.
How to prove the AI output yourself
- Recompute all budgets independently.
- Check link semantics against the controlled metamodel.
- Have parent and child owners approve the decomposition.
Retrieval and spaced review
Answer closed-notes today, then again after 1, 3, 7, and 30 days.
Define Decomposition.
Breaking a higher-level obligation into lower-level obligations whose combined satisfaction supports the parent.
What role does Allocation play here?
Assigning responsibility for an obligation or budget to one or more elements.
What must a reviewer be able to reconstruct?
Children jointly cover the parent scope and numerical budgets close with declared margin and uncertainty.
End-of-lesson summary
A child requirement must contribute to its parent without omitting obligations or creating contradictions. Trace links should state semantics such as derives, satisfies, verifies, refines, or informs, not merely 'related to'.
Student notes
For every child, write: parent, decomposition logic, allocated value, margin, owner, and why this child is sufficient.
Recommended readings
Instructor notes
Include one numerically impossible allocation. Traceability must reveal engineering inconsistency, not only missing rows.
3.3
Evidence chains from requirement to decision
Why this lesson matters
A compliance claim is only as strong as the weakest unexamined link between requirement, configuration, method, result, and decision.
Learning objectives
- Define and distinguish Evidence chain and Compliance assessment.
- Apply the lesson method to the worked evidence chains from requirement to decision 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 evidence chain connects a controlled requirement to the model or procedure used, input configuration, execution record, result, review, compliance assessment, and decision. Each link has direction, semantics, status, and validity conditions.
Key concepts
| Evidence chain | A traversable set of typed links from claim or requirement through supporting evidence to decision. |
|---|
| Compliance assessment | The documented comparison of evidence with an acceptance criterion. |
|---|
| Validity condition | A condition under which a link or result remains applicable. |
|---|
| Evidence gap | A missing, invalid, obsolete, or insufficient link that prevents a supported claim. |
|---|
Step-by-step explanation
- Start at the decision claim and traverse backward to acceptance criteria and authoritative requirement.
- Follow the executed result to its procedure or model, inputs, configuration, and quality checks.
- Confirm review status and independence appropriate to consequence.
- Record uncertainty and validity conditions at the result and link level.
- Traverse forward from each changed input to identify affected results, claims, and decisions.
Worked example
Claim: bracket BRK-C meets BRK-002. Evidence chain: BRK-002 -> load case LC-07 -> CAD revision C -> FEA model M12 -> run R44 -> stress result 112 MPa -> allowable A6 at 240 MPa -> margin assessment CA9 -> release decision D3.
- 1
Verify identifiers and configuration at each node.
- 2
Check R44 load, boundary conditions, material, mesh evidence, solver status, and result extraction.
- 3
Check allowable provenance, temperature, failure mode, and uncertainty treatment.
- 4
Compute nominal factor 240/112 = 2.14, then report that a nominal ratio alone does not close the claim without the approved margin method and uncertainties.
Result. The chain makes the compliance logic inspectable and exposes exactly where a revision, invalid run, or allowable change would break it.
Independent check. A reviewer can reproduce the compliance assessment and identify every decision affected by any upstream revision.
Common misconceptions
| Misconception | Correction |
|---|
| A passed test automatically verifies every linked requirement | The test supports only requirements whose conditions, quantities, configuration, and acceptance criteria it actually covers. |
|---|
| A tool output closes the question | A result remains a candidate until its inputs, method, configuration, uncertainty, and relevance have been checked. |
|---|
Diagnostic questions
Where should uncertainty appear?
At inputs, model and test results, comparisons, and the final decision interpretation.
What would make this work reproducible?
Controlled inputs, method or code, versions, assumptions, outputs, and a stated interpretation tied to the decision.
Practice ladder
BasicOrder ten shuffled evidence artifacts into a defensible chain.
IntermediateMark validity conditions on each link in the bracket chain.
AdvancedAdd independent test evidence that challenges the simulation and document the resulting decision state.
AI-assisted engineering task
Ask AI to summarize an evidence chain and list missing nodes. Require it to output only existing identifiers plus explicit unknowns.
How to prove the AI output yourself
- Traverse every proposed link in the source system.
- Recalculate compliance from raw or controlled results.
- Check that the decision owner reviewed limitations and conflicting evidence.
Retrieval and spaced review
Answer closed-notes today, then again after 1, 3, 7, and 30 days.
Define Evidence chain.
A traversable set of typed links from claim or requirement through supporting evidence to decision.
What role does Compliance assessment play here?
The documented comparison of evidence with an acceptance criterion.
What must a reviewer be able to reconstruct?
A reviewer can reproduce the compliance assessment and identify every decision affected by any upstream revision.
End-of-lesson summary
An evidence chain connects a controlled requirement to the model or procedure used, input configuration, execution record, result, review, compliance assessment, and decision. Each link has direction, semantics, status, and validity conditions.
Student notes
Draw the chain left to right and write the validity condition below every arrow.
Recommended readings
Instructor notes
Use a chain with one plausible but wrong configuration link. Students should inspect identity before calculating margin.
3.4
Traceability matrices, coverage, and failure modes
Why this lesson matters
A full matrix can create false assurance when links are stale, semantically weak, or generated from word overlap.
Learning objectives
- Define and distinguish Traceability matrix and Coverage.
- Apply the lesson method to the worked traceability matrices, coverage, and failure modes 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
Traceability measures coverage and supports navigation, impact analysis, and accountability. It does not prove requirement quality, evidence adequacy, or system correctness. Matrices are views of a richer relationship model.
Key concepts
| Traceability matrix | A tabular view showing relationships between two controlled sets of artifacts. |
|---|
| Coverage | The proportion or set of source artifacts with required valid target links. |
|---|
| Orphan | An artifact that should participate in traceability but has no valid required link. |
|---|
| Suspect link | A relationship whose validity may have changed because an endpoint or condition changed. |
|---|
Step-by-step explanation
- Define which link types and endpoint statuses count for the coverage question.
- Generate the matrix from controlled relationships rather than maintaining a disconnected spreadsheet copy.
- Inspect orphan requirements, orphan tests, many-to-many clusters, and unexpectedly broad evidence reuse.
- Mark links suspect after endpoint changes and require review before restoring validity.
- Sample links for semantic quality because a percentage cannot reveal a wrong relationship.
Worked example
A project reports 100% requirement-to-test coverage. One generic environmental test is linked to 42 unrelated requirements, including mass, maintainability, and software logging.
- 1
Recompute coverage using only approved 'verifies' links with matching quantity and condition.
- 2
Sample the 42-link cluster and inspect the test procedure and acceptance criteria.
- 3
Remove links that merely provide context or no evidence for the requirement.
- 4
Report corrected coverage with an evidence-gap list and responsible owners.
Result. Numerical coverage falls, but decision quality improves because the matrix now distinguishes evidence from association.
Independent check. Every counted link has direction, type, rationale, valid endpoints, applicable configuration, and reviewer disposition.
Common misconceptions
| Misconception | Correction |
|---|
| 100% trace coverage means compliance | Coverage says expected relationships exist under a rule; it does not establish evidence adequacy or passing results. |
|---|
| A tool output closes the question | A result remains a candidate until its inputs, method, configuration, uncertainty, and relevance have been checked. |
|---|
Diagnostic questions
When is a link suspect?
When an endpoint, configuration, semantic condition, or governing requirement changes.
What would make this work reproducible?
Controlled inputs, method or code, versions, assumptions, outputs, and a stated interpretation tied to the decision.
Practice ladder
BasicFind orphan rows and columns in a 5 by 5 trace matrix.
IntermediateDefine a coverage rule that excludes draft tests and suspect links.
AdvancedDesign metrics that discourage link inflation while revealing high-risk gaps.
AI-assisted engineering task
Ask AI to rank candidate trace links for human review. Use similarity only for prioritization, never automatic approval.
How to prove the AI output yourself
- Inspect source and target meaning, not only shared terms.
- Check link type and configuration.
- Measure false positives and missed links on a reviewed sample.
Retrieval and spaced review
Answer closed-notes today, then again after 1, 3, 7, and 30 days.
Define Traceability matrix.
A tabular view showing relationships between two controlled sets of artifacts.
What role does Coverage play here?
The proportion or set of source artifacts with required valid target links.
What must a reviewer be able to reconstruct?
Every counted link has direction, type, rationale, valid endpoints, applicable configuration, and reviewer disposition.
End-of-lesson summary
Traceability measures coverage and supports navigation, impact analysis, and accountability. It does not prove requirement quality, evidence adequacy, or system correctness. Matrices are views of a richer relationship model.
Student notes
Record coverage rule, denominator, allowed statuses, link types, exceptions, and review date beside every metric.
Recommended readings
Instructor notes
Show both an empty matrix and a falsely full matrix. Students should learn that semantic quality sits between the two.
LAB 3
Lab 3: Link requirements, models, simulations, tests, and decisions
Lab objective
Build a typed evidence graph and query complete and incomplete evidence chains.
Engineering context
The bracket evidence from Lesson 3.3 is represented as nodes and directional links.
Input data
- Node records with type and revision
- Typed links
- A target release decision
Step-by-step task
- Create the graph
- Traverse upstream from the decision
- Detect missing required node types
- Mark downstream links suspect after a CAD change
Python code
nodes = {
"BRK-002": {"type": "requirement", "rev": "B"},
"CAD-C": {"type": "geometry", "rev": "C"},
"M12": {"type": "model", "rev": "4"},
"R44": {"type": "simulation", "rev": "1"},
"CA9": {"type": "assessment", "rev": "2"},
"D3": {"type": "decision", "rev": "1"},
}
links = [
("BRK-002", "constrains", "M12"), ("CAD-C", "configures", "M12"),
("M12", "produces", "R44"), ("R44", "supports", "CA9"),
("CA9", "informs", "D3"),
]
required_types = {"requirement", "geometry", "model", "simulation", "assessment", "decision", "test"}
present = {node["type"] for node in nodes.values()}
print("Missing evidence types:", sorted(required_types - present))
changed = "CAD-C"
frontier, affected = [changed], set()
while frontier:
current = frontier.pop()
for source, relation, target in links:
if source == current and target not in affected:
affected.add(target)
frontier.append(target)
print("Affected by CAD-C:", sorted(affected))
Explanation of code
Step 1 create the graph Step 2 traverse upstream from the decision Step 3 detect missing required node types Step 4 mark downstream links suspect after a CAD change
Expected output
The graph reports missing test evidence and identifies M12, R44, CA9, and D3 as potentially affected by CAD-C.
Interpretation
A graph narrows review scope but cannot decide whether the change is materially significant. Engineers review suspect links and validity conditions.
Common errors
- Assuming every reachable node is invalid
- Using untyped links
- Failing to store endpoint revision and link status
Extension tasks
- Add link rationale
- Export Graphviz DOT
- Implement cycle detection and allowed link-type rules
Reflection questions
- Why is a reachable node only suspect?
- What evidence type is missing?
- How would conflicting test evidence be represented?
PROJECT
Mini-project 1: Bracket requirements and evidence baseline
Deliverable
A controlled bracket requirement set, architecture boundary, traceability matrix, evidence-chain diagram, change rule, and two-page review memo.
Required checks
At least eight requirements, typed links, one numerical budget, one deliberate evidence gap, and a justified disposition without fabricated data.