technical report research definition

Libraries | Research Guides

Technical reports, technical reports: a definition, search engines & databases, multi-disciplinary technical report repositories, topical technical report repositories.

"A technical report is a document that describes the process, progress, or results of technical or scientific research or the state of a technical or scientific research problem. It might also include recommendations and conclusions of the research."      https://en.wikipedia.org/wiki/Technical_report

Technical reports are produced by corporations, academic institutions, and government agencies at all levels of government, e.g. state, federal, and international.  Technical reports are not included in formal publication and distribution channels and therefore fall into the category of grey literature .

• Science.gov Searches over 60 databases and over 2,200 scientific websites hosted by U.S. federal government agencies. Not limited to tech reports.
• WorldWideScience.org A global science gateway comprised of national and international scientific databases and portals, providing real-time searching and translation of globally-dispersed multilingual scientific literature.
• Open Grey System for Information on Grey Literature in Europe, is your open access to 700.000 bibliographical references. more... less... OpenGrey covers Science, Technology, Biomedical Science, Economics, Social Science and Humanities.
• National Technical Reports Library (NTRL) This link opens in a new window The National Technical Reports Library provides indexing and access to a collection of more than two million historical and current government technical reports of U.S. government-sponsored research. Full-text available for 700,000 of the 2.2 million items described. Dates covered include 1900-present.
• Argonne National Lab: Scientific Publications While sponsored by the US Dept of Energy, research at Argonne National Laboratory is wide ranging (see Research Index )
• Defense Technical Information Center (DTIC) The Defense Technical Information Center (DTIC®) has served the information needs of the Defense community for more than 65 years. It provides technical research, development, testing & evaluation information; including but not limited to: journal articles, conference proceedings, test results, theses and dissertations, studies & analyses, and technical reports & memos.
• HathiTrust This repository of books digitized by member libraries includes a large number of technical reports. Search by keywords, specific report title, or identifiers.
• Lawrence Berkeley National Lab (LBNL) LBNL a multiprogram science lab in the national laboratory system supported by the U.S. Department of Energy through its Office of Science. It is managed by the University of California and is charged with conducting unclassified research across a wide range of scientific disciplines.
• National Institute of Standards and Technology (NIST) NIST is one of the nation's oldest physical science laboratories.
• RAND Corporation RAND's research and analysis address issues that impact people around the world including security, health, education, sustainability, growth, and development. Much of this research is carried out on behalf of public and private grantors and clients.
• TRAIL Technical Report Archive & Image Library Identifies, acquires, catalogs, digitizes and provides unrestricted access to U.S. government agency technical reports. TRAIL is a membership organization . more... less... Majority of content is pre-1976, but some reports after that date are included.

Aerospace / Aviation

• Contrails 20th century aerospace research, hosted at the Illinois Institute of Technology
• Jet Propulsion Laboratory Technical Reports Server repository for digital copies of technical publications authored by JPL employees. It includes preprints, meeting papers, conference presentations, some articles, and other publications cleared for external distribution from 1992 to the present.
• NTRS - NASA Technical Reports Server The NASA STI Repository (also known as the NASA Technical Reports Server (NTRS)) provides access to NASA metadata records, full-text online documents, images, and videos. The types of information included are conference papers, journal articles, meeting papers, patents, research reports, images, movies, and technical videos – scientific and technical information (STI) created or funded by NASA. Includes NTIS reports.

Computing Research

• Computing Research Repository
• IBM Technical Paper Archive
• Microsoft Research
• INIS International Nuclear Information System One of the world's largest collections of published information on the peaceful uses of nuclear science and technology.
• Oak Ridge National Laboratory Research Library Primary subject areas covered include chemistry, physics, materials science, biological and environmental sciences, computer science, mathematics, engineering, nuclear technology, and homeland security.
• OSTI.gov The primary search tool for DOE science, technology, and engineering research and development results more... less... over 70 years of research results from DOE and its predecessor agencies. Research results include journal articles/accepted manuscripts and related metadata; technical reports; scientific research datasets and collections; scientific software; patents; conference and workshop papers; books and theses; and multimedia
• OSTI Open Net Provides access to over 495,000 bibliographic references and 147,000 recently declassified documents, including information declassified in response to Freedom of Information Act requests. In addition to these documents, OpenNet references older document collections from several DOE sources.

Environment

• National Service Center for Environmental Publications From the Environmental Protection Agency
• US Army Corp of Engineers (USACE) Digital Library See in particular the option to search technical reports by the Waterways Experiment Station, Engineering Research and Development Center, and districts .
• National Clearinghouse for Science, Technology and the Law (NCSTL) Forensic research at the intersection of science, technology and law.

Transportation

• ROSA-P National Transportation Library Full-text digital publications, datasets, and other resources. Legacy print materials that have been digitized are collected if they have historic, technical, or national significance.
• Last Updated: Jul 13, 2022 11:46 AM
• URL: https://libguides.northwestern.edu/techreports

• Research Guides
• University Libraries
• Advanced Research Topics

Technical Reports

• What is a Technical report?
• Find Technical Reports
• Print & Microform Tech Reports in the Library
• Author Profile

What is a Technical Report?

What is a Technical Report?  

"A technical report is a document written by a researcher detailing the results of a project and submitted to the sponsor of that project." TRs are not peer-reviewed unless they are subsequently published in a peer-review journal.

Characteristics (TRs vary greatly): Technical reports ....

• may contain data, design criteria, procedures, literature reviews, research history, detailed tables, illustrations/images, explanation of approaches that were unsuccessful.
• may be published before the corresponding journal literature; may have more or different details than  its subsequent journal article.
• may contain less  background information since the sponsor already knows it
• classified and export controlled reports
• may contain obscure acronyms and codes as part of identifying information

Disciplines:

• Physical sciences, engineering, agriculture, biomedical sciences, and the social sciences. education etc.

Documents research and development conducted by:

• government agencies (NASA, Department of Defense (DoD) and Department of Energy (DOE) are top sponsors of research
• commercial companies
• non-profit, non-governmental organizations
• Educational Institutions
• Issued  in print, microform, digital
• Older TRs may have been digitized and are available in fulltext on the Intranet
• Newer TRs should be born digital

Definition used with permission from Georgia Tech. Other sources: Pinelli & Barclay (1994).

• Nation's Report Card: State Reading 2002, Report for Department of Defense Domestic Dependent Elementary and Secondary Schools. U.S. Department of Education Institute of Education Sciences The National Assessment of Educational Progress Reading 2002 The Nation’s
• Study for fabrication, evaluation, and testing of monolayer woven type materials for space suit insulation NASA-CR-166139, ACUREX-TR-79-156. May 1979. Reproduced from the microfiche.
• << Previous: Home
• Next: Find Technical Reports >>
• Last Updated: Sep 1, 2023 11:06 AM
• URL: https://tamu.libguides.com/TR

Penn State University Libraries

Technical reports, recognizing technical reports, recommendations for finding technical reports, databases with technical reports, other tools for finding technical reports.

• Direct Links to Organizations with Technical Reports
• Techical report collections at Penn State
• How to Write

Engineering Instruction Librarian

Engineering Librarian

Technical reports describe the process, progress, or results of technical or scientific research and usually include in-depth experimental details, data, and results. Technical reports are usually produced to report on a specific research need and can serve as a report of accountability to the organization funding the research. They provide access to the information before it is published elsewhere. Technical Reports are usually not peer reviewed.  They need to be evaluated on how the problem, research method, and results are described.  

A technical report citation will include a report number and will probably not have journal name. 

Technical reports can be divided into two general categories:

• Non-Governmental Reports- these are published by companies and engineering societies, such as Lockheed-Martin, AIAA (American Institute of Aeronautical and Astronautics), IEEE (Institute of Electrical and Electronics Engineers), or SAE (Society of Automotive Engineers).
• Governmental Reports- the research conducted in these reports has been sponsored by the United States or an international government body as well as state and local governments.

Some technical reports are cataloged as books, which you can search for in the catalog, while others may be located in databases, or free online. The boxes below list databases and online resources you can use to locate a report. 

If you’re not sure where to start, try to learn more about the report by confirming the full title or learning more about the publication information. 

Confirm the title and locate the report number in NTRL. 

Search Google Scholar, the HathiTrust, or WorldCat. This can verify the accuracy of the citation and determine if the technical report was also published in a journal or conference proceeding or under a different report number. 

Having trouble finding a report through Penn State? If we don’t have access to the report, you can submit an interlibrary loan request and we will get it for you from another library. If you have any questions, you can always contact a librarian! 

• National Technical Reports Library (NTRL) NTRL is the preeminent resource for accessing the latest US government sponsored research, and worldwide scientific, technical, and engineering information. Search by title to determine report number.
• Engineering Village Engineering Village is the most comprehensive interdisciplinary engineering database in the world with over 5,000 engineering journals and conference materials dating from 1884. Has citations to many ASME, ASCE, SAE, and other professional organizations' technical papers. Search by author, title, or report number.
• IEEE Xplore Provides access to articles, papers, reports, and standards from the Institute of Electrical and Electronics Engineers (IEEE).
• ASABE Technical Library Provides access to all of the recent technical documents published by the American Society of Agricultural Engineers.
• International Nuclear Information System (INIS) Database Provides access to nuclear science and technology technical reports.
• NASA Technical Reports Server Contains the searchable NACA Technical Reports collection, NASA Technical Reports collection and NIX collection of images, movies, and videos. Includes the full text and bibliographic records of selected unclassified, publicly available NASA-sponsored technical reports. Coverage: NACA reports 1915-1958, NASA reports since 1958.
• OSTI Technical Reports Full-text of Department of Energy (DOE) funded science, technology, and engineering technical reports. OSTI has replaced SciTech Connect as the primary search tool for Department of Energy (DOE) funded science, technology, and engineering research results. It provides access to all the information previously available in SciTech Connect, DOE Information Bridge, and Energy Citations Database.
• ERIC (ProQuest) Provides access to technical reports and other education-related materials. ERIC is sponsored by the U.S. Department of Education, Institute of Education Sciences (IES).
• Transportation Research International Documentation (TRID) TRID is a newly integrated database that combines the records from TRB's Transportation Research Information Services (TRIS) Database and the OECD's Joint Transport Research Centre's International Transport Research Documentation (ITRD) Database. TRID provides access to over 900,000 records of transportation research worldwide.
• TRAIL Technical Reports Archive & Image Library Provide access to federal technical reports issued prior to 1975.
• Defense Technical Information Center (DTIC) The largest central resource for Department of Defense and government-funded scientific, technical, engineering, and business related information.
• Correlation Index of Technical Reports (AD-PB Reports) Publication Date: 1958
• Criss-cross directory of NASA "N" numbers and DOD "AD" numbers, 1962-1986

Print indexes to technical reports :

• Government Reports Announcements & Index (1971-1996)
• Government Reports Announcements (1946-1975)
• U.S. Government Research & Development Reports (1965-1971)
• U.S. Government Research Reports (1954-1964)
• Bibliography of Technical Reports (1949-1954)
• Bibliography of Scientific and Industrial Reports (1946-1949)
• Next: Direct Links to Organizations with Technical Reports >>
• Last Updated: Oct 5, 2023 2:56 PM
• URL: https://guides.libraries.psu.edu/techreports

Technical Report: What is it & How to Write it? (Steps & Structure Included)

A technical report can either act as a cherry on top of your project or can ruin the entire dough.

Everything depends on how you write and present it.

A technical report is a sole medium through which the audience and readers of your project can understand the entire process of your research or experimentation.

So, you basically have to write a report on how you managed to do that research, steps you followed, events that occurred, etc., taking the reader from the ideation of the process and then to the conclusion or findings.

Sounds exhausting, doesn’t it?

Well hopefully after reading this entire article, it won’t.

However, note that there is no specific standard determined to write a technical report. It depends on the type of project and the preference of your project supervisor.

With that in mind, let’s dig right in!

What is a Technical Report? (Definition)

A technical report is described as a written scientific document that conveys information about technical research in an objective and fact-based manner. This technical report consists of the three key features of a research i.e process, progress, and results associated with it.

Some common areas in which technical reports are used are agriculture, engineering, physical, and biomedical science. So, such complicated information must be conveyed by a report that is easily readable and efficient.

Now, how do we decide on the readability level?

The answer is simple – by knowing our target audience.

A technical report is considered as a product that comes with your research, like a guide for it.

You study the target audience of a product before creating it, right?

Similarly, before writing a technical report, you must keep in mind who your reader is going to be.

Whether it is professors, industry professionals, or even customers looking to buy your project – studying the target audience enables you to start structuring your report. It gives you an idea of the existing knowledge level of the reader and how much information you need to put in the report.

Many people tend to put in fewer efforts in the report than what they did in the actual research..which is only fair.

We mean, you’ve already worked so much, why should you go through the entire process again to create a report?

Well then, let’s move to the second section where we talk about why it is absolutely essential to write a technical report accompanying your project.

Read more:  What is a Progress Report and How to Write One?

Importance of Writing a Technical Report 

1. efficient communication.

Technical reports are used by industries to convey pertinent information to upper management. This information is then used to make crucial decisions that would impact the company in the future.

Examples of such technical reports include proposals, regulations, manuals, procedures, requests, progress reports, emails, and memos.

2. Evidence for your work

Most of the technical work is backed by software.

However, graduation projects are not.

So, if you’re a student, your technical report acts as the sole evidence of your work. It shows the steps you took for the research and glorifies your efforts for a better evaluation.

3. Organizes the data 

A technical report is a concise, factual piece of information that is aligned and designed in a standard manner. It is the one place where all the data of a project is written in a compact manner that is easily understandable by a reader.

4. Tool for evaluation of your work 

Professors and supervisors mainly evaluate your research project based on the technical write-up for it. If your report is accurate, clear, and comprehensible, you will surely bag a good grade.

A technical report to research is like Robin to Batman.

Best results occur when both of them work together.

So, how can you write a technical report that leaves the readers in a ‘wow’ mode? Let’s find out!

How to Write a Technical Report? 

When writing a technical report, there are two approaches you can follow, depending on what suits you the best.

• Top-down approach- In this, you structure the entire report from title to sub-sections and conclusion and then start putting in the matter in the respective chapters. This allows your thought process to have a defined flow and thus helps in time management as well.
• Evolutionary delivery- This approach is suitable if you’re someone who believes in ‘go with the flow’. Here the author writes and decides as and when the work progresses. This gives you a broad thinking horizon. You can even add and edit certain parts when some new idea or inspiration strikes.

A technical report must have a defined structure that is easy to navigate and clearly portrays the objective of the report. Here is a list of pages, set in the order that you should include in your technical report.

Cover page- It is the face of your project. So, it must contain details like title, name of the author, name of the institution with its logo. It should be a simple yet eye-catching page.

Title page- In addition to all the information on the cover page, the title page also informs the reader about the status of the project. For instance, technical report part 1, final report, etc. The name of the mentor or supervisor is also mentioned on this page.

Abstract- Also referred to as the executive summary, this page gives a concise and clear overview of the project. It is written in such a manner that a person only reading the abstract can gain complete information on the project.

Preface – It is an announcement page wherein you specify that you have given due credits to all the sources and that no part of your research is plagiarised. The findings are of your own experimentation and research.

Dedication- This is an optional page when an author wants to dedicate their study to a loved one. It is a small sentence in the middle of a new page. It is mostly used in theses.

Acknowledgment- Here, you acknowledge the people parties, and institutions who helped you in the process or inspired you for the idea of it.

Table of contents – Each chapter and its subchapter is carefully divided into this section for easy navigation in the project. If you have included symbols, then a similar nomenclature page is also made. Similarly, if you’ve used a lot of graphs and tables, you need to create a separate content page for that. Each of these lists begins on a new page.

Introduction- Finally comes the introduction, marking the beginning of your project. On this page, you must clearly specify the context of the report. It includes specifying the purpose, objectives of the project, the questions you have answered in your report, and sometimes an overview of the report is also provided. Note that your conclusion should answer the objective questions.

Central Chapter(s)- Each chapter should be clearly defined with sub and sub-sub sections if needed. Every section should serve a purpose. While writing the central chapter, keep in mind the following factors:

• Clearly define the purpose of each chapter in its introduction.
• Any assumptions you are taking for this study should be mentioned. For instance, if your report is targeting globally or a specific country. There can be many assumptions in a report. Your work can be disregarded if it is not mentioned every time you talk about the topic.
• Results you portray must be verifiable and not based upon your opinion. (Big no to opinions!)
• Each conclusion drawn must be connected to some central chapter.

Conclusion- The purpose of the conclusion is to basically conclude any and everything that you talked about in your project. Mention the findings of each chapter, objectives reached, and the extent to which the given objectives were reached. Discuss the implications of the findings and the significant contribution your research made.

Appendices- They are used for complete sets of data, long mathematical formulas, tables, and figures. Items in the appendices should be mentioned in the order they were used in the project.

References- This is a very crucial part of your report. It cites the sources from which the information has been taken from. This may be figures, statistics, graphs, or word-to-word sentences. The absence of this section can pose a legal threat for you. While writing references, give due credit to the sources and show your support to other people who have studied the same genres.

Bibliography- Many people tend to get confused between references and bibliography. Let us clear it out for you. References are the actual material you take into your research, previously published by someone else. Whereas a bibliography is an account of all the data you read, got inspired from, or gained knowledge from, which is not necessarily a direct part of your research.

Style ( Pointers to remember )

Let’s take a look at the writing style you should follow while writing a technical report:

• Avoid using slang or informal words. For instance, use ‘cannot’ instead of can’t.
• Use a third-person tone and avoid using words like I, Me.
• Each sentence should be grammatically complete with an object and subject.
• Two sentences should not be linked via a comma.
• Avoid the use of passive voice.
• Tenses should be carefully employed. Use present for something that is still viable and past for something no longer applicable.
• Readers should be kept in mind while writing. Avoid giving them instructions. Your work is to make their work of evaluation easier.
• Abbreviations should be avoided and if used, the full form should be mentioned.
• Understand the difference between a numbered and bulleted list. Numbering is used when something is explained sequence-wise. Whereas bullets are used to just list out points in which sequence is not important.
• All the preliminary pages (title, abstract, preface..) should be named in small roman numerals. ( i, ii, iv..)
• All the other pages should be named in Arabic numerals (1,2,3..) thus, your report begins with 1 – on the introduction page.
• Separate long texts into small paragraphs to keep the reader engaged. A paragraph should not be more than 10 lines.
• Do not incorporate too many fonts. Use standard times new roman 12pt for the text. You can use bold for headlines.

Proofreading

If you think your work ends when the report ends, think again. Proofreading the report is a very important step. While proofreading you see your work from a reader’s point of view and you can correct any small mistakes you might have done while typing. Check everything from content to layout, and style of writing.

Presentation

Finally comes the presentation of the report in which you submit it to an evaluator.

• It should be printed single-sided on an A4 size paper. double side printing looks chaotic and messy.
• Margins should be equal throughout the report.

• You can use single staples on the left side for binding or use binders if the report is long.

AND VOILA! You’re done.

…and don’t worry, if the above process seems like too much for you, Bit.ai is here to help.

Read more:  Technical Manual: What, Types & How to Create One? (Steps Included)

Bit.ai : The Ultimate Tool for Writing Technical Reports

What if we tell you that the entire structure of a technical report explained in this article is already done and designed for you!

Yes, you read that right.

With Bit.ai’s 70+ templates , all you have to do is insert your text in a pre-formatted document that has been designed to appeal to the creative nerve of the reader.

You can even add collaborators who can proofread or edit your work in real-time. You can also highlight text, @mention collaborators, and make comments!

Wait, there’s more! When you send your document to the evaluators, you can even trace who read it, how much time they spent on it, and more.

Exciting, isn’t it?

Start making your fabulous technical report with Bit.ai today!

Few technical documents templates you might be interested in:

• Status Report Template
• API Documentation
• Product Requirements Document Template
• Software Design Document Template
• Software Requirements Document Template
• UX Research Template
• Issue Tracker Template
• Release Notes Template
• Statement of Work
• Scope of Work Template

Wrap up(Conclusion)

A well structured and designed report adds credibility to your research work. You can rely on bit.ai for that part.

However, the content is still yours so remember to make it worth it.

After finishing up your report, ask yourself:

Does the abstract summarize the objectives and methods employed in the paper?

Are the objective questions answered in your conclusion?

What are the implications of the findings and how is your work making a change in the way that particular topic is read and conceived?

If you find logical answers to these, then you have done a good job!

Remember, writing isn’t an overnight process. ideas won’t just arrive. Give yourself space and time for inspiration to strike and then write it down. Good writing has no shortcuts, it takes practice.

But at least now that you’ve bit.ai in the back of your pocket, you don’t have to worry about the design and formatting!

Have you written any technical reports before? If yes, what tools did you use? Do let us know by tweeting us @bit_docs.

Further reads:

How To Create An Effective Status Report?

7 Types of Reports Your Business Certainly Needs!

What is Project Status Report Documentation?

Scientific Paper: What is it & How to Write it? (Steps and Format)

  Business Report: What is it & How to Write it? (Steps & Format)

How to Write Project Reports that ‘Wow’ Your Clients? (Template Included)

Business Report: What is it & How to Write it? (Steps & Format)

Internship Cover Letter: How to Write a Perfect one?

Related posts

User guide: how to write an effective one (tips, examples & more), what is project planning: a step by step guide, workflow automation & everything you need to know, client portals: communicate with clients the right way, how to create partnership marketing plan (template included), top 12 ai assistants of 2024 for maximized potential.

About Bit.ai

Bit.ai is the essential next-gen workplace and document collaboration platform. that helps teams share knowledge by connecting any type of digital content. With this intuitive, cloud-based solution, anyone can work visually and collaborate in real-time while creating internal notes, team projects, knowledge bases, client-facing content, and more.

The smartest online Google Docs and Word alternative, Bit.ai is used in over 100 countries by professionals everywhere, from IT teams creating internal documentation and knowledge bases, to sales and marketing teams sharing client materials and client portals.

👉👉Click Here to Check out Bit.ai.

Recent Posts

9 knowledge base mistakes: what you need to know to avoid them, personal user manual: enhance professional profile & team productivity, 9 document management trends every business should know, ai for social media marketing: tools & tactics to boost engagement, a guide to building a client portal for your online course, knowledge management vs document management.

Guide to Technical Reports: What it is and How to Write it

Introduction.

You want to improve the customers’ experience with your products, but your team is too busy creating and/or updating products to write a report.

Getting them ready for the task is another problem you need to overcome. 

Who wants to write a technical report on the exact process you just conducted? 

Exactly, no one.

Honestly, we get it: you’re supposed to be managing coding geniuses — not writers.

But it's one of those things you need to get it done for sound decision-making and ensuring communication transparency. In many organizations, engineers spend nearly 40 percent of their time writing technical reports.

If you're wondering how to write good technical reports that convey your development process and results in the shortest time possible, we've got you covered. 

Let’s start with the basics.  

What is a technical report?

A technical report is a piece of documentation developed by technical writers and/or the software team outlining the process of:

• The research conducted.
• How it advances.
• The results obtained.

In layman's terms, a technical report is created to accompany a product, like a manual. Along with the research conducted, a technical report also summarizes the conclusion and recommendations of the research.

The idea behind building technical documentation is to create a single source of truth about the product and including any product-related information that may be insightful down the line.

Industries like engineering, IT, medicine and marketing use technical documentation to explain the process of how a product was created. 

Ideally, you should start documenting the process when a product is in development, or already in use. A good technical report has the following elements:

• Functionality.
• Development. 

Gone are the days when technical reports used to be boring yawn-inducing dry text. Today, you can make them interactive and engaging using screenshots, charts, diagrams, tables, and similar visual assets.

💡 ‎Related resource: 5 Software Documentation Challenges & How To Overcome Them

Who is responsible for creating reports?

Anyone with a clear knowledge of the industry and the product can write a technical report by following simple writing rules. 

It's possible your developers will be too busy developing the product to demonstrate the product development process.

Keeping this in mind, you can have them cover the main points and send off the writing part to the writing team. Hiring a technical writer can also be beneficial, who can collaborate with the development and operations team to create the report.

Why is technical documentation crucial for a business?

If you’re wondering about the benefits of writing a report, here are three reasons to convince you why creating and maintaining technical documentation is a worthy cause. 

1. Easy communication of the process

Technical reports give you a more transparent way to communicate the process behind the software development to the upper management or the stakeholders. 

You can also show the technical report to your readers interested in understanding the behind the scenes (BTS) action of product development. Treat this as a chance to show value and the methodology behind the same. 

🎓 ‎ The Ultimate Product Development Checklist

2. Demonstrating the problem & solution

You can use technical documentation tools to create and share assets that make your target audience aware of the problem.

Technical reports can shed more light on the problem they’re facing while simultaneously positioning your product as the best solution for it. 

3. Influence upper management decisions 

Technical reports are also handy for conveying the product's value and functionality to the stakeholders and the upper management, opening up the communication channel between them and other employees. 

You can also use this way to throw light on complex technical nuances and help them understand the jargon better.

Benefits of creating technical reports

The following are some of the biggest benefits of technical documentation:

• Cuts down customer support tickets, enabling users to easily use the product without technical complications. 
• Lets you share detailed knowledge of the product's usability and potential, showing every aspect to the user as clearly as possible.  
• Enables customer success teams to answer user questions promptly and effectively.
• Creates a clear roadmap for future products. 
• Improves efficiency for other employees in the form of technical training.

The 5 types of technical reports

There are not just one but five types of technical reports you can create. These include:

1. Feasibility report 

This report is prepared during the initial stages of software development to determine whether the proposed project will be successful. 

2. Business report

This report outlines the vision, objectives and goals of the business while laying down the steps needed to crush those goals. 

3. Technical specification report

This report specifies the essentials for a product or project and details related to the development and design. 

4. Research report 

This report includes information on the methodology and outcomes based on any experimentation. 

5. Recommendation report

This report contains all the recommendations the DevOps team can use to solve potential technical problems.

The type of technical report you choose depends on certain factors like your goals, the complexity of the product and its requirements. 

What are the key elements of a technical report?

Following technical documentation best practices , you want the presented information to be clear and well-organized. Here are the elements (or sections) a typical technical report should have:

This part is simple and usually contains the names of the authors, your company name, logo and so on. 

Synopses are usually a couple of paragraphs long, but it sets the scene for the readers. It outlines the problem to be solved, the methods used, purpose and concept of the report. 

You can’t just write the title of the project here, and call it a day. This page should also include information about the author, their company position and submission date, among other things. The name and position of the supervisor or mentor is also mentioned here. 

The abstract is a brief summary of the project addressed to the readers. It gives a clear overview of the project and helps readers decide whether they want to read the report. 

The foreword is a page dedicated to acknowledging all the sources used to write this report. It gives assurance that no part of the report is plagiarized and all the necessary sources have been cited and given credit to. 

Acknowledgment 

This page is used for acknowledging people and institutions who helped in completing the report. 

Table of Contents 

Adding a table of contents makes navigating from one section to another easier for readers. It acts as a compass for the structure of the report.

List of illustrations 

This part contains all the graphs, diagrams, images, charts and tables used across the report. Ideally, it should have all the materials supporting the content presented in the report. 

The introduction is a very crucial part of the project that should specify the context of the project, along with its purpose and objective. Things like background information, scope of work and limitations are discussed under this section.

The body of the report is generally divided into sections and subsections that clearly define the purpose of each area, ideas, purpose and central scope of work. 

Conclusion 

The conclusion should have an answer to all the questions and arguments made in the introduction or body of the report. It should answer the objectives of the findings, the results achieved and any further observations made.

This part lists the mathematical formulas and data used in the content, following the same order as they were used in the report.

The page cites the sources from which information was taken. Any quotes, graphs and statistics used in your report need to be credited to the original source. 

A glossary is the index of all the terms and symbols used in the report.

Bibliography 

The bibliography outlines the names of all the books and data you researched to gain knowledge on the subject matter.

How to create your own technical report in 6 simple steps

To create a high-quality technical report, you need to follow these 5 steps. 

Step 1: Research

If you’ve taken part in the product development process, this part comes easily. But if you’ve not participated in the development (or are hiring a writer), you need to learn as much about the product as possible to understand it in and out. 

While doing your research, you need to think from your target users' perspectives. 

• You have to know if they’re tech-savvy or not. Whether they understand industry technicalities and jargon or not?
• What goals do you want to achieve with the report? What do you want the final outcome to look like for your users?
• What do you want to convey using the report and why?
• What problems are you solving with the report, and how are you solving them?

This will help you better understand the audience you’re writing for and create a truly valuable document. 

Step 2: Design

You need to make it simple for users to consume and navigate through the report. 

The structure is a crucial element to help your users get familiar with your product and skim through sections. Some points to keep in mind are:

• Outlining : Create an outline of the technical report before you start writing. This will ensure that the DevOps team and the writer are on the same page.
• Table of contents : Make it easy for your users to skip to any part of the report they want without scrolling through the entire document.
• Easy to read and understand : Make the report easy to read and define all technical terms, if your users aren’t aware of them. Explain everything in detail, adding as many practical examples and case studies as possible. 
• Interactive : Add images, screenshots, or any other visual aids to make the content interactive and engaging.
• Overview : Including a summary of what's going to be discussed in the next sections adds a great touch to the report.
• FAQ section : An underrated part of creating a report is adding a FAQ section at the end that addresses users' objections or queries regarding the product.

Step 3: Write 

Writing content is vital, as it forms the body of the report. Ensure the content quality is strong by using the following tips:

• Create a writing plan. 
• Ensure the sentence structure and wording is clear. 
• Don’t repeat information.
• Explain each and every concept precisely. 
• Maintain consistency in the language used throughout the document
• Understand user requirements and problems, and solve them with your content.
• Avoid using passive voice and informal words. 
• Keep an eye out for grammatical errors.
• Make the presentation of the report clean. 
• Regularly update the report over time.
• Avoid using abbreviations. 

Regardless of whether you hire a writer or write the report yourself, these best practices will help you create a great technical report that provides value to the reader.

Step 4: Format

The next step of writing technical reports is formatting.

You can either use the company style guide provided to you or follow the general rules of report formatting. Here is a quick rundown:

1. Page Numbering (excluding cover page, and back covers).

2. Headers.

• Make it self-explanatory.
• Must be parallel in phrasing.
• Avoid “lone headings.”
• Avoid pronouns .

3. Documentation.

• Cite borrowed information.
• Use in-text citations or a separate page for the same.  

Step 5: Proofread

Don’t finalize the report for publishing before proofreading the entire documentation. 

Our best proofreading advice is to read it aloud after a day or two. If you find any unexplained parts or grammatical mistakes, you can easily fix them and make the necessary changes. You can also consider getting another set of eyes to spot the mistakes you may have missed.

Step 6: Publish

Once your technical report is ready, get it cross-checked by an evaluator. After you get their approval, publish on your website as a gated asset — or print it out as an A4 version for presentation. 

Extra Step: Refreshing

Okay, we added an extra step, but hear us out: your job is not finished after hitting publish. 

Frequent product updates mean you should also refresh the report every now and then to reflect these changes. A good rule of thumb is to refresh any technical documentation every eight to twelve months and update it with the latest information. 

Not only will this eliminate confusion but also ensure your readers get the most value out of the document. 

Making successful technical reports with Scribe

How about developing technical reports faster and without the hassle? 

With Scribe and Scribe’s newest feature, Pages , you can do just that.

Scribe is a leading process documentation tool that does the documenting for you, pat down to capturing and annotating screenshots. Here's one in action.

Pages lets you compile all your guides, instructions and SOPs in a single document, giving you an elaborate and digital technical report you can share with both customers and stakeholders. 

{{banner-default="/banner-ads"}}

Here is a Page showing you how to use Scribe Pages .

Examples of good technical reports

You can use these real-life examples of good technical reports for inspiration and guidance!

• Mediums API Documentation
• Twilio Docs
• The AWS PRD for Container-based Products

Signing off…

Now you know how to write technical documentation , what's next?

Writing your first technical report! Remember, it’s not rocket science. Simply follow the technical writing best practices and the format we shared and you'll be good to go.

Ready to try Scribe?

Related content

• Scribe Gallery
• Help Center
• What's New
• Careers We're Hiring!
• Contact Sales

Technical Reports

Sources for identifying technical reports, what are technical reports, types of reports.

• Government-Based Indexes & Databases
• Subject-Oriented Subscription Databases

For More Help

Chat, email, or schedule a consultation with a subject librarian!

  Ask A Librarian

Social Sciences, Public Policy & Government Information Librarian

There are multiple approaches for identifying technical reports, depending on topic; some of these also contain full text for technical reports:

• Technical report indexes and databases (many of these are government-related)
• Some subject-oriented databases index technical reports and other materials in addition to peer-reviewed journal articles.
• Library search box or library catalog for holdings at the UNH Library
• WorldCat for holdings at other libraries (First Search or Books & Media Worldwide)
• References cited in articles

A technical report is a document written by a researcher detailing the results of a project and submitted to the sponsor of that project. Many technical reports are government sponsored with the Department of Energy, NASA, and the Department of Defense among the top sponsors.  A number of U.S. Government sponsors now make technical reports available full image via the internet. Some technical reports may be available in paper or on microfiche in the UNH Library.

Although technical reports are very heterogeneous, they tend to possess the following characteristics:

• technical reports may be published before the corresponding journal literature
• content may be more detailed than the corresponding journal literature, although there may be less background information since the sponsor already knows it
• technical reports are usually not peer reviewed unless the report is separately published as journal literature
• classified and export-controlled reports have restricted access
• obscure acronyms and codes are frequently used

Above text (with minor revisions) is used by permission and is from Georgia Tech Library's Technical Reports guide.

• Types of Technical Reports Committee on Scientific and Technical Information (COSATI) definitions for technical reports (source: Rutgers University Libraries Technical Reports guide)
• Next: Government-Based Indexes & Databases >>
• Last Updated: May 15, 2024 10:19 AM
• URL: https://libraryguides.unh.edu/technical-reports

Cookies on our website

We use some essential cookies to make this website work.

We'd like to set additional cookies to understand how you use our site. And we'd like to serve you some cookies set by other services to show you relevant content.

• Accessibility
• Staff search
• External website
• Schools & services
• Sussex Direct
• Professional services
• Schools and services
• Engineering and Informatics
• Student handbook
• Engineering and Design
• Study guides

Guide to Technical Report Writing

• Back to previous menu
• Guide to Laboratory Writing

School of Engineering and Informatics (for staff and students)

Table of contents

1 Introduction

2 structure, 3 presentation, 4 planning the report, 5 writing the first draft, 6 revising the first draft, 7 diagrams, graphs, tables and mathematics, 8 the report layout, 10 references to diagrams, graphs, tables and equations, 11 originality and plagiarism, 12 finalising the report and proofreading, 13 the summary, 14 proofreading, 15 word processing / desktop publishing, 16 recommended reading.

A technical report is a formal report designed to convey technical information in a clear and easily accessible format. It is divided into sections which allow different readers to access different levels of information. This guide explains the commonly accepted format for a technical report; explains the purposes of the individual sections; and gives hints on how to go about drafting and refining a report in order to produce an accurate, professional document.

A technical report should contain the following sections;

For technical reports required as part of an assessment, the following presentation guidelines are recommended;

There are some excellent textbooks contain advice about the writing process and how to begin (see Section 16 ). Here is a checklist of the main stages;

• Collect your information. Sources include laboratory handouts and lecture notes, the University Library, the reference books and journals in the Department office. Keep an accurate record of all the published references which you intend to use in your report, by noting down the following information; Journal article: author(s) title of article name of journal (italic or underlined) year of publication volume number (bold) issue number, if provided (in brackets) page numbers Book: author(s) title of book (italic or underlined) edition, if appropriate publisher year of publication N.B. the listing of recommended textbooks in section 2 contains all this information in the correct format.
• Creative phase of planning. Write down topics and ideas from your researched material in random order. Next arrange them into logical groups. Keep note of topics that do not fit into groups in case they come in useful later. Put the groups into a logical sequence which covers the topic of your report.
• Structuring the report. Using your logical sequence of grouped ideas, write out a rough outline of the report with headings and subheadings.

N.B. the listing of recommended textbooks in Section 16 contains all this information in the correct format.

Who is going to read the report? For coursework assignments, the readers might be fellow students and/or faculty markers. In professional contexts, the readers might be managers, clients, project team members. The answer will affect the content and technical level, and is a major consideration in the level of detail required in the introduction.

Begin writing with the main text, not the introduction. Follow your outline in terms of headings and subheadings. Let the ideas flow; do not worry at this stage about style, spelling or word processing. If you get stuck, go back to your outline plan and make more detailed preparatory notes to get the writing flowing again.

Make rough sketches of diagrams or graphs. Keep a numbered list of references as they are included in your writing and put any quoted material inside quotation marks (see Section 11 ).

Write the Conclusion next, followed by the Introduction. Do not write the Summary at this stage.

This is the stage at which your report will start to take shape as a professional, technical document. In revising what you have drafted you must bear in mind the following, important principle;

• the essence of a successful technical report lies in how accurately and concisely it conveys the intended information to the intended readership.

During year 1, term 1 you will be learning how to write formal English for technical communication. This includes examples of the most common pitfalls in the use of English and how to avoid them. Use what you learn and the recommended books to guide you. Most importantly, when you read through what you have written, you must ask yourself these questions;

• Does that sentence/paragraph/section say what I want and mean it to say? If not, write it in a different way.
• Are there any words/sentences/paragraphs which could be removed without affecting the information which I am trying to convey? If so, remove them.

It is often the case that technical information is most concisely and clearly conveyed by means other than words. Imagine how you would describe an electrical circuit layout using words rather than a circuit diagram. Here are some simple guidelines;

The appearance of a report is no less important than its content. An attractive, clearly organised report stands a better chance of being read. Use a standard, 12pt, font, such as Times New Roman, for the main text. Use different font sizes, bold, italic and underline where appropriate but not to excess. Too many changes of type style can look very fussy.

Use heading and sub-headings to break up the text and to guide the reader. They should be based on the logical sequence which you identified at the planning stage but with enough sub-headings to break up the material into manageable chunks. The use of numbering and type size and style can clarify the structure as follows;

• In the main text you must always refer to any diagram, graph or table which you use.
• Label diagrams and graphs as follows; Figure 1.2 Graph of energy output as a function of wave height. In this example, the second diagram in section 1 would be referred to by "...see figure 1.2..."
• Label tables in a similar fashion; Table 3.1 Performance specifications of a range of commercially available GaAsFET devices In this example, the first table in section 3 might be referred to by "...with reference to the performance specifications provided in Table 3.1..."
• Number equations as follows; F(dB) = 10*log 10 (F) (3.6) In this example, the sixth equation in section 3 might be referred to by "...noise figure in decibels as given by eqn (3.6)..."

Whenever you make use of other people's facts or ideas, you must indicate this in the text with a number which refers to an item in the list of references. Any phrases, sentences or paragraphs which are copied unaltered must be enclosed in quotation marks and referenced by a number. Material which is not reproduced unaltered should not be in quotation marks but must still be referenced. It is not sufficient to list the sources of information at the end of the report; you must indicate the sources of information individually within the report using the reference numbering system.

Information that is not referenced is assumed to be either common knowledge or your own work or ideas; if it is not, then it is assumed to be plagiarised i.e. you have knowingly copied someone else's words, facts or ideas without reference, passing them off as your own. This is a serious offence . If the person copied from is a fellow student, then this offence is known as collusion and is equally serious. Examination boards can, and do, impose penalties for these offences ranging from loss of marks to disqualification from the award of a degree

This warning applies equally to information obtained from the Internet. It is very easy for markers to identify words and images that have been copied directly from web sites. If you do this without acknowledging the source of your information and putting the words in quotation marks then your report will be sent to the Investigating Officer and you may be called before a disciplinary panel.

Your report should now be nearly complete with an introduction, main text in sections, conclusions, properly formatted references and bibliography and any appendices. Now you must add the page numbers, contents and title pages and write the summary.

The summary, with the title, should indicate the scope of the report and give the main results and conclusions. It must be intelligible without the rest of the report. Many people may read, and refer to, a report summary but only a few may read the full report, as often happens in a professional organisation.

• Purpose - a short version of the report and a guide to the report.
• Length - short, typically not more than 100-300 words
• Content - provide information, not just a description of the report.

This refers to the checking of every aspect of a piece of written work from the content to the layout and is an absolutely necessary part of the writing process. You should acquire the habit of never sending or submitting any piece of written work, from email to course work, without at least one and preferably several processes of proofreading. In addition, it is not possible for you, as the author of a long piece of writing, to proofread accurately yourself; you are too familiar with what you have written and will not spot all the mistakes.

When you have finished your report, and before you staple it, you must check it very carefully yourself. You should then give it to someone else, e.g. one of your fellow students, to read carefully and check for any errors in content, style, structure and layout. You should record the name of this person in your acknowledgements.

Two useful tips;

• Do not bother with style and formatting of a document until the penultimate or final draft.
• Do not try to get graphics finalised until the text content is complete.
• Davies J.W. Communication Skills - A Guide for Engineering and Applied Science Students (2nd ed., Prentice Hall, 2001)
• van Emden J. Effective communication for Science and Technology (Palgrave 2001)
• van Emden J. A Handbook of Writing for Engineers 2nd ed. (Macmillan 1998)
• van Emden J. and Easteal J. Technical Writing and Speaking, an Introduction (McGraw-Hill 1996)
• Pfeiffer W.S. Pocket Guide to Technical Writing (Prentice Hall 1998)
• Eisenberg A. Effective Technical Communication (McGraw-Hill 1992)

Updated and revised by the Department of Engineering & Design, November 2022

School Office: School of Engineering and Informatics, University of Sussex, Chichester 1 Room 002, Falmer, Brighton, BN1 9QJ [email protected] T 01273 (67) 8195 School Office opening hours: School Office open Monday – Friday 09:00-15:00, phone lines open Monday-Friday 09:00-17:00 School Office location [PDF 1.74MB]

Copyright © 2024, University of Sussex

Want to create or adapt books like this? Learn more about how Pressbooks supports open publishing practices.

1 The Formal Technical Report

For technical reports, formal and informal, readers are generally most interested in process and results. Clear presentation of results is at least as important as the results themselves; therefore, writing a report is an exercise in effective communication of technical information. Results, such as numerical values, designed systems or graphs by themselves are not very useful. To be meaningful to others, results must be supported by a written explanation describing how results were obtained and what significance they hold, or how a designed system actually functions. Although the person reading the report may have a technical background, the author should assume unfamiliarity with related theory and procedures. The author must consider supplying details that may appear obvious or unnecessary. With practice, the technical report writer learns which details to include.

The formal technical report contains a complete, concise, and well-organized description of the work performed and the results obtained. Any given report may contain all of the sections described in these guidelines or a subset, depending upon the report requirements. These requirements are decided by the author and are based on the audience and expected use of the report. Audience and purpose are important considerations in deciding which sections to include and what content to provide. If the purpose is to chronicle work performed in lab, as is typical for an academic lab report, the audience is typically the professor who assigned the work and the contents usually include detailed lab procedure, clear presentation of results, and conclusions based on the evidence provided. For a technical report, the audience may be colleagues, customers, or decision makers. Knowing the audience and what they are expecting to get out of reading the report is of primary consideration when deciding on sections to include and their contents.

There are certain aspects to all reports that are common regardless of audience and expected usage. Rather than relegate these overarching report-writing considerations to a secondary position, these items are presented before detailing the typical organization and contents for technical reports.

Universal Report-Writing Considerations

The items listed in this section are often overlooked by those new to technical report writing. However, these items set the stage for how a technical report is received which can impact the author, positively or negatively. While in an academic setting, the author’s grade could be impacted.  While in a professional setting, it is the author’s career that could be affected. Effective communication can make the difference in career advancement, effective influence on enacting positive change, and propelling ideas from thought to action. The list that follows should become second nature to the technical report writer.

Details to consider that affect credibility:

• Any information in the report that is directly derived or paraphrased from a source must be cited using the proper notation.
• Any information in the report that is directly quoted or copied from a source must be cited using the proper notation.
• Any reference material derived from the web or Internet must come from documentable and credible sources. To evaluate websites critically, begin by verifying the credibility of the author (e.g. – credentials, agency or professional affiliation). Note that peer reviewed materials are generally more dependable sources of information as compared to open source. Peer review involves a community of qualified experts from within a profession who validate the publication of the author. Open source information may be created by non-qualified individuals or agencies which is often not reviewed and/or validated by experts within the field or profession.
• Wikipedia is NOT a credible reference because the information changes over time and authors are not necessarily people with verifiable expertise or credentials.
• Provide an annotated bibliography of all references. Typically, annotations in technical reports indicate what the source was used for and establish the credibility of the source. This is particularly important for sources with credibility issues. However, an annotation can clarify why a source with questionable credibility was used.
• With the increasing availability of Generative Artificial Intelligence (AI) such as provided by ChatGPT, where GPT stands for Generative Pre-trained Transformer, credibility will likely be challenged more frequently and will be more difficult to establish. Generative AI models may provide invalid responses and a knowledgeable reader will pick up on that quickly.
• Make sure to know the consequences if you violate rules provided by your instructor in an academic setting or by your employer in a workplace setting for presenting work by another or by AI as if it were your own (without citation). Additionally, there may be rules on how much of your work can be AI-generated and what annotation you are required to provide when using generative AI. Know the rules and if you can’t find the rules, ASK.
• See Appendix A for information about citing sources and AI-generated content.

Details to consider that affect the professional tone:

• Passive voice: “The circuit resistance will be measured with a digital multimeter”.
• Active voice: “Measure the circuit resistance with a digital multimeter”.
• Avoid using personal pronouns such as “you”, “we”, “our”, “they”, “us” and “I”. Personal pronouns tend to personalize the technical information that is generally objective rather than subjective in nature. The exception is if the work as a whole is meant to instruct than to inform. For example, technical textbooks whose only purpose is to instruct employ personal pronouns.
• Avoid using “it”. When “it” is used, the writing often leads to a lack of clarity for the reader as to what idea/concept “it” is referring to, thus negatively impacting overall clarity of the writing.
• Use correct grammar, punctuation, and spelling. Pay attention to and address spell and grammar check cues from writing software such as Microsoft (MS) Word.  

Details to consider that affect the professional appearance:

• All figures and tables must be neatly presented and should be computer generated. Use a computer software package, such as Paint, Multisim, AutoCAD, or SolidWorks, to draw figures. If inserting a full-page figure, insert it so can be read from the bottom or from the right side of the page . ALL figures and tables must fit within or very close to the page margins.
• Generate ALL equations using an equation editor and provide each equation on its own line. Under normal circumstances, there is no reason to embed an equation within a paragraph.  Depending on presentation and how many equations are involved, number the equations for easy reference.
• Refer to appendix B for information on how to automatically create a Table of Contents and properly number pages.
• If the report includes an abstract, it should be on an unnumbered page after the title page and before the Table of Contents or it can be included on the title page.
• For all hard copy reports, all pages of the report must be 8 ½“ X 11” in size. Any larger pages must be folded so as to fit these dimensions. HOWEVER, in this day and age, an electronic submission is most common. Keep in mind that with an electronic submission, it is easier to provide an appealing look with color since a color printer is not required.

Details to consider that affect readability:

• Every section and sub-section of the report needs to start with an introductory paragraph that provides the context for the section or sub-section.
• Every figure, graph, table, and equation needs to be introduced to the reader prior to being presented to the reader. This introduction provides the context.
• ALWAYS NUMBER AND PROVIDE A TITLE FOR ALL FIGURES .
• Make sure that the verb used can actually operate on the noun. For example, stating “the goal for this report is to observe …” implies that the report can observe when it is likely that the goal of the work reported on is to make certain observations.
• Check for spelling and grammar errors which are often highlighted with cues by the text editing software. Follow capitalization, punctuation, and indentation norms. Remember to capitalize the names of proprietary items such as licensed software.
• Define acronyms and abbreviations prior to using them.

Finally, always consider carefully the context of information provided. Know your audience. Thoughtfully consider if a statement is clearly supported by the information provided without leaving your reader confused. Remember that by the time you are writing a report, you should know the information inside and out, but your audience is reading your report to learn.

Standard Components of a Formal Technical Report

Technical reports should be organized into sections and are typically in the order described in this section. While this is the recommended order, certain reports may lend themselves to either reordering sections and/or excluding sections.

The format for this page may vary, however, the following information is always included: report title, who the report was prepared for, who the report was prepared by, and the date of submission. This is not a numbered page of the report.

An abstract is a concise description of the report including its purpose and most important results . An abstract should not be longer than half a page, single-spaced, and must not contain figures or make reference to them. Technical authors are generally so focused on results that they neglect to clearly state the purpose for the work. That purpose is derived from the objectives or goals, most commonly provided by the person who assigned the work. In stating the purpose, it is critical to include key words that would be used in a database search since searches of abstracts are commonly used by professionals to find information they need to do their jobs and make important decisions. Results are summarized in the abstract but how much quantitative information is provided varies with report audience and purpose. It is common to include maximum percent error found in the experimental results as compared to theory. Do not use any specific technical jargon, abbreviations, or acronyms. This is not a numbered page of the report.

Table of Contents

Include all the report sections and appendices. Typically, sub-sections are also listed. This is not a numbered page of the report.

The Table of Contents is easy to include if you properly use the power of the software used to generate the report. The Table of Contents can be automatically generated and updated if the author uses built in report headings provided in the styles menu. It is worth the time and effort to learn these tools since their application are ultimately time-savers for report writers. Directions are provided in Appendix B on creating a Table of Contents in MS Word using section headings.

Introduction

The length of the Introduction depends on the purpose but the author should strive for brevity, clarity, and interest. Provide the objective(s) of the work, a brief description of the problem, and how it is to be attacked. Provide the reader with an overview of why the work was performed, how the work was performed, and the most interesting results. This can usually be accomplished with ease if the work has clearly stated objectives.

Additionally, the introduction of a technical report concludes with a description of the sections that follow the Introduction. This is done to help the reader get some more detailed information about what might be found in each of the report sections included in the body of the report (this does not include appendices). This can feel awkward but providing that information is the accepted standard practice across industries.

Be careful not to use specific technical jargon or abbreviations such as using the term “oscope” instead of “oscilloscope”. Also, make sure to define any acronyms or abbreviations prior to using them. For example, in a surveying lab report a student might want to refer to the electronic distance measuring (EDM) device. The first time the device is referred to, spell out what the acronym stands for before using the acronym, as demonstrated in the previous sentence. Apply this practice throughout wherever an acronym or abbreviation is used but not yet defined within the report.

Background Theory

The purpose of this section is to include, if necessary, a discussion of relevant background theory. Include theory needed to understand subsequent sections that either the reading audience does not already comprehend or is tied to the purpose for the work and report. For example, a report on resistor-capacitor electric circuits that includes measurement of phase shift would likely include a theoretical description of phase shift. In deciding what should or should not be included as background theory, consider presenting any material specific to the work being reported on that you had to learn prior to performing the work including theoretical equations used to calculate theoretical values that are compared to measured values. This section may be divided into subsections if appropriate. Keep the discussion brief without compromising on content relevant to understanding and refer the reader to and cite outside sources of information where appropriate.

The purpose of this section is to provide detailed development of any design included in the report. Do not provide a design section if there is no design aspect to the work. Be sure to introduce and describe the design work within the context of the problem statement using sentences; a series of equations without description and context is insufficient. Use citations if you wish to refer the reader to reference material. Divide this section into subsections where appropriate. For example, a project may consist of designing several circuits that are subsequently interconnected; you may choose to treat each circuit design in its own subsection. The process followed to develop the design should be presented as generally as possible then applied using specific numbers for the work performed. Ultimately, the section must provide the actual design tested and include a clear presentation of how that design was developed.

Theoretical Analysis

Although a theoretical analysis might be part of a design, the author needs to decide if that analysis should be included as part of the design section or a separate section. Typically, any theoretical work performed to develop the design would be included in the design section but any theoretical analysis performed on the design would be included in a separate section. Do not provide a theoretical analysis section if the theoretical work is all described as part of background theory and design sections. However, in most cases, a theoretical analysis section is included to provide important details of all analyses performed. Be brief. It is not necessary to show every step; sentences can be used to describe the intermediate steps. Furthermore, if there are many steps, the reader should be directed to an appendix for complete details. Make sure to perform the analysis with the specific numbers for the work performed leading to the theoretical values reported on and compared to experimental values in the results section of the report. Worth repeating: perform the analyses resulting in the numbers that are included as the theoretical values in the results section of the report. Upon reading the results section, the reader should be familiar with the theoretical values presented there because the reader already saw them in this section.

This section varies depending on requirements of the one who assigned the work and the audience. At a minimum, the author discusses the procedure by describing the method used to test a theory, verify a design or conduct a process. Presentation of the procedure may vary significantly for different fields and different audiences, however, for all fields, the author should BE BRIEF and get to the point . Like with any written work, if it is unnecessarily wordy, the reader becomes bored and the author no longer has an audience. Also, the procedure section should never include specific measurements/results, discussion of results, or explanation of possible error sources. Make sure all diagrams provided are numbered, titled, and clearly labeled.

Depending on the situation, there are two likely types of procedure sections. In one case, a detailed procedure may have already been supplied or perhaps it is not desirable to provide a detailed description due to proprietary work. In another case, it might be the author’s job to develop and provide all the detail so work can be duplicated. The latter is more common in academic lab settings. Writing guidelines for these possible procedure sections are provided below.

Procedure Type 1

Use this procedure type if you have been supplied with a detailed procedure describing the steps required to complete the work or detailed procedure is not to be supplied to potential readers (procedure may be proprietary). Briefly describe the method employed to complete the work. This is meant to be a brief procedural description capturing the intention of the work, not the details. The reader may be referred to the appendix for detailed procedure steps. The following list provides considerations for this type of procedure section.

• Example: For measurements made over a range of input settings, provide the actual range without including the details of the specific input settings or order data was taken (unless order affects results).
• If required by the person who assigned the work, include the detailed procedure in the appendix.
• MUST provide detailed diagram(s) of all applicable experimental set-ups (i.e. circuit diagram) that include specific information about the set-up, such as resistor values.
• Provide diagrams and/or pictures that will further assist the reader in understanding the procedural description.
• Provide a details of any work performed for which prescribed steps were not provided and that the author deems necessary for the reader’s comprehension.
• To test the theory of superposition, the circuit shown in Figure 1 is employed. The circuit is constructed on the lab bench and using MultismTM, a circuit simulation software. In both settings, a multimeter is used to measure the output voltage, as shown in Figure 1, for the following three cases: (1) Source 1 on and Source 2 off, (2) Source 1 off and Source 2 on, and (3) both sources on. These measurements are compared to the output voltage derived using theory as described earlier. Refer to the appendix for further detail or procedure.
• In order to test the theory of superposition, first each team member must calculate the output voltage for the circuit shown in Figure 1 for the following three cases: (1) Source 1 on and Source 2 off, (2) Source 1 off and Source 2 on, and (3) both sources on. Then one team member is assigned to build the circuit on the lab bench while the other team member constructs the circuit in Multisim. Once constructed, turn Source 1 on and Source 2 off then connect the positive lead of the meter to the positive end of the output voltage and the negative lead of the meter to the negative end of the output voltage. Record the meter reading. Next turn on Source 2 and turn off Source 1. Again, measure the output voltage using the meter ….

Procedure Type 2

Use this procedure type if you have not been supplied with a detailed description of the steps required to complete the work and/or you were required to develop and report procedure. The reader should be able to repeat the work based on the content supplied in this section.

• Equipment use
• Equipment maintenance
• Define terms specific to the technology
• Measurement techniques and/or calibration
• The description should be sufficiently clear so that the reader could duplicate the work. Do not assume that the reader has prior knowledge or access to prior reports, textbooks, or handouts.
• If part of the procedure was successfully described in a previous report, either repeat the procedure or include that report in the appendix and refer the reader to it.
• Where appropriate, provide additional diagrams and/or pictures to assist the reader in understanding the procedure.

Results and Discussion

Present the results of the work performed, within the context of the problem statement, using neatly organized and completely labeled tables and/or graphs whenever possible. When comparative data is available, present the data in a way that facilitates the comparison. For example, if theoretical and experimental values are available, present the values alongside one another accompanied by percent error. If it would help the reader understand the results, include a few sample calculations but put lengthy calculations in an appendix.

ALWAYS accompany results with a meaningful discussion. The discussion explains what the results mean and points out trends. In some cases, the results speak mostly for themselves and the discussion may be brief, i.e., “Table 2 shows that the designed variable modulus counter works as expected” along with a sentence or two stating how a variable modulus counter works and referring to parts of the table that verify/justify the statement. In other cases, the meaning of the results may not be as clear requiring more detailed discussion. In most cases, the results include data from more than one source to be compared to establish validity. Meaningful discussion immediately follows presentation of results and include:

• commenting on percent difference making sure it is clear to the reader which values are being compared and establishing comparative size of the difference in relation to expectations (negligible, small, large),
• cause for the difference (error sources are discussed further in the next paragraph), and
• how the results inform the reader as framed by the work’s objectives.

All three of the points are important to a meaningful discussion but the third one is most often overlooked. Discussion related to (3) may provide a statement about the theory used to predict the measured data. That statement often includes the theoretical assumptions made to predict the results and what the measured results indicate about the applicability of those theoretical assumptions to the experimental setting.

ALWAYS discuss the possible significant sources of error and how accurate the results need to be in order to be meaningful. Do not include a discussion of possible sources of error that would not add significantly to the observed error. What counts as significant depends on the situation. For example, if the components used have a tolerance of 5% and the accuracy of the equipment is within 0.5% of the measured value, then the equipment does not add significant error. However, if the components used have only a 1% tolerance then equipment with 0.5% accuracy is problematic. In general, it is impossible to obtain error-free results, therefore when there is 0% error there is still cause for discussion to comment on the situation that may result in error-free results or meaningful justification for expectation of error-free results. Expecting some error is not an excuse for lack of attention to detail when conducting procedures that minimize the error. Errors are different from mistakes. It is unacceptable to report mistakes. If a mistake was made, the work must be repeated until acceptable tolerances are achieved before submitting a report. Please find more on discussing percent error or percent difference in Appendix C.

When working in industry, it is imperative to know required level of accuracy for results. Your supervisor or client will expect results within specifications. If that means repetitive measurements to check for accuracy within tolerance, then do it. If it means performing a detailed analysis prior to making measurements, then do it. In an academic setting, the result of laziness or lack of effort may only be a bad grade. In a workplace, you may get fired!

Other information pertaining to writing Results and Discussion section can be found in Appendix C. This information includes

• How to calculate percent difference/error.
• Typical magnitudes of percent error for courses where circuits are constructed.
• What to consider writing about based on questions posed by the person assigning you to write the report.
• Guidelines for graphs provided in a report.

In this final section of the body of the report, the author should briefly bring everything together. It is similar to the abstract except that now specific results are concluded upon in a quantitative way. Therefore, the conclusion should be a concise description of the report including its purpose and most important results providing specific quantitative information. The conclusion should not contain figures or refer to them. As with the abstract, the reader should be able to read this section on its own which means that there should be no specific technical jargon, abbreviations, or acronyms used.

Anywhere within your writing that you have either copied or paraphrased another source, you must cite that source. This entails two steps. One is to provide a parenthetical citation at the location in the report where the material that is not your own resides and the other is to provide the complete bibliographic information in a References page following the Conclusion section of the report. If an annotated bibliography is required, include an annotation for ALL sources describing what the source was used for within the report and establishes the source’s credibility.

Using the APA style, the parenthetical citation at the location in the document where the copied or paraphrased material exists includes: author, publication date, and page number(s). For sources with no author, the name of the reference material is used. All this information is included within parentheses thus being referred to as a “parenthetical citation”.

The full bibliographic information for all reference material cited within your writing is collected on the References page. In technical papers, the referenced sources are usually listed in the order they are referred to in the body of the report and, in fact, many published engineering papers will simply number the references and then use that number in square brackets to replace the parenthetical citation within the body of the report. Those new to this form of technical writing, often ask about how and where to list references used but not explicitly cited in the body of the report. However, if the reference is important enough to list, that generally means that there is an appropriate place to cite it in the body of the report, perhaps in the introduction or background theory. In Appendix A you can find further information about creating citations using citation generators available on the internet that will create a properly formatted citation for you when provided with the relevant information. Although citation generators are readily available, the one I recommend is from Calvin College called KnightCite due to the minimum sponsored advertisements and can be found at http://www.calvin.edu/library/knightcite/ .

The References section begins on a new page; not on the same page with the conclusion. Refer to Appendix A for detailed information on preparing the References section. Also, there is a wealth of information about citation styles, including lengthy guides and short handouts, at https://sunydutchess.libguides.com/citations .

One final note on references and providing bibliographic information concerns use of sources that may appear to be questionable. There is no doubt that information from a wiki is questionable since, by definition, it can be changed by users including unqualified users. Although most wikis are reviewed and erroneous or misleading information corrected, at any given time there could be erroneous and misleading information. However, depending on report content, internet sources, including .com sites that have industry bias and .org sites that have policy bias, may have valuable information. Even .edu sites can be problematic if site is by an individual rather than an educational group within the institution since the former is likely not to have any editors and the latter is likely to be monitored and curated by the group. In order to establish credibility or usefulness of a source, especially a questionable one, provide an annotation to the bibliographic information that provides further information as to why the source was included and perspective on its application to the work reported. Information about annotated bibliographies is provided in Appendix A.

This section may not always be present. Materials included in an appendix may include lab sheets, parts list, diagrams, extensive calculations, error analyses, and lengthy computer programs.  Introduce numbered or lettered appendices rather than putting different items in one appendix.

Technical Report Writing Guidelines Copyright © by Leah M. Akins is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License , except where otherwise noted.

Share This Book

Scientific/Technical Reports

A scientific, engineering, or technical report informs readers about research you've conducted. (In your science classes, they may be called Lab Reports). These reports often follow the pattern explained here and as shown in the figure to the right, though the section titles and organization can vary by discipline or type of information you're reporting. Remember that your audience, content, and purpose should inform the way you present and discuss information.

These general guidelines may differ from the instructions provided by your professor or TA. ALWAYS follow your professor's or TA's instructions for writing scientific reports!

Introduction

Your introduction should justify that the study is important and worth conducting. It should have the following general structure:

• Begin with the general topic and describe the important "big picture" problem in the field.
• Connect the big picture to your research question
• Justify the logic and importance of the research question
• Set your research within the context of other research
• Reference relevant published studies and identify gaps and unresolved issues that this study addresses (references are always paraphrased, never quoted).
• Include only relevant information related to the crucial concepts of the study.
• End by stating your research question, your study purpose/goal, and/or any hypotheses/predictions.

Common Pitfalls

• Lack of focus: The introduction provides too many irrelevant details or lacks important concepts/details.
• Lack of organization: The introduction does not follow the structure listed above.
• Failure to justify the study: The introduction does not persuade readers that the study is worth doing and/or the reasoning behind the hypotheses is unclear.

Introduction Checklist

• Begins with the most general topic ("big picture") and progressively becomes narrower in scope.
• Provides appropriate background information that justifies why the study is worth doing. For example, you might introduce the importance of the problem by identifying a gap in previous research, inconclusive results in previous research, or the need for additional information.
• Includes only relevant information related to the crucial concepts of the study.
• Ends by introducing the study's purpose and clearly stating any hypotheses and predictions.

Methods Section

Your methods section should demonstrate that the research approach was appropriately designed and implemented, so that your audience trusts the results and so you establish your credibility. It will cover the details of your study, such as the following:

• Ways you addressed the research question/hypothesis
• Important materials used in the investigation (quantities, equipment, organisms, databases)
• For person-based research, the data collection method (interviews, surveys, observation, etc.), number and demographics of participants, etc.
• The outcomes/responses that were measured and how
• Any calculations (including formulae) and statistical tests used
• Any details that, if changed, would substantially alter the results
• Lack of organization: The methods are written as a play-by-play of what happened in the lab ("first, we got scissors, and then we cut the plants"), or the same procedure is described multiple times.
• Lack of detail: Follow the bulleted list above for necessary details to include.
• Unnecessary details: You can leave out details regarding safety (e.g., wearing gloves); common scientific practice (e.g., labeling, being careful); and steps that, if changed, would not alter the results (e.g., the class being broken up into groups).

Methods Section Checklist

• Thoroughly describes the procedure used to address the research question/hypothesis.
• Includes all relevant details (e.g., quantities, equipment, organisms, data collection method, etc.).
• Describes all calculations used (including formulae and definitions of the variables).
• Avoids being repetitive (i.e., describing the same procedure multiple times).
• Avoids unnecessary details.

Results Section

The results section organizes and simplifies the findings of the study for readers and presents objective explanations .

• Focus on the details that are most relevant for evaluating the study question/hypothesis.
• Begin paragraphs with topic sentences to describe a general pattern in the data. Then, describe the finer nuances of the data.
• Make comparisons and describe trends when appropriate (e.g., this increased faster than that, or this treatment was consistently lower than the others, etc.).
• Reference tables and figures within the text.
• Avoid any interpretation of or explanation for the results.
• Lack of organization: Paragraphs lack topic sentences, or the order in which results are presented is confusing or difficult to follow.
• Lack of important details: Fails to describe patterns in the data (see examples above) or fails to describe results for the entire experiment.
• Too many details: Too many numbers can be hard to follow and boring to read.

Results Section Checklist

• Describe important trends and provide relevant numerical values.
• Refer to all tables and figures within the text.
• Avoid interpretation of results.
• Avoid unnecessary details.

Discussion Section

The discussion section interprets and explains the study's results.

• Start by stating the overall conclusions with respect to the study's goals/hypotheses.
• Justify the overall conclusions by relating the results to the goals/hypotheses (why did you conclude this?).
• Providing explanations using relevant disciplinary concepts
• Comparing the study's results to other groups in class or to published studies
• Suggesting improvements on the experimental design and/or proposing ideas for future research
• Conclude by discussing the implications of the results with respect to the "big picture" issue mentioned in the introduction.
• Shallow data analysis: The analysis and explanation of the results is weak and lacks depth. Explanations may focus too much on human error rather than scientific or other disciplinary phenomena.
• Weak ideas for improvements or future research: Fails to explain how a design improvement might affect the results, or how a proposed study would advance understanding of the topic being addressed.

Discussion Section Checklist

• Starts with a statement of the overall conclusions with respect to the study's goals/hypotheses
• Briefly describes the results that led to the above conclusions
• Provides explanations of the results using primarily disciplinary concepts
• Explains how the results compare to other groups in class or to published studies (if applicable)
• Provides logical explanations for unexpected results or results that differ from published studies
• Explains how the study could be improved (if applicable) and how that might affect the results.
• Provides well-reasoned ideas for future research that would further understanding of the topic.
• Concludes by discussing the implications of the results with respect to the "big picture."

Tables and Figures

Tables and figures should help the reader visualize and understand your results.

• Focus on the most relevant results for evaluating the study question/hypothesis.
• Include enough information so readers can interpret the tables/figures on their own.
• Number tables and figures in the order in which they are referenced in the paper.

For help with Excel or statistics software, visit the Statistics Help Desk in BEST library.

• Confusing or disorganized tables/figures: Readers should easily understand the data presented in a figure or table.
• Improper formatting: Table or figure does not conform to format described below. Titles are vague and uninformative.

Table Formatting Checklist

• Columns and rows are clearly and concisely labeled and include units (e.g., mm) where appropriate (see example below)
• Data is neatly organized and easy to understand
• Table titles clearly and completely describe the data being presented (see example below)

Figure Formatting Checklist

• X- and y-axes are clearly and concisely labeled and include units (e.g., mm) (see A below)
• When multiple lines are graphed in the same figure, the lines are easy to distinguish and the key clearly shows what each line represents (see B below)
• Figure titles clearly and completely describe the data being presented (see example below)

Figure 1. Change in the average height of corn seedlings treated with different concentrations of soil nitrogen. Error bars indicate the standard deviation.

501 E. High Street Oxford, OH 45056

• Online: Miami Online
• Main Operator 513-529-1809
• Office of Admission 513-529-2531
• Vine Hotline 513-529-6400
• Emergency Info https://miamioh.edu/emergency

1601 University Blvd. Hamilton, OH 45011

• Online: E-Campus
• Main Operator 513-785-3000
• Office of Admission 513-785-3111
• Campus Status Line 513-785-3077
• Emergency Info https://miamioh.edu/regionals/emergency

4200 N. University Blvd. Middletown, OH 45042

• Main Operator 513-727-3200
• Office of Admission 513-727-3216
• Campus Status 513-727-3477

7847 VOA Park Dr. (Corner of VOA Park Dr. and Cox Rd.) West Chester, OH 45069

• Main Operator 513-895-8862
• From Middletown 513-217-8862

Chateau de Differdange 1, Impasse du Chateau, L-4524 Differdange Grand Duchy of Luxembourg

• Main Operator 011-352-582222-1
• Email [email protected]
• Website https://miamioh.edu/luxembourg

217-222 MacMillan Hall 501 E. Spring St. Oxford, OH 45056, USA

• Main Operator 513-529-8600

Initiatives

• Miami THRIVE Strategic Plan
• Miami Rise Strategic Plan
• Boldly Creative
• Annual Report
• Moon Shot for Equity
• Miami and Ohio
• Majors, Minors, and Programs
• Inclusive Excellence
• Employment Opportunities
• University Safety and Security
• Parking, Directions, and Maps
• Equal Opportunity
• Consumer Information
• Land Acknowledgement
• Privacy Statement
• Title IX Statement
• Report an Accessibility Issue
• Annual Security and Fire Safety Report
• Report a Problem with this Website
• Policy Library

How to Write a Technical Report?

What Is a Technical Report?

The definition of a technical report is the following: a technical report is a document written by a researcher; it describes how the research was conveyed: its phases, steps, results, peculiarities, etc., and may include deeper details like experimental data and outcome. It is a document that literally guides readers through the course of your work.

Who Needs a Technical Report?

Many organizations and companies use this type of technical documentation:

• Educational institutions
• Governmental organizations
• Commercial companies
• Non-profit organizations

As a rule, technical reports are widely used in the following industries: engineering, physical sciences, medical and biomedical fields, social sphere, etc.

Why Use a Technical Report?

If you have one of the following goals, a technical report will surely help you:

• You need to show the process of your work. Readers are interested in how you do it. Of course, results have a great value as well but how to check whether you’ve chosen the right way to get them?
• You need to represent important information. This type of technical documentation is often chosen to provide efficient communication among employees on different levels. For example, top management can make decisions based on the information given in technical reports. It means that a technical report may influence the way a company is going to develop in the future.
• You need to structure data. A technical report helps to represent information logically and show the cause-and-effect relations between the blocks of data.
• Attract the attention of readers to a problem. A technical report is a very good solution to show readers a problem and, of course, why it should be solved as soon as possible.

What Makes a Good Technical Report?

To write a high-quality technical report, you are to follow the rules that are common nearly for all types of technical documentation:

• Write for your readers : define your audience, their level of knowledge, organize the document the way they can easily use it;
• Use accurate, concise, and clear language;
• Eliminate errors: technical errors, inconsistencies, and errors in language;
• Use additional sources of information: references and visuals (diagrams, tables, graphs, etc.). For example, using diagrams can be very helpful if you need to show statistical data analyses. Our post - Using Diagrams in IT Documentation: Best Practices - will tell you more on how to use diagrams in technical documentation and which tools to choose;
• Keep your report short but informative.

What Is the Difference Between a Technical and Non-Technical Report?

Not every report can be called a technical one. Let’s figure out the difference between a technical report and a non-technical one.

So, a technical report is a document that gives in-depth technical information. A non-technical report contains other types of information - more general ones. A popular report is a good example of a non-technical report. A popular report is a short document that describes the state’s or government’s financial performance.

Structure of a Technical Report

A technical report usually contains the following elements:

• Synopses. This is the first element of a technical report, but it should be the last thing to write. It is only a couple of paragraphs long. You are to underline your attitude to the problem, the methods used, the purpose, and the concept of the report.
• Title page. It is not only the title of the project, there should be some information about the author, their position, submission date, etc.
• Abstract. It is a short technical summary. As a rule, it is addressed to the audience. They decide whether to read the report or not, as they may already be acquainted with the problem.
• Table of contents (TOC) . It is a guide to the report’s structure.
• List of illustrations. It is a list of diagrams, graphs, tables, or other materials that support the content of the report.
• Introduction. This is the introduction to the body of the report. Sometimes it contains relevant background information. This section describes the aims and objectives of the report, the scope of work, limitations, etc.
• Body. The longest and most important section of the report. It can be subdivided into logical parts. This is the main scope of work, ideas, methods, etc.
• Conclusion. Contains the answers to the questions that were specified at the beginning or solutions to the problems.
• Appendices. The list of references, books, etc.
• Glossary . The list of terms and symbols used in the report.

Formatting of Technical Reports

Formatting means highlighting some data or information. Formatting may include using corporate style guides to underline that the document belongs to a particular company, or it may include highlighting in order to underline the sense or importance of information. Sometimes, documents have both types of formatting.

Types of Technical Reports

Technical reports can be of various types depending on the industry, goals, and needs:

• Feasibility report. Is the most popular document at the beginning of the software development process. It helps teams make their choice between several options. It shows whether or not the task in question can be fulfilled with the specified resources.
• Business plan. It describes the goals of a business, methods of achievement, resources, timeline, etc.
• Technical specification. Describes requirements for a product or project and information on design and development.
• Research report. Is the result of an investigation: process and findings.
• Recommendation report. Contains recommendations to solve a problem.
• Policies and procedures. Contains guidelines for rational actions.

Even more types of technical reports can be singled out. The above-mentioned ones are considered to be basic.

If you are a newbie technical writer, now you surely know what a technical report is and how to write it; if you are an experienced one, you may find new ideas and sources of inspiration in this post. Whatever document you are creating, make sure you do your best to make it as clear as possible to your readers. Stay safe and create perfect technical documentation with ClickHelp !

Good luck with your technical writing! ClickHelp Team Author, host and deliver documentation across platforms and devices

Give it a Try!

Mind if we email you once a month?

• Privacy Policy

Home » Research Report – Example, Writing Guide and Types

Research Report – Example, Writing Guide and Types

Table of Contents

Research Report

Definition:

Research Report is a written document that presents the results of a research project or study, including the research question, methodology, results, and conclusions, in a clear and objective manner.

The purpose of a research report is to communicate the findings of the research to the intended audience, which could be other researchers, stakeholders, or the general public.

Components of Research Report

Components of Research Report are as follows:

Introduction

The introduction sets the stage for the research report and provides a brief overview of the research question or problem being investigated. It should include a clear statement of the purpose of the study and its significance or relevance to the field of research. It may also provide background information or a literature review to help contextualize the research.

Literature Review

The literature review provides a critical analysis and synthesis of the existing research and scholarship relevant to the research question or problem. It should identify the gaps, inconsistencies, and contradictions in the literature and show how the current study addresses these issues. The literature review also establishes the theoretical framework or conceptual model that guides the research.

Methodology

The methodology section describes the research design, methods, and procedures used to collect and analyze data. It should include information on the sample or participants, data collection instruments, data collection procedures, and data analysis techniques. The methodology should be clear and detailed enough to allow other researchers to replicate the study.

The results section presents the findings of the study in a clear and objective manner. It should provide a detailed description of the data and statistics used to answer the research question or test the hypothesis. Tables, graphs, and figures may be included to help visualize the data and illustrate the key findings.

The discussion section interprets the results of the study and explains their significance or relevance to the research question or problem. It should also compare the current findings with those of previous studies and identify the implications for future research or practice. The discussion should be based on the results presented in the previous section and should avoid speculation or unfounded conclusions.

The conclusion summarizes the key findings of the study and restates the main argument or thesis presented in the introduction. It should also provide a brief overview of the contributions of the study to the field of research and the implications for practice or policy.

The references section lists all the sources cited in the research report, following a specific citation style, such as APA or MLA.

The appendices section includes any additional material, such as data tables, figures, or instruments used in the study, that could not be included in the main text due to space limitations.

Types of Research Report

Types of Research Report are as follows:

Thesis is a type of research report. A thesis is a long-form research document that presents the findings and conclusions of an original research study conducted by a student as part of a graduate or postgraduate program. It is typically written by a student pursuing a higher degree, such as a Master’s or Doctoral degree, although it can also be written by researchers or scholars in other fields.

Research Paper

Research paper is a type of research report. A research paper is a document that presents the results of a research study or investigation. Research papers can be written in a variety of fields, including science, social science, humanities, and business. They typically follow a standard format that includes an introduction, literature review, methodology, results, discussion, and conclusion sections.

Technical Report

A technical report is a detailed report that provides information about a specific technical or scientific problem or project. Technical reports are often used in engineering, science, and other technical fields to document research and development work.

Progress Report

A progress report provides an update on the progress of a research project or program over a specific period of time. Progress reports are typically used to communicate the status of a project to stakeholders, funders, or project managers.

Feasibility Report

A feasibility report assesses the feasibility of a proposed project or plan, providing an analysis of the potential risks, benefits, and costs associated with the project. Feasibility reports are often used in business, engineering, and other fields to determine the viability of a project before it is undertaken.

Field Report

A field report documents observations and findings from fieldwork, which is research conducted in the natural environment or setting. Field reports are often used in anthropology, ecology, and other social and natural sciences.

Experimental Report

An experimental report documents the results of a scientific experiment, including the hypothesis, methods, results, and conclusions. Experimental reports are often used in biology, chemistry, and other sciences to communicate the results of laboratory experiments.

Case Study Report

A case study report provides an in-depth analysis of a specific case or situation, often used in psychology, social work, and other fields to document and understand complex cases or phenomena.

Literature Review Report

A literature review report synthesizes and summarizes existing research on a specific topic, providing an overview of the current state of knowledge on the subject. Literature review reports are often used in social sciences, education, and other fields to identify gaps in the literature and guide future research.

Research Report Example

Following is a Research Report Example sample for Students:

Title: The Impact of Social Media on Academic Performance among High School Students

This study aims to investigate the relationship between social media use and academic performance among high school students. The study utilized a quantitative research design, which involved a survey questionnaire administered to a sample of 200 high school students. The findings indicate that there is a negative correlation between social media use and academic performance, suggesting that excessive social media use can lead to poor academic performance among high school students. The results of this study have important implications for educators, parents, and policymakers, as they highlight the need for strategies that can help students balance their social media use and academic responsibilities.

Introduction:

Social media has become an integral part of the lives of high school students. With the widespread use of social media platforms such as Facebook, Twitter, Instagram, and Snapchat, students can connect with friends, share photos and videos, and engage in discussions on a range of topics. While social media offers many benefits, concerns have been raised about its impact on academic performance. Many studies have found a negative correlation between social media use and academic performance among high school students (Kirschner & Karpinski, 2010; Paul, Baker, & Cochran, 2012).

Given the growing importance of social media in the lives of high school students, it is important to investigate its impact on academic performance. This study aims to address this gap by examining the relationship between social media use and academic performance among high school students.

Methodology:

The study utilized a quantitative research design, which involved a survey questionnaire administered to a sample of 200 high school students. The questionnaire was developed based on previous studies and was designed to measure the frequency and duration of social media use, as well as academic performance.

The participants were selected using a convenience sampling technique, and the survey questionnaire was distributed in the classroom during regular school hours. The data collected were analyzed using descriptive statistics and correlation analysis.

The findings indicate that the majority of high school students use social media platforms on a daily basis, with Facebook being the most popular platform. The results also show a negative correlation between social media use and academic performance, suggesting that excessive social media use can lead to poor academic performance among high school students.

Discussion:

The results of this study have important implications for educators, parents, and policymakers. The negative correlation between social media use and academic performance suggests that strategies should be put in place to help students balance their social media use and academic responsibilities. For example, educators could incorporate social media into their teaching strategies to engage students and enhance learning. Parents could limit their children’s social media use and encourage them to prioritize their academic responsibilities. Policymakers could develop guidelines and policies to regulate social media use among high school students.

Conclusion:

In conclusion, this study provides evidence of the negative impact of social media on academic performance among high school students. The findings highlight the need for strategies that can help students balance their social media use and academic responsibilities. Further research is needed to explore the specific mechanisms by which social media use affects academic performance and to develop effective strategies for addressing this issue.

Limitations:

One limitation of this study is the use of convenience sampling, which limits the generalizability of the findings to other populations. Future studies should use random sampling techniques to increase the representativeness of the sample. Another limitation is the use of self-reported measures, which may be subject to social desirability bias. Future studies could use objective measures of social media use and academic performance, such as tracking software and school records.

Implications:

The findings of this study have important implications for educators, parents, and policymakers. Educators could incorporate social media into their teaching strategies to engage students and enhance learning. For example, teachers could use social media platforms to share relevant educational resources and facilitate online discussions. Parents could limit their children’s social media use and encourage them to prioritize their academic responsibilities. They could also engage in open communication with their children to understand their social media use and its impact on their academic performance. Policymakers could develop guidelines and policies to regulate social media use among high school students. For example, schools could implement social media policies that restrict access during class time and encourage responsible use.

References:

• Kirschner, P. A., & Karpinski, A. C. (2010). Facebook® and academic performance. Computers in Human Behavior, 26(6), 1237-1245.
• Paul, J. A., Baker, H. M., & Cochran, J. D. (2012). Effect of online social networking on student academic performance. Journal of the Research Center for Educational Technology, 8(1), 1-19.
• Pantic, I. (2014). Online social networking and mental health. Cyberpsychology, Behavior, and Social Networking, 17(10), 652-657.
• Rosen, L. D., Carrier, L. M., & Cheever, N. A. (2013). Facebook and texting made me do it: Media-induced task-switching while studying. Computers in Human Behavior, 29(3), 948-958.

Note*: Above mention, Example is just a sample for the students’ guide. Do not directly copy and paste as your College or University assignment. Kindly do some research and Write your own.

Applications of Research Report

Research reports have many applications, including:

• Communicating research findings: The primary application of a research report is to communicate the results of a study to other researchers, stakeholders, or the general public. The report serves as a way to share new knowledge, insights, and discoveries with others in the field.
• Informing policy and practice : Research reports can inform policy and practice by providing evidence-based recommendations for decision-makers. For example, a research report on the effectiveness of a new drug could inform regulatory agencies in their decision-making process.
• Supporting further research: Research reports can provide a foundation for further research in a particular area. Other researchers may use the findings and methodology of a report to develop new research questions or to build on existing research.
• Evaluating programs and interventions : Research reports can be used to evaluate the effectiveness of programs and interventions in achieving their intended outcomes. For example, a research report on a new educational program could provide evidence of its impact on student performance.
• Demonstrating impact : Research reports can be used to demonstrate the impact of research funding or to evaluate the success of research projects. By presenting the findings and outcomes of a study, research reports can show the value of research to funders and stakeholders.
• Enhancing professional development : Research reports can be used to enhance professional development by providing a source of information and learning for researchers and practitioners in a particular field. For example, a research report on a new teaching methodology could provide insights and ideas for educators to incorporate into their own practice.

How to write Research Report

Here are some steps you can follow to write a research report:

• Identify the research question: The first step in writing a research report is to identify your research question. This will help you focus your research and organize your findings.
• Conduct research : Once you have identified your research question, you will need to conduct research to gather relevant data and information. This can involve conducting experiments, reviewing literature, or analyzing data.
• Organize your findings: Once you have gathered all of your data, you will need to organize your findings in a way that is clear and understandable. This can involve creating tables, graphs, or charts to illustrate your results.
• Write the report: Once you have organized your findings, you can begin writing the report. Start with an introduction that provides background information and explains the purpose of your research. Next, provide a detailed description of your research methods and findings. Finally, summarize your results and draw conclusions based on your findings.
• Proofread and edit: After you have written your report, be sure to proofread and edit it carefully. Check for grammar and spelling errors, and make sure that your report is well-organized and easy to read.
• Include a reference list: Be sure to include a list of references that you used in your research. This will give credit to your sources and allow readers to further explore the topic if they choose.
• Format your report: Finally, format your report according to the guidelines provided by your instructor or organization. This may include formatting requirements for headings, margins, fonts, and spacing.

Purpose of Research Report

The purpose of a research report is to communicate the results of a research study to a specific audience, such as peers in the same field, stakeholders, or the general public. The report provides a detailed description of the research methods, findings, and conclusions.

Some common purposes of a research report include:

• Sharing knowledge: A research report allows researchers to share their findings and knowledge with others in their field. This helps to advance the field and improve the understanding of a particular topic.
• Identifying trends: A research report can identify trends and patterns in data, which can help guide future research and inform decision-making.
• Addressing problems: A research report can provide insights into problems or issues and suggest solutions or recommendations for addressing them.
• Evaluating programs or interventions : A research report can evaluate the effectiveness of programs or interventions, which can inform decision-making about whether to continue, modify, or discontinue them.
• Meeting regulatory requirements: In some fields, research reports are required to meet regulatory requirements, such as in the case of drug trials or environmental impact studies.

When to Write Research Report

A research report should be written after completing the research study. This includes collecting data, analyzing the results, and drawing conclusions based on the findings. Once the research is complete, the report should be written in a timely manner while the information is still fresh in the researcher’s mind.

In academic settings, research reports are often required as part of coursework or as part of a thesis or dissertation. In this case, the report should be written according to the guidelines provided by the instructor or institution.

In other settings, such as in industry or government, research reports may be required to inform decision-making or to comply with regulatory requirements. In these cases, the report should be written as soon as possible after the research is completed in order to inform decision-making in a timely manner.

Overall, the timing of when to write a research report depends on the purpose of the research, the expectations of the audience, and any regulatory requirements that need to be met. However, it is important to complete the report in a timely manner while the information is still fresh in the researcher’s mind.

Characteristics of Research Report

There are several characteristics of a research report that distinguish it from other types of writing. These characteristics include:

• Objective: A research report should be written in an objective and unbiased manner. It should present the facts and findings of the research study without any personal opinions or biases.
• Systematic: A research report should be written in a systematic manner. It should follow a clear and logical structure, and the information should be presented in a way that is easy to understand and follow.
• Detailed: A research report should be detailed and comprehensive. It should provide a thorough description of the research methods, results, and conclusions.
• Accurate : A research report should be accurate and based on sound research methods. The findings and conclusions should be supported by data and evidence.
• Organized: A research report should be well-organized. It should include headings and subheadings to help the reader navigate the report and understand the main points.
• Clear and concise: A research report should be written in clear and concise language. The information should be presented in a way that is easy to understand, and unnecessary jargon should be avoided.
• Citations and references: A research report should include citations and references to support the findings and conclusions. This helps to give credit to other researchers and to provide readers with the opportunity to further explore the topic.

Advantages of Research Report

Research reports have several advantages, including:

• Communicating research findings: Research reports allow researchers to communicate their findings to a wider audience, including other researchers, stakeholders, and the general public. This helps to disseminate knowledge and advance the understanding of a particular topic.
• Providing evidence for decision-making : Research reports can provide evidence to inform decision-making, such as in the case of policy-making, program planning, or product development. The findings and conclusions can help guide decisions and improve outcomes.
• Supporting further research: Research reports can provide a foundation for further research on a particular topic. Other researchers can build on the findings and conclusions of the report, which can lead to further discoveries and advancements in the field.
• Demonstrating expertise: Research reports can demonstrate the expertise of the researchers and their ability to conduct rigorous and high-quality research. This can be important for securing funding, promotions, and other professional opportunities.
• Meeting regulatory requirements: In some fields, research reports are required to meet regulatory requirements, such as in the case of drug trials or environmental impact studies. Producing a high-quality research report can help ensure compliance with these requirements.

Limitations of Research Report

Despite their advantages, research reports also have some limitations, including:

• Time-consuming: Conducting research and writing a report can be a time-consuming process, particularly for large-scale studies. This can limit the frequency and speed of producing research reports.
• Expensive: Conducting research and producing a report can be expensive, particularly for studies that require specialized equipment, personnel, or data. This can limit the scope and feasibility of some research studies.
• Limited generalizability: Research studies often focus on a specific population or context, which can limit the generalizability of the findings to other populations or contexts.
• Potential bias : Researchers may have biases or conflicts of interest that can influence the findings and conclusions of the research study. Additionally, participants may also have biases or may not be representative of the larger population, which can limit the validity and reliability of the findings.
• Accessibility: Research reports may be written in technical or academic language, which can limit their accessibility to a wider audience. Additionally, some research may be behind paywalls or require specialized access, which can limit the ability of others to read and use the findings.

About the author

Muhammad Hassan

Researcher, Academic Writer, Web developer

You may also like

Data Collection – Methods Types and Examples

Delimitations in Research – Types, Examples and...

Research Process – Steps, Examples and Tips

Research Design – Types, Methods and Examples

Institutional Review Board – Application Sample...

Evaluating Research – Process, Examples and...

• school Campus Bookshelves
• menu_book Bookshelves
• perm_media Learning Objects
• login Login
• how_to_reg Request Instructor Account
• hub Instructor Commons

Margin Size

• Download Page (PDF)
• Download Full Book (PDF)
• Periodic Table
• Physics Constants
• Scientific Calculator
• Reference & Cite
• Tools expand_more
• Readability

selected template will load here

This action is not available.

2.14: Technical Definitions and Descriptions

• Last updated
• Save as PDF
• Page ID 51532

• Tiffani Reardon, Tammy Powell, Jonathan Arnett, Monique Logan, & Cassie Race
• Kennesaw State University

\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

\( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

\( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

\( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

\( \newcommand{\Span}{\mathrm{span}}\)

\( \newcommand{\id}{\mathrm{id}}\)

\( \newcommand{\kernel}{\mathrm{null}\,}\)

\( \newcommand{\range}{\mathrm{range}\,}\)

\( \newcommand{\RealPart}{\mathrm{Re}}\)

\( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

\( \newcommand{\Argument}{\mathrm{Arg}}\)

\( \newcommand{\norm}[1]{\| #1 \|}\)

\( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

\( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

\( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

\( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

\( \newcommand{\vectorC}[1]{\textbf{#1}} \)

\( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

\( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

\( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

Learning Objectives

Upon completion of this chapter, readers will be able to:

• Explain and apply the 5 primary characteristics of technical definitions.
• Write a definition using appropriate content, descriptors, details, length, placement, and audience analysis.
• Avoid common technical definition problems.
• Explain and apply the 5 primary characteristics of technical descriptions.
• Write a description using the 6 common parts.
• Organize a description according to the 3 common organizational patterns.

Technical Definitions

When you think of the word "definition," what comes to mind? If you're like most people, you think of a dictionary's contents. What, then, does a dictionary definition contain?

Typically, dictionary definitions include a word's

• Standard spelling
• Syllable breaks
• Pronunciation
• Part of speech
• Current and archaic usage
• Synonyms/antonyms
• Variant spellings
• Variants including suffixes

If you've used a dictionary before, then none of these items should surprise you. Think, though... Are all dictionaries the same? And do they contain the same types of thing?

Not really. All dictionaries contain lists of words, but their contents are otherwise markedly different. A children's dictionary, for example, is much simpler and shorter than a "collegiate" dictionary, which is shorter and simpler than an unabridged dictionary, which pales in comparison to the Oxford English Dictionary, a two-volume monster that comes with a reinforced bookstand and its own magnifying glass.

All these different dictionaries share several characteristics, though, which are characteristics of any technical definition:

• their authors focus on a particular audience ;
• their contents describe the object of attention ;
• their contents clarify ambiguity ;
• readers can use the contents to communicate across expertise levels ; and
• readers can use the contents to solve problems .

At least one of these ideas should sound familiar. For example, focusing on a particular audience...haven't we mentioned that sometime before, in this very class?

As far as the other four elements go, the temptation is to say, "Well, yeah, of course. That's what a definition does." The trick, though, is to include the right information, structure it the right way, and build a good definition. That's what we'll talk about next.

Technical Definition Contents

As the name might suggest, a technical definition should explain what a thing is. But what does "explain what a thing is" actually mean? How long does the explanation have to be? And where does the explanation go?

The answers to these questions depend on the characteristics listed above and the noun (person, place, thing, idea, or process) you're defining, and we see the answers expressed in terms of content, length, and placement.

Descriptors

Let's talk descriptors that can be used in writing a definition. Here's a partial list of possible items you can use to define a noun:

• physical characteristics (a thing's color, shape, size, material, smell, taste, texture, and so on)
• operation (how it works, but not how to work it -- that's what goes in instructions)
• analogies ("It tastes like chicken," for example)
• specific examples

More possible descriptors exist, but these are the usual suspects. You'll choose appropriate ones based on the situation at hand.

Type of Details

The kind of detail you'd include in a technical definition will vary. As with everything you write—and quite literally everything, whether you're writing it for this class, in future classes, or over the rest of your life—you need to consider your audience very carefully. For example, who is your audience? What is s/he like? What kind of language would you use? What medium would the audience respond to best? What kind of words will the audience respond to best? Et cetera... In short, analyze your audience carefully and tailor the content to that audience.

As an illustration of the kind of details you'd choose for a particular audience, let's think about defining the special steel used in the crumple zone of a car's frame. (If you don't know what a crumple zone is, it's an area of a car that's designed to get squished in a crash and absorb all the kinetic energy, thereby making the passengers safer.)

We're going to define the steel in this part of the car for three different audiences: you, a car manufacturer, and a car buyer.

For you, if I defined the steel as boron-doped high-austenite steel that undergoes a martensitic transformation in a crash, that would probably mean nothing because the information is too detailed. However, if I defined the steel in a modern car's crumple zone as relatively soft steel that suddenly stiffens up when it's put under stress, then you'd probably understand just fine.

For a modern car manufacturer, though, neither of those definitions would be detailed enough. The manufacturer would need to know specifics about how much boron went into the steel, how ductile (bendable) the steel is, how much stress the steel can take before it stiffens or breaks, and how quickly the steel stiffens when it's put under stress. For this audience, you'd need to write a highly detailed, highly technical definition.

A car buyer, on the other hand, simply doesn't care what kind of steel goes into a car's crumple zone. The only thing a car buyer wants to know is if the car's NTSA crash test ratings are good.

Another thing to consider is what sort of object/process/thing it is you're documenting. Some nouns just don't require certain types of descriptors.

As an illustration of necessary details for a particular subject, let's consider the same example again: the steel used in a car's crumple zone.

High-austenite steel is relatively ductile; its manufacturing process includes cold rolling, annealing, and quenching; and car manufacturers use high-austenite steel in crumple zones because this steel gets harder and stiffer under pressure, thus protecting drivers.

All of these properties make sense when we're talking about metal. In contrast, saying that a certain piece of highaustenite steel has a mottled gray appearance, makes a clang in the key of C-sharp, or tastes like chocolate chip cookies probably isn't relevant to anybody.

As we've already mentioned, the audience's need for information will drive how much information you provide. If the audience both needs and can handle a lot of information, then get super-detailed. On the other hand, if the audience only needs or only can handle the basics for whatever reason, then keep the definition short and include just the absolutely necessary information.

As an illustration of length, let's consider a dictionary definition.

A person who consults the Oxford English Dictionary probably wants detailed information about the many ways a particular word has been used over the centuries. Accordingly, the OED definition should be very long and full of examples.

In contrast, a middle-school student who just wants to know how to pronounce a word or find out a word's meaning won't want to read pages upon pages of etymology and usage. That student just wants the basic information and nothing more.

The audience's need for information and the type of information you're defining will also drive where you place definitions. Four major options include placing definitions in

• independent sentences
• dependent clauses
• parenthetical asides
• separate sections

If you're using relatively simple terms and have a knowledgeable audience, use simple, short definitions that fit within an ordinary sentence. If the definition is a bit more complex and/or your audience needs a bit more information, use a parenthetical statement. If you're defining complicated or detailed information, even to a knowledgeable audience, insert full paragraphs or subsections.

Sometimes, depending on the nature of the document that contains a definition, you'll refer readers to entire sections, such as footnotes, a glossary in the back of a textbook, or appendices at the end of formal proposals and reports (hint, hint on this last part).

In a separate sentence: "Peanut butter is a paste made from ground peanuts."

In a dependent clause: "Jim's Steakhouse uses wide-mouth Mason jars, like those used for preserving homemade jam, as water glasses. "

In a parenthetical statement: "Siamese cats—easily identifiable by their blue eyes, triangular-shaped heads, incessant yowling, and self-entitled attitudes—come from Southeast Asia."

Technical Definition Problems

When you write technical definitions, pay special attention to avoiding these three problems:

• audience-inappropriate content/language
• circular definitions
• synonymous definitions

Audience-Inappropriate Material

We've already discussed this, so I'll keep my rap short: Analyze your audience and give your audience members what they need, in a way they can understand it.

Circular Definitions

Some bad definitions depend on the reader already knowing what the defined thing is/does.

Here's an example: "Superchlorination is a swimming pool chemistry technique that enables operators to achieve breakpoint chlorination." Okay...but what is breakpoint chlorination? "Breakpoint chlorination is an elevated level of chlorine that swimming pool operators reach by superchlorinating the water."

Synonymous Definitions

Other bad definitions substitute one synonym for another. Here's an example: "Chloramines are another name for combined chlorine." Okay...but what is combined chlorine? Oops. I've just defined a thing as itself.

Here's a revised version: "Chloramines are molecules of 'free chlorine' (the chemically active form of chlorine that sanitizes, oxidizes, and disinfects pool water) that met an organic substance, chemically bonded to the organic substance, became chemically neutral, and began to give off a foul odor." This version is much better, yes?

Technical Descriptions

Technical descriptions are similar to technical definitions. but technical descriptions can be stand-alone documents, whereas technical definitions are always components of a larger document. Furthermore, technical descriptions

• are usually longer than technical definitions,
• contain more detail,
• focus on functionality,
• often describe complicated subjects with multiple parts, and
• contain technical definitions.

Technical Description Parts

Since technical descriptions are longer and more detailed than technical definitions, descriptions contain two major sections: Introductions and Body sections.

Introduction

The contents of a technical description's introduction are very similar to the contents of a formal letter. In the first paragraph, you need to

• identify the thing to be described;
• provide some basic background information (purpose of writing, context of writing);
• give a brief overview of the thing to be described (what is it like, what is its purpose);
• and preview the rest of the document.

After the Introduction, a technical description's content will vary, depending on your audience and the thing being described. However, there are a few common themes in any technical description's body paragraphs.

The body paragraphs flesh out the background information in more detail. Again, like the body of a formal letter contains details about the letter's subject, the body of a technical description contains details about the background of the thing being documented. Of course, tailor the content based on your audience and the subject at hand.

Parts/Characteristics

The body paragraphs also include details about the various parts that make up the thing being described. If the thing is a physical object, you'll want to list and describe the various parts that make up the whole. If the thing is a place, then what makes it different from or similar to other places? If the thing is a process, then what are its necessary conditions and its various stages/steps?

A technical description's body can also include visual materials (and, conceivably, audio materials if the description is multimedia). These can be pictures, tables, diagrams, charts, graphs...if it's appropriate, put it in. One particular kind of visual material that we need to address under its own heading, though, is the specification.

Specifications

The word "specifications" has two definitions. One of the definitions refers to a list (often a table) of technical details about the object or process you're documenting. These can be part of a technical definition and are often necessary in a technical description.

The second meaning, which we'll address here, refers to images that depict the subject of a description and include callouts (lines or arrows with text attached) to highlight that object's constituent parts.

Please note: Specifications are not descriptions . They may be part of descriptions, but specifications cannot stand alone.

Here's why: Imagine that you bought a new, top-of-the-line TV. You're quite excited, as it's a technologically advanced TV, with one bazillion features that you can program and customize for the world's most amazing TV experience.

You unpack the box and, instead of an owner's manual, all you find is a single piece of paper that pictures the TV's remote control, with labeled arrows to each button. One button is labeled "Skip."

• What will the TV do if you press the button?
• What will be skipped?
• Can you undo a skip?
• What if you press the button twice? Three times?
• Can "Skip" be used while watching regular TV, or just during DVR replay?
• Does "Skip" have meaning for programming your DVR?

All these questions need answering before you dare press the "Skip" button. You'd be very unhappy if you missed recording this week's episode of Game of Thrones or somehow recorded over the Jersey Shore marathon...

Technical Description Organization

Long technical definitions need their own organization strategies, just as any piece of writing does, but technical descriptions usually rely on one of three organization schemes:

• general-to-specific
• chronological

Your choice of an organization strategy will depend on the kind of thing you're describing. In general, you'll always want to go from general to specific, for you need to begin by defining the thing and then proceed by breaking it down thematically. What that theme is, though, depends on the nature of the thing being described.

General-to-Specific

For example, let's say you're documenting a bicycle. Would it do any good to just start naming pieces? " Okay...here's the front wheel, and here's the seat, and here's the handlebars...ooh! My favorite part, the chain guard! " Of course not; you need some sort of internal logic to the parts list. A logical scheme might be to begin with major systems—frame, wheels, gears, brakes—and then describe how the systems work together or go into more detail about the parts that compose each of these systems.

What about describing the construction of a four-barrel carburetor? You'd likely want to describe how the parts fit together, so a spatial organization scheme would make sense, complete with an exploded-view diagram of the parts. (As a completely irrelevant side note, in the year 2000, I met the inventor of the four-barrel carburetor; he was in his early nineties, and he was volunteering as a math tutor at a community college in Arizona. He was a very nice fellow.)

Chronological

But what about describing a process, like smelting iron? Giving a tour of the factory wouldn't make much sense, would it? " Here's the blast furnace, and over here is the rock crusher. And then on this side, we've got the mold-making shop and a pile of spare wheelbarrow tires. "

No...you'd want to proceed chronologically, step-by-step, through the process. " First, dump trucks haul in raw ore and pour it into this bin. Then we use a bucket loader to transfer the ore into this machine, where we pulverize it. Then we load the crushed ore into these crucibles and roast the ore until the iron melts out. From that point, we... " You get the idea.

Technical Reports

• Technical Reports Databases
• Definition and Thesauri

Selected Technical Report Databases

• NTIS Database (National Technical Information Service) This link opens in a new window Access the latest research sponsored by the United States and select foreign governments. Online coverage back to 1964.

Georgia Tech Library's NTIS subscription database includes citations and abstracts from unclassified government-sponsored research reports from the Departments of Defense, Department of Energy, NASA, EPA, and other federal agencies. Many NTIS records link to full text; click on the NTIS "Full text" icon to link directly a full text PDF icon. Engineering Village platform.

• DTIC - S&T Research: Public Technical Reports This link opens in a new window DTIC - S&T Research: Public Technical Reports offers citations of unclassified, unlimited documents that have been entered into DTIC's Technical Reports Collection, as well as the electronic full-text of selected documents.

Search box - top of screen "Search this site, DoD S&T Reports, and more."

• ERIC This link opens in a new window The ERIC (Educational Resources Information Center) database covers all aspects of education and educational research, includes both abstracts of published and unpublished sources on thousands of educational topics. It corresponds to the printed indexes of RIE (Resources in Education) and CIJE (Current Index to Journals in Education).

ERIC can also be searched on the Georgia Tech Library ProQuest subscription platform (ProQuest top row " Change databases").

National Technical Reports Library ( NTRL ). The Department of Commerce National Technical Information Service offers free public access to a searchable online database of federal science and technology reports through their National Technical Reports Library (NTRL; selected full text). Georgia Tech students and faculty/staff: use the subscription NTIS database, which links to many full text technical reports using the NTIS record "Full text" icon.

• NTRS: NASA Technical Report Server This link opens in a new window Provides access to NASA aerospace information and domestic and international STI (scientific and technical information) pertinent to NASA's missions.

OSTI.GOV (Office of Scientific and Technical Information, U.S. Department of Energy). Formerly SciTech Connect. Makes discoverable over 75 years of research results from DOE and its predecessor agencies. Results include records for technical reports, journal articles, conference papers, theses, patents, data, and more. Many full text. Search box drop down menu gives "Advanced Search Options" and "More Options."  Left column filters after initial search. 

• TRAIL - Technical Reports Image & Archive Library This link opens in a new window U.S. government technical reports in technology and science issued prior to 1976.
• TRID Online This link opens in a new window Records from the Transportation Research Information Services (TRIS) database and Joint Transport Research Centre's International Transport Research Documentation (ITRD) database.

Transportation. Can filter results: "Result Type" - "Reports, books, and collections"

ILLiad Interlibrary Loan for Georgia Tech Students and Faculty/Staff

For individual technical reports not available online full text, Georgia Tech students and faculty/staff can request copies of technical reports by filling out an ILLiad request form .

• << Previous: Home
• Next: Definition and Thesauri >>
• Last Updated: May 22, 2024 9:49 AM
• URL: https://libguides.library.gatech.edu/techreports

A .gov website belongs to an official government organization in the United States.

A lock ( ) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

• About Adverse Childhood Experiences
• Risk and Protective Factors
• Program: Essentials for Childhood: Preventing Adverse Childhood Experiences through Data to Action
• Adverse childhood experiences can have long-term impacts on health, opportunity and well-being.
• Adverse childhood experiences are common and some groups experience them more than others.

What are adverse childhood experiences?

Adverse childhood experiences, or ACEs, are potentially traumatic events that occur in childhood (0-17 years). Examples include: 1

• Experiencing violence, abuse, or neglect.
• Witnessing violence in the home or community.
• Having a family member attempt or die by suicide.

Also included are aspects of the child’s environment that can undermine their sense of safety, stability, and bonding. Examples can include growing up in a household with: 1

• Substance use problems.
• Mental health problems.
• Instability due to parental separation.
• Instability due to household members being in jail or prison.

The examples above are not a complete list of adverse experiences. Many other traumatic experiences could impact health and well-being. This can include not having enough food to eat, experiencing homelessness or unstable housing, or experiencing discrimination. 2 3 4 5 6

Quick facts and stats

ACEs are common. About 64% of adults in the United States reported they had experienced at least one type of ACE before age 18. Nearly one in six (17.3%) adults reported they had experienced four or more types of ACEs. 7

Preventing ACEs could potentially reduce many health conditions. Estimates show up to 1.9 million heart disease cases and 21 million depression cases potentially could have been avoided by preventing ACEs. 1

Some people are at greater risk of experiencing one or more ACEs than others. While all children are at risk of ACEs, numerous studies show inequities in such experiences. These inequalities are linked to the historical, social, and economic environments in which some families live. 5 6 ACEs were highest among females, non-Hispanic American Indian or Alaska Native adults, and adults who are unemployed or unable to work. 7

ACEs are costly. ACEs-related health consequences cost an estimated economic burden of $748 billion annually in Bermuda, Canada, and the United States. 8

ACEs can have lasting effects on health and well-being in childhood and life opportunities well into adulthood. 9 Life opportunities include things like education and job potential. These experiences can increase the risks of injury, sexually transmitted infections, and involvement in sex trafficking. They can also increase risks for maternal and child health problems including teen pregnancy, pregnancy complications, and fetal death. Also included are a range of chronic diseases and leading causes of death, such as cancer, diabetes, heart disease, and suicide. 1 10 11 12 13 14 15 16 17

ACEs and associated social determinants of health, such as living in under-resourced or racially segregated neighborhoods, can cause toxic stress. Toxic stress, or extended or prolonged stress, from ACEs can negatively affect children’s brain development, immune systems, and stress-response systems. These changes can affect children’s attention, decision-making, and learning. 18

Children growing up with toxic stress may have difficulty forming healthy and stable relationships. They may also have unstable work histories as adults and struggle with finances, jobs, and depression throughout life. 18 These effects can also be passed on to their own children. 19 20 21 Some children may face further exposure to toxic stress from historical and ongoing traumas. These historical and ongoing traumas refer to experiences of racial discrimination or the impacts of poverty resulting from limited educational and economic opportunities. 1 6

Adverse childhood experiences can be prevented. Certain factors may increase or decrease the risk of experiencing adverse childhood experiences.

Preventing adverse childhood experiences requires understanding and addressing the factors that put people at risk for or protect them from violence.

Creating safe, stable, nurturing relationships and environments for all children can prevent ACEs and help all children reach their full potential. We all have a role to play.

• Merrick MT, Ford DC, Ports KA, et al. Vital Signs: Estimated Proportion of Adult Health Problems Attributable to Adverse Childhood Experiences and Implications for Prevention — 25 States, 2015–2017. MMWR Morb Mortal Wkly Rep 2019;68:999-1005. DOI: http://dx.doi.org/10.15585/mmwr.mm6844e1 .
• Cain KS, Meyer SC, Cummer E, Patel KK, Casacchia NJ, Montez K, Palakshappa D, Brown CL. Association of Food Insecurity with Mental Health Outcomes in Parents and Children. Science Direct. 2022; 22:7; 1105-1114. DOI: https://doi.org/10.1016/j.acap.2022.04.010 .
• Smith-Grant J, Kilmer G, Brener N, Robin L, Underwood M. Risk Behaviors and Experiences Among Youth Experiencing Homelessness—Youth Risk Behavior Survey, 23 U.S. States and 11 Local School Districts. Journal of Community Health. 2022; 47: 324-333.
• Experiencing discrimination: Early Childhood Adversity, Toxic Stress, and the Impacts of Racism on the Foundations of Health | Annual Review of Public Health https://doi.org/10.1146/annurev-publhealth-090419-101940 .
• Sedlak A, Mettenburg J, Basena M, et al. Fourth national incidence study of child abuse and neglect (NIS-4): Report to Congress. Executive Summary. Washington, DC: U.S. Department of Health an Human Services, Administration for Children and Families.; 2010.
• Font S, Maguire-Jack K. Pathways from childhood abuse and other adversities to adult health risks: The role of adult socioeconomic conditions. Child Abuse Negl. 2016;51:390-399.
• Swedo EA, Aslam MV, Dahlberg LL, et al. Prevalence of Adverse Childhood Experiences Among U.S. Adults — Behavioral Risk Factor Surveillance System, 2011–2020. MMWR Morb Mortal Wkly Rep 2023;72:707–715. DOI: http://dx.doi.org/10.15585/mmwr.mm7226a2 .
• Bellis, MA, et al. Life Course Health Consequences and Associated Annual Costs of Adverse Childhood Experiences Across Europe and North America: A Systematic Review and Meta-Analysis. Lancet Public Health 2019.
• Adverse Childhood Experiences During the COVID-19 Pandemic and Associations with Poor Mental Health and Suicidal Behaviors Among High School Students — Adolescent Behaviors and Experiences Survey, United States, January–June 2021 | MMWR
• Hillis SD, Anda RF, Dube SR, Felitti VJ, Marchbanks PA, Marks JS. The association between adverse childhood experiences and adolescent pregnancy, long-term psychosocial consequences, and fetal death. Pediatrics. 2004 Feb;113(2):320-7.
• Miller ES, Fleming O, Ekpe EE, Grobman WA, Heard-Garris N. Association Between Adverse Childhood Experiences and Adverse Pregnancy Outcomes. Obstetrics & Gynecology . 2021;138(5):770-776. https://doi.org/10.1097/AOG.0000000000004570 .
• Sulaiman S, Premji SS, Tavangar F, et al. Total Adverse Childhood Experiences and Preterm Birth: A Systematic Review. Matern Child Health J . 2021;25(10):1581-1594. https://doi.org/10.1007/s10995-021-03176-6 .
• Ciciolla L, Shreffler KM, Tiemeyer S. Maternal Childhood Adversity as a Risk for Perinatal Complications and NICU Hospitalization. Journal of Pediatric Psychology . 2021;46(7):801-813. https://doi.org/10.1093/jpepsy/jsab027 .
• Mersky JP, Lee CP. Adverse childhood experiences and poor birth outcomes in a diverse, low-income sample. BMC pregnancy and childbirth. 2019;19(1). https://doi.org/10.1186/s12884-019-2560-8 .
• Reid JA, Baglivio MT, Piquero AR, Greenwald MA, Epps N. No youth left behind to human trafficking: Exploring profiles of risk. American journal of orthopsychiatry. 2019;89(6):704.
• Diamond-Welch B, Kosloski AE. Adverse childhood experiences and propensity to participate in the commercialized sex market. Child Abuse & Neglect. 2020 Jun 1;104:104468.
• Shonkoff, J. P., Garner, A. S., Committee on Psychosocial Aspects of Child and Family Health, Committee on Early Childhood, Adoption, and Dependent Care, & Section on Developmental and Behavioral Pediatrics (2012). The lifelong effects of early childhood adversity and toxic stress. Pediatrics, 129(1), e232–e246. https://doi.org/10.1542/peds.2011-2663
• Narayan AJ, Kalstabakken AW, Labella MH, Nerenberg LS, Monn AR, Masten AS. Intergenerational continuity of adverse childhood experiences in homeless families: unpacking exposure to maltreatment versus family dysfunction. Am J Orthopsych. 2017;87(1):3. https://doi.org/10.1037/ort0000133 .
• Schofield TJ, Donnellan MB, Merrick MT, Ports KA, Klevens J, Leeb R. Intergenerational continuity in adverse childhood experiences and rural community environments. Am J Public Health. 2018;108(9):1148-1152. https://doi.org/10.2105/AJPH.2018.304598 .
• Schofield TJ, Lee RD, Merrick MT. Safe, stable, nurturing relationships as a moderator of intergenerational continuity of child maltreatment: a meta-analysis. J Adolesc Health. 2013;53(4 Suppl):S32-38. https://doi.org/10.1016/j.jadohealth.2013.05.004 .

Adverse Childhood Experiences (ACEs)

ACEs can have a tremendous impact on lifelong health and opportunity. CDC works to understand ACEs and prevent them.