Evaluation of Text–Based Requirements
Engineering Tools

An in-depth case study at Ericsson

Master’s thesis in Computer science and engineering

Auður Katarína Theodórsdóttir

Nora Ojensa

Department of Computer Science and Engineering
CHALMERS UNIVERSITY OF TECHNOLOGY
UNIVERSITY OF GOTHENBURG
Gothenburg, Sweden 2023





Master’s thesis 2023

Evaluation of Text–Based Requirements
Engineering Tools

An in-depth case study at Ericsson

Auður Katarína Theodórsdóttir
Nora Ojensa

Department of Computer Science and Engineering
Chalmers University of Technology

University of Gothenburg
Gothenburg, Sweden 2023



Evaluation of Text–Based Requirements Engineering Tools
An in-depth case study at Ericsson
Auður Katarína Theodórsdóttir & Nora Ojensa

© Auður Katarína Theodórsdóttir & Nora Ojensa, 2023.

Supervisor: Eric Knauss, Department of Computer Science and Engineering
Advisor: Filip Lange, Ericsson
Examiner: Gregory Gay, Department of Computer Science and Engineering

Master’s Thesis 2023
Department of Computer Science and Engineering
Chalmers University of Technology and University of Gothenburg
SE-412 96 Gothenburg
Telephone +46 31 772 1000

Typeset in LATEX
Gothenburg, Sweden 2023

iv



Evaluation of Text–Based Requirements Engineering Tools
An in-depth case study at Ericsson
Auður Katarína Theodórsdóttir & Nora Ojensa
Department of Computer Science and Engineering
Chalmers University of Technology and University of Gothenburg

Abstract
Context: Additional challenges related to requirements engineering practices arise
as software development moves from the waterfall model towards agile development,
where continuous integration and continuous deployment are often employed. This
change has resulted in the emergence of new requirements engineering tools. One of
which is a tool developed in-house at Ericsson by the name of T-Reqs.
Objective: The purpose of this study is to study these newly emerged tools by
conducting a case study at Ericsson to evaluate T-Reqs, i.e., illustrate its advantages
and disadvantages, as well as display how the tool is used in practice in comparison to
traditional requirements engineering tools. In addition, an identification of the tool’s
characteristics that also describe tools similar to T-Reqs and a formal definition for
these tools is proposed.
Method: The chosen research method is an in-depth case study where the data
collection was both qualitative and quantitative, i.e., a mixed method design. The
qualitative data was gathered through 14 semi-structured interviews with relevant
employees at Ericsson and followed by quantitative data gathering through a follow-
up survey. The results were then discussed in a cross-industry workshop.
Results: The results illustrate that the primary expectations towards T-Reqs were
increased usability and improved ways of working, which encompassed a scale-out of
the company and facilitated collaboration, among others. These expectations were,
for the most part, fulfilled. One of the main advantages identified was the tool’s
integration into the development environment, allowing for easy access, updates,
version control, and baselining. As the tool relies heavily on its users being comfort-
able with using Git version control, one of the main drawbacks of the tool relates
to its ease of use for users who lack the knowledge of standard IT technology. Fi-
nally, the main characteristics of the tool are that it is connected to version control,
integrated into each product’s repository, and its ease of use. From these character-
istics, a formal definition of these newly emerged tools is suggested, referred to as
text-based requirements management tools.
Conclusion: This study demonstrates that T-Reqs has been successfully integrated
into the development processes at Ericsson, providing many advantages over tradi-
tional requirements engineering tools. Thus, T-Reqs can be offered as an example of
how these text-based requirements management tools can facilitate the development
process in large-scale agile environments, once their implementation is carefully tai-
lored to the unique needs and context of the organization.

Keywords: requirements engineering, large-scale agile development, agile require-
ments engineering, requirements engineering tools, text-based requirements man-
agement tools

v





Acknowledgements
We want to express our gratitude to our supervisor, Eric Knauss, for his invaluable
support and guidance. We further thank Filip Lange for his contribution and help
during this thesis work as well as the enjoyable collaboration during the course
Industrial Practice Project which led to this thesis. In addition, we want to thank
our examiner Gregory Gay for his helpful comments and all the participants of the
interviews and surveys for taking the time to answer our questions and offer their
insights. Furthermore, we are thankful to the workshop participants at the Software
Center for sharing their perspectives and to Eric for inviting us to present our thesis
project. Finally, we want to thank our families for their continued love and support,
for which we are eternally grateful.

Auður Katarína Theodórsdóttir & Nora Ojensa
Gothenburg, June 2023

vii





Contents

1 Introduction 1
1.1 Statement of the Problem . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Purpose of the Study . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Significance of the Study . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background and Related Work 5
2.1 Requirements Engineering . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Agile Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Large-Scale Agile Development . . . . . . . . . . . . . . . . . 6
2.3 Agile Requirements Engineering . . . . . . . . . . . . . . . . . . . . . 7
2.4 Requirements Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.1 Evaluation of Requirements Tools . . . . . . . . . . . . . . . . 9

3 Case Context 17
3.1 Previous Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 T-Reqs Tool Description . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 T-Reqs Related Research at Ericsson . . . . . . . . . . . . . . . . . . 19
3.4 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Methods 23
4.1 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.1 Interview Methodology . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2 Survey Methodology . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.3 Workshop Methodology . . . . . . . . . . . . . . . . . . . . . 26

4.2 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Ethical Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4.1 Construct validity . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.2 Internal Validity . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4.3 External Validity . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4.4 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Results 33
5.1 RQ1 (Expectations) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.1 Implementation Considerations & Decisions . . . . . . . . . . 33

ix



Contents

5.1.1.1 Version Control & Storage . . . . . . . . . . . . . . . 33
5.1.1.2 Requirements Modeling . . . . . . . . . . . . . . . . 34
5.1.1.3 Traceability of Requirements & Test Cases . . . . . . 34
5.1.1.4 Interoperability of T-Reqs . . . . . . . . . . . . . . . 34
5.1.1.5 Ways of Working . . . . . . . . . . . . . . . . . . . . 34
5.1.1.6 Other Tools . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.2 Goals & Expectations . . . . . . . . . . . . . . . . . . . . . . 35
5.1.2.1 Usability . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.2.2 Improved Ways of Working . . . . . . . . . . . . . . 37

5.1.3 Fulfilled Expectations . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.4 Results from the Survey . . . . . . . . . . . . . . . . . . . . . 40

5.2 RQ2 (Advantages and Disadvantages) . . . . . . . . . . . . . . . . . . 45
5.2.1 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.2 In-House Development Versus Licensed Tool . . . . . . . . . . 50
5.2.3 Storage & Version control . . . . . . . . . . . . . . . . . . . . 51
5.2.4 Collaboration & Accessibility . . . . . . . . . . . . . . . . . . 52
5.2.5 Practical Observations of T-Reqs in Use . . . . . . . . . . . . 53
5.2.6 Results from the Survey . . . . . . . . . . . . . . . . . . . . . 56

5.3 RQ3 (Characteristics) . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3.1 Characteristics Described by More Experienced Interviewees . 65
5.3.2 Key Features Described by More Experienced Interviewees . . 66
5.3.3 Key Features Described by Less Experienced Interviewees . . 67
5.3.4 Results from the Survey . . . . . . . . . . . . . . . . . . . . . 68

5.4 Results from the Workshop . . . . . . . . . . . . . . . . . . . . . . . 71

6 Discussion 73
6.1 Interpretation of the Results . . . . . . . . . . . . . . . . . . . . . . . 73

6.1.1 RQ1 (Expectations) . . . . . . . . . . . . . . . . . . . . . . . 73
6.1.2 RQ2 (Advantages and Disadvantages) . . . . . . . . . . . . . . 77
6.1.3 RQ3 (Characteristics) . . . . . . . . . . . . . . . . . . . . . . 79

6.2 Advice for a Broader Context . . . . . . . . . . . . . . . . . . . . . . 80
6.2.1 Understand the Organizational Context . . . . . . . . . . . . . 80
6.2.2 Consider the Users . . . . . . . . . . . . . . . . . . . . . . . . 80
6.2.3 Focus on Collaboration . . . . . . . . . . . . . . . . . . . . . . 81
6.2.4 Cost-Benefit Analysis . . . . . . . . . . . . . . . . . . . . . . . 81
6.2.5 The Role of Guidelines . . . . . . . . . . . . . . . . . . . . . . 81
6.2.6 Final Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.3 Implications for Research and the Industry . . . . . . . . . . . . . . . 81
6.3.1 Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3.2 Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7 Conclusion 85

Bibliography 87

A Interview Guide I

x



Contents

B Survey V

C ChatGPT-4 prompt XXVI

xi



Contents

xii



1
Introduction

Due to software engineering practices moving toward continuous integration (CI)
and continuous deployment (CD), the more traditional ways of gathering and for-
mulating requirements to support a waterfall operation are less feasible. This is due
to the flexible environment CI/CD and an agile workflow present. To allocate a more
extended time to formulate requirements that further on are likely to change can be
a waste of valuable time and money. Thus, when introducing these agile methods,
typically less time is allocated to the construction of requirements. Spending less
time on the requirements often results in developers focusing solely on functional
requirements described in the form of user stories [1] and losing the level of detail
associated with requirements gathered through more plan-driven approaches [2]. In
abandoning the more plan-driven approaches, agile methods introduce a greater fo-
cus on close collaboration with stakeholders and customers, and thus requirements
must be available for changes during the development process. Using agile meth-
ods to perform requirements engineering is often referred to as agile requirements
engineering. However, a challenge presents itself when using this terminology as,
according to Heikkilä et al. [3], agile requirements engineering does not have a uni-
versal definition.

