Stakeholder, Product, and Boundary

A mission concept becomes useful when its boundaries are visible.

Yesterday you defined a need. Today you turn that need into a system concept that can survive review. The core question is simple:

What must the system do, and what must it refuse to pretend it can do?

That second half matters. Engineering gets weak when teams list capabilities but hide assumptions.

Build the requirement stack

Use three layers.

Product requirements

These describe the result the stakeholder needs.

Example:

• four roof zones represented;
• images traceable to location and orientation;
• evidence packaged so another reviewer can inspect it;
• limitations stated next to the product.

Operating requirements

These describe conditions the mission concept must respect.

Examples:

• approved operating area;
• people and obstacle boundaries;
• weather margin;
• usable launch and recovery area;
• current regulatory verification before any real operation.

System requirements

These describe capabilities the proposed UAS system must provide.

Examples:

• sufficient image detail;
• stable capture geometry;
• enough energy margin for the proposed route plus reserve;
• reliable position and control evidence for the scenario;
• data storage and file organization that preserve traceability.

Notice the order. System requirements come last. The aircraft exists to satisfy the mission, not the other way around.

Draw the concept boundary

A system boundary separates what your design controls from what it only depends on.

For the roof scenario, your team might control:

• proposed route geometry;
• selected aircraft concept;
• sensor choice;
• capture plan;
• checklist design;
• evidence packaging.

The team may depend on, but not control:

• current airspace status;
• site permission;
• weather;
• bystanders;
• GNSS conditions;
• stakeholder availability;
• current official rules.

That difference changes how you write the plan. A dependency should never be written as if the team can guarantee it.

One useful diagram

Build a simple system boundary like this:

STAKEHOLDER NEED
       |
       v
+---------------------------+
|      MISSION SYSTEM       |
| requirement -> route      |
| route -> aircraft/sensor  |
| capture -> evidence       |
| evidence -> product       |
+---------------------------+
   ^       ^        ^
   |       |        |
weather  authority  site conditions

The external arrows are not decoration. They are the things that can invalidate a technically good internal design.

Assumptions are temporary debts

An assumption is something you are treating as true because the evidence is not available yet.

Examples:

Assume the supplied site diagram is current.

Assume the proposed aircraft can carry the selected sensor with adequate endurance.

Those assumptions are acceptable in an early concept only if they are labeled and assigned a future verification step.

Bad version:

The aircraft has enough battery.

Better version:

Endurance is currently an assumption. Week 17 planning must compare route demand with verified aircraft/sensor endurance data and reserve margin.

Now the assumption has an owner and a destination.

Failure case: hidden stakeholder mismatch

A team creates a beautiful orthomosaic concept for a stakeholder who only needs three close-up inspection images.

The map may be technically impressive and still be the wrong product.

Why?

Because extra complexity creates extra capture, processing, validation, and operational requirements without solving a stronger stakeholder need.

The correct design principle is:

Use the least complex system that can produce defensible evidence for the stated need.

Build the concept architecture

Add these items to your capstone concept brief:

Then draw one system-boundary diagram showing what the mission system controls and what remains external.

Review question

Imagine the aircraft disappears from your document.

Could a reviewer still understand the stakeholder, product, success criteria, operating boundary, and dependencies?

If yes, the mission concept is starting from engineering.

If no, the aircraft is still driving the problem definition.