Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
technical report writing
Transcript of technical report writing
results title, authors, abstract, keywords introduction, literature review, research methodology, results, discussion of results,
limitations, conclusions, recommendations or implications, suggestions for further work main part references, appendices (f.e., questionnaires used, sample of interview transcripts,
program code) End part analysis, design, implementation, testing, and evaluation 1) Method or means of development (result)
How can we do/create/modify/evolve (or automate doing) X? (research question)
What is a better way to do/create/modify/evolve X?
2) Method for analysis or evaluation
How can I evaluate the quality/correctness of X?
How do I choose between X and Y?
3) Design, evaluation, or analysis of a particular instance
How good is Y? What is property X of artifact/method Y?
What is a (better) design, implementation, maintenance, or adaptation for application X?
How does X compare to Y?
What is the current state of X / practice of Y?
4) Generalization or characterization
Given X, what will Y (necessarily) be?
What, exactly, do we mean by X? What are its important characteristics?
What is a good formal/empirical model for X?
What are the varieties of X, how are they related?
5) Feasibility study or exploration
Does X even exist, and if so what is it like?
Is it possible to accomplish X at all?
[Shaw2003] literature review more later, but use this structure to read/summarize available papers 1) Follow the plan
2) Leave the text a couple of days before you revise yourself and then send it to your supervisor.
3) Check the text for spelling and grammatical errors
4) Check that the abstract summarizes the paper
5) Label all figures and tables and check that they are referred in the text
6) Are all pieces useful? Can anything be moved to appendix or removed?
7) Provide evidence for each conclusion Guidelines • Purpose
[Oates2005] Oates, B. J., Nov. 2005. Researching Information Systems and Computing, 1st Edition. Sage Publications Ltd. URL http://www.worldcat.org/isbn/141290224X
Shaw, M., 2003. Writing good software engineering research papers. In: 25th International Conference on Software Engineering, 2003. IEEE, pp. 726-736, URL http://dx.doi.org/10.1109/ICSE.2003.1201262
Krogstie, J., 2012, Bridging Research and Innovation by Applying Living Labs for Design Science Research, NORDIC CONTRIBUTIONS IN IS RESEARCH, Lecture Notes in Business Information Processing, 2012, Volume 124, Part 2 References Paradigm: Hevner et al. writes that “in the design science paradigm knowledge and understanding of a problem domain and its solution is achieved in the building and application of the designed artifact”[Krogstie2012]. Revise! the most difficult part is not write but revise macro revisions: move text, add examples, delete text, delete text microrevisions micro revisions do not use two words when one will do: search for "and"
do not use adjective or adverb unless you cannot avoid (interesting challenge -> challenge)
do not use a pronoun when a noun would be clearer (it -> the source code; they -> programmers)
do not use a general word when you can use a specific one (to make -> to code)
do not use the passive voice unless the subject is unknown or uninmportant (the system has been implemented -> I implemented the system during week 3; the OSS community implemented this module during March 2011.
Evidence is a piece of information that supports a conclusion. The classic example is from the law court: means, motive and opportunity.
see Table 5. Types of software engineering research validation [Shaw2003]. in your case see also http://www.dur.ac.uk/ebse/resources/notes/sa/Structured_Abstract_Template.pdf
suggested by M. Torchiano