To address these challenges, new requirements engineering tools have emerged
that support an agile environment, which is very susceptible to change. They rely
on Git-based knowledge storage, i.e., a version control system, which provides the
opportunity to connect requirements more closely to the code base as well as the
test suite of a system. In doing so, these tools also bring requirements closer to the
developers. Among these tools, the most notable are Doorstop [4] and T-Reqs [7]
(refer to T-Reqs’s tool description in Section 3.2). The latter has both an in-house
produced version at Ericsson and an open-source version developed by Chalmers
University of Technology and Gothenburg University [6]. Ericsson is a telecommu-
nications company based in Sweden, where large-scale agile systems development is
employed.

Five years have elapsed since Ericsson adopted T-Reqs into their requirements
engineering processes. In a previous study [7], the challenges mitigated by T-Reqs
have been showcased. However, the study did not encompass the evaluation of how
T-Reqs is used in practice and if these mitigations are fully utilized by users. Fur-
thermore, the question of whether Ericsson’s expectations for T-Reqs, when it was
implemented, have been met still needs to be answered. The study aims to answer
these questions by conducting an in-depth case study at Ericsson and collecting
qualitative and quantitative data through semi-structured interviews [37] with em-
ployees at Ericsson and a follow-up survey. The employees who were interviewed

1



1. Introduction

are the current users of T-Reqs, i.e., testers and system managers. The objective
was to identify and highlight its successful aspects while also examining potential
drawbacks. This analysis provides insights that can be contextualized within the
realm of similar requirements engineering tools relying on a version control system,
e.g., Git. In general, it can showcase themes that can be valuable to companies with
similar environments, using Git or any version control system in their requirements
engineering tool. Further, in order to increase the generalizability and transferabil-
ity of the results, an additional data collection method was conducted in the form of
a workshop with experts in the industry on the topics of requirements and tooling.

1.1 Statement of the Problem
Gathering and formulating requirements by following the waterfall model has proven
to not be feasible in an agile environment utilizing CI/CD. Requirements have to
be gathered fast and must be susceptible to change during the development process
[8]. This has resulted in new requirements engineering tools being on the rise that
support agile work. Since these requirements engineering tools are quite new in
the industry, there is not a lot of research on them in general, let alone on their
performance. The problem is, therefore, that it is not entirely clear how these tools
can be classified and how well they are performing in the industry. That is, questions
arise as to whether these tools are meeting the desired expectations, i.e., solving the
challenges faced by using the more traditional tools, in addition to whether there
are perhaps some unexpected benefits or drawbacks from using these tools.

1.2 Purpose of the Study
The purpose of this study is to get a better understanding of the new requirements
engineering tools that have surfaced to mitigate the challenges that have arisen due
to employing requirements engineering in this different development environment.
That is, how are they used in practice, their observed advantages and disadvantages,
and moreover, their characteristics. In order to increase our knowledge of these
tools, an in-depth case study was performed to evaluate the text-based requirements
engineering tool T-Reqs, currently being used at Ericsson.

We aim to evaluate the current state of the tool, how it is used, and how the
tool performs in practice. This is mainly to systematically identify and assess the ad-
vantages and disadvantages of T-Reqs, additionally uncovering unknown challenges
possibly being introduced with T-Reqs. The assessment will focus on determining
whether the tool meets its expectations and successfully addresses the challenges
faced by Ericsson when they used traditional requirements engineering tools such as
IBM Rational RequisitePro and Rational Rhapsody. By doing so, the study aims
to determine if T-Reqs effectively facilitates the requirements engineering process at
Ericsson.

The result will be used to characterize T-Reqs and tools with similar char-
acteristics and propose a formal definition for them. This study aims to illustrate
as well the advantages and disadvantages of using said tools, and the results can

2



1. Introduction

benefit Ericsson as well as other companies operating in a similar company context,
i.e., large-scale agile development. Based on the results of this study, companies
can identify whether tools similar to T-Reqs would be a good alternative for their
development processes. Since the study is structured as a case study, as remarked
by Stol et al. [43], generalization is not the goal. However, by displaying the context
in which the tool is utilized and the expressed experiences of requirements engineer-
ing practitioners gathered from a workshop, transferability, and generalization of
the findings can be applied to a certain extent. Further, by illustrating the char-
acterization of T-Reqs and constructing a proposal for a definition of this class of
requirements engineering tools, we contribute to the research knowledge and suggest
directions for future research.

1.3 Research Questions
To evaluate the text-based requirements engineering tool T-Reqs, we formulated the
following research questions:

RQ1: How well do the expectations of T-Reqs before its implementation
match with how the tool performs today?

RQ2: What advantages and disadvantages of T-Reqs can be observed in prac-
tice in relation to traditional requirement tools?

RQ3: What characterizes tools such as T-Reqs in contrast with more tradi-
tional requirements tools?

These research questions help to illuminate the value that T-Reqs brings to the
requirements engineering process at Ericsson in comparison to traditional require-
ments engineering tools. This, consequently, will showcase to companies following
similar development practices if tools such as T-Reqs would be a suitable option to
manage their requirements.

1.4 Significance of the Study
By conducting an in-depth case study of practices and the requirements engineering
tool at Ericsson, we are able to contribute qualitative results to the research commu-
nity in the area of requirements engineering in large-scale agile system development.
The research builds upon the information regarding the exploration of alternatives to
traditional requirements engineering tools, which is beneficial for both practitioners
and researchers. That is, it is beneficial for practitioners in the sense that compa-
nies will be able to make better decisions regarding their requirements engineering
practices and which tools are most suitable for them. It benefits the research com-
munity as the study also questions current research, and the results are valuable as
to know in which areas to focus on when discussing requirements engineering tools
in large-scale agile environments. A formal definition of the group of tools T-Reqs

3



1. Introduction

belongs to will facilitate the discussion regarding requirements engineering tools in
a scientific manner.

1.5 Outline
This thesis report is organized as follows. In Section 2, the topics related to this
study will be explained by illustrating the prior related work that has been performed
in those areas. In Section 3, the case context will be explained by mentioning the
previous relevant research performed at Ericsson and what each role at the company
encompasses. In Section 4, the methodology of the study is explained, as well as
the different data collection methods and analysis. The threats to the validity of
the study will also be discussed. In Section 5, the results from the semi-structured
interviews, the survey, and the workshop will be reported in accordance with the
research questions posed in this study. In Section 6, the results in the previous
section will be reflected upon and discussed, and the conclusion of the report is in
Section 7.

4



2
Background and Related Work

The topics of this research, i.e., requirements engineering, agile development, and ag-
ile requirements engineering, will be discussed in this chapter in relation to previous
research on these topics. Furthermore, requirements engineering and management
tools will be discussed along with different evaluation methods previously employed.

2.1 Requirements Engineering
According to the International Requirements Engineering Board, IREB, require-
ments engineering is defined as “The systematic and disciplined approach to the
specification and management of requirements with the goal of understanding the
stakeholders’ desires and needs and minimizing the risk of delivering a system that
does not meet these desires and needs.” (p. 11) [22]. Thus, it is important to note
that requirements engineering is a multifaceted practice, that is, not only defining
the requirements and constraints of a system but the entire process of managing
them. IREB specifies that the main activities in performing requirements engineer-
ing include elicitation, documentation, validation, and management tasks, which
also cover requirements analysis and conflict resolution. [22]. In addition to the
previously mentioned tasks, requirements verification, requirements reuse, and re-
quirements quality assessment are also noted in the ISO standard ISO/IEC/IEEE
29148:2018 [23]. The standard illustrates the processes and products when perform-
ing requirements engineering in the life cycle of the system and software.

In contrast to the IREB classification, the standard does not declare docu-
mentation as a specific task but rather mentions different types of requirements
specifications. Furthermore, requirements analysis is also treated as a separate task
instead of being classified as part of elicitation. This classification is further illus-
trated in the ISO standard ISO/IEC TR 24766:2009 [24], which is a guide for the
expected capabilities of requirements engineering tools. It lists 158 requirements
engineering tool capabilities which pertain to six different requirements engineering
tasks. This standard is discussed in more detail in Section 2.4. In this report, we
will mainly concern ourselves with the requirements engineering tasks that T-Reqs
encompasses: documentation (including specification), validation and verification,
and requirements management, i.e., change management and traceability.

A study by The Standish Group, where IT executive managers were surveyed
and interviewed, indicates that the practice of requirements engineering is essential
for a successful software project [20]. The study included 375 respondents from
companies from various industries and sizes. The results show that incomplete

5



2. Background and Related Work

requirements are one of the main reasons why software projects fail, while clearly
stated requirements are one of the major contributing factors to a successful project.
Requirements engineering is also stated as the most important activity in the devel-
opment of complex and software-intensive systems, according to Konrad et al. [21].
As the complexity of a system under development increases, so does the importance
of good requirements engineering.

In spite of the importance of requirements engineering, there is no universal
process that states how requirements engineering should be conducted or when in
the development process of a system. The most suitable requirements engineering
process must be chosen each time depending, for example, on the development
context or the overall development process [22].

2.2 Agile Development
Agile software development officially dates back to 2001 when the “Agile Mani-
festo” was constructed [2]. It emerged as a response to the previous develop-
ment method, i.e., plan-driven software development. Plan-driven software devel-
opment, also termed traditional software engineering, is an up-front development
process [2, 17, 18]. Well-defined iterations, extensive documentation, and an ex-
haustive requirement design stage at the start of the project are some of the core
principles. In contrast, agile development aims to mitigate some initial up-front doc-
umentation and be more flexible in managing change and getting products to market
faster. This includes designing requirements, which would be done throughout the
development process.

2.2.1 Large-Scale Agile Development
Introducing agile development practices to companies with multiple development
teams and larger projects can pose a challenge as these practices relate more to in-
dividual teams, such as extreme programming, XP [38–40], and do not thus account
for coordination between different teams or different parts of the organization. To
account for these challenges, agile development practices have been expanded into
different frameworks, e.g., Scaled Agile Framework (SAFe) and Large-Scale Scrum
(LeSS).

