Requirements Engineering for Upstream Aerospace Projects

Requirements Engineering for Upstream Aerospace Projects

Summary

Requirements engineering is the discipline that transforms an ambitious aerospace idea into a clear, structured and verifiable set of design expectations. In upstream aircraft projects, especially from TRL 1 to TRL 3, requirements are not only administrative documents. They are the bridge between vision, technical feasibility, project management, safety, market relevance and future validation.

For Bee ecosystem projects such as Bee-Plane, ISO-Plane, Mini-Bee and GPS 4D, requirements engineering is particularly important because the concepts are innovative, collaborative and often distributed between several schools or project teams. A detachable fuselage aircraft, a container-carrying cargo aircraft, a hybrid VTOL or a 4D navigation system cannot be developed only through isolated technical studies. Each team must understand what the system is expected to do, under which assumptions, with which constraints, and how success will be proven.

A good requirement is not just a wish. It is a clear statement that can be understood, discussed, traced and verified. It helps future teams continue the project instead of restarting it. It also helps the Coordinator, Participants and partner institutions maintain a shared technical baseline under the Lesser Open Bee License 1.3.

1. Why requirements matter in early aerospace design

In early aircraft design, teams often begin with sketches, CAD models, market ideas or simulation concepts. This is useful, but it can quickly become confusing if the team does not define what the aircraft or system must actually achieve. Requirements provide this structure.

In an upstream aerospace project, requirements help answer basic but critical questions:

• What mission is the aircraft designed for?
• Who will use it?
• What payload must it carry?
• How far must it fly?
• How fast must it fly?
• Which airport, landing zone or airspace constraints apply?
• Which safety level is expected?
• Which assumptions are fixed, and which remain open?
• How will we know that the concept is mature enough for the next TRL?

Requirements engineering prevents teams from designing attractive but incoherent concepts. It also prevents each work package from inventing its own assumptions independently.

2. Requirements as a system-engineering activity

Requirements engineering is not only the responsibility of the project manager. It is a system-engineering activity involving all technical teams.

The aerodynamic team needs mass, speed, altitude and mission assumptions. The structure team needs load cases, payload and safety factors. The propulsion team needs power, range and energy requirements. The market team needs operational and cost assumptions. The software team needs data formats, latency, interfaces and user scenarios.

In other words, requirements are the common language between disciplines.

A requirement is useful when it connects:

Need → Function → Constraint → Design choice → Verification evidence.

For example:

Element	Example
Need	Reduce aircraft turnaround time.
Function	Allow passenger or cargo module preparation outside the aircraft carrier.
Constraint	Module attachment and detachment must be safe, repeatable and inspectable.
Design choice	Detachable fuselage architecture.
Verification evidence	Operational sequence analysis, attachment-system simulation and ground-handling time estimate.

3. Requirements in Bee projects

Bee projects are especially exposed to requirement-management challenges because they are collaborative and multi-year. Several teams may work on the same aircraft across different schools, different academic years and different technical scopes.

Bee-Plane requires requirements on the Bee carrier, the detachable Basket, attachment system, passenger/cargo configuration, aerodynamics, ground operations and modular maintenance.

ISO-Plane requires requirements on ISO-container compatibility, cargo-bay geometry, autonomous loading, payload mass, range, runway compatibility, floor strength and market positioning.

Mini-Bee requires requirements on VTOL capability, rotor performance, safety, cockpit instrumentation, emergency use, transportability and power-chain architecture.

GPS 4D requires requirements on trajectory optimization, real-time data, airspace constraints, user interface, collision avoidance, weather integration and interoperability.

In each case, requirements should not be hidden inside presentations. They should be extracted, structured, versioned and published so that future teams can reuse them.

4. Difference between needs, functions, constraints and requirements

Student teams often mix several concepts. The distinction is important.

Concept	Meaning	Example
Need	A problem or expectation from the user or project context.	Transport a standard 20-foot ISO container by air.
Function	What the system must do to satisfy the need.	Carry the container inside the aircraft.
Constraint	A limit imposed on the solution.	The container geometry and maximum payload define the cargo-bay dimensions and structural loads.
Requirement	A precise, verifiable statement derived from needs, functions or constraints.	The cargo bay shall accommodate a 20-foot ISO container with its defined length, width, height and maximum operational mass.

This transformation is one of the most important tasks in early design. It allows vague ambition to become engineering work.

5. What makes a good requirement?

A good requirement should be:

