Digital Engineering Foundations · Module 3 of 8
Requirements, Functions and Architecture
Give the evidence chain something to anchor to: verifiable requirements, a lightweight functional and physical architecture with interfaces, and typed traceability that shows coverage and reveals change impact.
Readiness check
Building on Modules 1–2. Tick only what you can do closed-notes.
- Identify a stakeholder need and distinguish it from a design solution.
- Write a measurable value with units.
- Define a system boundary and name what a component does.
- Identify a physical or information interface.
- Read a matrix and name the source and target of a relationship.
The core idea
A requirement is an obligation that can be verified; architecture gives that obligation a place to land; traceability records the typed relationships between them and the evidence.
Digital engineering depends on verifiable requirements because they anchor the evidence chain. Architecture stays lightweight here: it organizes what the subsystem must do and which parts or interfaces carry those responsibilities, so traceability can sit between requirements and specialist artifacts like CAD, analysis and test. A typed trace link declares its meaning, satisfies, verifies, analyses, derives from, and coverage checks that requirements have suitable evidence and that evidence answers a real need.
The skills, taught in order
Four steps: write requirements you can check, organize functions and interfaces, allocate them to an architecture, then trace everything with typed links and check coverage.
3.1 From needs to verifiable requirements
A requirement states what must be true, under which conditions, and how success is checked. Start from the stakeholder need and system boundary, use measurable criteria with units, and assign a verification method before building evidence. "The bracket shall be strong" becomes "the bracket shall support a 600 N vertical load at the mounting point with permanent deformation below 0.2 mm." Avoid hiding a design choice inside a requirement unless a real interface demands it.
3.2 Functions, components and interfaces
Architecture is the organized description of what the subsystem must do and what parts or interfaces carry those responsibilities. List functions before parts, transfer load, locate payload, attach to frame, preserve clearance, then map components to functions. Treat interfaces as controlled engineering agreements: the mounting face, fastener pattern, load direction and allowable envelope form an interface that must be controlled, because interfaces are where mismatches between teams, parts and tools appear.
3.3 Logical and physical architecture, and allocations
A logical architecture describes responsibilities independent of the chosen hardware (the load path, the attachment function); a physical architecture assigns those responsibilities to real parts and features (the arm, the base plate, the two M6 fasteners). An allocation is the recorded decision that a function is carried by a component or interface. Keeping the two views distinct lets a design change swap the physical part without losing the logical intent, and it gives traceability an explicit place to attach.
3.4 Traceability and coverage
Traceability is the controlled record of relationships among artifacts, using typed links (satisfies, verifies, analyses, validates, supports, derives from, uses) rather than vague associations. Coverage checks whether requirements have enough downstream evidence and whether each evidence item answers a real need. Use the links to find orphan requirements (no evidence) and orphan evidence (supports nothing), and to identify review candidates after a change. Traceability shows relationships; it does not make weak evidence strong.
Lab connection. Labs 2–3 build the requirements register and traceability matrix for the bracket. Verification methods and their evidence are the subject of Module 5.
Worked example 1: turning a wish into a verifiable requirement
A stakeholder says "the bracket should be lightweight and durable." Convert this into verifiable requirements with methods, without locking the design prematurely.
- ProblemRewrite a vague wish as verifiable requirements and assign a verification method to each.
- Given / findWish: "lightweight and durable." Context: mounts a 5 kg payload, indoor use, target cost class. Find measurable requirements + methods.
- ModelEach requirement needs a condition, a measurable criterion with units, and a feasible verification method (inspection, analysis, demonstration or test).
- Solve"Lightweight" → "mass ≤ 300 g" (verify by inspection: weigh the part). "Durable" is ambiguous, so split it: "shall survive 10,000 load cycles at 600 N without visible crack" (verify by test) and "peak stress ≤ 0.6 × yield under the 600 N static case" (verify by analysis). Keep "two M6 fasteners on a 50 mm pitch" as an interface requirement, since the mating frame is fixed.
- CheckEach requirement is checkable, none hides a design solution except the justified interface constraint, and every requirement names a method before evidence is built.
- Conclusion"Lightweight and durable" is not a requirement; it is a need. Splitting it into measurable, method-tagged requirements is what makes the later evidence chain meaningful.
Worked example 2: reading coverage from a traceability matrix
Given a small requirements-to-evidence matrix, find the orphan requirement, the orphan evidence, and the review candidates after a load change.
- ProblemJudge coverage and change impact from typed links, not from link count.
- Given / findLinks: REQ-LOAD verified by TEST-LOAD-01, analysed by ANA-STRESS-01; REQ-MASS has no downstream link; ANA-THERMAL-01 supports no requirement; DEC-B0 uses stress result and mass estimate. A load change is proposed.
- ModelCoverage = every requirement has suitable evidence; orphans = requirements with none or evidence linked to none. Change impact = downstream candidates of the changed node, decided by an engineer.
- SolveOrphan requirement: REQ-MASS (no evidence) → needs a verification link. Orphan evidence: ANA-THERMAL-01 (supports nothing) → either link it to a real requirement or remove it from the evidence set. Load change candidates: ANA-STRESS-01 and TEST-LOAD-01 (both tied to REQ-LOAD), and DEC-B0 (uses the stress result) → all flagged for review.
- Check"More links are always better" is false, the thermal analysis is noise until tied to a need. Traceability found candidates; it did not declare anything invalid.
- ConclusionTyped links plus coverage checks turn a matrix into a working change-impact and completeness tool.
Misconceptions and diagnostics
| Mistake | Diagnostic question | Correction |
|---|---|---|
| Every wish is a requirement | "Who is obligated, and how will it be verified?" | Needs must be refined into measurable, method-tagged requirements. |
| A requirement should include the solution | "Could another design satisfy the same need?" | Avoid premature solution lock unless a real interface demands it. |
| A parts list is an architecture | "Does it show functions and interfaces?" | Architecture adds functions, responsibilities and controlled interfaces. |
| More links are always better | "Does each link have a clear type and purpose?" | Noise makes traceability harder to inspect; use typed, purposeful links. |
| Traceability proves correctness | "Is the linked evidence itself credible?" | Traceability shows relationships; it does not make weak evidence strong. |
Practice ladder
Rewrite three weak requirements from the lab dataset, add a verification method to each, and mark one as interface-controlled. Write one requirement you would reject and explain why.
Show answer
Each rewrite has a condition, a measurable criterion with units, and a method. The interface requirement cites the fixed mating part. A rejectable requirement is one that is unverifiable ("shall be robust") or that embeds an unjustified solution.
Draw a boundary for the final-project subsystem, list four functions, map functions to components or features, and write two interface statements.
Show answer
Functions come before parts (transfer load, locate payload, attach, preserve clearance). Each maps to a feature. Interface statements fix the mounting face and fastener pattern, load direction, and envelope, the controlled agreements.
Build a traceability matrix with the lab data, find one orphan requirement and one orphan evidence item, and write the review candidates after a load change.
Show answer
Good work uses typed links, names the orphan requirement (no evidence) and orphan evidence (no requirement), and lists the downstream candidates of the changed requirement as review items, without declaring them invalid.
For one real subsystem of your own, write 6–10 verifiable requirements, a lightweight architecture with allocations, and a traceability matrix, then report coverage.
What good work looks like
Measurable requirements with methods; a logical-to-physical allocation; typed links; and a coverage statement naming any orphans. This package feeds the capstone in Module 8.
Working with AI, and proving it yourself
Use AI as an examiner, not a solver
Portfolio task
Let AI generate candidate trace links, then review each for false positives and false negatives against your requirements and evidence, recording the accepted, edited and rejected links.
Retrieval and spaced review
Closed notes. Answer out loud, then reveal.
1. What makes a requirement verifiable?
A clear condition, a measurable criterion, and a feasible verification method.
2. Why control interfaces?
Interfaces are where mismatches between teams, parts and tools appear; they are controlled agreements.
3. What is the difference between logical and physical architecture, and what is an allocation?
Logical describes responsibilities independent of hardware; physical assigns them to real parts; an allocation is the recorded decision linking a function to a component or interface.
4. What is a typed trace link, and what is coverage?
A relationship with declared meaning between identified artifacts; coverage is the extent to which requirements have suitable linked evidence.
5. Does traceability prove correctness?
No, it shows relationships. The linked evidence must itself be credible.