EASA · Published 2020-01-07

System Engineering Requirements - Aircraft System Development Process - EASA Rotorcraft & VTOL 2019

privateReview: unreviewedConfidence: high
requirementsdecompositiontraceabilityverificationarp4754asystems-engineeringcoverageabstraction-levelsevaluation
Open on YouTube ↗

Summary

Overview

  • Speaker: Nick Kefalas, Sikorsky Aircraft / Lockheed Martin
  • Channel: EASA
  • Main topic: System engineering requirements in aircraft system development
  • Purpose: To educate engineering professionals on proper requirement definition, structuring, decomposition, and verification in aviation system design. Nick Kefalas discusses the critical role of system engineering requirements within the aircraft system development process, focusing on EASA and FAA standards (ARP4754A, ARP4761), requirements decomposition, writing guidelines, traceability, and verification methods for complex aircraft systems.

Topic Map

Introduction to Requirements

  • Explanation: Requirements are the starting point of any design, defining intended function, operational performance, and conditional behavior.
  • Key claims:
    • Requirements are the starting point of any design.
    • Must specify function and conditional behavior.
    • Must be written with verification in mind.
  • Examples:
    • Intended operational and system performance.
  • Terminology:
    • Intended Function
    • Conditional Behavior
    • Verifiability
  • Why it matters: Poorly written requirements lead to un-verifiable and non-compliant designs.

Types of System Requirements

  • Explanation: Categorization of requirements including customer, operational, performance, physical, maintenance, interfaces, and certification.
  • Key claims:
    • Requirements span customer needs, operations, performance, and physical constraints.
    • Certification and safety must be considered from the top of the process.
  • Examples:
    • Dimensional/volumetric physical requirements.
    • Power and signal interface budgets.
  • Terminology:
    • Customer Requirements
    • Operational Requirements
    • Performance Requirements
    • Physical Requirements
    • Derived Requirements
  • Why it matters: Proper categorization ensures all system attributes are accounted for during design.

Decomposition and Allocation

  • Explanation: Top-down decomposition of aircraft functions down to LRUs, circuit cards, and PLDs.
  • Key claims:
    • Decomposition must be top-down starting from aircraft functions and safety.
    • Every tier must have direct/allocated and derived requirements.
    • Design should flow from requirements, not constraints.
  • Examples:
    • Decomposing from Level 1 Aircraft Functions down to Level 6 PLD Design.
  • Terminology:
    • Decomposition
    • Allocation
    • Line Replaceable Unit (LRU)
    • Derived Requirements
  • Why it matters: Ensures traceability and consistency across all layers of system abstraction.

Writing Requirements Guidelines

  • Explanation: Best practices for writing clear, specific, verifiable requirements using standard templates.
  • Key claims:
    • Use standard templates to maintain consistency across teams.
    • Write in the positive sense rather than using 'shall not'.
    • Target the audience: engineers and technicians building the system.
  • Examples:
    • Standard form template including function name, description, trace links, inputs, and outputs.
  • Terminology:
    • Traceability
    • Positive Sense
    • Template
    • Identifier (POO)
  • Why it matters: Well-written requirements prevent ambiguity and design errors.

Verification in System Development

  • Explanation: Verification activities including inspection, analysis, simulation, and testing to assure compliance.
  • Key claims:
    • Verification must be performed to assure compliance to all system requirements.
    • Test at the lowest level possible before integrating upwards.
    • The sum of all testing must provide complete coverage.
  • Examples:
    • Inspection of engineering drawings, simulation models, and hardware testing.
  • Terminology:
    • Inspection
    • Analysis
    • Simulation
    • Testing
    • Coverage
  • Why it matters: Guarantees that the design performs its intended function safely and complies with regulations.

Key Points

Requirements are the starting point of design

  • Explanation: Design flows from requirements, and 99% of requirements in current systems are not verifiable due to generic wording.
  • Evidence: Observed industry practices in system design.
  • Practical implication: Write requirements with verification and testability explicitly in mind.

Safety analysis must start at the top

  • Explanation: ARP4754A and ARP4761 guidelines dictate that safety and failure analysis must drive requirements from the top down.
  • Evidence: Reference to ARP4754A and ARP4761 standards.
  • Practical implication: Do not treat safety as an afterthought or bottom-up activity.

Test at the lowest level possible

  • Explanation: Verification should be conducted at the most granular level (e.g., LRU, circuit card) rather than waiting for box-level ATPs.
  • Evidence: Common industry pitfall discussion.
  • Practical implication: Enables early detection of gaps and design flaws.