In a systematic literature review by Dikert et al. [39], 42 cases of adoption of
agile at scale from the industry were examined. A company was considered large-
scale if it had 50 employees or more or a minimum of six teams. The reported
challenges identified were 35 and 29 success factors. The challenges were grouped
into nine categories, with the highest percentage of occurrences in the cases being:
agile difficult to implement, integrating non-development functions, requirements
engineering challenges, and change resistance. The success factors were grouped
into eleven categories, e.g., management support, commitment to change, choosing
and customizing the agile approach, and requirements management. From these
challenges and success factors, it is evident that there must be a desire in the com-
pany for a change, both high and low in the company’s hierarchy, and important to

6



2. Background and Related Work

find a good solution that will fit the company context. Requirements also play a big
role, and the importance of requirements management is emphasized.

In a multiple case study by Kasauli et al. [41], challenges and practices regard-
ing requirements engineering at seven large-scale system companies were identified.
The data was collected and validated through 20 interviews, five focus groups, and
eight workshops. From the data, 24 challenges were identified and grouped into
six themes, i.e., (C1) build and maintain shared understanding of customer value,
(C2) support change and evolution, (C3) build and maintain shared understanding
about system, (C4) representation of requirements knowledge, (C5) process aspects
and (C6) organizational aspects. In the study, T-Reqs is mentioned as a solution
for some of these challenges. More specifically, the challenges of managing experi-
mental requirements and updating requirements, i.e., when and who should update
the requirements, under C2. Under C4, the challenge of consistent requirements
quality across teams and boundaries. Finally, under C6, the challenge of bridging
plan-driven and agile, i.e., between system level and team level.

2.3 Agile Requirements Engineering
A systematic literature review on agile requirements engineering practices and chal-
lenges was performed by Inayat et al. [14]. Literature published between 2002 and
June 2013 was reviewed, which resulted in 21 papers being identified that discussed
agile requirements engineering. Among these papers was a case study by Bjarna-
son et al. [15] identifying benefits and side-effects of agile practices in large-scale
requirements engineering and an empirical study conducted by Ramesh et al. [16]
relating agile requirements engineering practices and challenges. The review iden-
tified 17 practices relating to agile requirements engineering, and eight challenges
posed by those practices. Additionally, it made note of five challenges stemming
from traditional requirements engineering, which were mitigated by agile require-
ments engineering.

The 17 requirements engineering practices found to be adopted in agile soft-
ware development are, for example, face-to-face communication, iterative require-
ments, change management, cross-functional teams, and requirements management.
According to Ramesh et al., “Accommodating requirements changes during devel-
opment is a way of tuning the system to better satisfy customer needs” (p. 65) [16].
They further noted that the most requested changes to the requirements were to
either add or drop features.

The five challenges linked to traditional requirements engineering that are
solved by agile requirements engineering are, namely, communication issues, over-
scoping, requirements validation, requirements documentation, and rare customer
involvement. As stated by Bjarnason et al. [15], communication gaps are solved, for
example, by having cross-functional teams, gradual detailing of requirements, and
the practice of having an integrated requirements engineering process. The integra-
tion entails bringing the requirement engineering process closer to the development
in the hope of bettering the developers’ understanding and improving communi-
cation. As mentioned above, this is an expected outcome of using T-Reqs, i.e.,
bringing requirements closer to the developers. Tools such as T-Reqs are expected

7



2. Background and Related Work

to align with the practices of agile requirements engineering and facilitate the pro-
cess. Thus, by illustrating the findings of the literature above, the expectation is
that this corresponds with the experience of the employees at Ericsson.

It is important to note that, as mentioned above, agile requirements engineer-
ing does not have a universal definition as stated by Heikkilä et al. [3] and thus
presents an obvious challenge when discussing the topic. In the same paper, they
note that the practices of agile and traditional requirements engineering have sim-
ilar goals. However, the difference lies in the methods and emphases, where on
the one hand, traditional requirements engineering emphasizes processes and doc-
uments. On the other hand, agile requirements engineering emphasizes reactivity
and informal communication.

2.4 Requirements Tools
Tools exist to aid developers in the software development process. These tools
have been referred to as CASE, i.e., computer-aided software engineering tools [29].
Among those tools are tools relating to requirements engineering. Both IREB and
ISO/IEC TR 24766:2009 state the importance of using requirements engineering
tools to perform requirements engineering tasks whenever possible [22, 24]. The
standard ISO/IEC/IEEE 29148:2018 attests to this as well, particularly to employ
requirements management tools in more complex projects [23]. ArgonDigital (pre-
viously Seilevel) also emphasizes this by stating that it is critical that a tool for
requirements management is adopted, especially in larger corporations where there
can be hundreds of thousands of requirements for a project [28].

The terminology used to describe requirements engineering tools varies across
different studies, with the terms “requirements engineering tools” and “requirements
management tools” often used interchangeably. In this paper, we will regard re-
quirements engineering tools as tools supporting the entire requirements engineer-
ing process and all its activities, while requirements management tools facilitate
the management of requirements once they are created, as stated in the standard
ISO/IEC TR 24766:2009 [24]. To further illustrate this, the definition given in the
CPRE glossary published by IREB states that requirements management is “The
process of managing existing requirements and requirements related work products,
including the storing, changing and tracing of requirements.” (p. 17) [25].

Available requirements engineering tools vary in functionality and the require-
ments engineering activities that they support. There has also been a rapidly chang-
ing market as many new tools have emerged and old ones have become deprecated,
with feature sets changing widely, as noted by ArgonDigital [28], and Gea et al. [34].
Where the newly emerging tools increasingly support visual modeling, traceability
analysis, and collaborative functionality for teams. ArgonDigital has made evalu-
ation reports comparing many tools in the industry, published in the years 2007,
2011, and 2016, where in their last report, they compared 175 different requirements
engineering tools. Selecting an inappropriate tool or one with excessive complexity
can impede the progress of a project, as noted by Young [33]. He emphasizes that a
requirements engineering tool should not be chosen out of convenience or arbitrary
criteria but the need to consider what is best for the operations.

8



2. Background and Related Work

With new tools emerging with new feature sets, the market is not homoge-
neous, and groupings should be represented in the terminology. A recent study
presenting a newer tool, Doorstop, has used the terminology of centralized, cloud-
based, and decentralized to categorize requirements management tools. Centralized
tools are a more traditional way of creating and storing requirements by using a cen-
tralized hosted database for the storage of requirements and a dedicated program
with a graphical user interface. Cloud-based tools offer a web browser for their users
to interact with to collaborate on their requirements documentation. Lastly, decen-
tralized tools store requirements as files instead of database entries, thus eliminating
the requirement for a dedicated server. Decentralized tools, T-Reqs therein, have
changed the way that requirements management can be conducted by connecting
requirements and the source code closer together [4].

Another way of categorizing these requirements tools is based on which re-
quirements engineering tasks they cover. As an example, IREB states in their hand-
book that differentiating between different tools can be done based on the following
requirements engineering aspects, i.e., management of requirements, requirements
engineering process, documentation of the knowledge about the requirements, mod-
eling of requirements, collaboration in requirements engineering, and testing and/or
simulation of the requirements. They further state that most tools do not cover all
of these tasks, and thus a combination of different tools must be considered to fully
support the whole requirements engineering process [22]. Similarly, the ISO stan-
dard ISO/IEC TR 24766:2009 states that the following tasks within requirements
engineering are processes that a requirements engineering tool should address, that is
requirements elicitation, requirements analysis, requirements specification, require-
ments and product validation and verification, and requirements management [24].

2.4.1 Evaluation of Requirements Tools
Evaluating requirements engineering tools is greatly beneficial for companies when
adopting a new requirements engineering tool [33]. A prevalent method of achieving
this involves the quantitative comparison of the features of different tools based on a
standardized criteria list. Such lists are typically derived from prior studies and are
compiled by experts in the field. They encapsulate the comprehensive range of fea-
tures that a requirements engineering tool should ideally possess, thereby providing
a solid foundation for comparison. In this study, a combination of multiple criteria
lists is utilized to examine the capabilities of T-Reqs, understand its strengths, and
identify valuable features that may be lacking.

Santillán conducts an extensive literature review to examine various publicly
available and industry-recognized criteria lists. Based on this review, they propose
a new comprehensive list compiled from these sources. The sources of these lists
are INCOSE, DSTO, ITEA, DESS, DaimlerChrysler, RWTH, Aachen, and Seilevel
[30]. An overview of these lists is offered in Table 2.1. Seilevel, now ArgonDigital,
has released a new evaluation report (2016) since the publication of the literature
review was conducted with updated criteria [28]. Santillán’s criteria list contains an
extensive amount of features, some of which may not be applicable in all contexts;
for example, features specific to software product line requirements were deemed

9



2. Background and Related Work

irrelevant within the scope of Ericsson’s operations. Furthermore, while modeling
was deemed unnecessary in their report, it has been reinstated as a relevant feature
in this study. Additionally, due to the detail of the list, some overview is lost. For
the purpose of this study, the list was therefore summarized into more high-level
features. To avoid bias in the features selected in the summarized list, the AI model
ChatGPT-4, developed by OpenAI [26], was used to maintain objectivity. The
correctness of the items was then verified by the authors. Details pertaining to the
prompt used for ChatGPT-4 can be found in Appendix C.

Publisher Creation Year Categories Requirements
INCOSE 1990 13 68
DSTO 1997 11 149

ITEA DESS 2001 18 78
Daimler-Chrysler 2004 21 101
RWTH Aachen 2006 24 110

Seilevel 2011 23 230
Table 2.1: Criteria lists overview

