How to Write a Technical Report

A great program that no one can understand is of limited use. Technical reports are how computing people communicate their work: to instructors, teammates, clients and future maintainers. In courses they appear as lab reports, project reports and capstone documents. At work they take the form of design documents, postmortems and research summaries.

This guide explains how to plan and write a clear technical report, from structure to style, with a checklist you can reuse.

Know your audience and purpose

Before writing, decide:

1. Who will read this? An instructor, a client, a teammate or a future engineer?
2. What do they know already? This sets how much background to include.
3. What should they do or understand afterward? Decide the main message.

State the purpose in one sentence, such as: "This report describes the design and evaluation of a cache for a web service and shows that it reduces average response time by 40 percent." Everything should support it.

The standard structure

Most technical reports follow a similar pattern.

Adjust to the assignment. A lab report may merge several sections, while a capstone will expand them.

Abstract

The abstract is a short summary, usually 150 to 250 words. It states the problem, the approach, the main results and the conclusion. Write it last and make sure it can be understood alone. Avoid citations and undefined jargon.

Introduction

A good introduction does four things.

1. Introduces the problem and why it matters.
2. Explains the limits of existing approaches, if relevant.
3. States your goal and approach.
4. Lists your contributions or findings and outlines the report.

Keep it concise, and avoid long background that belongs in a later section.

Background and related work

Summarize the concepts the reader needs and the key prior work. Compare and contrast, instead of listing. Explain how your work differs. Cite sources accurately, and avoid copying phrases from them.

Design and method

Describe your approach precisely enough that another person could repeat it. Include:

• Requirements and constraints.
• Architecture, with a diagram.
• Algorithms or models, with pseudocode if helpful.
• Data sets and how you prepared them.
• Tools, languages and versions.
• Reasons for key decisions and alternatives you considered.

Use present tense for describing the design and past tense for what you did.

Implementation

Highlight the interesting parts, not every detail. Explain challenges and how you solved them. Show short code snippets that illustrate key ideas, and link to the full repository. A reader should understand how the pieces fit together.

Evaluation and results

Evidence is the heart of a technical report. Explain:

1. What you measured and why.
2. How you measured it: environment, hardware, data size, number of runs.
3. Baselines and comparisons.
4. Results in tables and charts.
5. Interpretation: what the numbers mean.

Report variability, such as averages with standard deviations, not single runs. Be careful with claims. If results are modest or mixed, say so.

Discussion

Interpret the results in context. Explain surprises, trade-offs, limitations and threats to validity. Discuss what you would do differently. Honest discussion strengthens credibility.

Conclusion and future work

Summarize the problem, approach and key results in a paragraph or two. Suggest concrete next steps. Do not introduce new results.

Figures, tables and code listings

Visuals make reports easier to read when used well.

• Number and caption every figure and table, and refer to them in the text.
• Label axes and units.
• Keep diagrams simple, with consistent symbols.
• Choose chart types that fit the message: lines for trends, bars for comparisons.
• Format code in a monospaced font with line numbers when needed, and keep listings short.
• Make visuals readable in black and white.

The guide to commenting and documenting code offers tips on explaining code clearly.

Writing style

Technical writing values clarity over flourish.

1. Use short, direct sentences.
2. Define terms and acronyms on first use.
3. Prefer active voice where it reads naturally.
4. Be precise: give numbers, versions and conditions.
5. Avoid vague words like "fast," "many" or "better" without data.
6. Keep paragraphs focused on one idea.
7. Use headings and lists for navigation.
8. Stay consistent in terminology.

Citing sources

Cite papers, documentation, datasets and code you reuse. Use the style your course requires, such as IEEE or ACM, and keep a consistent format. Quote sparingly. Give credit for ideas as well as words, and respect licenses for code and data.

Revising

Draft first, then revise in passes.

1. Structure: does the order make sense?
2. Argument: does each section support the main message?
3. Evidence: is each claim supported by data?
4. Clarity: can a newcomer follow it?
5. Style: trim wordiness and fix grammar.
6. Formatting: headings, captions, references.

Read aloud, and ask a classmate to read and tell you what they think the main point is. If their answer differs from yours, revise.

A short example of clear technical writing

Compare two ways of reporting a result. The weak version says: "Our cache made the system much faster." The strong version says: "Adding a least-recently-used cache of 1,000 entries reduced the median response time from 180 ms to 105 ms (42 percent) across 20 runs of 10,000 requests; the 95th percentile fell from 410 ms to 260 ms. The improvement was smaller when the working set exceeded the cache size."

The strong version names the change, gives numbers, states how many runs were made, reports a second measure and notes a limit. A reader can judge it and repeat it. That is the standard to aim for in every section.

Writing as you build

Do not wait until the end of a project to start writing. Keep a running notes file with design decisions, experiments and results, with dates. Save screenshots and graphs as you create them. When it is time to write, you will assemble a report from material you already have, not try to remember what happened weeks ago. Many students find that a few notes after each work session save hours later.

Working with a template

Many schools and journals provide templates. Use them early so that formatting does not become a last-minute scramble. Learn your tools for references and figures. A document editor with styles, or a typesetting system such as LaTeX if your course uses it, makes structure and numbering automatic. Spend an hour learning the tool, and it will pay off across many reports.

Reports for different audiences

A report for an instructor can assume the course background, while a report for a client must explain terms and focus on outcomes. A report for future maintainers should emphasize design decisions and how to run, test and extend the system. If you must serve several audiences, put a plain-language summary at the start and technical detail in later sections or appendices. Tell each reader where to look.

Common mistakes

• Describing everything without a clear message.
• Skipping the problem statement.
• Results without methods, or the reverse.
• Unlabeled figures.
• Pasting large code blocks with no explanation.
• Overstated claims.
• Missing references.
• Leaving writing for the last night.

How to write a computer science capstone applies these ideas to the largest report most students write.

A final checklist

1. The purpose is clear in the first paragraph.
2. The abstract matches the report.
3. Methods are detailed enough to reproduce.
4. Results are presented with context and uncertainty.
5. Figures and tables are numbered, captioned and cited.
6. Claims are supported and limitations are stated.
7. References are complete and consistent.
8. The writing is proofread.

Final thoughts

A good technical report makes complex work understandable. Know your audience, follow a clear structure, show your evidence and write plainly. These skills will serve you in every computing job, where writing is a daily part of engineering.