Types of ReportsIn Reporting Services, you can use reports in a variety of ways. This topic describes the terminology used to describe the various types of reports and the ways reports get created and used. A single report can have characteristics from more than one type; for example, snapshot reports can be parameterized, ad hoc reports incorporate clickthrough report functionality due to the report models upon which they are based, and subreports can be linked reports.With Reporting Services, you can create the following types of reports:

Parameterized reports  Linked reports  Snapshot reports  Cached reports  Ad hoc reports  Clickthrough reports  Drilldown reports  Drillthrough reports  Subreports 

  Report Appearance, Processing, and Delivery TerminologyThere are several ways to think about report type. You might think about it as the way data appears in the report. In Reporting Services, the appearance of data in a report depends on the type of data region you use; for example, tabular reports and chart reports use different data regions. For more information about how to display data, see Data Regions. Likewise, the functionality that is available in a report depends on the output format; for example, interactive features like drillthrough reports are available in Web-based export formats but not in all Image-based export formats. A report's final output format affects which features you can include in a report. For more information about design considerations for various export formats, see Exporting Reports.There is also terminology associated with the stage of processing a report is in. For more information about the differences between report definitions, publishedreports, and rendered reports, see Reports and Report Definitions. Finally, for information about report scheduling and on-demand reports, see Scheduling Reports and Subscriptions.

  Parameterized ReportsA parameterized report uses input values to complete report or data processing. With a parameterized report, you can vary the output of a report based on values that are set when the report runs. Parameterized reports are frequently used for drillthrough reports, linked reports, and subreports, connecting and filtering reports with related data.Using ParametersParameters are used in dataset queries to select report data, to filter the result set that the query returns, or to set layout properties used to display or hide parts of a report. You can also specify cascading parameters that populate a series of dependent, drop-down parameter lists. For example, a drop-down list of Region parameter values can be used to populate a drop-down list of City parameter values.You can use parameters with linked reports by pairing a specific parameter with each linked report to change the outcome. For example, you can create a single regional sales report that shows the sales for all regions, and then use a parameter for each linked report to filter data for a particular region. Specific parameter values can be stored with the report so that users do not have to type values.Not all parameters may be visible in the report at run time. A report author, report server administrator, or content manager can specify which values to use and then hide the input fields on the report.Query Parameters and Report ParametersReporting Services supports two kinds of parameters: query parameters and report parameters. Query parameters are used during data processing to select or filter data. Query parameters are specified in the syntax of a data processing extension. If a query parameter is specified, a value must be provided either by the user or by default properties to complete the SELECT statement or stored procedure that retrieves data for a report. Report parameters are used during report processing to show a different aspect of the data. A report parameter is usually used to filter a large set of records, but it can have other uses depending on the queries and expressions used in the report. Report parameters differ from query parameters in that they are

defined in a report and processed by the report server, while query parameters are defined as part of the dataset query and processed on the database server. For more information, see Adding Parameters to Your Report and Setting Parameter Properties for a Published Report.

  Linked ReportsA linked report is a report server item that provides an access point to an existing report. Conceptually, it is similar to a program shortcut that you use to run a program or open a file.A linked report is derived from an existing report and retains the original's report definition. A linked report always inherits report layout and data source properties of the original report. All other properties and settings can be different from those of the original report, including security, parameters, location, subscriptions, and schedules.You can create a linked report on the report server when you want to create additional versions of an existing report. For example, you could use a single regional sales report to create region-specific reports for all of your sales territories.Although linked reports are typically based on parameterized reports, a parameterized report is not required. You can create linked reports whenever you want to deploy an existing report with different settings. For more information, see Adding, Modifying, and Deleting Linked Reports.

  Snapshot ReportsA report snapshot is a report that contains layout information and query results that were retrieved at a specific point in time. Unlike on-demand reports, which get up-to-date query results when you select the report, report snapshots are processed on a schedule and then saved to a report server. When you select a report snapshot for viewing, the report server retrieves the stored report from the report server database and shows the data and layout that were current for the report at the time the snapshot was created.Report snapshots are not saved in a particular rendering format. Instead, report snapshots are rendered in a final viewing format (such as HTML) only when a user or an application requests it. Deferred rendering makes a snapshot portable. The report can be rendered in the correct format for the requesting device or Web browser.Report snapshots serve three purposes:

Report history. By creating a series of report snapshots, you can build a history of a report that shows how data changes over time. 

Consistency. Use report snapshots when you want to provide consistent results for multiple users who must work with identical sets of data. With volatile data, an on-demand report can produce different results from one minute to the next. A report snapshot, by contrast, allows you to make valid comparisons against other reports or analytical tools that contain data from the same point in time.

Performance. By scheduling large reports to run during off-peak hours, you can reduce processing impact on the report server during core business hours. 