Based on Santillán’s compilation of popular criteria lists in industry and its
summarization by an AI tool, the following feature list was devised (refer to Fig-
ure 2.2, 2.3, 2.4, 2.5 and 2.6) to facilitate the evaluation of T-Reqs against other
prominent requirements engineering tools. The selection of these tools was based
on the categorization of centralized, cloud-based, and decentralized tools. Ratio-
nal DOORS was chosen as a representative centralized tool, while Jama represents
the cloud-based category. T-Reqs and Doorstop exemplify decentralized tools. The
information in regard to these tools’ features was gathered from the websites, doc-
umentation, and Git repositories of the tools [4, 5, 46]. Additionally, ArgonDigital’s
2016 requirements management tool evaluation report [45] was used, in which Jama
was covered.

Although more features mean more possibilities, studies have shown that se-
lecting a requirements engineering tool is not just a quantitative task, and it must
conform to the context and environment of the operations in question [28,31,32,34].
The standard ISO/IEC TR 24766:2009 further adds to this sentiment by stating
that; “Users tend to focus on specifying their functional or behavioral requirements,
but users also have expectations about how well the product would work. Char-
acteristics that fall into this category include how easy it is to use, how quickly it
runs, how often it fails, and how it handles unexpected conditions. Such charac-
teristics are known as software quality attributes or simply quality factors and are
often considered as a part of the system’s non-functional requirements.” (p. 21) [24]
A value-based evaluation approach is recommended by Heindl et al. [31], where the
tool’s features are weighted based on the value they bring to the company.

In this study, we heavily consider the context under the premise that T-Reqs is
to be evaluated under real-world usage. In addition to the criteria list, we will discuss
the features and factors that have been identified during qualitative interviews and

10



2. Background and Related Work

a follow-up survey with industry users. Based on users’ statements, we will answer
research questions RQ2: “What advantages and disadvantages of T-Reqs can be
observed in practice in relation to traditional requirement tools?” and RQ3: “What
characterizes tools such as T-Reqs in contrast with more traditional requirements
tools?”.

Internal requirements for the tool can also be defined to evaluate tools in
accordance with the requirements engineering process and software tool environment
at the company. Ericsson has developed a comprehensive list outlining the required
functionality in terms of specific requirements. These requirements will be presented
in Section 3.3, which will delve into the case context and prior research conducted at
Ericsson. These requirements will serve as a basis for evaluating research question
RQ1: “How well do the expectations of T-Reqs before its implementation match
with how the tool performs today?”, in addition to the responses in the interviews
and survey.

Feature Description T-Reqs
(Decentral-
ized)

Doorstop
(Decentral-
ized)

Jama
(Cloud-
based)

Rational
DOORS
(Central-
ized)

(1/5) Require-
ments Management
Main Activities
and Baselining
Version Control The tool should provide features for

reproducing and rolling back to ear-
lier versions of requirements.

yes yes yes yes (their
own, i.e., not
connected
to the test
cases and the
code)

Change Control The tool should be able to dis-
tinguish between formal and infor-
mal changes, provide a filter to
review new/changed requirements,
maintain an automatic audit trail
for requirement changes, and notify
project participants about changes
via email. The tool should also
make the history of requirements
changes easily viewable.

partially
(changes
maintained
with version
control, view
for history of
requirements
forthcoming)

partially
(changes
maintained
with version
control)

yes yes

Status Tracking The tool should allow requirements
to be filtered by criteria (e.g., sta-
tus), allow complex attributes with
predefined value choices, and enable
the editing of requirements’ status.

yes yes yes yes

Tracing The tool should support link-
ing requirements to existing docu-
ments, models, client documenta-
tion, notes, and emails. It should
enable the creation of links between
requirements of the same type, dif-
ferent types, and those in defined
groups. It should be able to display
traceability results in a table or a
diagram, describe the nature of the
relationship link between require-
ments, and enforce the creation and
change of certain types of traceabil-
ity links. The tool should support
M:N bidirectional linking and the
creation of a custom tracing model
to link requirements to user-defined
types of artifacts.

partially partially
(traces be-
tween items
in yaml files)

partially partially
(usually links
between ar-
tifacts or
external
links, not
models un-
less including
a modelling
tool)

Baselining The tool should allow for the
creation of requirements baselines,
comparison of baselines, and work
with specific baselines. The tool
should be able to show the differ-
ence, and what is new between the
last version and the current version.

yes yes yes yes

Modelling The tool should enable the creation
of requirement models.

yes no yes (limited
linking due
to being
stored as
images)

no

Table 2.2: Feature Comparison: Requirements Management Main Activities and
Baselining

11



2. Background and Related Work

Feature Description T-Reqs
(Decentral-
ized)

Doorstop
(Decentral-
ized)

Jama
(Cloud-
based)

Rational
DOORS
(Central-
ized)

(2/5) Information
Management
Views The tool should allow sorting and

filtering of requirements based on
various criteria, saving of cus-
tom views (both private and pub-
lic), and instantly applying filtered
views. It should support the dis-
play of requirements as a list, a hi-
erarchy, or custom traceability data
tables.

partially
(filtering
possible us-
ing python
scripts, re-
quirements
displayed in
a hierarchy)

partially
(filtering
possible us-
ing python
scripts, re-
quirements
displayed in
a hierarchy)

yes yes

Navigation The tool should offer keyword
search, navigation through the
requirements hierarchy, drag-and-
drop ability for moving require-
ments within the hierarchy, and
easy navigation of traceability hier-
archy.

partially (no
drag-and-
drop ability)

partially
(e.g., no
drag-and-
drop ability,
search can
be performed
with python
scripts)

yes partially
(unclear
if it offers
traceability
hierarchy)

Analysis Functions The tool should provide traceabil-
ity analysis to identify missing links
within requirements and detect in-
consistencies in links.

yes yes yes not clear

Import The tool should support bulk enter-
ing of requirements, identifying re-
quirements from external text doc-
uments, and batch import of struc-
tured data as new requirements
from various types of documents.

yes yes yes yes

Export The tool should allow exporting
requirements to various formats
with the capability of highlighting
changes against a previous baseline,
exporting a subset of requirements
based on a filter view, and export-
ing data from any report for further
analysis.

yes partially
(e.g., no
highlighting
of changes)

yes partially
(unclear if it
offers high-
lighting of
changes)

Specification Genera-
tion

The tool should be able to produce
requirements documentation in var-
ious pre-defined formats and allow
defining custom formats for docu-
mentation output.

partially
(no custom
formats)

partially
(no custom
formats)

yes (difficult
to get cus-
tom formats
to look good)

partially
(unclear
whether cus-
tom formats
are always
offered)

Reporting The tool should offer comprehensive
reporting functionalities, including
metrics reporting, metrics charting,
reporting on requirement link prob-
lems, requirement maturity, review
status, open issues, assignments,
and more. It should allow viewing
and customizing dashboard reports,
creating burndown reports, gener-
ating traceability reports, and re-
porting on the number of reviews
and issues of requirements.

forthcoming yes, HTML yes (burn-
down reports
need integra-
tion)

yes (burn-
down reports
need integra-
tion)

Users and Access Con-
trol

The tool should provide access
management features to restrict ac-
cess permissions for individual users
and groups, and manage visibility
of requirements for clients based
on requirement attributes or project
association.

no not relevant
(open-source
tool provid-
ing CLI and
connected
to version
control)

yes yes

Offline Use The tool should support working of-
fline with the capability of merging
changes upon reconnecting, provid-
ing reminders for synchronization,
and offering a read-only view.

yes yes yes no

User Interface The tool should allow easy edit-
ing of requirements, support drag-
and-drop linking of requirements,
cut and paste functionality between
the tool and other applications, and
quick access to detailed informa-
tion about requirements. The inter-
face should be customizable, allow-
ing assignment of functions to but-
tons, hot keys, and menus.

partially partially
(simple desk-
top and user
interface)

partially
(cannot
drag-and-
drop linking
of require-
ments, can-
not assign
functions to
buttons/hot
keys/menus)

yes (consid-
ered dated
however)

Usability The tool should be easy to use and
learn.

partially
(developer
friendly)

yes yes partially
(extended
documen-
tation but
buried func-
tionality)

Table 2.3: Feature Comparison: Information Management

12



2. Background and Related Work

Feature Description T-Reqs Doorstop Jama Rational
DOORS

(3/5) Require-
ments’ Data Man-
agement
Requirements’ Archi-
tecture

The tool should allow definition of
data to be captured for each re-
quirement, grouping requirements
by project, organizing by groups
and hierarchies, defining custom
ID formats for requirements, man-
aging dependencies and glossaries,
tracking requesters, setting up com-
plex attributes, capturing rationale,
managing links to external docu-
ments, voting and setting priorities
on requirements, and defining dif-
ferent types of requirements.

partially
(e.g., setting
up complex
attributes)

partially
(e.g., voting
or prioritisa-
tion offered)

partially (no
management
for glos-
saries)

yes

Requirements’ Cap-
ture

The tool should provide functions
for easy entry of new requirements,
assigning unique IDs, assignment
of requirements to different ana-
lysts, marking new entries for re-
view, copying requirements from
other projects, defining stakehold-
ers for each requirement, and allow-
ing reuse of requirements between
projects.

yes yes yes yes

Requirements Edition
and Deletion

The tool should allow editing and
deletion of requirements with fea-
tures for bulk editing, real-time up-
dates, safe deletion options, and
preventing concurrent editing by
multiple users in online mode.

yes yes yes yes

Requirements’ Qual-
ity

The tool should offer automatic
checks for spelling, grammar, and
ambiguous words, and the ability
to mark duplicate requirements and
merge them together. It should also
allow defining validation checks for
user-defined attributes.

no no partially
(no ability
to mark
duplicate
requirements
and merge
them)

partially
(unclear if
identification
of duplicate
requirements
is possible)

Requirements’ En-
richment

The tool should support rich text
formatting, tables, maintenance of
formatting when pasting from other
documents, inclusion of mathemat-
ical equations and special symbols,
and incorporation of images and
embedded documents. It should
also support the addition of audio
and video files.