Frameworks, Models & Processes

Top-Down Decomposition Framework

  • How it works: Breaks down aircraft-level functions through architecture, LRU, circuit card, to PLD level.
  • Components:
    • Level 1: Aircraft Functions
    • Level 2: System Architecture
    • Level 3: LRU Design
    • Level 4: Assembly Design
    • Level 5: Circuit Card Design
    • Level 6: PLD Design
  • When to use: During system engineering and architecture definition phases.

Requirement Writing Template

  • How it works: Standardizes requirement attributes to ensure completeness and traceability.
  • Components:
    • Function Name
    • Description & Terminology
    • Trace Links
    • Justification for Derived Requirements
    • Outputs (Description, Units)
    • Inputs (Affecting Output, Power-on, Reset, Assert/Deassert, Invalid behavior)
  • When to use: When authoring system, hardware, or software requirements documents.

Examples & Case Studies

Engineers writing top-level requirements specifying exact resistor values (e.g., 100 ohms).

  • Illustrates: Premature detailing in requirement decomposition.
  • Lesson: Detailed design parameters like resistor values belong several tiers down, not at the top aircraft level.

Actionable Takeaways

  • Immediate:
    • Use standardized requirement templates across engineering teams.
    • Write requirements in the positive sense rather than negative constraints.
    • Ensure every requirement has a unique identifier.
  • Strategic:
    • Integrate safety and failure analysis (ARP4754A/ARP4761) at the top of the development lifecycle.
    • Maintain strict traceability between requirements, design, and verification.
    • Plan verification activities at the lowest possible level of abstraction.
  • Questions to investigate:
    • Are our current requirements verifiable?
    • Do we have bidirectional traceability established across all design tiers?
    • Is safety analysis driving our top-level requirements?

Claims Worth Verifying

  • 99% of all requirements we see right now in most of our system designs are not verifiable. (statistical/experiential)
  • ARP4754A and ARP4761 are the key elements to any design and should be the starting point. (regulatory/standard)

Notable Quotes

"Requirements are the starting point of any Design." (at 0:46) "The key to doing this is keeping all three balls in the air at the same time." (at 18:26)

Compressed Summary

  • Requirements define intended functions, operational performance, and conditional behaviors.
  • Decomposition must proceed top-down from aircraft functions to component levels.
  • Standard templates enhance requirement clarity, consistency, and traceability.
  • Verification must be planned at the lowest possible level of abstraction.
  • Keywords: requirements, decomposition, traceability, verification, arp4754a
  • Core insight: Rigorous top-down requirement definition, structured decomposition, and early verification planning are essential for compliant and safe aircraft system development.

Core insights

7
Failure Modemedium noveltymoderate evidence

The dominant failure mode in requirement specifications is verifiability, not completeness: the speaker claims roughly 99% of requirements in current system designs are not verifiable, implying that specifications are routinely written without testability as a gate.

Why it matters

If the same ratio holds for agent task specifications, capability descriptions, or tool contracts, then most 'requirements' wired into agent harnesses cannot be objectively checked, so evaluation collapses into subjective judgment. Treating verifiability as a hard admission gate at authoring time is a cheap upstream control that replaces expensive downstream debugging.

Generalization

Any specification consumed by an automated system (agent task descriptions, tool contracts, policy configs, eval rubrics) should be rejected at authoring time unless a concrete verification method exists; unverifiable specs are latent defects that surface only as silent non-compliance.

99% of all requirements we see right now in most of our system designs are not verifiable
Open source video
Must be written with verification in mind
Open source video
Architecturemedium noveltystrong evidence

Decomposition is defined as a fixed multi-tier ladder — Level 1 Aircraft Functions, Level 2 System Architecture, Level 3 LRU Design, Level 4 Assembly Design, Level 5 Circuit Card Design, Level 6 PLD Design — where every tier must carry both allocated (direct) and derived requirements, with derived requirements explicitly justified.

Why it matters

This gives a concrete model for how many abstraction layers an agentic system needs and what belongs at each layer: outcomes allocated from above, plus locally-derived behaviors that must be justified and traced rather than allowed to appear implicitly. It turns traceability from a documentation chore into a structural property of the layer stack.

Generalization

Layered agent or tool architectures should enforce a fixed tier count with two requirement classes per tier (inherited/allocated and derived/emergent), because emergent behaviors that lack provenance are exactly the ones that cannot be audited or regressed.

