Module 5/5 · Weeks 13–15 · 27 h

Documentation and presentation

UAT 494 Unmanned Aircraft Systems and Automation Technology Capstone Project II

About 80 minDraft, awaiting reviewLast updated 28 September 2026

By the end of this module you will be able to

Organise an evidence dossier that traces from conclusions to source data
Summarise the verification status of every requirement honestly, including open items
Write a user manual and a project report for the committee and the users
Prepare the presentation and demonstration for the committee

Prerequisites: UAT 494 Modules 1–4

Why this matters

The committee has little time and will judge on the conclusions, the evidence and the demonstration. The drone knowledge base’s exercise on dossier review stresses that a good dossier starts from the conclusions and lets the reader trace straight to the source evidence, that every document carries a version and change log, and that open issues must not be hidden to make it look complete.

The evidence dossier

The dossier is layered: conclusions and limitations, then the requirements verification matrix (RVM), then each test report, then the raw data and configuration. Every layer cites the one below with clear identifiers and versions, following the configuration management principles of ISO 10007.

Four stacked bands widening from top to bottom: conclusions and limitations, requirements verification matrix RVM, individual test reports, and raw data, logs, images and configuration — Figure 1 The evidence dossier from conclusions to source data

Example 1 Final RVM status

Requirements from UAT 493 with the results from Modules 3–4 (hypothetical data).

rvm = {   # requirement: (status, evidence)
    "R1 crack recall >= 0.90": ("met on sample, not demonstrated", "T1 report v2, test set TS-03"),
    "R4 round <= 15 min": ("verified", "T2 flight log set FL-11..20"),
    "R6 coordinates within 3 m": ("verified", "T3 GCP survey v1"),
    "R5a store images": ("verified", "A1 storage analysis v1"),
    "R5b send report": ("verified", "D1 walkthrough with office"),
    "R8 web dashboard": ("not started (Could)", "-"),
    "R2 usability SUS >= 68": ("verified", "SUS survey n=5"),
}
counts = {}
for req, (status, ev) in rvm.items():
    key = status.split(" (")[0].split(" on ")[0]
    counts[key] = counts.get(key, 0) + 1
    print(f"{req:<28} {status:<34} {ev}")
verified = sum(1 for s, _ in rvm.values() if s == "verified")
print(f"verified {verified}/{len(rvm)} = {verified / len(rvm):.0%}; open items must appear in the conclusions")

R1 crack recall >= 0.90      met on sample, not demonstrated    T1 report v2, test set TS-03
R4 round <= 15 min           verified                           T2 flight log set FL-11..20
R6 coordinates within 3 m    verified                           T3 GCP survey v1
R5a store images             verified                           A1 storage analysis v1
R5b send report              verified                           D1 walkthrough with office
R8 web dashboard             not started (Could)                -
R2 usability SUS >= 68       verified                           SUS survey n=5
verified 5/7 = 71%; open items must appear in the conclusions

R2 is the requirement rewritten in UAT 493 so that it is measurable with a SUS score. Five of seven requirements are verified. R1 is met on the sample but not yet demonstrated with confidence, and R8 was cut in priority order. Both must appear in the conclusions with reasons and a plan. This kind of disclosure makes the committee trust the verified parts more.

Manuals and reports

The project report puts conclusions before details (Markel and Selber, 2025) and covers the problem, requirements, architecture, testing, results, limitations and recommendations
The user manual is written for irrigation staff, not for the development team, covering pre-flight preparation, flying, reading the report, and what to do when something goes wrong
The handover package contains software versions, configuration files and operating limits so that others can continue the work

Presentation and demonstration

A 15–20 minute presentation should answer three questions: what problem was solved, how far it was achieved with evidence, and what remains. A live demonstration is risky, so prepare a backup video and logged data, and obtain permission for the demonstration flight area.

Example 2 Overall project score

Course weights: proposal 20%, progress and advisor meetings 30%, product, report and presentation 50% (hypothetical scores).