partially
(embedding
in version
control sys-
tem)

partially
(embedding
in version
control sys-
tem)

partially
(unclear if
the addition
of audio and
video files is
possible)

partially
(unclear if
the addition
of audio and
video files is
possible)

Requirements’ Issue
Tracking

The tool should facilitate issue cre-
ation from requirements, link to is-
sues in other tools, and have its
own issue tracking functionality. It
should also keep track of resolu-
tions to open issues and maintain
a record of open issues by require-
ment.

partially
(issue track-
ing in re-
view/version
control sys-
tem)

partially
(issue track-
ing in re-
view/version
control sys-
tem)

yes unclear

Table 2.4: Feature Comparison: Requirements’ Data Management

13



2. Background and Related Work

Feature Description T-Reqs Doorstop Jama Rational
DOORS

(4/5) Techni-
cal Specification,
Licensing and Sup-
port
Tool Integration The tool should support automated

integration with issue tracking sys-
tems, design tools, development en-
vironments, revision control sys-
tems for linked documents, note-
taking software, and test manage-
ment systems.

yes yes yes yes

Extensibility The tool should provide an external
API and allow ad-hoc queries of re-
quirement data.

yes yes yes yes

System Specification The tool should support both
installed central repository and
client-only installations. It should
provide web and non-web inter-
faces, supporting Windows and
Unix/Linux platforms, and man-
age multiple concurrent users. It
should also detail platform resource
requirements. The tool should sup-
port various database platforms in-
cluding MS Access, SQL Server, Or-
acle, and MySQL, and allow the
merging of requirements from dif-
ferent databases. It should also
highlight its ease of installation
and administration, and indicate
whether it is open-source or com-
mercial, and its current user base.
It should scale with increasing num-
ber of input requirements and not
limit the number of user-defined at-
tributes.

partially/not
relevant

yes yes yes

Licensing The tool should provide informa-
tion on its license policy and costs,
warranty options, and maintenance
& upgrade policies, along with
maintenance costs.

not relevant
(in-house de-
velopment)

not rele-
vant (open-
source)

yes yes

Training and Tool
Help

The tool should offer a variety
of learning aids such as sample
requirements, workflow tutorials,
training classes, and both online
and offline documentation. It
should also offer context-sensitive
help within the system, phone sup-
port, and online support such as
message boards, knowledge base,
user groups, wikis, etc.

yes yes yes yes

Table 2.5: Feature Comparison: Technical Specification, Licensing and Support

14



2. Background and Related Work

Feature Description T-Reqs Doorstop Jama Rational
DOORS

(5/5) Distributed
Collaboration
Informal communica-
tion

This includes the tool’s ability
to foster communication among
stakeholders. This can be achieved
through both synchronous (real-
time chat, videoconferencing,
VoIP) and asynchronous (email-
like) means. The tool should allow
users to insert links to relevant
objects in their messages, access
discussions they’ve been a part
of, and save essential parts of a
conversation’s transcript.

no no yes (com-
ment stream)

yes (in
DOORS next
generation)

Awareness This pertains to the tool’s abil-
ity to provide users with informa-
tion about other team members.
This includes their connection sta-
tus, roles, geographical location,
workload, and recent actions. The
tool should also allow personaliza-
tion of visual cues, send email no-
tifications about actions taken by
others, and allow users to subscribe
to changes in requirements.

partially
(provides
awareness
through ver-
sion control
system)

partially
(provides
awareness
through ver-
sion control
system)

yes unclear

Workflow manage-
ment

The tool should be capable of defin-
ing custom workflows for differ-
ent types of requirements, as well
as for all types of requirements.
It should also provide predefined
workflows. The tool should track
and request approval or sign-off for
requirements, and enable task def-
inition and rights assignment for
each workflow step.

no no yes yes (with
integration
to other IBM
Rational
tools)

Table 2.6: Feature Comparison: Distributed Collaboration

15



2. Background and Related Work

16



3
Case Context

In this chapter, we relate the previous research that has been conducted at Ericsson
relating to their requirements engineering process along with more company-specific
information, i.e., the context of this case study.

3.1 Previous Tools
The previous tools used at Ericsson were Rational RequisitePro and Rational Rhap-
sody. RequisitePro is a requirements management tool where requirements are writ-
ten in Word documents and parsed into databases. Rhapsody is a modeling tool
where unified modeling language, UML, is used and thus mainly suitable for func-
tional requirements. Diagrams are created using preexisting shapes and symbols
known to UML, which are dragged and dropped onto the canvas. Thus, the di-
agrams are highly customizable, and their layouts are configurable. An example
image of Rational Rhapsody is provided in Figure 3.1.

Figure 3.1: Example diagram in Rational Rhapsody from IBM’s webpage;
https://www.ibm.com/products/systems-design-rhapsody

In 2017 it was decided to replace these tools with a tool that better suited the
intended practices at Ericsson. That is, the tools were not adequate for an agile en-

17



3. Case Context

vironment, with cross-functional teams and continuous integration present. It must
be noted that despite the tools not matching the desired ways of working, the main
reason for the switch was that IBM was no longer supporting Rational RequisitePro,
and the license cost of both Rational RequisitePro and Rhapsody was very high. In
order to address the requirements engineering needs, a potential transition to IBM’s
alternative tool, Rational DOORS, was initially considered. However, an internal
proposal to develop an in-house solution called T-Reqs was presented as an alterna-
tive. Following a comprehensive comparative study conducted within Ericsson, the
T-Reqs proposal was ultimately chosen as the preferred option.

3.2 T-Reqs Tool Description

T-Reqs is a text-based requirements engineering tool, relying on Git-based knowl-
edge storage and residing in a product’s repository. Requirements are written and
reside in Markdown files and are encompassed by XML tags which contain certain
attributes relating to each requirement. Examples of attributes are the unique ID
associated with each requirement and for which products this requirement has been
implemented. A simplified example of a requirement is as follows:

<treqs-requirement id = "REQ100" implemented-for = "product">
Here is where the requirement is written
</treqs-requirement>

The Markdown files can also include trace links indicating traces between
requirements and test cases, as well as PlantUML diagrams. These Markdown files
containing requirements reside in the repository of each product and can thus be
interacted with in a similar manner as normal code.

To increase the usability of the tool, different views and plugins have been
implemented. The most notable are referred to as T-Reqs Web and T-Reqs Viewer
and a plugin for the editors Eclipse and Visual Studio Code. The plugin dynamically
displays the formatted result from the T-Reqs tags and PlantUML in the Markdown
files as HTML.

T-Reqs Web (refer to Figure 3.2) is a web interface where requirements can
be viewed. There, employees can search for requirements and have access to the
ticketing system in JIRA, and they can see which feature a requirement belongs to
and the implementation status of a requirement. They can also see the results of
test cases and the requirements the tests are connected to.

T-Reqs Viewer (refer to Figure 3.3) is an interface that enables employees to
make queries to an SQL database requesting a certain subset of the requirements that
fit specific criteria. The database is only an intermediate storage for optimization,
as during each build of the code, metadata contained in the product’s repository
will be uploaded to it.

18



3. Case Context

Figure 3.2: Example of T-Reqs Web interface

Figure 3.3: Example of T-Reqs Viewer interface

3.3 T-Reqs Related Research at Ericsson
A case study was performed at Ericsson to investigate the flow of requirements from
strategy to release in large-scale agile, performed by Heikkilä et al. [10]. Data was
collected in 43 interviews, which were analyzed qualitatively. The interviews were
conducted in 2011 and 2013. The study illustrated the transition of the company
from a plan-driven ways of working to agile development at a larger scale. The find-
ings of the study showcased that practitioners noted increased motivation, improved
efficiency, and increased flexibility. However, the noted problems were reported be-
ing overcommitment and growing technical debt, among others. The study mainly
gives a glimpse of how these procedures worked before the usage of the current
requirements engineering tool and thus offers a comparison to the current state of
affairs.

As mentioned above, different challenges have been identified when perform-
ing requirements engineering in agile software development. According to Knauss
et al. [7], the challenges most relevant to T-Reqs are as follows,

19



3. Case Context

C1 Updating and deprecating requirements
Requirements defined at the beginning of development can become outdated
and thus need to be changed. The challenge arises if it is uncertain who should
update the requirements and when those updates should take place.

C2 Access to tooling and requirements
Traditional requirements tools often charge fees per user. Thus, it does not fa-
cilitate multi-user access for companies performing large-scale agile processes.

C3 Consistent requirements quality
It is a challenge to keep the quality of requirements consistent across different
artifacts.

C4 Managing experimental requirements
It is important to capture experimental requirements as they might later be
incorporated into the design. The challenge is that these requirements must
be handled differently than stable requirements.

C5 Create and maintain traces
Traces are important in order to determine whether a requirement has been
implemented or not. However, they are not always prioritized by the develop-
ment team as they provide no direct value.

C6 Plan verification and validation based on requirements
The challenge relates to how testing can be planned when requirements are
now incomplete and incremental.

In the pursuit of selecting a tool to mitigate these challenges, Ericsson had specified
requirements, two of which could not be fulfilled by most requirements engineering
tools on the market in 2017. They read; (1) The tool must integrate well with Git,
(2) The tool must allow for changes of the same artifact by many people [7].

Other requirements relating to the tool included that it must be feasible to
store the traces from requirements to test cases in order to know when requirements
were delivered as code and how it was tested, as well as to know which requirement
was delivered at a certain time. The traces should be stored in the exact location
of the other artifacts to assert that the trace information is always in sync with the
artifacts. In terms of the requirements themselves, it must be possible to assign a
unique identifier to them as well as store additional descriptive information about
them, i.e., attributes. It should be a possibility to view the requirements in a human-
readable format. Additionally, both requirements and test cases, including their
definitions, should be stored in the same Git repository as the code. It must also be
possible to create and store test results. Further, changes to the artifacts should be
easy to undo as well as easily updated by the cross-functional development team.
The selected tool should also be similar to the current tools being used by the team.
Finally, it needs to be possible to validate the system after making changes, that
is, make certain that no edit can break the system and it should also be possible to
release any build with minimal manual work, as requirements and test cases should
always be in sync with the code.