• Clear: everyone understands the same meaning.
• Atomic: it expresses one idea only.
• Necessary: it is linked to a real need or constraint.
• Feasible: it can realistically be achieved.
• Verifiable: it can be checked by analysis, simulation, inspection or test.
• Traceable: its origin is documented.
• Versioned: changes are recorded.
• Consistent: it does not contradict other requirements.

A weak requirement says:

The aircraft shall be efficient.

A better requirement says:

The aircraft shall achieve a cruise lift-to-drag ratio target defined in the aerodynamic baseline for the selected mission configuration.

Even if the value is not yet frozen, the requirement becomes useful because it identifies what must be measured, who owns the assumption, and which document must define the target.

6. Types of requirements in upstream aerospace projects

Requirements can be organized into families.

Requirement type	Description
Stakeholder requirements	Describe what users, operators, maintainers, regulators, academic teams or the Coordinator expect.
Mission requirements	Describe what the aircraft or system must accomplish: range, payload, speed, mission duration, route type, emergency case or operational scenario.
Functional requirements	Describe what the system must do: lift, fly, navigate, load, unload, communicate, stabilize, optimize, display, store or protect.
Performance requirements	Quantify how well the system must perform: speed, range, payload, climb rate, power, latency, accuracy, turnaround time, cost or emissions.
Interface requirements	Describe how subsystems interact: mechanical attachment, CAD reference planes, data formats, electrical buses, aerodynamic load transfer, software APIs or file formats.
Safety requirements	Describe acceptable behaviour under nominal and degraded conditions: redundancy, failure detection, emergency landing, pilot override, structural margins or safe states.
Regulatory requirements	Identify standards, certification categories, airspace rules and operating constraints.
Environmental requirements	Address fuel burn, emissions, noise, recyclability, lifecycle impact or sustainable materials.
Documentation requirements	Define what must be published, in which format, with which metadata and under which license reference.

7. Requirements and TRL logic

Requirements must evolve with the TRL level.

TRL phase	Requirement role
TRL 1	Requirements are exploratory. They help clarify the mission and identify possible design drivers.
TRL 2	Requirements become structured. They define the concept, main functions, assumptions and first performance targets.
TRL 3	Requirements must be connected to evidence. The team should show preliminary analytical, numerical or experimental validation.

A TRL 2 requirement may say:

The aircraft concept shall include an autonomous loading solution compatible with the target cargo mission.

A TRL 3 requirement should be more precise:

The loading solution shall be validated through a documented kinematic model, preliminary structural load calculation and operational sequence analysis.

This progressive refinement is normal. Early requirements are allowed to evolve, but the evolution must be documented.

8. Requirements workflow for student teams

A recommended workflow is the following.

1. Collect inputs: read previous reports, wiki pages, CAD models, presentations, market studies and technical notes.
2. Identify stakeholders: list operators, users, maintainers, regulators, partner schools, future teams and the Coordinator.
3. Define use cases: describe concrete missions, not abstract ideas.
4. Extract needs: identify what the project is trying to solve.
5. Define functions: translate needs into system functions.
6. Write requirements: use clear, verifiable statements.
7. Classify requirements: organize them by domain.
8. Assign ownership: each requirement should have a responsible work package.
9. Define verification methods: analysis, simulation, inspection, test or review.
10. Publish and version: store requirements in a wiki page, spreadsheet or repository with a changelog.

9. Requirement formulation rules

Use shall for mandatory requirements.

Use should for recommendations or design preferences.

Use may for optional features.

Avoid vague words such as optimized, robust, efficient, simple, cheap, fast or innovative unless they are defined by measurable criteria.

Weak formulation	Better formulation
The aircraft shall be easy to maintain.	The main inspection points shall be accessible without removing the complete module.
The aircraft shall be very safe.	The system shall include a documented degraded-mode behaviour for loss of one sensor input.
The software shall be user-friendly.	The interface shall display aircraft position, route, alert status and selected mission mode.
The structure shall be light.	The structure team shall document the mass of each major component and compare it with the mass budget.

10. Traceability

Traceability means that each requirement has an origin, an owner and a verification path.

A requirement without traceability is fragile. Future teams will not know whether it comes from a regulation, a customer need, a calculation, a design choice, a market study or a personal assumption.

A basic traceability table should include:

Field	Purpose
Requirement ID	Unique identifier.
Requirement text	Complete requirement statement.
Source	Origin of the requirement.
Rationale	Why the requirement exists.
Owner	Responsible work package or team.
Status	Draft, proposed, accepted, changed, verified or obsolete.
Verification method	Analysis, simulation, inspection, test or review.
Related files	CAD, report, simulation, spreadsheet or wiki links.
TRL evidence	File or result proving progress.
Last update	Date and version tracking.

