Week 16 · lesson
Concept Brief Review
A concept review is where a team finds expensive mistakes while they are still cheap.
You are not trying to prove the mission is ready to fly. You are trying to decide whether the problem definition and system concept are strong enough to justify detailed planning.
That is a different decision.
The review board does not grade enthusiasm
A reviewer should be able to challenge the concept using evidence.
Use five lenses:
| Review lens | Question |
|---|---|
| Need | Is there a real stakeholder problem? |
| Product | Is the deliverable specific and testable? |
| Boundary | Are legal, site, safety, and technical limits visible? |
| Architecture | Do proposed system capabilities connect to requirements? |
| Unknowns | Are assumptions labeled and assigned future verification? |
A concept can fail review even if the drone choice looks excellent.
Worked review: the school-roof concept
Suppose the brief says:
We will use a high-end quadcopter to inspect the roof and create a 3D model.
A reviewer should immediately ask:
- Who requested a 3D model?
- What decision will the model support?
- Which roof areas matter?
- What evidence quality is actually required?
- Is a 3D reconstruction necessary, or would labeled imagery solve the need with less complexity?
- Which permissions and operating conditions are still unresolved?
Now compare that with:
Facilities needs a current visual record of four assigned drainage zones. The proposed product is a labeled image set that supports visible-condition comparison. A 3D model is outside the current requirement unless later review shows it adds necessary evidence.
The second concept is narrower, but stronger. It tells you what the system is for and prevents unnecessary scope growth.
Score the concept, not the slide deck
Use this readiness table.
| Criterion | Ready | Needs revision | Evidence |
|---|---|---|---|
| Stakeholder is identified | |||
| Need is written as a problem, not a technology request | |||
| Product is specific | |||
| Success can be tested | |||
| Operating boundary is explicit | |||
| System capabilities map to requirements | |||
| Dependencies are visible | |||
| Assumptions have future verification steps | |||
| Non-goals prevent scope creep |
A blank evidence column means the rating is not defensible.
Failure pattern: requirement laundering
Requirement laundering happens when a preference quietly gets rewritten as if it were mandatory.
Example:
We want to use autonomous waypoints.
becomes:
The mission requires autonomous waypoints.
Why? No one knows.
A reviewer should force the team to reconnect the requirement to the stakeholder product:
Which product requirement fails if the mission is flown manually or simulated another way?
If there is no answer, it is not yet a requirement.
Run the concept review
Exchange briefs with another team or perform a structured self-review.
Record:
- Strongest requirement: the requirement with the clearest stakeholder connection.
- Weakest claim: the statement with the least evidence or most hidden assumptions.
- Largest boundary risk: the external condition most likely to invalidate the concept.
- Unnecessary complexity: one feature that may not be required.
- Next verification: the single check Week 17 must perform first.
Then revise the concept brief. Do not merely add reviewer comments at the bottom. Change the design where the evidence says the design is weak.
Phase-1 exit decision
Your team may move into detailed mission planning when the concept answers this sentence cleanly:
For [stakeholder], we will produce [specific product] to support [need/decision], using a proposed UAS system that must satisfy [key requirements] while remaining inside [operating boundary]; the main unresolved assumptions are [unknowns] and will be verified before the plan is treated as executable.
That sentence is not the capstone. It is the foundation the capstone can safely stand on.