Since the traditional tools could not support the desired functionality in re-
gard to large-scale agile practices, Ericsson eventually decided to develop a tool

20



3. Case Context

in-house to account for their situation and environment. Thus, T-Reqs was devel-
oped, and with textual modeling of requirements engineering, it was expected to
mitigate some of the challenges met within requirements engineering in large-scale
agile environments.

3.4 Roles
The roles within the company that are relevant for this case study due to their prox-
imity and usage of T-Reqs are General System Manager and Team System Manager.
Thus, an explanation of the responsibilities of said roles will be given to emphasize
the difference between them and give better context behind the perspectives of the
interviewees later in the report.

General System Manager : The responsibility of the General System Manager is
twofold. Firstly, to perform studies, i.e., look ahead and discover which feature or
functionality should be implemented and how. These features can be based on the
mobile broadband standard, which Ericsson follows, or customer requests. These
studies are either classified as system studies or initial feature studies. The system
studies have a broader scope and are often later broken down into multiple initial
feature studies. The scope of the initial feature studies corresponds to a feature
that a cross-functional team would be able to work on. Upon finalizing the decision
to proceed with the development of a specific feature, the preparation of system
requirements for the feature development in the teams falls under the responsibility
of the General System Manager as well. This feature is then presented to the team,
and the General System Manager supports the team with creating and writing the
requirements from the initial, often more high-level requirements. Thus, breaking
down the requirement into more technical requirements. The General System Man-
ager continuously reviews the requirements throughout the development process of
the feature and is notified of any changes made by the team. The collaboration with
the team is mainly done through the Team System Managers, and each feature a
team works on has an assigned General System Manager. Secondly, the General
System Managers have the responsibility to answer questions from customers and
business salespersons, in addition to handling change requests from customers.

Team System Manager : The Team System Manager is part of the cross-functional
development team and thus is either a developer or functional tester alongside their
role of Team System Manager. Their responsibility is to understand the feature,
write and update the requirements in T-Reqs, support the team by explaining at-
tributes or fields to other members of the team. Additionally, they have discus-
sions regarding the requirements with the team and the General System Manager
responsible for the feature as well as communicating any changes made during de-
velopment to the General System Manager. The Team System Manager thus has
the perspective of the requirements in mind, but the whole team is responsible for
the requirements. It is important to note that despite the General System Manager
being the artifact responsible for the requirements, the team must be able to defend
the requirements and ensure that they correspond to what has been implemented.

21



3. Case Context

22



4
Methods

The method chosen for this master’s thesis is an in-depth case study [10]. The
design chosen for data collection is inspired by Creswells’ proposed mixed method
research and design [11]. In this design, quantitative and qualitative data and meth-
ods associated with said data are combined. Among the different types of mixed
method designs suggested in Creswells’ book, the chosen method for this research is
Exploratory Sequential Mixed Methods Design which occurs in three phases. The
initial phase entails exploring qualitative data. The second phase entails a feature
being created, in our case, a survey instrument, from the gathered qualitative data.
Finally, in the last phase, the feature is tested by using quantitative research meth-
ods.

This case study method was chosen to get a good understanding of the context
and the people who interact with T-Reqs, in order to give a more accurate evaluation
of T-Reqs. The decision to use an Exploratory Sequential Mixed Methods Design,
starting with interviews and then a survey, is based on the idea of having a good
overview of the themes present in the context before quantifying them with a survey,
which is also standard practice [35]. The objective is to create a comprehensive
survey that thoroughly encompasses all facets pertaining to the research inquiries
while remaining vigilant in avoiding any potential influence from prior biases in
the construction of the survey framework. The outcomes obtained from the survey
can serve as a valuable instrument to assess and evaluate the themes identified
during the interviews and, subsequently, establish a collective agreement among the
interviewees. The overview of the case study process can be seen in Figure 4.1.

Figure 4.1: Overview of the case study

23



4. Methods

4.1 Data Collection
As per the chosen design, data will be collected in the first phase and the last phase.
In the first phase, data was collected through semi-structured interviews, i.e., a data
collection method associated with qualitative research. In the last phase, a collection
of data in a follow-up survey, i.e., a method connected to quantitative research.

In addition to the data collected through the chosen design, the preliminary
results from the interviews were presented at a workshop with requirements engineer-
ing practitioners. This was in order to achieve more generalization of our findings in
this case study by getting insights from practitioners whether or not T-Reqs would
be applicable in their company context and what advantages and characteristics of
T-Reqs resonated with them.

4.1.1 Interview Methodology
The research design incorporated a series of fourteen interviews as a primary data
collection method. Participants were selected based on their roles within Ericsson,
comprising both General System Managers and Team System Managers with differ-
ent levels of experience, reflecting a range of perspectives on the use of the T-Reqs
tool. That is, all participants are the current users of T-Reqs and are thus familiar
with the tool and have experience with working with it.

The selection of interviewees followed a mixed approach that incorporated
elements of convenience and snowball sampling strategies [36]. Initially, our company
liaison provided a list of potential participants amenable to participating in the
study. Subsequently, we leveraged the snowball sampling method, asking these
initial participants to recommend additional personnel within Ericsson who could
provide valuable insights for the research. This dual strategy ensured a broad and
diverse range of views, enriching our understanding of T-Reqs within the company
context.

Interviews were conducted until perceived saturation was reached, that is until
no new themes emerged. At the same time, the sampling of the interviewees with
snowball sampling had reached its end. That is, we had no immediate contacts as
possible next interviewees.

The interviews were semi-structured, which entails that an interview guide was
prepared for the interviews with specific questions to ask but allowing for improvisa-
tion as well. It is hard to know beforehand all relevant topics or areas that might be
valuable to discuss. Thus, it is beneficial to leave room for other topics of discussion
relating to an answer to the research questions.

The interviews took approximately one hour and were structured by beginning
with identifying the background of the interviewee, i.e., their current and previous
roles, how long they had been employed at Ericsson, and if they had any experience
with other requirements engineering tools. Then, the questions posed related to
each of the research questions in succession. Beginning with collecting data on how
well the tool is performing in terms of meeting the desired expectations and whether
it is solving the relevant problems they had with the previous way of writing and
managing the requirements. Additionally, discovering if there are any unexpected

24



4. Methods

Subject Current Role Experience
Interviewee 1 General SM High
Interviewee 2 General SM High
Interviewee 3 Developer Low
Interviewee 4 General SM High
Interviewee 5 General SM Low
Interviewee 6 General SM Low
Interviewee 7 General SM High
Interviewee 8 General SM High
Interviewee 9 General SM High
Interviewee 10 General SM Low
Interviewee 11 General SM High
Interviewee 12 General SM Low
Interviewee 13 Team SM Low
Interviewee 14 Team SM Low

Table 4.1: Table of interviewees

benefits or problems with the tool. Next, which advantages and disadvantages the
interviewees perceived the tool to possess. The participants were finally asked to
identify either the characteristics of the tool or if the interviewee was not familiar
with other requirements engineering tools, the key features of the tool. The interview
guide devised and used for the interviews can be seen in Appendix A.

In Table 4.1, the interviewees are listed with both their current role and their
experience level. The column indicating experience is associated with their expe-
rience with using other requirements engineering tools. High experience indicates
that the interviewee had experience with working with other requirements engineer-
ing tools. This correlated with the interviewee having over five years of working
experience at Ericsson, i.e., before switching to T-Reqs, and thus they had experi-
ence with Rational RequisitePro and Rhapsody. Low experience indicates that the
interviewee’s only experience with requirements engineering tools is through using
T-Reqs. This correlated with the interviewees having joined the company after the
switch to T-Reqs.

4.1.2 Survey Methodology
The qualitative results from the interviews were used as input for constructing the
survey questions. This increased the possibility of more precision and less ambiguity
due to the questions being crafted with specific domain knowledge and vocabulary
used by the interviewees. The ambiguity is further decreased due to the survey
being sent out to the participants of the interviews, i.e., as a follow-up survey.
Thus, the respondents of the survey were only employees that had participated in
the interviews. Ten out of fourteen possible respondents answered the survey. The
rest were not able to answer due to unavailability, and one participant did not answer
due to the nature of their interaction with the tool.

The reason for gathering quantitative data from the same employees as had

25



4. Methods

Subject Current Role Experience
Respondent 1 General SM High
Respondent 2 General SM Low
Respondent 3 Team SM Low
Respondent 4 Team SM Low
Respondent 5 General SM Low
Respondent 6 General SM High
Respondent 7 General SM High
Respondent 8 General SM High
Respondent 9 General SM High
Respondent 10 General SM High

Table 4.2: Table of respondents to the follow-up survey

been a part of the qualitative data-gathering phase was twofold. First, by sending
the survey only to the previous interviewees, the likelihood of them misunderstand-
ing the questions was reduced as these were the topics discussed in the interviews.
Second, this made it possible to verify that a topic or opinion brought up by only
one interviewee was shared among the other interviewees. That is, to get an under-
standing of other interviewees’ sentiments towards the topics or opinions, whether
they found it irrelevant or had not thought of it during the interview.