Decomposition must be top-down starting from aircraft functions and safety
Open source video
Every tier must have direct/allocated and derived requirements
Open source video
Level 1: Aircraft Functions
Open source video
Level 6: PLD Design
Open source video
Practicemedium noveltymoderate evidence

Verification should be pushed to the lowest possible level of abstraction rather than deferred to box-level acceptance tests, and the aggregate of all tests is expected to sum to complete coverage.

Why it matters

Pushing verification downshortens the feedback loop and localizes failures, but it makes correctness a composition property: coverage must be argued additively across tiers, which is precisely where agent eval suites break down. It reframes eval design as a coverage-partition problem, not a benchmark-selection problem.

Generalization

Agent systems should be verified at the smallest independently testable unit (prompt template, tool call, memory write, retrieval step) with an explicit argument that the union of unit-level checks covers the end-to-end behavior.

Test at the lowest level possible before integrating upwards
Open source video
The sum of all testing must provide complete coverage
Open source video
Enables early detection of gaps and design flaws
Open source video
Failure Modemedium noveltymoderate evidence

Over-specification at the wrong abstraction tier is called out as a concrete anti-pattern: engineers writing top-level, aircraft-level requirements that pin exact design parameters such as a 100-ohm resistor value.

Why it matters

Pinning implementation constants in a high-level orchestration or system prompt destroys the flexibility of the tiers below and couples top-level intent to volatile implementation detail. The same failure appears when an orchestrator prompt hard-codes a model name, token budget, or tool argument that belongs in the leaf-level component.

Generalization

Each abstraction tier should specify only what its consumers need to reason about; leaking leaf-level constants upward converts a stable interface into a brittle constraint and makes lower tiers unswappable.

Detailed design parameters like resistor values belong several tiers down, not at the top aircraft level
Open source video
Design should flow from requirements, not constraints
Open source video
Mechanismhigh noveltystrong evidence

The requirement template mandates enumerating conditional and abnormal behavior explicitly: inputs must cover 'Affecting Output, Power-on, Reset, Assert/Deassert, Invalid behavior', plus output units and justification for derived requirements.

Why it matters

This is a concrete completeness checklist for interface contracts, forcing authors to specify startup, reset, signal edge, and invalid-input semantics rather than only the happy path. Applied to tool and agent interfaces, it directly targets the failure class where a component behaves acceptably on nominal input and undefined otherwise.

Generalization

Any tool/agent interface spec should enumerate, as first-class fields, initialization, reset, edge-triggered transitions, and invalid-input behavior — not just the nominal mapping from input to output.

Inputs (Affecting Output, Power-on, Reset, Assert/Deassert, Invalid behavior)
Open source video
Justification for Derived Requirements
Open source video
Outputs (Description, Units)
Open source video
Tradeoffmedium noveltymoderate evidence

Requirements should be written in the positive sense rather than as negative constraints ('shall not'), and standardized templates should be used to keep consistency across teams.

Why it matters

Positive assertions are directly observable and testable; negative constraints define an unbounded complement (all the ways something must not happen), which is why they are hard to verify. Standardizing templates trades authoring freedom for cross-team comparability of specs and evals.

Generalization

Favor observable positive assertions in eval criteria and agent instructions; express prohibitions only where an equivalent positive, checkable condition can be derived, and standardize the spec format so specs from different teams are mechanically comparable.

Write in the positive sense rather than using 'shall not'
Open source video
Use standard templates to maintain consistency across teams
Open source video
Mental Modelmedium noveltymoderate evidence

Safety and failure analysis is asserted to be a top-down driver of requirements — ARP4754A and ARP4761 are framed as the starting point of the design process, not a downstream validation activity.

Why it matters

If safety derives requirements from the top rather than being verified afterward, then hazard analysis must shape the architecture and interface definitions themselves. An agent-safety program structured the same way would derive constraints before component design, rather than bolting guardrails onto a finished pipeline.

Generalization

Safety and failure analysis should be an input to architecture selection and interface definition, producing derived requirements at every tier, instead of a post-hoc compliance check on an already-built system.

safety and failure analysis must drive requirements from the top down
Open source video
Do not treat safety as an afterthought or bottom-up activity
Open source video

Deep dives

5

Verifiability as an Admission Gate for Agent Specifications

Research question

What concrete authoring-time linting and admission criteria can raise the fraction of verifiable requirements in agent task specs, tool contracts, and eval rubrics above the claimed ~1% baseline?