For more information about creating report snapshots, see Setting Report Processing Properties.

  Cached ReportsA cached report is a saved copy of a processed report. Cached reports are used to improve performance by reducing the number of processing requests to the report processor and by reducing the time required to retrieve large reports. They have a mandatory expiration period, usually in minutes. For more information about how to use cached reports, see Report Caching in Reporting Services.

  Ad Hoc ReportsAn ad hoc report can be created from an existing report model by using Report Builder. Ad hoc reports refer specifically to Report Builder reports, and not to reports that you can create using the Report Wizard. Ad hoc reports leverage report models and pre-defined templates to enable information workers to quickly and easily explore business data using familiar terminology and data structures that have been implemented in the report model. Ad hoc reports can be saved and run locally or published to a report server, just like other Reporting Services reports. For more information about ad hoc reports, see Designing and Implementing Reports Using Report Builder 1.0.

  Clickthrough Reports

A clickthrough report is a report that displays related data from a report model when you click the interactive data contained within your model-based report. These reports are generated by the report server based on the information contained within the report model. The person who created the model determines which fields are interactive and which fields are returned when a clickthrough report is opened. These field settings cannot be changed in the report authoring tools. For more information, see Viewing Clickthrough Reports from a Report (Report Builder 1.0).Clickthrough reports are autogenerated. However, you can create an alternative customized report to the model for interactive data items that is displayed instead. The custom report is a standard Reporting Services report. For more information, see Working with Clickthrough Reports.

  Drilldown ReportsDrilldown reports initially hide complexity and enable the user to toggle conditionally hidden report items to control how much detail data they want to see. Drilldown reports must retrieve all possible data that can be shown in the report. For more information, see Hiding Report Items Conditionally.For reports with large amounts of data, consider drillthrough reports instead.

  Drillthrough ReportsDrillthrough reports are standard reports that are accessed through a hyperlink on a text box in the original report. Drillthrough reports work with a main report and are the target of a drillthrough action for a report item such as placeholder text or a chart. The main report displays summary information, for example in a matrix or chart. Actions defined in the matrix or chart provide drillthrough links to reports that display greater details based on the aggregate in the main report. Drillthrough reports can be filtered by parameters, but they do not have to be. Drillthrough reports differ from subreports in that the report does not display within the original report, but opens separately. They differ from clickthrough reports in that they are not autogenerated from the data source, but are instead custom reports that are saved on the report server. They differ from drilldown reports in that they retrieve the report data only for the specified parameters or for the dataset query. For more information, see Adding Links to a Report.

  SubreportsA subreport is a report that displays another report inside the body of a main report. Conceptually, a subreport is similar to a frame in a Web page. It is used to embed a report within a report. Any report can be used as a subreport. The subreport can use different data sources than the main report. The report that the subreport displays is stored on a report server, usually in the same folder as the parent report. You can set up the parent report to pass parameters to the subreport.Although a subreport can be repeated within data regions using a parameter to filter data in each instance of the subreport, subreports are typically used with a main report as a briefing book or as a container for a collection of related reports. For more information, see Adding Subreports.For reports with many instances of subreports, consider using drillthrough reports instead.

  See Also

A report is a dreadfully official document that is written to serve the range of purpose in the engineering and business disciplines; sciences and social sciences. Therefore, they need to be clear-cut and accurate. Good report writing call for--- professionalism, profound knowledge of the subject, attentiveness, and outstanding writing proficiency.

Types of Report Writing ---

Research Report Writing Business Report Writing Science Report Writing

Research Report Writing--- To presents the tangible proof of the conducted research is the major intention of the academic assignment. When writing on research report, you must ponder over clarity, organization, and content. Research reports are all the more same to technical reports, lab reports, formal reports and scientific papers which comprise a quite

consistent format that will facilitate you to put your information noticeably, making it crystal clear.

Business Report Writing--- In business milieu, Business report writing happens to be an indispensable part of the communication process. Executive summary is written in a non-technical manner. By and large, audience for business reports will consist of upper level manager, for that reason you should take the audience needs in consideration. Go on with the introduction to articulate the problem and determine the scope of the research. To attain the desired results, don't fail to state about the precise quantitative tools.

Science Report Writing--- Parallel to a business report, science report writing also corresponds with the line of investigation. To report upon an empirical investigation, these reports make use of standard scientific report format, portraying technique, fallout and conclusions. As an assignment in undergraduate papers within the scientific disciplines, it is required frequently.

The main objective of the Science report is to boast an aim, the technique which enlightens how the project has been analyzed, the outcomes which presents the findings and the conclusion. This embraces advance research suggestions and your own biased opinion on the topic which has been talked about.

When writing a science report, do not fail to remember to use heading and subheadings in order to direct a reader through your work. In the form of tables and graphs, Statistical evidence should be incorporated in appendices. Than refer to it in the body of your scientific report.