Traceability is essential in Bee projects because teams change every year. Good traceability allows new participants to understand the project history quickly.

11. Requirements baseline

A requirements baseline is a frozen version of the requirements at a given project milestone. It does not mean that requirements can never change. It means that changes must be intentional and documented.

Typical baselines:

• Initial needs baseline.
• TRL 1 concept baseline.
• TRL 2 architecture baseline.
• TRL 3 preliminary validation baseline.
• Pre-review baseline.
• Final academic deliverable baseline.

Each baseline should include the date, version, responsible team and summary of changes.

12. Requirements and WBS

The Work Breakdown Structure should reflect the requirements. If a requirement has no task associated with it, it will probably not be addressed. If a task has no requirement associated with it, its usefulness should be questioned.

Requirement	Associated WBS tasks
The aircraft shall be compatible with a defined cargo-loading scenario.	Cargo-bay sizing; loading kinematics; structural floor analysis; ground-operation sequence; safety review.
The GPS 4D interface shall display dynamic no-fly zones.	Data model; map layer integration; user-interface display; simulation scenario; validation test.

This link between requirements and WBS is one of the best ways to connect project management with engineering design.

13. Requirements and risk management

Many project risks are actually requirement risks.

• If a requirement is unclear, the team may build the wrong thing.
• If a requirement is unrealistic, the team may waste time.
• If a requirement is not verified, the project may claim progress without evidence.
• If two requirements conflict, the architecture may become incoherent.

A requirement risk register should identify:

• unclear requirements;
• unverified assumptions;
• conflicting requirements;
• requirements without owners;
• requirements without verification methods;
• requirements depending on unavailable data;
• requirements that may strongly affect cost, mass or certification.

Each risk should have an action: clarify, split, test, relax, escalate or document.

14. Requirements and open-source collaboration

Under the Bee collaborative logic, requirements should be reusable. They should not remain in private notebooks or local files. They should be published in a structured format that future teams can understand.

Good practice includes:

• publishing requirement tables on the wiki;
• storing editable versions in shared repositories;
• using clear file names;
• adding version dates;
• referencing derived work;
• keeping a changelog;
• linking requirements to CAD, simulation and reports;
• including the correct license reference.

This supports continuity between student cohorts and strengthens the open-engineering value of the project.

15. Recommended requirement table

A recommended table for Bee projects is:

Field	Description
ID	Unique identifier.
Title	Short requirement name.
Requirement	Complete “shall” statement.
Type	Mission, functional, performance, interface, safety, regulatory, environmental or documentation.
Source	Market study, previous report, regulation, Coordinator input, technical calculation or design review.
Rationale	Why the requirement exists.
Owner	Responsible work package.
Verification	Analysis, simulation, inspection, test or review.
Status	Draft, proposed, accepted, changed, verified or obsolete.
TRL evidence	Document or file proving progress.
Version	Last modification.

This table can be managed in a spreadsheet, wiki table or requirements-management tool. For student teams, a simple spreadsheet is often enough if it is well maintained.

16. Example requirements for Bee projects

Bee-Plane examples

• The Bee carrier shall provide the aerodynamic lifting surfaces, cockpit, engines and landing gear required for the selected mission profile.
• The Basket interface shall allow safe mechanical connection between the carrier structure and the detachable module.
• The passenger Basket shall be compatible with the selected cabin layout and emergency-egress assumptions.
• The aerodynamic team shall document the impact of Basket geometry on drag, stability and aircraft performance.

ISO-Plane examples

• The aircraft shall carry a 20-foot ISO container within the defined cargo bay envelope.
• The loading system shall allow container loading and unloading without external heavy lifting equipment in the target operational scenario.
• The cargo floor shall support the defined maximum payload with documented safety assumptions.
• The aircraft configuration shall be evaluated against runway, range and cargo-market requirements.

Mini-Bee examples

• The aircraft shall provide vertical take-off and landing capability for the defined mission mass.
• The rotor system shall provide sufficient thrust margin for hover and controlled descent assumptions.
• The cockpit shall display critical flight and system information required for safe operation.
• The structure shall be compatible with the defined transportability constraints.

GPS 4D examples

• The system shall represent aircraft position using latitude, longitude, altitude and time.
• The trajectory engine shall include no-fly zones, obstacles and airspace constraints in route calculation.
• The interface shall display normal, emergency and weather-related trajectory options.
• The data model shall support open exchange formats suitable for reuse by future teams.

