e-Informatica Software Engineering Journal

Volume 00, Issue 0, pages: 1–7

BibTEX

Sample Paper: How to Use This Template

Firstname1 Surname1* , Firstname2 Surname2 , Firstname3 Surname3

*
Corresponding author: [Link]@[Link]

Article info Abstract

Keywords: Context: Why is this research important?

test-driven development Give a brief explanation of the motivation for conducting the study.
software quality Objective: What is the question addressed in this research?
... Describe the aim of the study, including, e.g., the object under
examination, the focus, and the perspective
Submitted: 1 Dec. 2025 Method: What are the research methods applied?
Revised: 10 Dec. 2025 Briefly characterize the research method and procedure, and also
Accepted: 10 Dec. 2025 provide quantitative information, e.g., the sample size, dataset char-
Available online: 11 Dec. 2024 acteristics, etc. E.g., We conducted a controlled experiment with 80
practitioners...
Results: What are the main results in the context of the study
objective?
E.g., Method 2 was significantly more effective than Method 1 with
a large non-parametric effect size measure p̂, the mean number of
defects found by participants using Method 2 was 33 while...
Conclusions: What are the main findings of the study and their
implications (both for practitioners and researchers)?
The result reinforced existing evidence regarding the superiority of
Method 2 over Method 1...

1. Introduction

This sample paper template is inspired by guidelines used in the software engineering
discipline on how to structure research papers, e.g., [1, 2], how to report secondary studies,
e.g., [3, 4], and the experience of the editors of the journal.
Providing a clear explanation, motivating the goal of your study, and de-
scribing the main contributions of the paper is critical for convincing reviewers
and editors that your study is worth publishing.
Below, we present the most important components that should be included in a good
introduction section. Of course, it is up to the author’s convenience how to structure this
section.

Problem statement

What is the broader context of the problem you study (if you address a very specific
sub-problem start from explaining the broader context)? What is the problem being
addressed by the study? Where does it occur? Who has observed it? Why is it important 1

© 0000 The Authors. Published by Wrocław University of Science and Technology Publishing House.
This is an open access article under the CC BY-SA 4.0 license international.
 Surname1 et al. e-Informatica Software Engineering Journal, 00 (0000),

to be solved?

Research objective

What is the main research question to be answered by this study? It is often convenient to
use the GQM goal template [5]:
Analyze (Object(s) of study)
For the purpose of (Purpose)
With respect to their (Quality Focus)
From the point of view of the (Perspective)
In the context of (Context).
Specific examples can be found, e.g., in [1, 6].

Study context

Include information that is necessary to understand whether the research relates to a specific
situation (environment). The description of the context is essential for practitioners as well
as for researchers. Practitioners need context information to see if the technique, process, or
tool under study would apply to their organization. Researchers need context information
to understand the limits of the study (e.g., whether the results are generalizable), to
replicate results, and to aggregate results or perform meta-analyses.

Contribution statement

State what are the main contributions of the paper. It could be an enumerated list: The
main contributions of the paper are 1) the analysis of the impact of ... 2) ...
Although naming the contributions of the paper might seem a natural part of the
conclusions sections, it is very helpful for the readers to know in advance what they will
learn from the paper and guide their focus while they are reading it.

How the paper is structured

The rest of this paper is structured as follows: in Section 2, we present a description of

the tool, in Section 3, we briefly discuss work done in similar areas by other researchers;
in Section 4, we describe details of the research setup; in Section 5, we report the results of
the study. Then, in Section 6, we discuss the collected results, as well as describe potential
threats to the validity of the research, and we conclude the paper in Section 7.

2. Background

The background section is optional and used to introduce the readers to the constructs
and terms that they might not be familiar with. Consider including it when: you focus on
a narrow subfield (e.g., you study a very specialized method); you use methods that are
novel in the field and your peers might not have much experience with them; you use a
2 specific notation that might be confusing for your peers.
Surname1 et al. e-Informatica Software Engineering Journal, 00 (0000),