Reports are a common form of writing because of the inclusion of recommendations which are helpful in implementing the decision.

A report is a very formal document that is written for a variety of purposes, generally in the sciences, social sciences, engineering and business disciplines. Generally, findings pertaining to a given or specific task are written up into a report. It should be noted that reports are considered to be legal documents in the workplace and, thus, they need to be precise, accurate and difficult to misinterpret. 

A report is a very formal document that is written for a variety of purposes, generally in the sciences, social sciences, engineering and business disciplines. Generally, findings pertaining to a given or specific task are written up into a report. It should be noted that reports are considered to be legal documents in the workplace and, thus, they need to be precise, accurate and difficult to misinterpret. 

laboratory reports health and safety reportsresearch reports case study reportsfield study reports cost-benefit analysis reportsproposals comparative advantage reportsprogress reports feasibility studiestechnical reports instruction manualsfinancial reports And on it goes …

Engineering

Reports can outline a proposal for a project; report on progress of a project; present research and findings from a project; detail the technical aspects of innovations; present results from a feasibility or cost-benefit analytical study.

Education and Health Science

Practicum reports are based on experiences at prac. school or hospital. Ongoing journal entries are written up into a report at the end of term. There are field and research reports.

Science and some Social Sciences

Laboratory reports outline, analyse and evaluate results from experiments. Research or field reports are findings from the field and make recommendations based on this. Feasibility studies report investigations into the feasibility of something and make recommendations accordingly. Case study reports are found especially in the areas of social welfare, social work, and psychology.

Business

Report writing is frequently used in business subjects. Reports can range from short memos to lengthy reports such as cost-benefit analysis reports; research and field reports; financial reports; proposals; progress reports; health and safety reports; quality reports; case study reports.

Reports are organised into separate sections according to the specific requirements of the given task. While it is important that paragraphs are structured and there is unity, coherence and logical development to the report, it is not a continuous piece of writing like an essay. Each type of report serves a very specific purpose and is aimed at a very particular audience.

Report writing may seem repetitive to us, but this is because reports are not usually read from cover-to-cover by one person. For example, a manager may read only the synopsis or abstract and act on the advice it contains while a technical officer may read only the section that explains how things work. On the other hand, a personnel officer may look at only the conclusions and recommendations that directly affect his or her working area.

Because there is such a wide range of reports that serve different purposes, your faculty will generally have guidelines that they want you to follow. As a general rule, however, the following should give you some indication of what to include in a formal report.

A letter of transmittal

This is a covering letter which is sent with the report to the person or organisation that requested the report. (Your assignment may not require you to provide this with your report.)

Sample letter of transmittal

  

A title page

This outlines the name of the report; who prepared the report; for whom the report was prepared; the nature of the report; the date the report was prepared.

Sample title page

 

An abstract or synopsis

An abstract or synopsis outlines, very briefly, the entire report. It contains: the aim or purpose, the procedures followed, the main findings and conclusions and recommendations that are outlined in the report. The abstract or synopsis is like an introduction of an essay.

Sample abstract

This report discusses the feasibility study carried out from 12 June 2001 to 7 December 2001 into the damming of the Blue River between Johnson's Creek and Blackstump Creek. Water flow rates, sediment levels, fish stock numbers, weed infiltration rates and salinity tests have been carried out and positive conclusions have been drawn. It should be noted that areas flooded by the proposed dam include only those areas already declared unusable for agricultural purposes. It is expected that economic opportunities for a fishery, council caravan park, irrigation leases and household water meter reservoirs will be forthcoming within twelve months of the dam's completion. It is recommended that the council approves dam construction and seeks firm financial backing immediately.

A contents page

This includes the page numbers of each section within the report and any appendices that are attached to the report. It does not include the title page or abstract. These are attached to the report before the contents page.

The report itself

The report is broken into sections and each section and subsection has a heading. Often, a numbering system is used to indicate each section or subsection. Becoming more popular, however, is changing the font size of headings to indicate the importance of each heading. Only numbering style is indicated below.

Sample numbering system used in report writing

1. INTRODUCTION

1.1. Aim1.2. Scope1.3. Background to study2. PROCEDURE

2.1. Data collection method2.2. Literature review2.2.1. Literature review of journals 2000 – 20013. ANALYSIS Of DATA

3.1. Water flow of Blue River3.2. Sediment levels of Blue River3.3. Fish stock numbers3.4. Weed infiltration rates3.5. Salinity levels of Blue River

3.6. Likely areas to be flooded4. CONCLUSIONS

5. RECOMMENDATIONS

REFERENCESAPPENDICES

 Privacy Copyright Disclaimer Accessibility Contact

