Problem identification

Why this matters

Most failed projects do not fail because the engineering was poor. They fail because the team solved the wrong problem. A team that starts from “we want to build an AI inspection drone” often ends up with a system that works but that nobody wants to use. A team that starts from a real user problem knows what to build and knows when it has succeeded. The ABET criteria for engineering technology programs require a project that integrates technical and non-technical skills to solve a problem, which is exactly what this course does.

The whole course follows one hypothetical case: an automated drone system that inspects a 2 km irrigation canal, extended from the mission-concept example in the drone knowledge base. This course is the first project semester and ends with a project proposal; building and testing happen in the next project semester. Every module has a project deliverable. The Python code for every module can be downloaded from /downloads/uat-493/.

Stakeholders

A stakeholder is anyone affected by, or with authority over, the project, not only the customer.

Stakeholder needs can conflict. The irrigation office wants detailed images, while the community along the canal worries about their homes being photographed. Identifying this early lets the design accommodate it, for example by limiting the imaging area and deleting unrelated images.

Problem statement and ConOps

A good problem statement says who has what problem, what the impact is and how it can be measured, without naming a solution.

• Poor: “We need an AI drone to inspect the canal” (the solution is already chosen)
• Better: “The irrigation office only finds damage to canal banks after water has leaked, because staff can walk the 2 km line only once a month, so repairs are late and water is lost”

A concept of operations (ConOps), as described in the NASA Systems Engineering Handbook, explains how the system will be used to meet the need, usually told in time order from the user’s point of view.

Assumption register and mission sizing

Every estimate at this stage rests on assumptions. An assumption register records each one with its data owner, how it will be checked and its status, so that an assumption does not quietly become a “fact” that nobody checked.

import math

assumptions = {  # value, data owner, status
    "canal length m": (2000, "irrigation office map", "checked"),
    "corridor width m": (60, "site visit", "to check"),
    "footprint across track m": (90, "camera spec at 60 m height", "to check"),
    "footprint along track m": (60, "camera spec at 60 m height", "to check"),
    "forward overlap": (0.75, "mapping practice for the team", "assumed"),
    "ground speed m/s": (5.0, "flight test", "to check"),
}
v = {k: val for k, (val, _, _) in assumptions.items()}
spacing = v["footprint along track m"] * (1 - v["forward overlap"])
passes = math.ceil(v["corridor width m"] / v["footprint across track m"])
photos = passes * (math.floor(v["canal length m"] / spacing) + 1)
flight_min = passes * v["canal length m"] / v["ground speed m/s"] / 60 + 3     # + 3 min take-off, landing and transit
print(f"photo spacing {spacing:.0f} m, passes {passes}, photos {photos}, flight ≈ {flight_min:.1f} min per round")
print(f"weekly for a year: {52 * photos:,} photos, about {52 * photos * 25 / 1000:.0f} GB at 25 MB each")
unchecked = [k for k, (_, _, st) in assumptions.items() if st != "checked"]
print(f"{len(unchecked)} of {len(assumptions)} assumptions not yet checked:", ", ".join(unchecked))

photo spacing 15 m, passes 1, photos 134, flight ≈ 9.7 min per round
weekly for a year: 6,968 photos, about 174 GB at 25 MB each
5 of 6 assumptions not yet checked: corridor width m, footprint across track m, footprint along track m, forward overlap, ground speed m/s

Module lab

Common mistakes

Summary

• Start from stakeholders and real needs, not from technology
• A problem statement gives a measurable impact without a solution; a ConOps tells the use of the system in time order
• An assumption register separates what is known from what must be checked, and shows what to check first
• Verification means building it right to the requirements; validation means building the right thing

Check your understanding

1. Is “we need a drone with a thermal camera” a good problem statement? Why?
2. The image is 60 m long along track with 80% overlap. What is the photo spacing?
3. A flight line is 1,500 m long with a 15 m photo spacing. How many photos are needed?
4. Is the question “did we build the right thing?” verification or validation?
5. Besides the assumed value, what should an assumption register record?