Design report

The design report is the project's permanent record. The presentation in lesson 12 lasts twenty minutes and is remembered for a few weeks; the report will be read by the sponsor's engineers deciding whether to launch a program, by the flight school deciding whether to wait for an electric trainer, by future capstone teams starting a similar project, and by the course assessors deciding whether the team has met the outcomes. Every one of these readers is busy, none of them was in the room when the decisions were made, and most will read only part of it. Priya opens the report-planning meeting in week 18 with a sentence Dr. Nakamura said at the concept review: “If I can't find your answer on the first page, I'll assume you don't have one.”

Who reads it and what they need

The team lists the readers and what each needs. Dr. Nakamura and Élise need the answer and the reasons, the risks, and what it would cost to proceed: they will read the executive summary closely, the conclusions, and the parts of the body where they doubt a number. The sponsor's specialists, Marcus for structures, Tomasz for aerodynamics, Rachel for certification, need enough method and data in their own areas to check the work. The school's owner and chief instructor need the operating cost, the mission and the limitations in language they can use. The assessors need evidence of process: how requirements were set, how concepts were chosen, how analyzes were checked. And a future reader, perhaps an engineer at Prairiewind Aerospace reopening the study in five years when batteries have improved, needs to be able to rerun the sizing with new numbers.

No single document structure serves all of these readers perfectly, but a conventional engineering report structure comes close, because each reader knows where to look.

Answer first

Engineering students are trained to write in the order they worked: background, method, results, conclusion. Readers want the opposite. The report therefore puts the answer in the first paragraph of the executive summary and again at the start of the conclusions, and each section of the body starts with its own result before explaining how it was reached. This is sometimes called the pyramid principle: the main point at the top, supported by a few key arguments, each supported by evidence below. A reader can stop at any level and take away the correct message.

The team drafts the opening of the executive summary six times. The first draft begins, “This report presents the conceptual and preliminary design of a two-seat electric training aircraft.” Professor Lindqvist crosses it out: the reader already knows that from the title. The final version begins with the answer: “A two-seat battery-electric trainer can fly the school's circuit and air-work lessons with the required reserve, at a maximum take-off mass of 772 kg, using battery packs expected to be available by the end of the decade. It meets nine of the ten driving requirements. It meets the cost target of 60 percent of a piston trainer's hourly cost only if a few hundred aircraft are sold, and only narrowly where fuel is expensive. The team recommends a conditional go: a funded battery qualification and certification-basis phase before any commitment to full development.”

That paragraph has three properties worth copying. It states the result with numbers. It states the limitation in the same paragraph as the success, not on page 40. And it ends with a recommendation that tells the reader what to do.

The body of the report

Each body section follows the same pattern: the result, the method, the evidence and its checks, the uncertainty, and the implications for the design. Sections are written by their owners, so Fatima writes structures and Lucas the battery, but Priya edits the whole report for a single voice, consistent terms and consistent numbers. The configuration sheet from lesson 1 is the source of every design number; when Grace finds that the wing area appears as 14.0 m² in one section and 13.97 in another, the rule is simple: the sheet says 14.0, so every section says 14.0, and the sizing section explains that the loop converged at 13.97 before rounding.

Calculations are in the appendices, not the body. The body states what was calculated, the key inputs, the result and how it was checked, and refers to the appendix for the detail. The team's Python scripts go into an appendix with their outputs, and into the shared repository with instructions to rerun them, so that the future reader at Prairiewind Aerospace can change the battery specific energy and see what happens. Test data, the full compliance matrix, the risk register, the decision records and the team charter are also appendices.

Figures, tables and numbers

A figure or table must be understandable on its own, because many readers look at figures before reading text. Every figure has a caption that says what it shows and what the reader should notice, axes with quantities and units, and a number that the text cites before the figure appears. A figure that the text never mentions is either unnecessary or a sign that an argument is missing. Tables align numbers by the decimal point, give units in the column heading, and use the same number of significant figures for values of the same precision.

Numbers in the report carry the precision the analysis supports, not the precision the computer printed. The sizing loop gives 768.4 kg; the uncertainty in the empty mass fraction is at least 5 percent, so the report says “about 770 kg”. The weighted score of 3.85 is reported with the sensitivity result next to it, so no reader takes the second decimal place seriously. Illustrative values, such as the fault tree failure rates and the battery price, are labeled as illustrative wherever they appear, including in figure captions and the executive summary.

Checking the report

Before the report goes to the sponsor, three reviews take place. Each author checks their own section against a checklist. Then the team runs a script that checks the report mechanically: word counts against the budgets for each section, figures that are never cited, requirements missing from the compliance matrix, and average sentence length, a rough guide to readability.