CQUniversity CRICOS Provider Codes: QLD - 00219C; NSW - 01315F; VIC - 0162

Additional sections that may be required in the report. 

Appendices

Appendices include things like raw data sheets, extra or supplementary information or diagrams, maps of regions etc. You draw your reader's attention to the appropriate appendix by indicating this briefly at the appropriate place in the report. For example:

Water flow rates indicate that there is no significant change between 1998 and 2001. Comprehensive flow rate charts for the period 1998-2000 are included as Appendix A.

Glossary

Sometimes, when there is a lot of 'jargon' contained in a report (as in Science or Engineering), a glossary of terms should also be included. This ensures that those reading the report understand the way you have used the terms or jargon in your report. Sometimes words can have different meanings in different disciplines. If you need to include a glossary, it would generally be placed just after the contents page.

Language style

The style of language used in reports is concrete, active and formal as a rule. The rules of plain English definitely apply most of the time.

There is no room for bias or 'fudging' results especially when they are considered to be legal documents. This is particularly the case in engineering, business, the sciences and some social sciences.

LayoutThe use of white space is very important in report writing. Spacing between headings, subheadings, paragraphs, ends of sections, diagrams etc. need to be uniform. As a guide—one space between heading and subheading, one space between paragraphs, and two spaces between the end of a section and the next heading. Whatever you choose, make sure you aim for consistency.

Introduction

Aim

In this section you indicate the purpose of the report.

Scope

This shows what the report includes and excludes. For example:

This feasibility study indicates the environmental feasibility of the proposed damming of the Blue River between Johnson's Creek and Blackstump Creek. It does not include building specifications of the dam itself. A further proposal would be offered if council decides to proceed with the recommendations of this study.

Background to study

This section contains any relevant details regarding the background information that may be needed to make sense of the information in the report. It may outline the history of a project, or major players in the project. For example:

In January 2008, Kalkadoo township experienced severe water shortages as a result of prolonged drought periods during 2005 and 2006. The Kalkadoo Shire Council has made it a priority for this situation to be remedied so that this situation does not occur in the future. The Shire Council had conducted investigations into providing a dam for the region in the late-1980s but plans were halted due to public dissatisfaction with the outcome of those investigations. Further environmental studies needed to be conducted over a longer period to determine the impact of the dam on neighbouring farms and Crown land reserves. This series of investigations was completed in December 2003. The outcome suggested no significant negative environmental or economic impacts would be felt. In June 2004, the Shire Council proposed that the final stages of the feasibility study should be conducted, and conclusions and recommendations from the entire study should be tabled at Council's Planning Committee meeting scheduled for 12 January 2005. This feasibility study report should thus enable Council to make a final decision regarding improving water supplies to the Shire. This is one of its three priority areas for the period 2004-2009.

Data collection methods

In this section, you would briefly outline how you collected the data that will provide the basis for analysis that will produce conclusions and recommendations. Even though it may be called something different, all reports use specific data and ways of collecting it that would be included in this section.

In research reports, you would probably use a different heading because your data would come mainly from texts and journal articles. This is the section where you would discuss the main issues arising from your research. 

In reports that are based on data you have collected yourself, like the report used in the example so far, this section would detail the methods you used to collect that data and why those methods were chosen. You would also outline the steps taken during the process of collecting data and carrying out research. An example is set out below:

During this six-month feasibility study, data were collected and analysed according to the criteria outlined for environmental impact studies as set out in the Queensland Department of Primary Industry's Environmental Studies Handbook (2003). Water flow rates were measured according to rate of flow 100 ml per hour. These rates were recorded three times per week during the study. Sediment and salinity levels were measured according to the percentage of suspended siltation carried in the fastest flowing section of the river channel. These measurements were also taken three times per week, and more often during the change of tides. Fish stock numbers were recorded once per month where tagged fish were counted and measured. Specific areas within the study region were targeted and fish stock numbers randomly checked using sonar equipment. Weed infiltration rates were recorded, both in the river itself, and in the land regions that would be directly affected by flooding. Weekly recordings were made of the types of species already present in the areas of study, and identification of new varieties was monitored.

Analysis of data

This section is perhaps the longest section in most reports and it is where, using visual displays, you outline the data you have collected.

Graphs, charts, tables, maps, graphic displays should always be used to summarise the findings you have made from the data you have collected.

Each set of data may be displayed in more than one way and each diagram or visual should have a title, figure or table number, and should be clearly labelled.

Each set of data is systematically displayed and analysed in a paragraph under the appropriate diagram. For example:

Water flow rates

Table 1: Water flow rates—Blue River, 1 June 2003 – 7 December 2003

Date Time Volume/Hour 100 ml/Hour Recommended flow rate for viable damming