17. Verification methods

Every requirement should be linked to a verification method.

Verification method	Description
Analysis	Equations, sizing rules, mass budgets, performance calculations.
Simulation	CFD, FEA, trajectory simulation, control simulation, kinematic model.
Inspection	CAD review, document review, interface check, model comparison.
Test	Prototype test, bench test, software test, sensor test, user test.
Review	Expert review, design review, TRL review, peer review.

At TRL 1 and TRL 2, analysis and review are often dominant. At TRL 3, simulations and preliminary tests should become more important.

18. Common mistakes

Mistake 1 — Writing requirements too late

Requirements should guide design, not merely describe it after the fact.

Mistake 2 — Using vague adjectives

Efficient, safe, simple and innovative must be translated into measurable or reviewable criteria.

Mistake 3 — Mixing several requirements into one sentence

A requirement should contain one verifiable idea.

Mistake 4 — Not documenting assumptions

A requirement based on an unknown mass, speed or payload becomes unreliable.

Mistake 5 — Forgetting interfaces

Many failures come from poorly managed interfaces between teams.

Mistake 6 — Not updating obsolete requirements

If a requirement changes, the change must be visible.

Mistake 7 — Confusing design choice and requirement

A requirement says what must be achieved. A design choice says how the team proposes to achieve it.

19. Practical checklist before publishing

Before publishing a requirements page, verify that it includes:

• project name;
• TRL level;
• date;
• version number;
• scope;
• stakeholders;
• mission scenarios;
• requirements table;
• source of each requirement;
• owner of each requirement;
• verification method;
• status;
• open points;
• risks;
• links to WBS;
• links to technical deliverables;
• license reference.

20. Recommended deliverables

A requirements-engineering work package should produce:

Deliverable	Purpose
Requirements wiki page	Public and readable synthesis.
Requirements spreadsheet	Structured and editable requirement table.
Mission-scenario note	Concrete operational scenarios.
Stakeholder map	Identification of users, operators, maintainers, partners and regulators.
Functional analysis	Link between needs, functions and requirements.
Interface requirement table	Requirements between subsystems and teams.
Verification matrix	Link between each requirement and its proof method.
Requirements risk register	Risks related to unclear, conflicting or unverified requirements.
Change log	History of modifications.
TRL baseline summary	Frozen requirement state at a project milestone.

These deliverables do not need to be complex. They need to be clear, traceable and maintained.

21. Suggested template for a requirements page

= Requirements Engineering – Project Name – TRL Level =

== Summary ==
Short description of the project scope and requirement baseline.

== Project Scope ==
What system, subsystem or mission is covered?

== Stakeholders ==
Who uses, operates, maintains, regulates or continues the project?

== Mission Scenarios ==
Concrete use cases and operational situations.

== Needs and Functions ==
List of user needs and system functions.

== Requirements Table ==
Structured table with ID, text, type, source, owner, verification and status.

== Interface Requirements ==
Mechanical, electrical, aerodynamic, software and documentation interfaces.

== Verification Strategy ==
How requirements will be checked.

== Risks and Open Points ==
Unclear, conflicting or high-impact requirements.

== Change Log ==
Version history.

== Next TRL Recommendations ==
What should be refined, tested or validated next?

== License Reference ==
Task achieved under the Lesser Open Bee License 1.3 Chapter 2 Open source – © Coordinator Technoplane SAS.

22. Conclusion

Requirements engineering is one of the foundations of credible upstream aerospace design. It helps teams move from enthusiasm to structured development. It clarifies what the aircraft or system must do, why it must do it, who is responsible and how progress will be proven.

For Bee projects, requirements engineering also supports the collaborative spirit of the Lesser Open Bee License. It makes knowledge reusable, protects continuity between cohorts, and helps the Consortium build shared technical confidence.

A strong requirements page does not freeze creativity. It channels creativity toward a design that can be explained, tested, improved and continued.

Internal references

• Lesser Open Bee License 1.3.
• Bee-Plane collaborative project documentation.
• ISO-Plane TRL2 project documentation.
• Mini-Bee technical and project-management documentation.
• GPS 4D collaborative project documentation.
• Best Practices for Lesser Open Bee License 1.3 Users.
• Best Practices for Engineers on Project Management.
• Best Practices for Collaborative Engineering Deliverables, Bee Projects TRL 1–3.

License reference

Task achieved under the Lesser Open Bee License 1.3 Chapter 2 Open source – © Coordinator Technoplane SAS.