weights = {"proposal": 0.20, "progress & advisor meetings": 0.30, "product, report & presentation": 0.50}
scores = {"proposal": 82, "progress & advisor meetings": 75, "product, report & presentation": 88}
assert abs(sum(weights.values()) - 1) < 1e-9
total = sum(weights[k] * scores[k] for k in weights)
for k in weights:
    print(f"{k:<32} {scores[k]:>3} x {weights[k]:.2f} = {weights[k] * scores[k]:5.1f}")
print(f"final {total:.1f}")
gain = weights["progress & advisor meetings"] * 10
print(f"10 more points on progress would add {gain:.1f} to the final score")

proposal                          82 x 0.20 =  16.4
progress & advisor meetings       75 x 0.30 =  22.5
product, report & presentation    88 x 0.50 =  44.0
final 82.9
10 more points on progress would add 3.0 to the final score

The product and presentation carry half the weight, but steady progress still counts for almost a third, so meeting the advisor every two weeks with progress numbers, as in Module 1, pays off.

A long bar split into three parts: proposal 20 percent in blue, progress 30 percent in green, and product, report and presentation 50 percent in gold — Figure 2 Project assessment weights

Module lab

Lab: dossier and presentation

Organise the dossier as in Figure 1; every document has a version, date and change log
Summarise the RVM with Example 1 and write conclusions that include open items
Write the user manual, have real users read and follow it, and note where they got confused
Rehearse the presentation with the advisor and prepare a backup video of the demonstration
Hand over the software, configuration and documents to the users or the next team

Common mistakes

Watch out

Conclusions citing evidence that cannot be found
Hiding requirements that failed
Writing the manual in the development team’s jargon
No backup plan for the live demonstration
Submitting only the report without handing over software and configuration

Summary

The evidence dossier traces from conclusions to source data at every layer
The final RVM states the status of every requirement honestly, including open items
The report is for the committee, the manual is for users, and the handover package is for whoever continues
The presentation answers what was solved, how far, and what remains, with a backup plan

Check your understanding

6 of 8 requirements are verified. What percentage is that?
Proposal 70, progress 80, product 90. What is the overall score (20/30/50)?
Why should failed requirements not be hidden?
How does a user manual differ from a project report?
What main questions should the presentation answer?

Answers

$6/8 = 75%$
$0.2 \times 70 + 0.3 \times 80 + 0.5 \times 90 = 83$
The committee would stop trusting the whole dossier, and users might operate the system beyond its capability
A manual lets users carry out tasks; a report shows the committee the problem, method, evidence and limitations
What problem was solved, how far it was achieved with evidence, and what remains

Key formulas

Share of requirements verified	$\frac{n _{verified}}{n _{requirements}}$
Overall project score	$G = 0.20 P + 0.30 Q + 0.50 F$

Key references

National Aeronautics and Space Administration. (2016). NASA systems engineering handbook (NASA/SP-2016-6105 Rev 2). link
INCOSE. (2023). INCOSE systems engineering handbook: A guide for system life cycle processes and activities (5th ed.). Wiley. link
Dym, C. L., Little, P., & Orwin, E. J. (2013). Engineering design: A project-based introduction (4th ed.). Wiley. link
Markel, M., & Selber, S. A. (2025). Technical communication (14th ed.). Macmillan Learning. link
International Organization for Standardization. (2017). Quality management — Guidelines for configuration management (ISO 10007:2017). link

In class / field

Team project work, advisor meetings and progress presentations

Learning evidence: Project milestone deliverables

Module quiz

This is a formative self-check, not a graded exam

Knowledge domain: Law, safety and risk

Documentation and presentation

By the end of this module you will be able to

Why this matters

The evidence dossier

Manuals and reports

Presentation and demonstration

Module lab

Common mistakes

Summary

Check your understanding

Key formulas

Key references

Further reading

Reviewing the dossier and explaining limitations

In class / field

Module quiz

Documentation and presentation

Lesson

By the end of this module you will be able to

Why this matters

The evidence dossier

Manuals and reports

Presentation and demonstration

Module lab

Common mistakes

Summary

Check your understanding

Key formulas

Key references

Further reading

Reviewing the dossier and explaining limitations

In class / field

Module quiz