The table indicates that periods of peak flow occurred between July and September 2003. The rates of flow are 50% higher than those rates recommended to be viable for substantial damming of an area. The lowest flow recorded occurred during November but is still significantly higher than the recommended flow rate for viable damming. There is no evidence to suggest that these levels are unusual for this region. Table 2 compares water flow rates for the same periods from studies conducted over the period 1999-2001. (See Table 2, page 12.) This indicates that the water flow rates are stable and there is very little variation from year to year or month to month.

Conclusions

The conclusions are dot pointed and are drawn directly from the analysis section of the report. Dot points are used when the sequential order is not important. For each section under the main heading 'Analysis', there should be at least one corresponding conclusion. For example:

The Blue River flow rate is significantly higher than was expected. Damming the Blue River between Johnson's Creek and Blackstump Creek would not affect average water flow rates upstream or downstream from this area.

Sediment levels remained between 0.02% and 0.05% during the dry months. Sediment levels of 1.2% are considered to be acceptable. Damming the river will not significantly increase sedimentation downstream. Upstream, sediment levels will increase between 0.5% and 1.0%. This increase is still within the acceptable range according to guidelines (given by the Department of Primary Industries).

Recommendations

These are your suggestions for further action based on your conclusions. Not all reports will ask for recommendations. Some will have a section where both conclusions and recommendations are given. Recommendations are numbered as they normally follow sequentially. For example:

1. The damming of the Blue River between Johnson's Creek and Blackstump Creek should proceed.

2. Damming of this area could lead to significant economic advantages.

References

A reference list with publication details of sources used should be included after the conclusions/recommendations section. Any appendices follow the reference list.

How to Write a Good Report Bhaskaran Raman, Apr 2004

This short document describes how to write a good report. This is based on common mistakes I have observed over a period of time. While most of the following apply in general, they have been written with BTech/MTech/PhD students in mind.

The comments below apply for course projects, other semester projects, technical reports, theses (BTech/MTech/PhD). That is, technical writing in general. While a google search on the topic may churn out many hits, the following is tailored for IIT (Kanpur) students in particular.

I will first mention some general guidelines, then the structure of the report. Towards the end, I will also describe how to refine your writing, and how to give feedback on others' writing. Based on these, I will recommend a possible strategy for producing high-quality reports which have high potential for being published.

General Guidelines

These are some general things you should know before you start writing. I will try to answer the questions of the purpose of report writing, and the overall approach as well.

Purpose of a report: writing to be read

A key thing to keep in mind right through your report writing process is that a report is written to be read, by someone else. This is the central goal of report-writing. A report which is written for the sake of being written has very little value.

Before you start writing your report, you need to have in mind the intended audience. In the narrowest of possibilities, your report is meant for reading by yourselves, and by your advisor/instructor, and perhaps by your evaluation committee. This has value, but only short-term. The next broader possibility is that your report is readable by your peers or your juniors down the line. This has greater value since someone else can continue on your work and improve it, or learn from your work. In the best case possibility, your report is of publishable quality. That is, readable and useful for the technical community in general.

Overall approach: top-down

Take a top-down approach to writing the report (also applies to problem solving in general). This can proceed in roughly three stages of continual refinement of details.

1. First write the section-level outline,2. Then the subsection-level outline, and3. Then a paragraph-level outline. The paragraph-level outline would more-or-less

be like a presentation with bulleted points. It incorporates the flow of ideas.

Once you have the paragraph-level flow of ideas, you can easily convert that into a full report, by writing out the flow of ideas in full sentences.

While doing the paragraph-level outline, think also about (a) figures, (b) tables, and (c) graphs you will include as part of the report at various stages. You will find that many things can be better explained by using simple figures at appropriate places.

Another thing to nail-down while doing the paragraph-level outline is the terminology you will be using. For instance, names of various protocols/algorithms/steps in your solution. Or names/symbols for mathematical notation.

The overall approach also includes multiple stages of refinement, and taking feedback from others (peers/advisor/instructor). I will talk about these in more detail after talking about the overall report structure.

Structure of a report

The following should roughly be the structure of a report. Note that these are just guidelines, not rules. You have to use your intelligence in working out the details of your specific writing.

Title and abstract: These are the most-read parts of a report. This is how you attract attention to your writing. The title should reflect what you have done and should bring out any eye-catching factor of your work, for good impact.

The abstract should be short, generally within about 2 paragraphs (250 words or so total). The abstract should contain the essence of the report, based on which the reader decides whether to go ahead with reading the report or not. It can contain the following in varying amounts of detail as is appropriate: main motivation, main design point, essential difference from previous work, methodology, and some eye-catching results if any.

Introduction: Most reports start with an introduction section. This section should answer the following questions (not necessarily in that order, but what is given below is a logical order). After title/abstract introduction and conclusions are the two mainly read parts of a report.

