Engineering capstone teams spend months designing, building, and testing a product, and then write the report in the final week. The result is often a long document that describes what was done in loose chronological order, with figures that are not explained and conclusions that overstate the results. Instructors who grade dozens of such reports know how much time goes into finding the actual engineering decisions buried in the narrative.

A report in engineering has a distinct job. It must let a reader who was not on the team understand the problem, see why the design choices were made, verify that the design meets requirements, and know what remains uncertain. Students who learn to write this way are preparing for the documents they will produce on the job, from design reviews to test reports.

A rubric built around these functions helps instructors read quickly and gives students a clear target. The sections below describe the criteria that matter most. Reading in this order also lets an instructor judge a team quickly, since a report that fails to state testable requirements rarely recovers later in the document, however polished the writing may be, and it gives students a checklist to follow before the final week.

Start with the problem and the requirements

A strong report states the problem in terms of the user's need and translates it into specific, measurable requirements, such as a load capacity, a cost limit, or a response time. Check whether the requirements are testable and whether the rest of the report refers back to them. When requirements are vague, the testing and conclusions that follow tend to be vague as well.

• Require measurable, testable requirements near the start
• Look for compared alternatives and reasons for each design choice
• Check that calculations show units and stated assumptions
• Reward honest reporting of failures and uncertainty
• Frame feedback as questions a reviewing engineer would ask

Judge the justification of design decisions

The heart of the report is the reasoning behind the design. Look for evidence that students considered alternatives, compared them against criteria, and chose with reasons, whether through a decision matrix, calculations, or prototypes. A report that describes the final design without explaining why it was chosen over others leaves the reader unable to evaluate the engineering judgment, which is exactly what a client or review board would need to know.

Check that calculations and assumptions are shown and sensible. A single sample calculation with units, followed by a table of results, is usually enough, but the assumptions behind it must be stated. Mark errors in units carefully, since they signal larger problems, such as a misunderstanding of the physical quantity involved or a transcription error that carried into later results, and a short note explaining the error teaches more than a deduction alone.

Score testing and honest reporting of results

Testing sections should describe the method, present results clearly, and compare them with the requirements. Reward students who report results that fall short and discuss why, rather than glossing over failures. Honest treatment of limitations and uncertainty, such as measurement error or small sample size, is a hallmark of professional engineering, where a clearly stated limitation builds more trust with a client than a perfect-looking result nobody can verify.

Examine figures, tables, and captions as part of the grade. Each should be numbered, referenced in the text, and understandable on its own. Students often include unexplained graphs that the reader cannot interpret, and a quick check of two or three figures per report will usually reveal whether the team understood what it was presenting, so spend your reading time there before you read the surrounding text.

Give feedback that mirrors a design review

Frame feedback as questions a reviewing engineer would ask, such as how did you decide on this material, or what happens if the load doubles. Students learn to anticipate the questions and address them in the report. This also prepares them for oral defenses and client presentations, where the same questions will arrive in real time and without the chance to revise first, so practicing the answers on paper is a low-risk rehearsal.

Where a program allows it, a rubric-based tool can give teams a first read on organization, clarity, and whether each required section is complete, so instructors can focus on technical reasoning, with technical content verified by faculty. The tool cannot judge whether a design is safe or sound. That responsibility stays with the people who teach the field, and with the engineers who will eventually sign off on real designs.