# Design report checker: word budgets, figure references, requirement coverage and sentence length
import re
report = {
 'Executive summary': 'The Plover E2 is a two-seat electric trainer for circuit and air-work lessons. It meets nine of ten '
     'requirements at a maximum mass of 772 kg. Figure 1 shows the aircraft. The cost requirement R9 is met only above 200 aircraft in one market.',
 'Requirements': 'Requirements R1 to R10 come from the flight school and the certification basis. Figure 2 shows the mission.',
 'Sizing': 'The sizing loop in Figure 3 closes at 770 kg with a 59 kWh battery. The constraint diagram in Figure 4 sets the '
     'wing loading at 55 kg/m2 and the motor at 70 kW. Requirement R2 drives the battery and R4 drives the motor.',
 'Performance': 'The time-stepped battery simulation shows the reserve intact at end of life at 20 C and lost after a cold soak, '
     'which is why R10 requires pre-conditioning. Figure 6 shows the state of charge through the lesson.',
 'Compliance matrix': 'R1 met. R2 met with the pack at 20 C or warmer. R3 met. R4 met. R5 met. R6 met. R7 met with an 80 kW charger. R8 planned. R10 met by procedure.',
}
figures = {1: 'Plover E2 three-view', 2: 'Design mission', 3: 'Sizing loop', 4: 'Constraint diagram', 5: 'V-n diagram', 6: 'State of charge'}
budget = {'Executive summary': 60, 'Requirements': 40, 'Sizing': 70, 'Performance': 60, 'Compliance matrix': 50}
text = ' '.join(report.values())
for sec, body in report.items():
    words = len(body.split())
    sentences = [s for s in re.split(r'(?<=[.!?])\s+', body) if s]
    avg = words / len(sentences)
    flag = 'over budget' if words > budget[sec] else ''
    print(f'{sec:18s} {words:3d} words (budget {budget[sec]:3d}), {avg:4.1f} words per sentence {flag}')
cited = {int(n) for n in re.findall(r'Figure (\d+)', text)}
print('\nfigures never cited:', ', '.join(f'{n} ({figures[n]})' for n in figures if n not in cited) or 'none')
reqs = {f'R{i}' for i in range(1, 11)}
matrix = set(re.findall(r'\bR\d+\b', report['Compliance matrix']))
print('requirements missing from the compliance matrix:', ', '.join(sorted(reqs - matrix, key=lambda r: int(r[1:]))) or 'none')
print('requirements never discussed outside the matrix:',
      ', '.join(sorted(reqs - set(re.findall(r'\bR\d+\b', text.replace(report['Compliance matrix'], ''))), key=lambda r: int(r[1:]))))

Executive summary   44 words (budget  60), 11.0 words per sentence 
Requirements        18 words (budget  40),  9.0 words per sentence 
Sizing              44 words (budget  70), 14.7 words per sentence 
Performance         37 words (budget  60), 18.5 words per sentence 
Compliance matrix   33 words (budget  50),  3.7 words per sentence 

figures never cited: 5 (V-n diagram)
requirements missing from the compliance matrix: R9
requirements never discussed outside the matrix: R3, R5, R6, R7, R8

The checker finds three things in the draft extracts. Figure 5, the V-n diagram, is never cited, because the performance section that should discuss it was cut down for length; the team restores a paragraph explaining the negative gust result, since it changed the wing design. Requirement R9, the cost target, is missing from the compliance matrix: Owen had left it out because it was “not a technical requirement”, which is exactly the kind of omission that would make a reader suspect the team was hiding a weak result. And five requirements are never discussed outside the matrix. That is acceptable for some, which are simply met, but not for R8, the certification basis, which needs a sentence in the summary saying that compliance is planned, not shown.

The second review is a red team: Arjun and Professor Lindqvist read the draft as hostile reviewers, looking for unsupported claims, missing alternatives and optimistic assumptions. Arjun's most useful comment concerns the battery. The report says that 200 Wh/kg at pack level will be available “by the end of the decade”, but cites only one supplier's road map. He asks the team to show what happens if the value is 180, which the sizing loop already calculated, and to put that result in the executive summary, not only in the appendix.

The third review is by the sponsor's specialists, who check their areas. Marcus finds that the static test of the wing in the certification plan is to limit load only, and points out that it must go to ultimate. Rachel finds that the report says the noise requirement is “met”, when the estimate is from a simple model; the word becomes “expected to be met”.

Honest reporting

The most important quality of a design report is that it can be trusted. The team's earlier decisions make that easier: requirements were set with stakeholders, assumptions were tracked, and bad news was taken to the sponsor early. The report must keep the same standard. Four rules guide it. State what was shown and what was assumed, and keep them separate. Report results that go against the recommendation as prominently as those that support it. Distinguish evidence from tests that were planned as verification from development evidence and from analysis. And cite the sources of data and methods, so that readers can check them and so that the work of others is credited.

Professor Lindqvist adds a professional point. The team members will soon be engineers in training, and in a few years licensed engineers whose signature on a report means that they take responsibility for it. The codes of ethics of the Kansas State Board of Technical Professions and every similar body require that engineers express opinions only on the basis of adequate knowledge, present information honestly, and acknowledge the work of others. A capstone report is a good place to practice the habit.