o What is the setting of the problem? This is, in other words, the background. In some cases, this may be implicit, and in some cases, merged with the motivation below.

o What exactly is the problem you are trying to solve? This is the problem statement.

o Why is the problem important to solve? This is the motivation. In some cases, it may be implicit in the background, or the problem statement itself.

o Is the problem still unsolved? The constitutes the statement of past/related work crisply.

o Why is the problem difficult to solve? This is the statement of challenges. In some cases, it may be implicit in the problem statement. In others, you may have to say explicitly as to why the problem is worthy of a BTech/MTech/PhD, or a semester project, as the case may be.

o How have you solved the problem? Here you state the essence of your approach. This is of course expanded upon later, but it must be stated explicitly here.

o What are the conditions under which your solution is applicable? This is a statement of assumptions.

o What are the main results? You have to present the main summary of the results here.

o What is the summary of your contributions? This in some cases may be implicit in the rest of the introduction. Sometimes it helps to state contributions explicitly.

o How is the rest of the report organized? Here you include a paragraph on the flow of ideas in the rest of the report. For any report beyond 4-5 pages, this is a must.

The introduction is nothing but a shorter version of the rest of the report, and in many cases the rest of the report can also have the same flow. Think of the rest of the report as an expansion of some of the points in the introduction. Which of the above bullets are expanded into separate sections (perhaps even multiple sections) depends very much on the problem.

Background: This is expanded upon into a separate section if there is sufficient background which the general reader must understand before knowing the details of your work. It is usual to state that "the reader who knows this background can skip this section" while writing this section.

Past/related work: It is common to have this as a separate section, explaining why what you have done is something novel. Here, you must try to think of dimensions of comparison of your work with other work. For instance, you may compare in terms of functionality, in terms of performance, and/or in terms of approach. Even within these, you may have multiple lines of comparison -- functionality-1, functionality-2, metric-1, metric-2, etc.

Although not mandatory, it is good presentation style to give the above comparison in terms of a table; where the rows are the various dimensions of comparison and the columns are various pieces of related work, with your own work being the first/last column. See the related work section of my PhD thesis for an example of such a table :-).

While in general you try to play up your work with respect to others, it is also good to identify points where your solution is not so good compared to others. If you state these explicitly, the reader will feel better about them, than if you do not state and the reader figures out the flaws in your work anyway :-).

Another point is with respect to the placement of related work. One possibility is to place it in the beginning of the report (after intro/background). Another is to place it in the end of the report (just before conclusions). This is a matter of judgment, and depends on the following aspect of your work. If there are lots of past work related very closely to your work, then it makes sense to state upfront as to what the difference in your approach is. On the other hand, if your work is substantially different from past work, then it is better to put the related work at the end. While this conveys a stronger message, it has the risk of the reader wondering all through the report as to how your work is different from some other specific related work.

Technical sections: The main body of the report may be divided into multiple sections as the case may be. You may have different sections which delve into different aspects of the problem. The organization of the report here is problem specific. You may also have a separate section for statement of design methodology, or experimental methodology, or proving some lemmas in a theoretical paper.

The technical section is the most work-specific, and hence is the least described here. However, it makes sense to mention the following main points:

o Outlines/flow: For sections which may be huge, with many subsections, it is appropriate to have a rough outline of the section at the beginning of that section. Make sure that the flow is maintained as the reader goes from one section to another. There should be no abrupt jumps in ideas.

o Use of figures: The cliche "a picture is worth a thousand words" is appropriate here. Spend time thinking about pictures. Wherever necessary, explain all aspects of a figure (ideally, this should be easy), and do not leave the reader wondering as to what the connection between the figure and the text is.

o Terminology: Define each term/symbol before you use it, or right after its first use. Stick to a common terminology throughout the report.

Results: This is part of the set of technical sections, and is usually a separate section for experimental/design papers. You have to answer the following questions in this section:

o What aspects of your system or algorithm are you trying to evaluate? That is, what are the questions you will seek to answer through the evaluations?

o Why are you trying to evaluate the above aspects?o What are the cases of comparison? If you have proposed an algorithm or

a design, what do you compare it with?

o What are the performance metrics? Why?o What are the parameters under study?o What is the experimental setup? Explain the choice of every parameter

value (range) carefully.o What are the results?o Finally, why do the results look the way they do?

The results are usually presented as tables and graphs. In explaining tables and graphs, you have to explain them as completely as possible. Identify trends in the data. Does the data prove what you want to establish? In what cases are the results explainable, and in what cases unexplainable if any?

While describing a table, you have to describe every row/column. And similarly while describing a graph, you have to describe the x/y axes. If necessary, you have to consider the use of log-axes.

If you are presenting a lot of results, it may be useful to summarize the main take-away points from all the data in a separate sub-section at the end (or sometimes even at the beginning) of the results section.