The structure of the survey resembled the structure of the interviews, as par-
ticipants were first asked to indicate their current role at Ericsson, as well as whether
they had previous experience with other requirements engineering tools. Addition-
ally, they were asked to specify their general IT competencies, i.e., how comfortable
they were with using Git, Linux, and PlantUML. Table 4.2 shows the respondents
to the survey. The IT competence of each respondent has not been added to the
table as each participant either agreed or strongly agreed with being comfortable
with all three technologies, except Respondent 3, which disagreed with being com-
fortable with using PlantUML. After the questions relating to the background of
the participants, questions were posed where the participants were asked to relay
their sentiments to different statements regarding the tools. The statements were
grouped based on relevant themes and topics identified during the interviews and
were ordered based on which research questions they answered. Most questions
in the survey were in the format of a 5-point Likert scale, ranging from strongly
disagree to strongly agree. The option of “I don’t know” was also afforded to the
participants. Apart from the Likert scale questions, multiple answer questions were
also posed in order to validate the identified advantages and disadvantages as well
as the characteristics and key features of T-Reqs. The survey was online and sent
out to the participants of the interviews via email to minimize the disturbance in
the environment. The survey questions can be viewed in Appendix B.

4.1.3 Workshop Methodology
Our preliminary findings derived from the interviews were presented to experts in the
fields of requirements and requirements tooling from different companies in Gothen-

26



4. Methods

burg at a workshop at the Software Center at Chalmers University of Technology.
Two participants were from Ericsson, two from different automotive companies, and
one from a manufacturing company, along with two academic researchers from the
Computer Science and Engineering department at the University of Gothenburg and
Chalmers University of Technology. All participants had some prior knowledge of
T-Reqs.

The findings were presented in a slideshow presentation and followed by an
open discussion among the participants of the workshop. The purpose of this ad-
ditional data collection was to achieve more generalization of our findings. That is,
which identified advantages, disadvantages, and characteristics of T-Reqs the work-
shop participants resonated with based on their company context and whether the
tool would be suitable for their development processes. Thus, gaining a broader
perspective of which conditions and contexts T-Reqs would be most applicable.

4.2 Data Analysis
The analysis of the semi-structured interviews was conducted using coding methods.
In this context, coding refers to the process of categorizing and tagging raw data from
interviews or surveys to identify themes, patterns, and relationships [13]. Coding was
performed after the interviews, i.e., no code was predetermined. Additionally, coding
was performed independently by each author to ensure that no information relayed
in the interviews was overlooked and potentially identifying different perspectives
of how the data could be interpreted. The codes from each of the authors were
compared, and in most cases, they relayed the same information, however, with
different degrees of detail.

We used a combination of coding methods suggested by Saldaña in his cod-
ing manual [13], specifically First Cycle methods. These methods are foundational
coding procedures that are typically applied during the initial stages of qualitative
data analysis. Saldaña suggests using In Vivo Coding, Initial Coding, and/or Values
Coding specifically for interview transcripts. We found Initial Coding and In Vivo
Coding to be most suitable for our data. This was mainly due to Initial Coding
offering the freedom, in the beginning, to code as we went and try to give the best
representation of the data, i.e., as Saldaña states, Initial Coding is the first phase
of approaching the data through grounded theory. In Vivo Coding further offers to
give the best representation of the data as it involves using a word or short phrase
from the actual language of the participant as a code. It is useful for capturing how
participants frame their experiences using their own terms. For the final suggestion,
i.e., Values Coding, we did not find it as intuitive as the other two coding methods.
Values Coding involves associating a code either with the letter V, A, or B, indi-
cating whether the code relates to the interviewee’s value, attribute, or belief. As
was mentioned in Saldaña’s manual, it can be hard to determine to which type an
interviewee’s remark should be classified. We also thought that we risked that our
own beliefs and thoughts would affect the way that we categorized the remarks of
the interviewees. Therefore, we would not be offering the best representation of the
data.

As we progressed with the coding, we noticed elements of Process Coding

27



4. Methods

emerging in our codes. Process Coding involves using gerunds (“-ing” words) to
identify observable and conceptual actions in the data. This correlated with the
coding manual, stating that Initial Coding could often include In Vivo and Process
Coding.

Given the diverse range of topics covered in the interviews, adding another
layer of specificity to our codes was often necessary to clearly indicate, for example,
which tool the comment related to. To achieve this, we employed Subcoding. This
coding method involves assigning additional codes to a parent code to provide extra
details or capture a specific aspect of the coded data.

In summary, we used a combination of Initial Coding, In Vivo Coding, Pro-
cess Coding, and Subcoding methods to thoroughly analyze the data collected from
the semi-structured interviews. These coding techniques allowed us to distill the
rich qualitative data into identifiable themes and patterns, ultimately enabling us
to draw meaningful conclusions from our research.

The following are examples of codes from the interview transcripts:
“One goal was, [...], the usability. That it should be fairly easy to set up and to use the
tool on a daily basis” - Interviewee 1

The code associated with the quote above is: T-Reqs goal – Usability, “easy to set
up and to use”. In the code T-Reqs goal is the Initial Coding, Usability is the
Subcoding, and “easy to set up and to use” is the In Vivo Coding.

“Initially, it was very tough because if you want to copy the whole image, it was not
quite easy. You had to choose and select and so many things was, yeah. Sometimes it
gets wrong and you know copy pasting the things doesn’t work, it didn’t work properly.
So they had kind of a lot of issues, yeah.” - Interviewee 4

The code associated with the quote above is: Rhapsody: Issues with copying image.
In the code Rhapsody is the Initial Coding, and Issues with copying image is Process
Coding.

The evaluation criteria of the tool will be based on whether the tool has met the
desired expectations and solved the problems it was intended to solve. This can
be retrieved by comparing the answers in the interviews and the survey to the
documentation stating these expectations and mitigation of problems that justified
the initial decision to choose to work with T-Reqs.

4.3 Ethical Considerations
The following measures were taken to follow ethical guidelines regarding human
participants. The purpose of the interviews and the document containing the original
proposal for this research were provided to the participants prior to the interviews.
The purpose of the survey was also relayed. Participation in the interviews and
survey was both voluntary. The names of the participants were not recorded or
disclosed in any of the research documents. Thus, anonymity and confidentiality
were guaranteed. The interviews took no longer than one hour, to cause the least

28



4. Methods

amount of disturbance to the participants’ daily work. The participants were also
offered to ask questions if they needed any clarifications. Verbal consent for recording
the interviews was given at the start of each interview.

4.4 Threats to Validity

Given the research method chosen and the data collection and analysis performed in
this research, certain threats to validity have been introduced. In this section, these
threats will be discussed in accordance with the classification suggested by Runeson
et al. [11], i.e., construct validity, external validity, internal validity, and reliability.

4.4.1 Construct validity
A threat to construct validity that is present in this research concerns the topic of the
tool in comparison to the previous requirements engineering tools at Ericsson. That
is, half of the interviewees were not familiar with the previous tools or other tools
in the industry except T-Reqs. This posed a threat since two research questions
rely on knowledge of traditional requirements engineering tools. For the second
research question, where we asked the interviewees to describe the advantages and
disadvantages of the tool, this could be done without the knowledge of other tools.
However, for the research question regarding the characteristic of the tool, i.e., its
unique features, it proved more challenging. Thus, the interviewees that did not
have knowledge of other tools were instead asked to identify what they considered
the key features of the tool.

In addressing potential threats to the construct validity in our research method-
ology, it is crucial to acknowledge the role of the generative AI, ChatGPT-4, used in
our study. A key area where the AI tool was utilized was in summarizing a compre-
hensive criteria list from a prior study [30]. While summarizing, we were conscious
of the potential for bias towards T-Reqs if the summarization was performed man-
ually by the authors, as we might select items in the list in favor of T-Reqs, due to
our closeness to the tool. To mitigate this potential bias, we deployed the AI tool.
However, using an AI introduces its own potential threats to validity. Specifically,
there might be subtle changes in the meaning of the text due to the AI’s interpreta-
tion, posing a risk to the construct validity. To counteract this, we have diligently
reviewed the AI-generated summary and made necessary adjustments to ensure the
correctness and integrity of the summarization.

The AI tool was also employed for grammar and syntax correction in parts of
the paper. While the tool generally improves the consistency and clarity of the text,
it may not perfectly understand the context of the study. It could suggest changes
leading to inaccuracies in the grammar or phrasing. Therefore, although we carefully
scrutinized all AI-suggested changes, there is still a possibility of minor discrepancies
that might affect construct validity. These potential issues are essential to consider,
though they are unlikely to significantly impact the overall findings or conclusions
of our study.

29



4. Methods

4.4.2 Internal Validity
Given the heavy reliance on semi-structured interviews in this study, there is a risk
that the authors’ expectations and preconceptions could influence the data analysis
process. To address this potential threat to the study’s validity, we adopted a
coding approach based on established strategies proposed by Saldaña [13]. The
interview transcripts were coded independently by both authors and then compared
to promote consistency and reduce subjectivity. However, another potential threat
to the reliability of our study comes from the absence of checks for the coding process
by an independent, external party. This lack of external verification could introduce
a risk of the codes being less accurate or reliable, as the authors are not experts in the
field and have limited prior knowledge of requirements engineering tools. Although
this risk was partially mitigated by the independent coding process performed by
the authors, the absence of an external reviewer remains a limitation. To verify
and validate our findings from the interviews, we sent out a follow-up survey to the
interviewees in order to confirm our interpretations of the data gathered from the
interviews. Through these measures, we sought to enhance the rigor and reliability
of the study’s qualitative data analysis.

By using convenience sampling, a potential bias can be introduced, i.e, sam-
pling bias, as the ones agreeing to be interviewed might have a more positive view of
T-Reqs than the average population. Consequently, the sample may not be represen-
tative of the entire population and limits the generalizability of the study’s findings.
To address this limitation, we employed several strategies. First, the sample size
was selected with the goal in mind of striving to achieve data saturation, i.e., get as
many perspectives as possible in order to draw necessary conclusions. Second, we
utilized snowball sampling to diversify the participants and obtain a broader range
of perspectives, including hard-to-reach subjects. Third, to obtain a more diverse
sample, we also compared the characteristics of the participants to those of the
population. Specifically, we focused on the participants’ role at Ericsson and their
experience with requirements engineering tools as the main criteria for inclusion in
the study. By considering these characteristics, we aimed to ensure that the sample
accurately represented the target population and increased the generalizability of
the study’s findings. Despite these efforts, sampling bias remains a potential threat
to the validity of our findings.