Why

If most specifications cannot be objectively checked, agent evaluation collapses into subjective judgment; gating unverifiable specs at authoring time replaces expensive downstream debugging with cheap upstream control.

Must be written with verification in mind
Open source video
Requirements are the starting point of any design
Open source video
Source video

Fixed Tier Ladder for Agentic Architecture

Research question

Does enforcing a fixed multi-tier decomposition with allocated and derived requirements at each tier improve traceability and reduce brittle interfaces in agent systems?

Why

It provides a concrete criterion for how many abstraction levels an agentic system needs and what belongs at each layer; emergent behaviors without provenance become auditable gaps rather than silent drift.

Decomposition must be top-down starting from aircraft functions and safety
Open source video
Every tier must have direct/allocated and derived requirements
Open source video
Decomposing from Level 1 Aircraft Functions down to Level 6 PLD Design
Open source video
Source video

Coverage Composition from Lowest-Level Verification

Research question

Can unit-level verification at each abstraction tier be aggregated into complete end-to-end coverage in agent pipelines, and how are integration-boundary gaps accounted for?

Why

It reframes eval design as a coverage-partition problem rather than a benchmark-selection problem, and makes the sum-of-testing claim falsifiable in agent systems.

Must be written with verification in mind
Open source video
Traceability
Open source video
Source video

Tier Discipline Against Over-Specification in Agent Prompts

Research question

Does pinning leaf-level constants such as model names, token budgets, or tool arguments in high-level orchestrator prompts increase change cost and reduce substitutability of lower-tier components?

Why

Leaking leaf-level constants upward converts a stable interface into a brittle constraint and makes lower tiers unswappable; each tier should specify only what its consumers need to reason about.

Design should flow from requirements, not constraints
Open source video
Source video

Top-Down Safety-Driven Interface Derivation

Research question

Does deriving safety and failure analysis requirements before agent architecture and interface definition reduce post-hoc guardrail patches and safety defects compared with bottom-up guardrail addition?

Why

If safety derives requirements from the top, hazard analysis must shape architecture and interface definitions themselves, not be bolted on after a pipeline is built.

Certification and safety must be considered from the top of the process
Open source video
Source video

Article ideas

4

Verifiability Is the Only Requirement That Matters: Gating Agent Specs Before They Ship

The dominant defect in agent specifications is not incompleteness but unverifiability; teams should reject any agent task description, tool contract, or eval rubric at authoring time unless it has a concrete verification method, because unverifiable specs are latent defects that surface only as silent non-compliance.

Angle

Apply aircraft systems engineering verifiability discipline to agent task descriptions and tool contracts, with a proposed admission gate.

Source video

The Six-Tier Agent: Why Agentic Architectures Need Fixed Abstraction Ladders

Agentic systems should enforce a fixed tier ladder with both allocated and derived requirements at each tier, because emergent behaviors without provenance are exactly the ones that cannot be audited or regressed; traceability becomes a structural property of the layer stack rather than a documentation chore.

Angle

Map aircraft decomposition from Level 1 aircraft functions to Level 6 PLD design onto agent components such as orchestrator, policy, tool contract, prompt, and model call.

Source video

Don't Hard-Code the Resistor in the Orchestrator: Tier Discipline for Agent Prompts

Over-specification at the wrong abstraction tier—pinning model names, token budgets, or tool arguments in high-level orchestrator prompts—destroys flexibility and couples top-level intent to volatile implementation detail; each tier should specify only what its consumers need.

Angle

Apply the aircraft anti-pattern of writing top-level requirements with exact resistor values to agent prompt engineering and orchestration design.

Source video

Coverage Is a Composition Problem: Rethinking Agent Evals as Tier-Level Verification

Agent evaluation should shift from end-to-end benchmark selection to lowest-level unit verification with an explicit argued union-of-coverage, because correctness in agent systems is a composition property and the residual uncovered set at integration boundaries is the real risk.

Angle

Use the sum-of-all-testing-must-provide-complete-coverage claim to critique benchmark-centric eval and propose a coverage-partition model.

Source video

Project ideas

4

Agent Requirement Linter

gatehouse

An authoring-time linter that rejects agent task descriptions and tool contracts lacking an observable predicate, unit, or verification method will reduce the proportion of unverifiable specs by at least 50% compared with human review alone.

Proof of concept