Future work: This section in some cases is combined along with the "conclusions" section. Here you state aspects of the problem you have not considered and possibilities for further extensions.

Conclusions: Readers usually read the title, abstract, introduction, and conclusions. In that sense, this section is quite important. You have to crisply state the main take-away points from your work. How has the reader become smarter, or how has the world become a better place because of your work?

Refinement

No report is perfect, and definitely not on the first version. Well written reports are those which have gone through multiple rounds of refinement. This refinement may be through self-reading and critical analysis, or more effectively through peer-feedback (or feedback from advisor/instructor).

Here are some things to remember:

Start early, don't wait for the completion of your work in its entirety before starting to write.

Each round of feedback takes about a week at least. And hence it is good to have a rough version at least a month in advance. Given that you may have run/rerun experiments/simulations (for design projects) after the first round of feedback -- for a good quality report, it is good to have a rough version at least 2 months in advance.

Feedback should go through the following stages ideally: (a) you read it yourself fully once and revise it, (b) have your peers review it and give constructive feedback, and then (c) have your advisor/instructor read it.

Feedback: evaluating someone else's report

Evaluation of a report you yourself have written can give benefits, but it usually is limited. Even in a group project, it is not good enough to have one person write the report and the other person read it. This is because all the group members usually know what the project is about, and hence cannot critique the paper from outside.

It is best to take feedback from your peer (and of course return favours!). The feedback procedure is quite simple. The one reading has to critically, and methodically see if each of the aspects mentioned above in the "structure of the report" are covered. It may even help to have a check-list, although with experience this becomes unnecessary.

Check if the title/abstract make sense, are effective/eye-catching. Are all the relevant questions answered in the introduction? Is the overall structure of the rest of the sections meaningful? Is the difference from related/past work crisp and meaningful? Are the technical sections understandable? Are the figures/tables explained

properly? Is the terminology clear? Are the symbols used defined appropriately?

Are the results explained properly? Are the conclusions drawn from the graphs/tables sound? Or are there technical holes/flaws? Do the results show how the work presented is better/worse that the other cases of comparison?

When I give feedback on a peer's report or a student's report, I usually take a print-out and mark-up at various points in the paper. You may follow a similar procedure, or something suited to you. Be as critical as possible, but with the view that your peer has to improve his/her work, not with the view of putting him/her down. Your comments have to be impersonal. Likewise, while taking feedback from a peer, take the comments on their technical merit.

Recommended strategy for producing a high-quality report

Based on the above, I recommend the following strategy for students who want to produce a high-quality report, which would then have a high potential for being turned into a publication:

Think through the outline of the report even as you are working on the details of the problem. Such thinking will also lend focus to your work and you will end up optimizing the returns on the time invested.

Two months before the actual deadline, you have to have at least a paragraph-level outline of the report, with all details worked out.

After one round of critical analysis by yourselves (or by your group), have another student or another group review it, perhaps in exchange for you reviewing their work. Have them check your flow of ideas. While it may be good to get someone working in the same area, for much of the feedback, this may not really be necessary.

Now you are probably about 6-7 weeks from the deadline. At this point, have your advisor/instructor give feedback on the paragraph-level outline. Getting this early is important since, based on this, you may have to reorganize your report, rework your theorems, or rerun your experiments/simulations.

Have a pre-final version of the report ready 2 weeks before the deadline. Again, go through one round of self/peer-feedback, and then advisor/instructor feedback.

With these 3-4 rounds of revision and critical analysis, the quality of your report is bound to improve. And since many of the student theses are of good quality, quality of writing dramatically improves chances of publication.

Importance of report writing

A very precise and well written report can prove to be very helpful to a person’s career as it

gives all the relevant information related to the subject while on the other hand a poorly written

report can cause a problem for a person as the credibility of his work gets on stake. 

Reports are like another form to communicate effectively. They are also a way to analyze ones

knowledge and skills. Once information is in hand the main thing is how one manages to

organize and presents the information. The presentation of information in the reports should be

in a manner that they are logical and concise. The proper formatted reports are one of the

most essentials   tools  used for business proposals and by a number of organizations. These

reports when are read by the targeted person will provide useful information in such a good

manner that will increase your credibility as a person and as an organization as well.

Report writing format

Introduction Report writing is a time consuming business so it is a great shame if, having devoted all that time to writing your report, the quality is such that hardly anyone can be bothered to read it. Quite frankly, most report readers do not actually read all the report; they are too short of time. You might as well know it and accept it -- that is normal. They only read the parts that interest them. Frequently these are the summary, the conclusions and recommendations.

Of course, some readers do need all the details you so carefully included, they are specialists, but most do not. Most readers just need two things: that the information they want is where they expect it to be so they can find it, and that it is written clearly so that they can understand it.