4.4.3 External Validity
The delimitation of this study includes reducing the scope of the case study to
focus mainly on the text-based requirements engineering tool at Ericsson instead
of performing a general case study on said tools. This decision was mainly due to
resources and time constraints, i.e., depth was preferred over breadth, considering
the qualitative nature of a more complex evaluation like this. The authors of this
study also had the opportunity to work with T-Reqs during the master’s level course
Industrial Practice Project in Software Engineering and familiarize themselves with
the tool.

Due to the delimitation of the scope of the case study, the main limitation
of this study is the lack of generalizability. Since it is an evaluation of a tool in a

30



4. Methods

contained environment, i.e., within one company, the possibility could arise that the
company’s experience with the tool could not be comparable to another company.

The inherent risk of limited generalizability posed by a single case study
approach was mitigated through several strategic measures. Primarily, this was
achieved by formulating a research question that expands the scope to encompass
the general characteristics of these new tools and proposing a definition for them.
Additionally, a workshop was conducted to engage a diverse group of practitioners in
the discussion of preliminary findings derived from the interviews. The goal of these
discussions was not only to validate and refine the insights gained from the Ericsson
context but also to extrapolate these insights to broader contexts. By facilitating a
dialogue regarding the potential adoption of T-Reqs in other companies, we strived
to identify conditions and contexts where T-Reqs could demonstrate utility. This
method provided a platform for participants to share their unique perspectives, thus
enriching the research findings and enhancing their potential applicability beyond
the specific case of Ericsson. Finally, from the findings of this study, we offer advice
for what should be considered when choosing a requirements engineering tool in
Section 6.2.

By illustrating the specific context in which T-Reqs has been employed, con-
sidering the fulfilled expectations, advantages, and disadvantages of the tool, we
assume transferability [42] can be established. That is, experts in the field of re-
quirements and tooling can interpret the results of this study in order to evaluate
if they are applicable in their contexts. Thus, the workshop could be used to assess
whether transferability had been achieved.

4.4.4 Reliability
There exists a threat to the reliability of the research due to it potentially being
hard to replicate as the interviews were semi-structured. In order to minimize this
threat, the results derived from the interviews were verified by sending a follow-up
survey to the interview participants.

A threat to reliability is also present in terms of the questions posed during
the interviews or in the survey being unclear. This ambiguity could result in a mis-
understanding which will evidently skew the results. To mitigate this threat, the
authors performed a literature review analyzing challenges found regarding require-
ments engineering tools to familiarize themselves with the terminology and features
most common to the tools. This vocabulary was then employed to form the ques-
tions for the interviews. Additionally, due to the authors being acquainted with the
tool from previous interactions with it, the terminologies and vocabulary employed
in relation to it at Ericsson were already familiar to the authors and enabled eas-
ier discussions in the interviews, minimizing misunderstandings. For the questions
posed in the survey, this threat was mitigated by asking questions based on topics
and themes discussed during the interviews. Additionally, the survey was only sent
to those who participated in the interviews.

31



4. Methods

32



5
Results

In this chapter, the results of this case study will be presented in accordance with
the previously posed research questions.

5.1 RQ1 (Expectations)
How well do the expectations of T-Reqs before its implementation match with how
the tool performs today?

The main goals and expectations for the tool were increased usability and
improved ways of working. Most interviewees that were aware of the original
goals of the tool agreed that the tool had achieved what it set out to achieve
for the most part. Several interviewees noted that they had seen an increase in
requirements updates done by the teams themselves, the scale-out of the com-
pany was successful, and the tool is currently being adopted in organizations
across the company.

To answer this research question, we start by describing the considerations and
decisions made regarding the implementation of T-Reqs, gathered from both the
interviews and artifacts provided by Ericsson. Then relate the different expectations
and goals concerning the tool and whether those are considered to have been met
or not.

5.1.1 Implementation Considerations & Decisions
The following main areas of consideration were identified when it came to implement-
ing T-Reqs, i.e., version control and storage, requirements modeling, traceability of
requirements and test cases, interoperability, ways of working, and other tools.

5.1.1.1 Version Control & Storage

When using the previous requirements engineering tools, i.e., Rational RequisitePro
and Rhapsody, the version control handling had to be done manually and separately
from the tools. This evidently introduced more manual labor and was not time effi-
cient. It was thus considered important to be able to store requirements, code, and
test cases together to enable an easier way to baseline and thus compare and review
changes to both requirements and the code and test cases simultaneously. In order
to store requirements together with the code, it was considered most convenient to

33



5. Results

store the requirements in text-based files, i.e., Markdown files, which also complied
with the need for being able to view the requirements in a human-readable format.

5.1.1.2 Requirements Modeling

In order to replace the previous modeling tool Rhapsody, T-Reqs had to have the
possibility of also displaying diagrams alongside the requirements. It was decided
to integrate PlantUML into T-Reqs as it is text-based as well and could thus be
included in the T-Reqs files and managed the same way as the requirements.

5.1.1.3 Traceability of Requirements & Test Cases

The storage of trace links between requirements and test cases is vital as they justify
whether a requirement has been fulfilled or not. Thus, illustrating when a require-
ment was delivered as code and how it was tested. The original idea was to still
pertain the tracing information and the metadata in a database, as was done in
Rational RequisitePro. However, it was instead proposed to include the trace infor-
mation in the requirements documents, and test case files themselves. Therefore, all
artifacts are in a similar location, and in order to add a new requirement, the update
could be made in only a single file. This will also assert that the trace information
is always in sync with the artifacts.

5.1.1.4 Interoperability of T-Reqs

Different organizations within Ericsson have varying products that they develop, as
with varying tools that they employ. Therefore, it was important that the tool had
interoperability with other systems in use. The byproduct of selecting a traditional
requirements engineering tool is that they are often part of a package of other tools,
which the companies creating these tools suggest are used collectively. However,
Ericsson already had these other systems for their development processes, e.g., test,
build, and issue reporting systems, which they did not want to abandon without
cause. Thus, it was important that the new tool fit the current tool suite.

As mentioned above, it was important to have version control as part of the
tool, and thus, in order to make versioning consistent, T-Reqs is integrated into each
product’s repository. This was not done all at once and has rather been a gradual
spread across the departments and products, and T-Reqs plugins implemented for
the different development tools each department relies on.

5.1.1.5 Ways of Working

Apart from needing to switch tools due to RequisitePro no longer being supported,
one of the major factors in changing tools was also due to a new way of working,
which Ericsson wanted to introduce. Namely, they were moving towards more agile
ways of working. In doing so, they wanted to involve the team more in the require-
ment engineering process, i.e., integrating it more into the development process and
increasing the teams’ responsibility of managing the requirements. This should also
enhance the teams’ understanding of the requirements and aid in the implementa-
tion. This would be a challenge when considering licensing tools, as they are often

34



5. Results

charged per user. Thus, an incentive exists to either pick an open-source tool or
develop a tool in-house.

5.1.1.6 Other Tools

At the time, Ericsson experts evaluated other tools on the market, but none were
considered suitable for the development at the company, which opted thus to develop
its own tool. As many interviewees pointed out, this is not an uncommon occurrence
as there is a culture within Ericsson to develop their own tools. Which, as one
interviewee stated, has been done with varying success, but they considered T-Reqs
to be a “decent result” (Interviewee 6). On the other hand, another interviewee
stated that they didn’t know if in-house development was good or bad as a lot of the
initial work performed on developing the tool “could have been resolved with having
a licensed tool” (Interviewee 2). However, the consensus among the interviewees
was that developing the tool in-house was a good decision as it was then tailored to
Ericsson’s needs, i.e., licensing tools offer a large variety of features that are not all
applicable for Ericsson’s requirements management. Additionally, it makes it easy
to reach out and request changes or bug fixes, i.e., offers “good customer support”
(Interviewee 10). However, Interviewee 14 noted that compared to the licensing
tool, T-Reqs lacks in providing extensive documentation and instructions, though
that is on the mend.

5.1.2 Goals & Expectations
The following goals and expectations towards T-Reqs were identified, i.e., usabil-
ity and improved ways of working. The expectation of improved ways of working
contains the subgoals scale-out, automated test reporting, facilitated collaboration,
pertain the structure, and master branch release ready.

5.1.2.1 Usability

One of the primary goals of introducing the new tool was to emphasize ease of use,
i.e., that it should be easy to set up the tool as well as to use it. This should be true
for both frequent users and infrequent users, i.e., the tool should also be intuitive
enough to benefit users that do not use it on a regular basis. This was partly solved
by using the existing Git framework accessible through a Linux virtual machine, i.e.,
technology that most developers were familiar with. This familiarity with Git also
lends itself to the expectation of developers having less fear of losing work, i,e., for
example, changes made should be easy to undo. Using the existing Git framework
also ensured that developers could remain working in the same environment, i.e.,
that they did not have to switch between tools while developing. In addition to
the version control, an HTML preview can be generated in the editor to parse the
syntax written for the requirements in the Markdown files, including the PlantUML
diagrams. This enables the developers to view how the requirement will be displayed
in the T-Reqs Web before they commit their changes.

35



5. Results

Figure 5.1: Visualisation of the themes and sub-themes identified in regard to RQ1
(Expectations)

36



5. Results

5.1.2.2 Improved Ways of Working

Scale-Out: One of the main expectations of moving the requirements closer to the
development teams was to be able to scale better, i.e., increase the number of cross-
functional development teams, thus enabling large-scale agile development. For
Ericsson’s previous