Build a rule-based and LLM-assisted linter over YAML/JSON agent specs that flags unverifiable phrases, missing units, and absent verification methods; run it on a sample of 100 agent task specs and tool contracts; require authors to address flags before merge.

Measurement

Percentage of specs flagged per category; reduction in unverifiable specs after linter feedback; inter-rater agreement between linter and human reviewers on verifiability judgments.

Source video

Tier Ladder Mapper for Agent Pipelines

movement-lab

Mapping agent components onto a fixed multi-tier ladder with allocated and derived requirements at each tier will reduce the number of mis-tiered constants and lower change propagation cost compared with an ad-hoc layer assignment.

Proof of concept

Define a six-tier ladder for an agent pipeline (e.g., L1 goals, L2 orchestrator, L3 tool contracts, L4 prompts, L5 model calls, L6 parameters); annotate a real agent pipeline; identify constants and behaviors at the wrong tier; refactor and measure change propagation.

Measurement

Count of mis-tiered constants before and after refactor; number of files changed when swapping a low-tier parameter; traceability coverage of allocated and derived requirements per tier.

Source video

Coverage Composition Auditor for Agent Evals

beyond-evals

Tier-level unit checks that declare which end-to-end behaviors they exercise can compose into end-to-end coverage with a measurable residual uncovered set, revealing integration-boundary gaps that benchmark-only evaluation misses.

Proof of concept

Instrument an agent pipeline with unit checks at each tier; build a coverage matrix mapping each check to declared end-to-end behaviors; compute the union of covered behaviors and the residual uncovered set; compare with an end-to-end benchmark suite.

Measurement

Percentage of end-to-end behaviors covered by the union of tier-level checks; size and composition of the residual uncovered set; number of integration-boundary gaps detected that end-to-end benchmarks did not flag.

Source video

Safety-First Agent Interface Derivation

gatehouse

Deriving safety and failure-analysis requirements before agent interface definition will reduce the number of post-hoc guardrail patches and the rate of safety violations in red-team tests compared with a baseline that adds guardrails after pipeline construction.

Proof of concept

Run a structured hazard analysis on an agent pipeline; derive safety requirements for tool interfaces and orchestration boundaries; implement them in the interface contracts; compare against a baseline pipeline with post-hoc output filters.

Measurement

Number of post-hoc guardrails added after initial build; safety violations per 1,000 red-team prompts; latency and complexity overhead of safety-derived interface constraints.

Source video

Architectural implications

3

Traceability is treated as a structural requirement linking requirements, design, and verification across every tier, with justification required for derived requirements.

Before

Specs, implementation, and tests live in separate artifacts joined by human memory or ad-hoc links.

After

A traceability layer becomes a first-class artifact that records allocated vs derived requirements and couples each requirement to a verification method.

Consequence

Eval harnesses can be generated or audited from the requirement graph, and emergent behaviors without provenance become detectable gaps rather than silent drift.

Source video

Verification is decomposed to the lowest possible level with an explicit coverage-summation requirement.

Before

Evaluation happens primarily end-to-end on integrated systems, where failures are expensive to localize.

After

Unit-level verification at each tier with an argued union-of-coverage across tiers.

Consequence

Shift in where evaluation code lives and how much of the test budget is allocated to leaf components versus integration runs.

Source video

A fixed six-tier decomposition binds abstract functions to physical implementation details with a designated level for each.

Before

Design layers are chosen ad hoc and details drift upward or downward without constraint.

After

A named tier ladder where each level has a defined responsibility and its own requirement class.

Consequence

Interface boundaries become enforceable; a constant pinned at the wrong tier becomes an identifiable defect rather than a style preference.

Source video

Tradeoffs and failure modes

4

Verification pushed to the lowest level with aggregate coverage

Benefit

Early detection of gaps and design flaws before costly integration.

Cost or risk

Correctness becomes a composition argument; the sum of unit-level tests may still miss integration-level failures, and complete-coverage claims are hard to substantiate.

The sum of all testing must provide complete coverage.
Open source video
Source video

Positive-sense requirement writing

Benefit

Assertions become directly observable and testable.

Cost or risk

Some constraints are naturally prohibitions; forcing them into positive form can obscure intent or produce convoluted, weaker statements.

Write in the positive sense rather than using 'shall not'.
Open source video
Source video

Standardized requirement templates

Benefit

Consistency and comparability across teams.

Cost or risk

Rigid template fields may not fit every requirement class, and rote template compliance can mask the fact that the requirement is still unverifiable.

Use standard templates to maintain consistency across teams.
Open source video
Source video