The background section should be concise, i.e., cover as little as possible and offer
references to broaden the readers’ knowledge of the topic.

3. Related Work

A good related work section should discuss previous research that is relevant to the
presented study. If there are multiple aspects of your study, you can consider dividing it
into subsections.
A common mistake is to present previous research without discussing how they relate
to the study presented in the paper. A desirable structure could look like this:

Smith et al. [10] studied the problem of ... In our study, we investigate a similar problem
of ..., however, we apply different methods and study it in the industrial context.

Finally, the section shall be concluded by clearly showing the room for the study
presented in the paper.

4. Method

Research goal and questions/hypotheses

Assuming that the goal / central research questions have been presented in the introduction
section, they should be elaborated and potentially decomposed into a set of more specific
research questions.
A common mistake is to define research questions/hypotheses without discussing/jus-
tifying their role in obtaining the main goal of the study (answer the central research
question).

Research method / procedure

The description of the research method strongly depends on the method itself. However, we
recommend framing your research using one of the Empirical Software Engineering (ESE)
research methods. For artifact-design-related studies, you can consider framing your study
as a Design Science Research study or as an Action Research study if it involves solving
a practical problem in its natural context. Other common research methods employed in
ESE are Survey Research, Case Studies, Controlled Experiments, Systematic Literature
Reviews, etc. Each type of study and research method used requires different aspects to be
presented and discussed. However, we strongly recommend following the ACM SIGSOFT
Empirical Standards for Software Engineering guidelines1 [7] while designing and reporting
empirical studies.

1
Empirical Standards —[Link] [Link]
EmpiricalStandards/docs/ 3
 Surname1 et al. e-Informatica Software Engineering Journal, 00 (0000),

5. Results

Results can be presented in a single or multiple sections depending on the authors’

convenience.
When including figures, please use the LaTeX commands as for Figure 1. Similarly,
please format tables similarly to Table 1.

Figure 1: An exemplary figure

Also, while referring to particular figures and tables, please treat them as proper nouns.
All included figures and tables shall be referenced in the manuscript’s text.

Table 1: Guidelines for effect size magnitude interpretation (see [8])

Effect small medium large

Cliffs δ 0.112 0.276 0.428
Probability of superiority (p̂) 0.556 0.638 0.714

Please use the code LaTeX environment to include source code listings as presented in
Listing 1.
Listing 1: R source code snippet for [Link] model creation and tuning with mlr3

train_task = as_task_classif(
train_set,
target = "BuildResult",
positive = "1"
)
test_task = as_task_classif(
test_set,
target = "BuildResult",
positive = "1")
inner_resampling = rsmp("cv")
outer_resampling = rsmp("cv")
...

When reporting results of mapping studies or Systematic Literature Reviews, please

separate a list of references of primary studies from the list of regular references (e.g., in
the related work section). In such a case, you should provide two BibTeX files:

% your regular references list

\setbiblabelwidth{1000}
4 \bibliographystyle{IEEEtran_for_EI}
Surname1 et al. e-Informatica Software Engineering Journal, 00 (0000),

\bibliography{sample_paper}

% primary studies
\setbiblabelwidth{1000}
\bibliographystyleS{IEEEtran_for_EI}
\bibliographyS{primary_studies}

6. Discussion

Discussion should go back to research questions and explain how they can be answered based
on the results. It should also discuss the implications of the study for both practitioners
and researchers in the area. Finally, we pay attention to the discussion of Threats to
validity. There are some well-known recommendations regarding how to discuss threats to
validity, e.g., by Wohlin et al. [9]. Also, there are guidelines targeted to address common
threats specific to particular research methods, e.g., for Design Science Research [10],
simulation-based studies [11].

7. Conclusions

What was the goal of the study (reminder)? What was the scope of the study, and how it
was performed (a brief reminder)? What were the most important results? What are the
main findings, contributions, and implications? What are potential future work directions?

Acknowledgment

Please remember that there is a separate section for naming the funding sources.

CRediT authorship contribution statement