It is similar to reading a newspaper. You expect the news headlines to be on the front page; the sports coverage to be at the back; the TV listings on page whatever and the editorial comment in the middle. If what you want is not in its usual place then you have to hunt for it and you may get irritated. So it is with a report.

There is a convention as to what goes where. Stick with the convention and please your readers. Break the convention and people may get slightly irritated – and bin your report.

So what is that convention, the standard format?

Standard Sections 

Title Section. In a short report this may simply be the front cover. In a long one it could also include Terms of Reference, Table of Contents and so on.

Summary. Give a clear and very concise account of the main points, main conclusions and main recommendations. Keep it very short, a few percent of the total length. Some people, especially senior managers, may not read anything else so write as if it were a stand-alone document. It isn’t but for some people it might as well be. Keep it brief and free from jargon so that anyone can understand it and get the main points. Write it last, but do not copy and paste from the report itself; that rarely works well.

Introduction. This is the first part of the report proper. Use it to paint the background to ‘the problem’ and to show the reader why the report is important to them. Give your terms of reference (if not in the Title Section) and explain how the details that follow are arranged. Write it in plain English.

Main Body. This is the heart of your report, the facts. It will probably have several sections or sub-sections each with its own subtitle. It is unique to your report and will describe what you discovered about ‘the problem’.

These sections are most likely to be read by experts so you can use some appropriate jargon but explain it as you introduce it. Arrange the information logically, normally putting things in order of priority -- most important first. In fact, follow that advice in every section of your report.

You may choose to include a Discussion in which you explain the significance of your findings.

Conclusions. Present the logical conclusions of your investigation of ‘the problem’. Bring it all together and maybe offer options for the way forward. Many people will read this section. Write it in plain English. If you have included a discussion then this section may be quite short.

Recommendations. What do you suggest should be done? Don’t be shy; you did the work so state your recommendations in order of priority, and in plain English.

Appendices. Put the heavy details here, the information that only specialists are likely to want to see. As a guide, if some detail is essential to your argument then include it in the main body, if it merely supports the argument then it could go in an appendix.

Conclusions and Recommendations In conclusion, remember that readers expect certain information to be in certain places. They do not expect to hunt for what they want and the harder you make it for them the more likely they are to toss you report to one side and ignore it. So what should you do?

1. Follow the generally accepted format for a report: Summary, Introduction, Main Body, Conclusions, Recommendations and Appendices. 2. Organise your information in each section in a logical fashion with the reader in mind, usually putting things in order of priority – most important first.

Sample

Sample Report

Date: September 1, 2000To: Center Interns From: Center Team Leader Subject: Writing and Designing a Report

This report outlines some of the format considerations for designing business reports. Report formats can be designed in a variety of ways. Often, the organization you are working for may have standard requirements for report formats--be sure to follow these if they exist.

Reports can be as simple as the standard memo format or as complex as a formal report which might include

title page; letter or memo of transmittal ; table of contents  ; list of illustrations; executive summary or abstract ; body text; references ; appendices.

Note: Remember that you may or may not need to include all of these items, depending on the writing situation you are responding to.

Like a memo, any report should always specify the

date, recipients, writer(s), subject.

The kind of report format you choose should be appropriate for the communication situation. For example, this report is formatted as a memo, which is appropriate for more informal situations or for short reports. Regardless of whether the report is formal or informal, in any report you should begin by stating the purpose of the report. The format, content, and organization of the rest of the report depends on its purpose.

Progress/Status Reports

In any project that extends over a period of time, you will often be asked to provide a progress report. In these reports, you should include the following:

Summarize the progress you have made so far--use specific terms, for example, "I have analyzed 60% of the available data." Relate your progress back to the original goals of the project.

Under a "Work Completed" heading, describe the specific tasks you have completed and describe any difficulties and obstacles that you have encountered.

Under a "Work to be Completed" heading, describe the tasks that remain to be done. If you need to adjust the original schedule, provide a new schedule.

If appropriate, you can also include a section on "Preliminary Findings" if you want feedback from your readers.

Close with a reiteration of the final product that will result from your project. Depending on the situation--if there have been substantial changes in the scope or the project or in the schedule--you might also want to request a meeting to discuss the project.

Other Kinds of Reports

As mentioned earlier in this report, there isn't a "standard format" for reports--the most important thing in designing a report is to clearly outline its purpose, and then answer the following questions:

What did you do? Why did you choose the particular research methods you

used? What did you learn and what are the implications of what you

learned? If you are writing a recommendation report, what action are

you recommending in response to what you learned?

What is most important about report writing is that you have carefully considered the rhetorical situation. When you prepare your report, be sure to analyze the context and determine what

information to include, what tone to use, and how to format the document to meet the standards of the organization you are submitting to.