Top-down safety-driven requirements

Benefit

Hazards shape architecture and interfaces before implementation commitments harden.

Cost or risk

Upfront analysis cost and slower early iteration; safety-derived requirements may over-constrain designs if analysis is conservative.

safety and failure analysis must drive requirements from the top down
Open source video
Source video

Open questions

5

What concrete admission test would raise the fraction of verifiable requirements above the claimed ~1% baseline?

Why unresolved

The summary asserts the non-verifiability rate but gives no mechanism for detecting or repairing unverifiable requirements at authoring time.

Research direction

Build a linting/analysis pass over requirement text that rejects or flags statements lacking an observable predicate, unit, or measurement method, then measure the flag rate against human review.

Source video

Does coverage of decomposed unit-level verification actually compose to end-to-end coverage?

Why unresolved

The summary states the sum of all testing must provide complete coverage but does not define how coverage is aggregated across tiers or what is lost at integration boundaries.

Research direction

Prototype a coverage model where tier-level checks declare which end-to-end behaviors they exercise, and quantify the residual uncovered set for an agent pipeline.

Source video

How should derived (emergent) requirements be represented, justified, and traced back to allocated requirements?

Why unresolved

The summary requires justification for derived requirements without specifying a representation or review criterion.

Research direction

Design a requirement graph schema with allocated and derived edge types, and test whether it can capture agent-emergent behaviors discovered during evaluation.

Source video

Is the six-tier decomposition ladder the right depth for agentic software, or does it need more or fewer levels?

Why unresolved

The ladder is derived from aircraft hardware hierarchy and the summary offers no argument for why this depth applies elsewhere.

Research direction

Map agent architecture components (orchestrator, policy, tool, model call, prompt) onto an analogous tier ladder and test whether mismatches in tier assignment predict brittle interfaces.

Source video

How is operational/system performance and conditional behavior expressed so that it is measurable rather than descriptive?

Why unresolved

The summary asserts requirements must specify function and conditional behavior but does not give the measurable form.

Research direction

Define conditional-behavior requirement templates (trigger condition, observable response, bounded latency) and validate them on a non-aviation system.

Source video

Key claims

8
factualVerification needed

The overwhelming majority of requirements in current system designs are not verifiable.

Evidence

99% of all requirements we see right now in most of our system designs are not verifiable.

Question

What measurement procedure produced the ~99% figure, and over what population of requirements and systems was it computed?

Source video
causalVerification needed

Correction: writing requirements in the positive sense rather than as 'shall not' constraints leads to better verification outcomes.

Evidence

Write in the positive sense rather than using 'shall not'.

Question

Do positive-form requirements measurably outperform negative-form requirements on verification completeness or defect detection?

Source video
causalVerification needed

Verifying at the lowest possible level enables earlier detection of gaps and design flaws.

Evidence

Test at the lowest level possible before integrating upwards

Question

What is the observed reduction in defect localization cost when verification moves from box-level to component-level testing?

Source video
causalVerification needed

The aggregate of all tests can and must provide complete coverage of system requirements.

Evidence

The sum of all testing must provide complete coverage.

Question

Can coverage from independently verified tiers be shown to compose into complete end-to-end coverage, and how are integration-boundary gaps accounted for?

Source video
causalVerification needed

Requirements decomposition must proceed top-down from aircraft functions and safety considerations.

Evidence

Decomposition must be top-down starting from aircraft functions and safety

Question

Does top-down decomposition produce fewer traceability breaks or unallocated requirements than bottom-up or mixed approaches?

Source video
opinionVerification needed

Safety and failure analysis must drive requirements from the top down rather than being applied after design.

Evidence

safety and failure analysis must drive requirements from the top down

Question

What evidence supports top-down safety analysis as a driver of requirements versus bottom-up validation in terms of certification outcomes or defect rates?

Source video
comparativeVerification needed

Design parameters such as exact component values belong several tiers below top-level requirements.

Evidence

Detailed design parameters like resistor values belong several tiers down, not at the top aircraft level.

Question

Does pinning implementation constants at high tiers measurably increase change cost or reduce substitutability of lower-tier components?

Source video
opinionVerification needed

ARP4754A and ARP4761 are the key elements to any design and should be the starting point.

Evidence

ARP4754A and ARP4761 are the key elements to any design and should be the starting poin

Question

Are these standards necessary or sufficient for requirement correctness, or do they mainly provide process scaffolding?

Source video

Connections

5