[Specify the First- and the Last-Name of the first Author, eg, John Doe]: Data curation,
Methodology, Investigation, Writing – original draft, Writing – review and editing, Vi-
sualization. [Specify the First- and the Last-Name of the second Author, eg., Jane Doe]:
Conceptualization, Funding acquisition, Methodology, Investigation, Writing – review and
editing, Supervision… See: [Link]

Declaration of competing interest

The authors declare that they have no known competing financial interests or personal
relationships that could have appeared to influence the work reported in this paper.

Funding

This research was performed within the Non-Technical Debt in Large-Scale Agile Software
Development (NODLA) Project, funded by the Knowledge Foundation, Sweden. 5
 Surname1 et al. e-Informatica Software Engineering Journal, 00 (0000),

Declaration of AI assistance in the writing process

During the preparation of this work, the author(s) utilised [Specify Tool/Service Name] in
order to [State the Reason for Use, e.g., improve grammar and clarity]. Subsequent to the
application of this tool/service, the author(s) reviewed and edited the content as necessary
and accept full responsibility for the final content of the publication.

References

[1] A. Jedlitschka, M. Ciolkowski, and D. Pfahl, Reporting Experiments in Software Engineering.

London: Springer London, 2008, pp. 201–228. [Online]. [Link]
044-5_8
[2] C. Wohlin, P. Runeson, M. Höst, M.C. Ohlsson, B. Regnell et al., Experimentation in
Software Engineering: An Introduction, 2nd ed. Berlin Heidelberg, Germany: Springer, 2012.
[3] B. Kitchenham, L. Madeyski, and D. Budgen, “SEGRESS: Software Engineering Guidelines
for REporting Secondary Studies,” IEEE Transactions on Software Engineering, Vol. 49,
No. 3, 2023, pp. 1273–1298. [Online]. [Link]
[4] B. Kitchenham, L. Madeyski, and D. Budgen, “How Should Software Engineering Secondary
Studies Include Grey Material?” IEEE Transactions on Software Engineering, Vol. 49, No. 2,
2023, pp. 872–882. [Online]. [Link]
[5] R. van Solingen and E. Berghout, The Goal/Question/Metric Method: A Practical Guide
for Improvement of Software Development. London, UK: McGraw-Hill, 1999.
[6] L. Madeyski, Test-Driven Development: An Empirical Evaluation of Agile Practice. (Hei-
delberg, London, New York): Springer, 2010, foreword by Prof. Claes Wohlin. [Online].
[Link]
[7] P. Ralph, N. bin Ali, S. Baltes, D. Bianculli, J. Diaz et al., “Empirical standards for software
engineering research,” 2021.
[8] B. Kitchenham, L. Madeyski, D. Budgen, J. Keung, P. Brereton et al., “Robust Statistical
Methods for Empirical Software Engineering,” Empirical Software Engineering, Vol. 22,
No. 2, 2017, pp. 579–630. [Online]. [Link]
[9] C. Wohlin, P. Runeson, M. Höst, M.C. Ohlsson, B. Regnell et al., Experimentation in
software engineering. Springer Science & Business Media, 2012.
[10] R.J. Wieringa, Design Science Methodology for Information Systems and Software Engineer-
ing. Springer, 2014. [Online]. [Link]
[11] B. Bernard Nicolau de França and G. Horta Travassos, “Simulation based studies in software
engineering: A matter of validity,” CLEI electronic journal, Vol. 18, No. 1, 2015, pp. 5–5.

Appendix A. Examplary appendix

This is an example of an appendix.

Authors and affiliations

Firstname1 Surname1 Firstname2 Surname2

e-mail: [Link]@[Link] e-mail: [Link]@[Link]
ORCID: [Link] ORCID: [Link]
Faculty of Computer Science, XXX University, Faculty of Computer Science, XXX University,
6 Poland Sweden
Surname1 et al. e-Informatica Software Engineering Journal, 00 (0000),

Firstname3 Surname3
e-mail: [Link]@[Link]
ORCID: [Link]
Faculty of Computer Science, XXX University,
Germany