[datatype=bibtex] [fieldset=issn, null] [fieldset=month, null]
[fieldset=urldate, null]

# Tailoring Stakeholder Interests to Task-Oriented Functional Requirements

Philipp Haindl  Software Competence Center Hagenberg, Austria  Department of
Business Informatics - Software Engineering, Johannes Kepler University Linz,
Austria  Reinhold Plösch  Department of Business Informatics - Software
Engineering, Johannes Kepler University Linz, Austria

###### Abstract

Without a specific functional context, non-functional requirements can only be
approached as cross-cutting concerns and treated uniformly across all features
of an application. This neglects, however, the heterogeneity of non-functional
requirements that arises from stakeholder interests and the distinct
functional scopes of software systems, which mutually influence how these non-
functional requirements have to be satisfied. Earlier studies showed that the
different types and objectives of non-functional requirements result in either
vague or unbalanced specification of non-functional requirements. We propose a
task analytic approach for eliciting and modeling user tasks to approach the
stakeholders’ pursued interests towards the software product. Stakeholder
interests are structurally related to user tasks and each interest can be
specified individually as a constraint of a specific user task. These
constraints support DevOps teams with important guidance on how the interest
of the stakeholder can be satisfied in the software lifecycle sufficiently. We
propose a structured approach, intertwining task-oriented functional
requirements with non-functional stakeholder interests to specify constraints
on the level of user tasks. We also present results of a case study with
domain experts, which reveals that our task modeling and interest-tailoring
method increases the comprehensibility of non-functional requirements as well
as their impact on the functional requirements, i.e., the users’ tasks.

_Keywords_ Stakeholder Interests $\cdot$ Requirements Negotiation $\cdot$ Task
Modeling $\cdot$ Constraint Specification

## Remark

This paper is an addition to our peer-reviewed publications in [1, 2] and
contains a more elaborate presentation of our findings. When citing our work,
please always cite the peer-reviewed publications; citing this technical
report should always be optional for cases where you explicitly reference
aspects that were not published in the peer-reviewed publications.

##  1 Introduction

Intertwining functional and non-functional requirements (NFRs) is a
challenging endeavor in software projects of any scale. The primarily
engineering-oriented understanding of NFRs neglects the practical relevance of
business, strategic, operational, legal and privacy interests which must be
taken into account throughout the DevOps cycle. We use the term stakeholder
interest to emphasize this broader understanding of NFRs. In industry, these
stakeholder interests are typically specified as cross-cutting concerns
throughout the application without considering relevance, applicability, and
characteristic of an interest for a certain software feature. As the
complexity of satisfying an interest differs between features, this lack of
preciseness in specifications results in undetected non-functional
dependencies between components and features in development, as well as
increasing operational efforts throughout the DevOps cycle [3]. Focusing on
concrete tasks that users will perform with a software system allows
functional units of work to be elicited from a user perspective. In contrast
to isolated features, tasks can be seen as functional units that focus on the
users’ goals and therefore required interactions between features. This makes
the individual relevance of competing NFRs for a single user task more
tangible. In our work, we understand constraints as refinements and
operationalizations of NFRs. Constraints of a user task can unambiguously be
validated for fulfillment. Especially among non-technical stakeholders, this
facilitates requirements negotiation [4] and assessment of tradeoffs in
satisfying constraints [5].

In this paper we present an approach for eliciting and modeling user tasks
based on a modified form of hierarchical task analysis [6]. It facilitates the
tailoring of stakeholder interests to user tasks so that the interests can be
refined into constraints and satisficed during the full software lifecycle.
The prime objective of these constraints is to satisfice the original
interest, i.e., to satisfy an interest sufficiently and not better than
required. The precise refinement of each interest as a constraint on the level
of user tasks also gives DevOps teams a more tangible understanding of how an
individual constraint must be practically handled in software design,
implementation, and operation.

Our approach augments the computer-implemented development method outlined by
US Pat. No. 15/661,498 [7], which aims to find suitable quantitative
constraints for NFRs through Monte-Carlo simulations. Our work explicitly
facilitates elicitating, refining and specifying constraints for individual
functional requirements with quantitative measures. Also, it supports
requirements engineers in the process of evaluating possible trade-offs of
contradicting NFRs on the level of user tasks.

The remainder of this paper is organized as follows. An overview of related
work and the demarcation of our approach to other works are given in section
2. In section 3 we describe the research context and study design we chose to
answer the research questions. Following, section 4 introduces our approach to
eliciting, modeling and tailoring functional requirements and stakeholder
interests. Section 5 presents an evaluation of this approach with experts from
software engineering, operations, and product management before we describe
the possible threats to validity in section 6. The conclusion of our work and
possible directions for future work are presented in section 7.

##  2 Related Work

Goal- [8, 9] and hence task-driven [10, 3] approaches have proven to be
effective for requirements elicitation. They do, however, not guide
stakeholders to specify suitable NFRs for a certain product or service.
According to Fotrousi et al. [11], the key limitation of goal models is that
the impact of an unsatisfied NFR towards a goal is difficult to understand for
stakeholders. Riegel et al. [12] elaborated on a prioritization method which
classifies non-engineering related NFRs by project-related, financial,
customer, operational business performance or business-strategy related
benefits. Karlsson et al. [13] investigated the applicability of goal models
in the context of market-driven software development and highlighted the
benefits of goal-centered feature elicitation. They showed that these models
facilitate stakeholder participation in the requirements engineering process.

Regnell et al. [14] presented the QUPER approach for relating NFRs to
development costs needed for their fulfillment. According to their
observations, stakeholders lack a shared understanding of the required
efforts, and thus costs, for fulfilling NFRs in practice. Their framework
QUPER allows to prioritize and balance NFRs through comparison with products
of competitors. Cleland-Huang et al. [15] presented a method for tracing
quality goals of different levels of granularity in specification documents,
offering a means to systematically review interrelations between quality goals
and system components. Hermann et al. [16] compare two methods for refining
NFRs from quality goals. Again, the authors stress the importance of
specifying NFRs individually for functional requirements and also to
scrutinize the relation between NFRs and business goals.

Another stream of research tackles the different satisfaction criteria of NFRs
in the context of individual user tasks and software features. Zubcoff et al.
[17] propose a Pareto-based approach for specifying soft goals in the context
of user tasks which assists requirements engineers in evaluating trade-offs
between NFRs. The authors also underline that NFRs shall be specified
individually for functional requirements to improve end-user satisfaction.
This argumentation is also taken by Ameller et al. [18] who compare approaches
for model-driven design in software engineering. The authors conclude that
most model-driven design approaches do not intertwine functional requirements
and NFRs which may result in the expectations of the stakeholders not being
fully satisfied. Ameller et al. [19] present a survey among practitioners in
18 companies about the practice of NFR specification in model-driven design.
The interviewees argued that NFRs are not only difficult to specify through
models, but even difficult to discover and explicate in measurable terms. As a
result of this imprecise definition, the fulfillment of NFRs usually can only
be evaluated very late in the software development process. Also, the
intervieews reported that in their companies unmet NFRs in projects often
require retrofitting of functional requirements. An interview study of
Svensson et al. [20] also shows that in practice, NFRs have a lower priority
than functional requirements and are partly not even specified in the early
stages of development. This lack of integration between functional
requirements and NFRs can result in long time-to-market and cost overruns in
software projects [21, 22, 23, 24].

In summary, recent research had elaborated the importance of balancing
functional and NFRs in understanding technical qualities, but no structured
method has yet been presented that captures interests outside the technical
domain. As can be recognized, several authors especially underlined the
suitability of goal-centered approaches to increase stakeholder participation
and facilitate shared understanding. The approach presented in this paper
explicitly links these two strands of research, providing a structured method
for eliciting and specifying constraints from NFRs for individual functional
requirements. Our approach also permits stakeholders to have different domains
and thus interpretations of NFRs before gradually refining and eventually
collectively specifying appropriate constraints therefor with quantitative
measures.

##  3 Research Context and Study Design

Figure 1: Research methods for iteratively deriving codes, a theory, and
further improvement directions for our task-oriented interest tailoring
approach through expert interviews (adapted from [25]).

Our study started with a literature review of key challenges for eliciting and
specifying NFRs using moderation-based prioritization techniques for assessing
individual relevance for software features. Originating from informal
discussions we expanded this literature review by human task analysis to
assess how these methods can be used to elicit and prioritize functional
requirements from user tasks.

Based on this literature review we designed an exploratory case study using
expert interviews to research the elicitation practice and specification
preciseness of NFRs in different companies. Following, we presented the
experts our approach to the task-oriented modeling of functional requirements
and tailoring stakeholder interests to elicited user tasks.

###  3.1 Case Study Design

Taking the guidelines by Runeson and Höst [26] as a blueprint we designed the
questionnaire covering practices, challenges, and problems that arise during
specifying NFRs with different stakeholders. Also, we conducted a pilot
interview as suggested by Yin [27] with one highly experienced expert and
included his feedback to improve the questionnaire itself. Particulary, we
refined certain phrases in the questionnaire and used more common terminology
to assure a good understanding during the interviews among the experts.

The questionnaire comprised 20 open questions and 4 closed questions on a
4-point Likert scale and was separated into 3 parts: The first part captured
educational and company background, roles in projects and years of experience
with requirements engineering. In the second part we asked questions to find
out how the companies currently model functional requirements and NFRs, what
challenges they are confronted with, and what types of stakeholder interests
typically need to be taken into account thereby. Finally, in the third part we
presented the experts our approach for tailoring stakeholder interests to
concrete constraints in the context of user tasks. During the interviews we
used figure 4 to present the approach to the experts. In this final part we
asked them to rate suitability and applicability of the approach as well as
anticipated benefits and drawbacks.

We conducted 11 face-to-face expert interviews with senior software engineers,
technical product and project managers, and requirements engineers from
different companies in Austria. The interviewees’ companies have a mean
employee count of 65 and ranged from small enterprises to companies with more
than 1000 employees. Industry sectors comprise public administration, finance,
logistics, IT consultancy, public media, ERP software development, and
software product manufacturing. The experts have an average of 13 years
professional experience with requirements engineering, and each expert
typically held multiple roles in the projects. The primary roles of the
experts were software development and architecture (28%), business (14%) or
requirements management (14%), project coordination (14%), and technical
product (9%) and infrastructure management (9%). This distribution of roles
reflects the interweaving between functional, quality, and resource aspects in
software projects.

###  3.2 Research Questions

The exploratory case study should help us to answer 3 research questions:

  * •

RQ1 - What elicitation and specification practices for NFRs are used in
industry? This question focuses on the preciseness and granularity of elicited
requirements and how interdependencies between contradicting requirements are
detected.

  * •

RQ2 - What are typical classes of stakeholder interests in software projects?
This question intends to clarify how the different types of NFRs can be
attributed to certain types of stakeholders (e.g., from legal, business or
engineering domains).

  * •

RQ3 - How do requirement engineers rate our approach for modeling and
tailoring stakeholder interests in the context of user tasks? The focus of
this question is to gather feedback from experts particularly regarding the
proposed modeling approach for functional requirements and the methodology for
tailoring stakeholder interests to constraints.

###  3.3 Data Analysis Procedure

The interviews took between 50 and 90 minutes and were performed and
transcribed by one researcher. Subsequently, the interview transcripts were
analyzed by two researchers and the answers to the closed questions were coded
quantitatively. The answers to the open questions where coded in the
transcripts for the later extraction of qualitative data. At that point we did
not categorize the statements to ensure that we do not exclude potentially
important qualitative data at an early stage of analysis (cf. figure 1).

Following, the qualitative statements were categorized conjointly by two
researchers using a grounded theory [28, 29] approach. The objective hereby
was to assign each statement meaningfully to a category and later draw
practical conclusions from the answers. The categories were developed
iteratively and similar statements combined in one category until consensus
was reached among the two researchers. A second senior researcher cross-
checked the process but was not involved in transcribing or coding the
interviews.

From the 11 interviews we extracted a total of 763 statements (68 on average
per interview). After several iterations we condensed 59 categories out of the
qualitative statements expressed in the interviews. Finally, we identified 9
classes of stakeholder interests that best categorize the different objectives
pursued through NFRs. The final classification schema for stakeholder
interests is discussed in section 5.2 and our aggregated findings from
analyzing the interviews are presented in section 5.

##  4 Description of the Approach

Figure 2: The method defines a structured sequence from capturing user tasks
to collecting and tailoring stakeholder interests for the specification of
task-dependent constraints.

The described approach hierarchically decomposes functional blocks of software
into tasks which can be executed by the user. In contrast to eliciting
isolated features, this gives a more comprehensive picture about how these
different functional blocks are related to each other so that the user can
achieve the goal of each task with the software. To facilitate integration and
participation of stakeholders from multiple domains, each step of the method
is repeated until all stakeholders have a sufficient understanding of tasks
and user goals. Figure 2 illustrates the eight steps of the approach, starting
with capturing user tasks and collecting interests.

###  4.1 Capturing User Tasks

1

Elicitation: To elicit tasks, we rely on hierarchical task analysis [6] with
some modifications to carve out the functional scope of the elicited actions.
Hierarchical task analysis breaks down a task into goals, subgoals, plans, and
operations, focusing on the structure and decomposition of the task into a
hierarchy of subtasks in sequential order of tasks so that the goal can be
attained. According to this notion, a task is a sequence of actions that
people perform to attain a goal. The elicitation of tasks in our method
follows a sequential procedure that provides structured guidance to detail the
functional scope and connections between tasks.

  * –

Step 1: Define task under analysis. Which task should be analyzed and what is
its objective? Scope boundaries must be clearly defined prior to analysis,
typically driven by the underlying business model.

  * –

Step 2: Collect data for task analysis. This collection comprises data about
task execution, dependencies between tasks, constraints, and interviewing
subject matter experts or key users.

  * –

Step 3: Determine the overall task goal. This will become the root goal of the
hierarchy, i.e., the starting point for decomposition.

  * –

Step 4: Determine subtasks. The predecessor task goal will then be used to
derive subtasks necessary for achieving the superordinate goal.

  * –

Step 5: Identify task details. Derived from the goal of each subtask, identify
the intentions of the user in attaining the goal and the resulting
responsibilities of the system to support these intentions. We elaborate this
step in more detail below.

  * –

Step 6: Define execution plans. Execution plans organize how to reach the goal
of the task by modeling execution order and dependencies between the subtasks.
The objective is to define how the subtasks relate to each other so that the
goal of the task can be achieved.

While hierarchical task analysis allows infinite refinement of tasks to the
point that tasks are purely operational for a user, our method only allows
refinement of tasks by means of task details tables. This forces the
development team to define the granularity of tasks upfront. If the refinement
is still too vague to be operational, a separate model should be created for
refinement. This assures that tasks and constraints can be properly treated
and described at the refined level.

Figure 3: Meta-model of the approach for specifying task-dependent stakeholder
interests. Figure 4: Modeling Subtasks, System Responsibilities, Information
Objects and Conditional Flows.

For the structured elicitation of task details, our approach offers two
perspectives: (1) user intentions, the user’s interactions during execution of
the task; and (2) system responsibilities to support these user intentions
through the system. Both perspectives are compared with each other in tabular
form and refined with pre- and postconditions, as well as information objects,
which describe the information generated or required for task execution. The
relations between these concepts are defined in the meta-model illustrated in
figure 3. The task detailing step helps to map the fine-grained intentions of
the user to suitable functional requirements by carving out the minimal and
satisfactory technical solution to execute the task effectively.

2

Modeling: In the next step, the control flow and decision points between the
subtasks are modeled. Figure 4 shows an exemplary task of searching for a book
at an online store. This example was also used for presenting our approach in
the expert interviews. Each subtask is modeled as a rectangular gray box
labeled with the corresponding user intention and incorporates one or multiple
rounded rectangles (i.e., system responsibilities) that reflect the required
software functionality. Information objects are denoted by colored rectangles,
with the direction of the arrows indicating whether the information object is
generated or consumed by the respective subtask. The objective of this
modeling is to outline the control flow among the subtasks for all
stakeholders and to facilitate sketching the required software features. In
this work we refer to features as concrete software implementations [30] which
realize the actions that are required to implement a task. Also, the
granularity of the actions executed within a subtask can be chosen arbitrarily
to foster a common understanding of the scope and goal of the features among
the involved stakeholders. In contrast to process modeling, this type of
modeling primarily focuses on the flow among the activities and also relates
them to the technical counterparts needed for their execution. For the sake of
simplicity, we abstain to describe conditional loops or concurrent executions
of subtasks in our modeling approach.

3 Prioritization: Next, only those user tasks are selected for the subsequent
steps, which are most important (following the idea of a minimum viable
product (MVP)), bear a competitive advantage, or have been selected by an
agile team for development in the next program increment. Typically, the
question of importance can only be answered by considering the underlying
business model. Also, the required assessment of the tasks’ value contribution
prevents specifying details or exhaustive constraints for rarely executed
tasks.

###  4.2 Collecting Stakeholder Interests

4

Elicitation: Due to their primary technical focus, the notion of NFRs does not
satisfactorily cover non-technical objectives of stakeholders having an impact
on a software system. This specially comprises all objectives that must be
considered continuously throughout the software lifecycle, from software
development and operation to its decommissioning. Existing classification
schemes [31, 32] for these non-technical objectives, which we understand as
stakeholder interests, also reflect their relevance for software quality and
need for precise specification. These stakeholder interests are still
unsatisfactorily covered by existing, solely technically oriented standards
such as ISO/IEC 29148:2011 [33] or ISO/IEC 25030:2007 [34], which often
results in NFRs being only vaguely elicited.

The objective of this step is to capture all stakeholders’ quality-related,
operational, business, legal, and other non-behavioral interests that
influence how the later software system needs to support the tasks of the
users. We extended existing classification schemes by additional interests,
which we gathered from the expert interviews. This interest classification
schema practically aids the elicitation of the interests and is presented in
section 5.2.

Table 1: Tailoring stakeholder interests: The results from qualitatively
evaluating individual relevance of interests for each user task (task-interest
matrix, left) allow to derive concrete quantitative constraints (task-
constraint matrix, right).

| User Tasks |
---|---|---
|  Search
for book |  Update
credit card
information |  Change shipping address |  Write
book review |
Stakeholder Interests |  The software
must be
responsive to
user inputs. |  |  |  |  |
The software
must handle
peaks of con-
current users. |  |  |  |  |
The software
must be
maintainable
effortlessly. |  |  |  |  |
The software shall be
modularized
into separate
units. |  |  |  |  |
The software
must be
resilient to
external
outages. |  |  |  |  |

User Tasks
---
Search
for book |  Update
credit card
information |  Change
shipping
address |  Write
book review
response time $<$ 2
ms |  response time $<$ 3
ms |  response time $<$ 3
ms |  response time $<$ 4
ms
$>$ 100
users per
minute |  $>$ 100
users per
minute |  $>$ 50
users per
minute |  $>$ 70
users per
minute
technical debt
$<$ 1 day |  technical debt
$<$ 2 days |  technical debt
$<$ 2 days |  technical debt
$<$ 3 days
class fan
out $<$ 10 |  class fan
out $<$ 4 |  class fan
out $<$ 4 |  class fan
out $<$ 10
MTBF
$<$ 1 min |  MTBF
$<$ 1 min |  MTBF
$<$ 5 min |  MTBF
$<$ 10 min

5

Documentation: In this step, the elicited stakeholder interests are documented
informally to express the stakeholders’ objectives and expectations towards
the software system. It is important to document each stakeholder interest in
a manner comprehensible for all involved stakeholders to foster shared
understanding and also to later assess its individual relevance for other
interests. In this step of the method an interest does not need to be
documented on a quantitative basis. The concrete tailoring and deriving of
constraints for each user tasks is done in a subsequent step. Stakeholder
interests can be documented in the following ways:

  * $\bullet$

“The software must be responsive to user inputs.”

  * $\bullet$

“… handle peaks of concurrent users.”

  * $\bullet$

“… be deployable automatically.”

  * $\bullet$

“… recover quickly after outages.”

  * $\bullet$

“… be operated in the cloud.”

  * $\bullet$

“In-Transit customer data must be encrypted.”

Our method explicitly separates interest elicitation from documentation. The
former being conducted by all stakeholders in a brainstorming like manner
striving to unveil as many possibly relevant interests that could impact the
software lifecycle; the latter just to document the results from the
elicitation step.

###  4.3 Tailoring Stakeholder Interests

6

Refinement: Similar to the refinement of user tasks, also stakeholder
interests are iteratively refined until they show a delimited and
comprehendible scope for the later tailoring. Refined stakeholder interests
again are documented conjointly with the relevant stakeholders. This is done
to cross-check that there is common understanding about the interest even
after its refinement. Stakeholder interests which are too large in scope are
decomposed up to a suitable level. The overall objective of this step is to
prevent ambiguities about an interest’s scope among the stakeholders. Uniform
comprehension about the scope of an interest is the prerequiste for its
effective tailoring and the specification of suitable constraints therefore.

7

Tailoring: In this step, the stakeholder interests and user tasks are analyzed
pairwise to evaluate the relevance of an interest and how it can be satisfied
in each narrow task context. This detailed analysis also assures that all
elicited stakeholder interests eventually are made operational for software
engineers at the level of individual user tasks.

Stakeholder interests and user tasks are then related to each other in a two-
dimensional task-interest matrix. Following, each interest is tailored
individually to each user task so that it can be fulfilled exactly for the
respective user task. Resulting from this tailoring is a qualitative ordering
of the cells indicating the relevance of the interest for the respective user
task, e.g., through coloring cells darker gradually with relevance.

This qualitative ordering is shown on the left side of table 1. It also shows
that at that point of the method no quantitative fulfillment criteria for the
stakeholder interests are defined. The focus of this step is on getting a
common understanding about the relevance of an interest for a particular user
task. As a practical example, the interest that “the software must be
responsive to user inputs” might be subjected to different qualitative
expectations depending on the concrete user task. Responsiveness might be much
more important for a user when searching for a book than when writing a book
review, but less important when changing the shipping address. As an example
from the perspective of the software manufacturer, the interest “the software
shall be modularized into separate units.” is important when changing credit
card information or the shipping address of the customer. These two tasks are
part of the billing process and thus the associated source code need to be
better modularized than for other tasks.

Analyzing these interests outside the context of individual user tasks
neglects the fact that some tasks are more important than others and thus need
more attention. The fulfillment of interests typically requires intertwining
multiple teams, e.g., requirements engineering and DevOps teams. This even
more emphasizes the need to evaluate its relevance conjointly with all
relevant stakeholders in the narrow context of a user task. Also, stakeholder
interests evaluated with little relevance for multiple user tasks should be
revised as this indicates ambiguities regarding its scope or its actual
irrelevance.

###  4.4 Specifying Constraints

8

Specification: In the last step of our method, the matrix created in the last
step serves as input for eventually specifying concrete constraints. These
constraints are specified individually for each user task to satisfice the
stakeholder interests. Hence, when specifying concrete constraints the
objective is to fulfill the stakeholder interests satisfactorily and not
optimally, so that a majority of stakeholder interests can be fulfilled.

The previous qualitative evaluation of individual relevance of an interest for
a user task helps to find concrete metrics and criteria for specifying the
constraints. Ideally, one should start with determining metrics and values for
the most relevant user task for a stakeholder interest. Taking the example
illustrated in table 1, the task to search for a book needs to be specially
responsive. Determining the response time as metric and measurements of below
2 milliseconds as being very responsive, the other constraints can be derived
thereof straightforwardly. This procedure is repeated until

  * •

for each cell in the matrix there is a concrete constraint defined, or
alternatively

  * •

the stakeholders agree the interest is of little relevance for a certain user
task and does not need to be specified.

Table 1 shows the transition from the qualitative evaluation of the interests’
relevance (left) into concrete constraints for each user task (right). The
main outcome of this step is a 2-dimensional task-constraint matrix
incorporating user tasks, stakeholder interests and constraints consolidated
between the involved stakeholders.

##  5 Case Study Results

In this section we present selected results that we extracted from the
interview transcripts. The concrete research context and design of the case
study is described in section 3. We group our findings correspondingly to the
research questions. Verbal statements from the interviews are italized and
reflect the given answer of the expert without our interpretation.

###  5.1 Practice of Eliciting and Specifying Non-Functional Requirements

The first research question addresses the elicitation and specification
practices for NFRs in the interviewees’ companies. Hereby we carve out the
current state of practice in the companies to derive possible directions for
improvements through our approach. We asked the experts 3 questions to find
out

  * •

which methods they use to elicit NFRs, and

  * •

how precise they elicit certain categories of NFRs, and

  * •

how they detect contradicting NFRs during requirements engineering.

Figure 5: Practice of NFR elicitation in the interviewed companies.

As shown in figure 5, in 72% of the companies, NFRs are elicited through
informal meetings, i.e., without any structured method or checklist. The
respective experts explained that their companies usually abstain from
eliciting NFRs during requirements engineering. This is because their
companies are convinced that “…the engineers know what it should work like”
and because they “…have always done it that way”. In 27% of the companies,
NFRs are elicited based on predefined templates of best-practices. While these
templates do not specify concrete constraints or measures how to evaluate the
fulfillment of NFRs, they provide blueprints how to generically handle them
during software development. Industry-best practices, i.e., commercial
templates for generic specification of NFRs are used in 18% of the interviewed
companies. Only in 9% of companies, NFRs are elicited collaboratively in a
brainstorming like manner and tailored to an individual software project.

In another question we asked the experts how precisely security,
maintainability, performance, portability and reliability requirements are
defined in their companies using concrete quantitative measures. As can be
depicted from figure 6, security and maintainability requirements are most
precisely defined in the interviewed companies. The preciseness of performance
and portability requirements are a minor interest for these companies.
Reliability requirements are mostly not specified at all. The respective
experts argues that their companies “…rely on the middleware to ensure this.”

Figure 6: Preciseness of NFR specification in the interviewed companies.

It can be summarized that security and maintainability requirements are
specified in most interviewed companies. On the other hand, runtime
characteristics such as performance, portability, and reliability are
specified either unprecise or not specified at all.

###  5.2 Classification of Stakeholder Interests

The second research question examines how the different types of NFRs that
typically arise in the projects can be condensed into a classification schema
for stakeholder interests. The objective hereby is to identify classes of
similar interests which are common for specific types of stakeholders (e.g.,
from the legal, business or engineering domain). This classification schema
provides a structure for eliciting the stakeholder interests in the respective
step of our method (cf. section 4.2).

Based on existing taxonomies for NFRs of Chung et al. [21], Roman [35], and
Sommerville [36] we initially categorized the answers of the experts into 12
classes of stakeholder interests. We only included those classes of
stakeholder interests which have at least been mentioned by one of the experts
as being relevant. This is due to the experience of the experts that some
interests are practically more important than others.

After an additional refinement step we condensed these stakeholder interests
into 9 classes according to the following classification schema:

  * •

Interface interests come in two flavors:

    * –

User interface interests concern how the system should interact with users.
This especially affects the users’ interaction device (e.g., mobile apps,
desktop applications) and the modality of the interaction (e.g., through
virtual or physical keyboards, gesture-based or motion-controlled
interactions).

    * –

Application interface interests address the user’s interactions with other
systems during execution of a task. These interests especially concern the
peculiarities of other systems, for example in terms of network protocols,
transaction management, or data formats.

  * •

Informational interests denote objectives regarding the visual and semantic
expression that must be taken into account when presenting information to the
user. These interests typically arise when the prospective user groups of the
software process information differently, such as e.g., elderly users and
digital natives or users of different cultures. Also, these interests address
accessibility aspects aiming on the inclusion of people with disabilities.

  * •

Behavioral interests describe how the system shall behave under normal and
exceptional conditions. These interests primarily address time-based response
behavior, resource utilization (e.g., bandwidth or memory utilization),
reliability, availability, confidentiality, and ability to cope with
catastrophes or unplanned service outages.

  * •

Operating interests focus on how the later solution shall be deployed,
monitored, and operated. These typically address cloud-service provisioning or
virtualization, the use of application servers and operating systems,
networks, and access to physical IT systems.

  * •

Human interests cover motivational aspects and special skills of users and
DevOps teams required for operating the software.

  * •

Lifecycle interests address how the software system should align with project
management methodologies and engineering standards to assure its
maintainability, comprehensibility, and portability throughout its lifecycle.

  * •

Economic interests align the software system with the business model, revenue
streams, and performance indicators. These interests typically are derived
from make-or-buy and product strategy decisions.

  * •

Data governance interests delineate how data should be processed and stored
among the systems which are involved in task execution in order to facilitate
data backtracking, governance, and updating.

  * •

Legal and policy interests address how policies and legal issues, e.g.,
privacy and copyright liabilities, data export prohibitions (e.g., embargoed
countries), and commercial and fiscal laws can be obeyed. They also capture
implications of the commercial use of open-source licensed software or source-
code ownership restrictions arising from the intellectual property rights of
software developers.

###  5.3 Task-Oriented Modeling of Functional Requirements and Tailoring of
Stakeholder Interests

In the frame of the third research question we performed an evaluation of our
task-oriented modeling and interest tailoring approach through expert
interviews in the different companies.

####  5.3.1 Applicability of the Task-Oriented Modeling Approach

The interviews included six questions to evaluate the applicability of our
task-oriented modeling approach for different objectives, identify benefits,
and weaknesses and determine whether the experts would use this approach in
their projects. First, we presented each expert a sample set of user tasks and
task details for a well-known online book store and described how these
concepts would be modeled and interlinked in our approach. Then, we asked them
whether the combined display of tasks, information objects, control flows, and
implementation endpoints (cf. figure 4) would help them to:

  * $\bullet$

understand the utility of the task for the user;

  * $\bullet$

detect missing but critical functionality to achieve the user’s goal; and

  * $\bullet$

prioritize tasks by provided utility, for example to sketch a minimum viable
product (MVP).

Figure 7: Applicability of the task-oriented modeling approach for selected
objectives.

As depicted in figure 7, the experts responded positively that our approach
helps them to understand the provided utility and goal of each task for the
user and also to detect whether critical functionality is missing for the goal
to be attained. The decomposition of the superordinate user goal into tasks
and subtasks in particular fosters intuitive understanding of what objectives
are attained through the user and what is required from an engineering
perspective to implement the task.

While 73% of the experts rated the approach applicable or rather applicable to
prioritize tasks according to the provided utility for the user, 18% rated it
applicable for this purpose. Our approach, however, does not aim to support
task prioritization but rather assumes that tasks have already been selected,
for example based on the feature set of the MVP.

The experts were also asked if any additional modeling elements would be
necessary for them to use the approach in their projects. Among their answers,
most frequently mentioned were the requirements for demarking user roles and
labeling tasks with tags along with better support for describing exceptions
and the interdependences among tasks and user-interface elements.

Next, we asked the experts to rate our concept of information objects to
explicate information that is consumed or generated during execution of a user
task. While all experts argued that information objects support them to model
task-related information, they see different benefits associated with them.
Automated generation of domain objects has been mentioned by 44% of the
experts. They summarized that when adhering to a formal modeling standard such
as UML, domain objects can be generated with little effort. Explicating
implicit domain knowledge, which is often only poorly documented, has been
mentioned as a benefit by 22% of the experts. A share of 17% of experts argued
that information objects would help them to better understand functional
requirements as they always depend on each other. Facilitating the evaluation
of implementation feasibility was highlighted by 11% of the experts. They
argued that information objects help them to more easily detect
interdepencencies and obstacles between requirements. In the same line of
argumentation, 5% of experts stressed that information objects are specially
beneficial to resolve data dependencies between functional requirements.

Figure 8: Benefits of information objects for task-oriented modeling of
functional requirements.

####  5.3.2 Suitability of the Task-Oriented Modeling Approach

Finally, the experts were asked to rate the suitability of the approach for
modeling functional requirements, again on a 4-point Likert scale, and to
justify their answers.

Figure 9: Suitability of the task-oriented modeling approach.

Figure 9 illustrates that the answers gave a clear picture of the approach’s
suitability, as all experts positively rated our approach as either suitable
(64% of experts) or rather suitable (36% of experts). No responses indicated
that the approach could not be applied in practice. Next, the experts were
asked to elaborate the benefits and weaknesses of the approach. They argued
that especially due to the granularity and focus on user tasks, the main
benefits of the approach include:

  * $\bullet$

fostering shared understanding of functional requirements among stakeholders
especially across domains;

  * $\bullet$

easier and more precise structuring of the functional scope compared to e.g.,
user stories or epics;

  * $\bullet$

additional guidance for eliciting functional requirements through the
structured decomposition of goals into tasks and subtasks.

Concerning the weaknesses of the method, 27% of the experts recognized no
weaknesses for the practical introduction of the method. We codified the open
answers of the 73% experts naming weaknesses, summarizing their statements as
follows. 34% responded that, as with every structured method, our approach
requires knowledge of how to use it effectively in projects. The experts also
assumed that the method would require only little training time for its
practical introduction, due to its simplicity. The additional maintenance
effort to adapt diagrams to changing requirements was expressed as a weakness
by 22% of the experts, and the complexity of the model elements was also
mentioned by 22% of the experts. Flexibility and additionally introduced
complexity were each mentioned by 11% of the experts.

Before asking the experts to rate our approach, we presented them a selection
of tasks from a well-known online book store and a list of generally
understandable performance, privacy, and legal interests (cf. section 4.2).
Then, we illustrated how these interests can be used in our approach to derive
constraints on the level of user tasks. Finally, we asked the experts 4
questions to evaluate our method for tailoring these interests in the context
of individual user tasks.

####  5.3.3 Suitability of the Interest-Tailoring Approach

The experts were asked to rate the overall suitability of the approach on a
4-point Likert scale. Again we received predominantly positive feedback, with
55% experts judging the approach as suitable and 36% as rather suitable. The
9% of experts judging the approach as rather unsuitable argued that a precise
and comprehensive specification of constraints from interests should only be
done for selected features and not on the level of user tasks. No expert
judged the interest tailoring approach as unsuitable for their projects.

####  5.3.4 Benefits and Weaknesses of the Interest-Tailoring Approach.

Finally, we asked the experts 2 open questions to elaborate the benefits of
our interest tailoring approach on the level of user tasks. We condensed their
answers to these questions into 8 categories. Increased comprehensibility of
the system was expressed as a benefit by 82% of the experts, namely by
increasing the clarity of objectives pursued through an interest. In 55% of
the interviews, the experts mentioned the increased specification quality of
constraints derived from interests, and 36% said it would help them to assess
project risks by better understanding interests and their interdependencies.

In 18% of interviews, experts expressed the prioritization of interests, the
time savings accrued by deriving constraints from interests, and the ease of
documentation as benefits of the approach. Only 9% of experts mentioned that
our approach could also help them to detect critical paths. Based on the open
answers examining the weaknesses, we codified the experts’ answers into 3
groups. 45% of experts believed that the approach would introduce an
additional specification effort but also expressed that the expected benefits
outweighed these tradeoffs accompanying any structured method. 27% of experts
mentioned the complexity of the approach as a drawback, and a further 18%
anticipated that our approach would result in explicitly specifying standard
industry constraints that usually need no special documentation (e.g., a
default availability, common security requirements).

##  6 Threats to Validity

We see a threat to construct validity in the different interpretations of the
questions by the experts, which is mainly due to their different roles and
experiences. We addressed this threat by showing each expert concrete
definitions of the terminology used in the interview and discussed any
ambiguities. When summarizing the interview answers, we also considered the
background and role of each expert to determine from what view and with what
intention the statement was given. Also, as the objective of the interviews
conducted in our exploratory case study was on gathering feedback for
methodological improvement of the method, a further empirical validation is
necessary after the experts have applied our method.

The foremost threat to internal validity can be seen in some experts’ trend to
answer in confirmation of our theories, which became evident when elaborating
on the practice of eliciting constraints. This could have led to confirmation
bias, but we regard this as negligible because in response to this trend to
answer towards confirming our theories, we asked follow-up questions to
capture the experts’ actual experiences.

We addressed the threat to external validity by selecting experts who operate
in different industry sectors, and we also selected only one expert per
company. However, we see a threat to the generalizability of the results to
other industries due to the different size and maturity of requirements
engineering practices in the companies. Also, an empirical validation of the
approach needs to be conducted to gather empirical evidence about the
generalizability of the results.

##  7 Conclusion and Future Work

Utilizing the proposed hierarchical task analysis approach to structurally
decompose tasks into subtasks seems to offer a promising approach to clarify
the core functionality needed to support the users’ goals for involved
stakeholders. Stakeholder interests can be effectively tailored to constraints
within the context of a user task so that each interest can be fulfilled in a
satisfying but not inevitably optimal way. Our approach explicitly addresses
challenges arising from both the heterogeneity of stakeholder interests and
the interdependences between functional requirements and NFRs in software
systems.

We have focused our exploratory case study on the elicitation practice and
specification preciseness of NFRs in the companies. The main objective of this
research design was to effectively address the issues and challenges gathered
from the expert interviews in our method. Together with an industry partner we
are currently planning an empirical validation of the approach to ensure the
generalizability and the applicability of the results in an industrial
context.

Future work shall concentrate on ensuring scalability of the method for large-
scale software engineering projects. Also, we are currently defining an
operational quality model for specifying the constraints of the task-
constraint matrix using concrete measures. Along with suitable instruments
that operationalize these measures this allows to automatically monitor
fulfillment of stakeholder interests throughout the DevOps cycle.

## Bibliography

  * [1] Philipp Haindl and Reinhold Plösch  “Tailoring and Evaluating Non-Functional Interests Towards Task-Oriented Functional Requirements” accessed 2022/01/15  In _Combined Proceedings of the Workshops at Software Engineering 2020 Co-located with the German Software Engineering Conference 2020 (SE 2020)_ 2581, 2020  URL: http://ceur-ws.org/Vol-2581/aesp2020paper1.pdf
  * [2] Philipp Haindl, Reinhold Plösch and Christian Körner  “A Research Preview on TAICOS - Tailoring Stakeholder Interests to Task-Oriented Functional Requirements”  In _Requirements Engineering: Foundation for Software Quality_ , LNCS 11412  Essen, Germany: Springer Nature Switzerland, 2019, pp. 1–7  DOI: 10.1007/978-3-030-15538-4_22
  * [3] Didar Zowghi and Chad Coulin  “Requirements Elicitation: A Survey of Techniques, Approaches, and Tools”  In _Engineering and Managing Software Requirements_ Berlin, Heidelberg: Springer Berlin Heidelberg, 2005, pp. 19–46  DOI: 10.1007/3-540-28244-0_2
  * [4] J.. Blaine and J. Cleland-Huang  “Software Quality Requirements: How to Balance Competing Priorities”  In _IEEE Software_ 25.2, 2008, pp. 22–24  DOI: 10.1109/MS.2008.46
  * [5] Patrik Berander and Anneliese Andrews  “Requirements Prioritization”  In _Engineering and Managing Software Requirements_ Berlin, Heidelberg: Springer, 2005, pp. 69–94
  * [6] John Annett  “Hierarchical Task Analysis”  In _The Handbook of Task Analysis for Human-Computer Interaction_ London, UK: Taylor & Francis, 2003, pp. 67–82
  * [7] A. Gehmeyr et al.  “Computer-Implemented Product Development Method” US Pat. No. 15/661,498, 2018
  * [8] A. Lamsweerde  “Goal-oriented requirements engineering: a guided tour”  In _Proceedings Fifth IEEE International Symposium on Requirements Engineering_ , 2001, pp. 249–262  DOI: 10.1109/ISRE.2001.948567
  * [9] Colette Rolland and Camille Salinesi  “Modeling Goals and Reasoning with Them”  In _Engineering and Managing Software Requirements_ Berlin, Heidelberg: Springer Berlin Heidelberg, 2005, pp. 189–217  URL: https://doi.org/10.1007/3-540-28244-0_9
  * [10] Soren Lauesen and Mohammad A. Kuhail  “Task descriptions versus use cases”  In _Requirements Engineering_ 17.1, 2012, pp. 3–18  URL: https://doi.org/10.1007/s00766-011-0140-1
  * [11] F. Fotrousi, S.. Fricker and M. Fiedler  “Quality requirements elicitation based on inquiry of quality-impact relationships”  In _2014 IEEE 22nd International Requirements Engineering Conference (RE)_ , 2014, pp. 303–312  DOI: 10.1109/RE.2014.6912272
  * [12] Norman Riegel and Joerg Doerr  “A Systematic Literature Review of Requirements Prioritization Criteria”  In _Requirements Engineering: Foundation for Software Quality_ Springer, Cham, 2015, pp. 300–317  DOI: 10.1007/978-3-319-16101-3_22
  * [13] Lena Karlsson et al.  “Requirements engineering challenges in market-driven software development – An interview study with practitioners”  In _Qualitative Software Engineering Research_ 49.6, 2007, pp. 588–604  DOI: 10.1016/j.infsof.2007.02.008
  * [14] B. Regnell, R.. Svensson and T. Olsson  “Supporting Roadmapping of Quality Requirements”  In _IEEE Software_ 25.2, 2008, pp. 42–47  DOI: 10.1109/MS.2008.48
  * [15] J. Cleland-Huang et al.  “Goal-centric traceability for managing non-functional requirements”  In _Proceedings. 27th International Conference on Software Engineering, 2005. ICSE 2005._ , 2005, pp. 362–371  DOI: 10.1109/ICSE.2005.1553579
  * [16] Andrea Herrmann, Daniel Kerkow and Joerg Doerr  “Exploring the Characteristics of NFR Methods – A Dialogue About Two Approaches”  In _Requirements Engineering: Foundation for Software Quality_ Springer, Berlin, Heidelberg, 2007, pp. 320–334  DOI: 10.1007/978-3-540-73031-6_24
  * [17] Jose Zubcoff et al.  “Evaluating different i*-based approaches for selecting functional requirements while balancing and optimizing non-functional requirements: A controlled experiment”  In _Information and Software Technology_ 106, 2019, pp. 68–84  DOI: 10.1016/j.infsof.2018.09.004
  * [18] D. Ameller, X. Franch and J. Cabot  “Dealing with Non-Functional Requirements in Model-Driven Development”  In _2010 18th IEEE International Requirements Engineering Conference_ , 2010, pp. 189–198  DOI: 10.1109/RE.2010.32
  * [19] D. Ameller et al.  “Dealing with Non-Functional Requirements in Model-Driven Development: A Survey”  In _IEEE Transactions on Software Engineering_ , 2019, pp. 1–1  DOI: 10.1109/TSE.2019.2904476
  * [20] Richard Berntsson Svensson, Tony Gorschek and Björn Regnell  “Quality Requirements in Practice: An Interview Study in Requirements Engineering for Embedded Systems”  In _Requirements Engineering: Foundation for Software Quality_ , Lecture Notes in Computer Science  Springer Berlin Heidelberg, 2009, pp. 218–232
  * [21] Lawrence Chung and Julio Cesar Prado Leite  “On Non-Functional Requirements in Software Engineering”  In _c_ Berlin, Heidelberg: Springer, 2009, pp. 363–379
  * [22] L. Chung, B.A. Nixon, E. Yu and J. Mylopoulos  “Non-Functional Requirements in Software Engineering” 5, International Series in Software Engineering  Springer US, 2000
  * [23] J. Doerr et al.  “Non-functional requirements in industry - three case studies adopting an experience-based NFR method”  In _13th IEEE International Conference on Requirements Engineering (RE’05)_ , 2005, pp. 373–382  DOI: 10.1109/RE.2005.47
  * [24] Maya Daneva, Luigi Buglione and Andrea Herrmann  “Software Architects’ Experiences of Quality Requirements: What We Know and What We Do Not Know?”  In _Requirements Engineering: Foundation for Software Quality_ , Lecture Notes in Computer Science  Springer Berlin Heidelberg, 2013, pp. 1–17
  * [25] Michael Vierhauser, Rick Rabiser and Paul Grünbacher  “A Case Study on Testing, Commissioning, and Operation of Very-large-scale Software Systems” event-place: Hyderabad, India  In _Companion Proceedings of the 36th International Conference on Software Engineering_ , ICSE Companion 2014  New York, NY, USA: ACM, 2014, pp. 125–134  DOI: 10.1145/2591062.2591179
  * [26] Per Runeson and Martin Höst  “Guidelines for conducting and reporting case study research in software engineering”  In _Empirical Software Engineering_ 14.2, 2009, pp. 131–164  DOI: 10.1007/s10664-008-9102-8
  * [27] Robert K. Yin  “Case Study Research and Applications: Design and Methods”  Los Angeles: SAGE Publications, Inc, 2017
  * [28] Steve Adolph, Wendy Hall and Philippe Kruchten  “Using grounded theory to study the experience of software development”  In _Empirical Software Engineering_ 16.4, 2011, pp. 487–513  DOI: 10.1007/s10664-010-9152-6
  * [29] Barney Glaser and Anselm Strauss  “The Discovery of Grounded Theory: Strategies for Qualitative Research”  New Brunswick: Routledge, 2000
  * [30] Pierre Bourque and Richard E. Fairley  “Guide to the Software Engineering Body of Knowledge”  Los Alamitos, CA, USA: IEEE Computer Society Press, 2014
  * [31] Martin Glinz  “Rethinking the notion of non-functional requirements”  In _Proceedings of the Third World Congress for Software Quality (3WCSQ 2005)_ 2, 2005, pp. 55–64
  * [32] M. Broy  “Rethinking Nonfunctional Software Requirements”  In _Computer_ 48.5, 2015, pp. 96–99  DOI: 10.1109/MC.2015.139
  * [33] “ISO/IEC/IEEE International Standard - Systems and software engineering – Life cycle processes –Requirements engineering”  In _ISO/IEC/IEEE 29148:2011(E)_ , 2011, pp. 1–94  DOI: 10.1109/IEEESTD.2011.6146379
  * [34] “ISO/IEC/IEEE 25030:2007 International Standard - Software product Quality Requirements and Evaluation (SQuaRE) - Quality requirements” (accessed 2022/01/15)  In _25030:2007_ , 2018  URL: https://www.iso.org/standard/35755.html
  * [35] Roman  “A taxonomy of current issues in requirements engineering”  In _Computer_ 18.4, 1985, pp. 14–23  DOI: 10.1109/MC.1985.1662861
  * [36] Ian Sommerville  “Software Engineering”  Pearson, 2016


# Holographic Entanglement Entropy in $T\bar{T}$-deformed CFTs

M. R. Setare , S. N. Sajadi
Department of Science, Campus of Bijar, University of Kurdistan, Bijar, Iran
Electronic address<EMAIL_ADDRESS>address<EMAIL_ADDRESS>
###### Abstract

In this work, we study the holographic entanglement entropy of two dimensional
$T\bar{T}$-deformed conformal field theory. We compute the correction due to
the deformation up to the leading order of the deformation parameter in the
framework of New massive gravity, General minimal massive gravity, and Exotic
general massive gravity. We also apply Song’s prescription to obtain the
entanglement entropy for deformed theories. In each cases, we find agreement
between the results.

##  1 Introduction

Holographic conjecture is one of the powerful tools to study quantum gravity,
in which the quantum gravity in $d$ spacetime dimension is equivalent to a
quantum field theory on $d-1$ dimensions boundary. An important example is a
holographic duality between conformal field theory in $d$ dimension and
$(d+1)$-dimensional AdS gravity [1]-[3]. Conformal field theory is by
definition a UV complete framework, in which the rules of local quantum field
theory apply at all energy scales. CFTs, are critical points of RG flows. It
is then natural to ask: can holography be extended to effective QFTs for which
the UV behavior is not described by a CFTs? In the context of AdS3/CFT2, this
the question has been answered by Zamolodchikov [4] by considering a general
class of exactly solvable irrelevant deformations of 2D CFT. In [5] proposed
that in the holographic dual, this deformation represents a geometric cut-off
on a wall at finite radial distance $r=r_{c}$ in the bulk that removes the
asymptotic region of AdS and places the QFT on it. More precisely if a CFT has
a gravity dual, then the deformed theory is dual to the original gravitational
theory with the new boundary at $r=r_{c}$. In this paper following the papers
[6] and [7] we would like to understand the effect of this deformation on
entanglement entropy using holography in the framework of higher derivative
massive gravity in $2+1$ dimensions.
Because of the absence of local degrees of freedom, General Relativity (GR) in
three dimensions is an easier theory for studying the different aspects of
gravity. New Massive Gravity(NMG) is a three-dimensional theory of gravity
with parity-even, higher derivative action which at the linearized level
reduces to massive spin-two Fierz-Pauli theory [8], [9].
General Minimal Massive Gravity (GMMG) which was introduced in [10], is an
example of the 3D theory of gravity with actions that makes use of two
auxiliary one-forms, $h$ and $f$, which at the level of the field equations
can be integrated out, leading to the New Massive Gravity field equations
supplemented by the Cotton tensor and by a parity even tensors, $J_{ab}$. This
term with respect to the curvature is quadratic, and therefore the field
equations for the metric remain of fourth-order. These effective Einstein
equations cannot be obtained only from a variational principle of the metric
as a dynamical field, nevertheless, they are on-shell consistent as it is the
case in the theories introduced in [11], [12], [13] and [14]. GMMG avoids the
bulk-boundary clash and therefore possesses positive energy excitations around
the maximally AdS3 vacuum as well as a positive central charge in the dual
CFT. Such problem in the previously constructed gravity theories with local
degrees of freedom in 2+1-dimensions namely Topologically Massive Gravity and
the cosmological extension of New Massive Gravity is present [8], [15], [16].
Exotic general massive gravity is another 3D theory of gravity with
parity$-$odd action which describes a propagating massive spin$-$2 fields. The
field equations of this theory supplement the Einstein equations with a term
that contains up to 3rd of the metric and is built with combinations and
derivatives of the Cotton tensor [13]. The different aspects of this model
have been studied in [17], [18], [19], [20], [21], [22].

The paper is organized as follows: In section 2, we obtained the entanglement
entropy for NMG with parity even action, directly by using on-shell action and
using the RT-method. In section 3, for the other Chern-Simons like theories of
gravity GMMG and EGMG we obtain the entanglement entropy and repeat the
procedure of previous section for them. We provide some conclusions in Section
4.

##  2 Entanglement Entropy for NMG

Among massive gravity models in three dimensions, a well known one is that of
the new massive gravity. This model is equivalent to the three-dimensional
Fierz-Pauli action for a massive spin$-2$ field at the linearized level. In
addition, NMG preserves parity symmetry which is not the case for the
topological massive gravity (TMG). The action of NMG is presented as follows

$S_{NMG}=\dfrac{1}{8\pi G}\int
d^{3}x\sqrt{-g}\left[R-2\lambda-\dfrac{1}{m^{2}}(R^{\mu\nu}R_{\mu\nu}-\dfrac{3}{8}R^{2})\right]$
(1)

where $\lambda$ and $M$ are the cosmological constant and the parameter of
NMG, respectively. By a variation of the Lagrangian we obtain

$E_{\mu\nu}=G_{\mu\nu}+\lambda g_{\mu\nu}-\dfrac{1}{2m^{2}}N_{\mu\nu},$ (2)

with

$\displaystyle
N_{\mu\nu}=-\dfrac{1}{2}\nabla^{2}Rg_{\mu\nu}-\dfrac{1}{2}\nabla_{\mu}\nabla_{\nu}R+2\nabla^{2}R_{\mu\nu}+4R_{\mu
a\nu
b}R^{ab}-\dfrac{3}{2}RR_{\mu\nu}-R_{\alpha\beta}R^{\alpha\beta}g_{\mu\nu}+\dfrac{3}{8}R^{2}g_{\mu\nu},$
(3)

and $G_{\mu\nu}$ is the Einstein tensor. To obtain the renormalized action we
should add the generalized Gibbons-Hawking boundary term for NMG and the
counter-term to the action (1) as follows

$S_{GH}=\int
d^{2}x\sqrt{-\gamma}\left(2K+\hat{f}^{ab}K_{ab}-\hat{f}K\right),\;S_{ct}=\left(1+\dfrac{1}{2m^{2}l^{2}}\right)\int
d^{2}x\sqrt{-\gamma}(1+\delta^{2}\kappa(z,\bar{z})).$ (4)

where

$\displaystyle K_{\mu\nu}$
$\displaystyle=-\dfrac{1}{2}(n_{\mu;\nu}+n_{\nu;\mu}),\;\gamma^{\mu\nu}=g^{\mu\nu}-n^{\mu}n^{\nu},\;\hat{f}^{ab}=f^{\mu\nu}\gamma_{\mu}{}^{a}\gamma_{\nu}{}^{b}\;f_{\mu\nu}=\dfrac{2}{m^{2}}\left(R_{\mu\nu}-\dfrac{1}{4}Rg_{\mu\nu}\right).$
(5)

Now, let us consider a deformed CFT on manifold $\mathcal{M}$. The
entanglement entropy is given by

$S_{EE}=\lim_{n\to 1}\dfrac{1}{1-n}\log\frac{Z_{n}}{Z^{n}}$ (6)

where $Z_{n}$ is the partition function on $\mathcal{M}^{n}$ which is obtained
by using the replica method in which one should prepare $n$ copies of the
manifold on which the original field theory lives and gluing them together.

We start with the deformed CFT defined on the boundary metric in two
dimensions with complex coordinates ($x,\bar{x}$) to cover this surface as

$ds^{2}=dxd\bar{x}.$ (7)

By using the following transformation of the coordinates one can convert the
metric to a conformal form as

$y=\left(\dfrac{x-a}{x-b}\right)^{\frac{1}{n}}$ (8)

then

$ds^{2}=e^{\phi(y,\bar{y})}dyd\bar{y},\;\;\;\;\;\;e^{\frac{\phi(y,\bar{y})}{2}}=nl\dfrac{|y|^{n-1}}{|y^{n}-1|^{2}}$
(9)

where $\phi$ is the Liouville field. One can construct the bulk spacetime
associated to the boundary metric (9) by using the Fefferman-Graham metric
[23]

$ds^{2}=\dfrac{d\rho^{2}}{4\rho^{2}}+\dfrac{1}{\rho}g_{ij}(\rho,X)dX^{i}dX^{j},\;\;\;\;g_{ij}(\rho,X)=g_{ij}^{(0)}(X)+\rho
g_{ij}^{(1)}(X)+...$ (10)

here $X^{i}=(y,\bar{y})$ and $g^{(0)}_{ij}=e^{\phi}dyd\bar{y}$. So the bulk
metric can be written as follows [24]

$ds^{2}=\dfrac{d\rho^{2}}{4\rho^{2}}+\dfrac{1}{\rho}e^{\phi}dyd\bar{y}+\dfrac{1}{2}T_{\phi}dy^{2}+\dfrac{1}{2}\bar{T}_{\phi}d\bar{y}^{2}+\dfrac{1}{4}R_{\phi}dyd\bar{y}+\dfrac{1}{4}\rho
e^{-\phi}(T_{\phi}dy+\dfrac{1}{4}R_{\phi}d\bar{y})(\bar{T}_{\phi}d\bar{y}+\dfrac{1}{4}R_{\phi}dy)$
(11)

where

$R_{\phi}=4\partial_{y}\bar{\partial}_{y}\phi,\;\;\;\;T_{\phi}=\partial^{2}_{y}\phi-\dfrac{1}{2}(\partial_{y}\phi)^{2},\;\;\;\;\;\bar{T}_{\phi}=\bar{\partial}^{2}_{y}\phi-\dfrac{1}{2}(\bar{\partial}_{y}\phi)^{2}.$
(12)

The following coordinate transformations [25]

$\xi=\sqrt{\dfrac{e^{\phi}}{\rho}}+\dfrac{1}{4}\sqrt{\dfrac{\rho}{e^{\phi}}}|\partial_{y}\phi|^{2},\;\;\;\;z=y+\dfrac{1}{2}\dfrac{\rho
e^{\phi}\bar{\partial}_{y}\phi}{1+\dfrac{1}{4}\rho
e^{-\phi}|\partial_{y}\phi|^{2}}$ (13)

convert the FG coordinate to the Poincare coordinate, which brings us to the
following metric

$ds^{2}=\dfrac{d\xi^{2}}{\xi^{2}}+\xi^{2}dzd\bar{z}.$ (14)

This metric is a solution for NMG if

$\lambda=-\left(1+\dfrac{1}{4m^{2}}\right).$ (15)

The NMG on-shell action is given by

$S_{NMG}=\left(1+\dfrac{1}{2m^{2}}\right)\left[-\dfrac{1}{\delta^{2}}\iint
e^{\phi}dzd\bar{z}-\dfrac{1}{2}\iint\psi
dzd\bar{z}-\dfrac{\delta^{2}}{16}\iint e^{-\phi}\psi^{2}dzd\bar{z}\right]$
(16)

here we assumed $\rho=\delta^{2}$, then the regulator surface is

$\xi_{f}=\dfrac{1}{\delta}e^{\frac{\phi}{2}}+\dfrac{\delta}{4}e^{-\frac{\phi}{2}}\psi.$
(17)

While on the boundary
$n^{\mu}=\xi\delta^{\mu}_{\xi},\gamma=-\xi^{4}/4,g=-\xi^{2}/4$ and
$K=\gamma^{ab}K_{ab}=2$ one can get the Gibbons-Hawking term and the counter
term as

$S_{GH}=\left(1+\dfrac{1}{2m^{2}}\right)\left[\dfrac{2}{\delta^{2}}\iint
e^{\phi}dzd\bar{z}+\iint\psi dzd\bar{z}+\dfrac{\delta^{2}}{8}\iint
e^{-\phi}\psi^{2}dzd\bar{z}\right],$ (18)

and

$S_{ct}=-\left(1+\dfrac{1}{2m^{2}}\right)\left[\dfrac{1}{\delta^{2}}\iint
e^{\phi}dzd\bar{z}+\iint\dfrac{1}{2}\psi+\kappa(z,\bar{z})e^{\phi(z,\bar{z})}dzd\bar{z}+\dfrac{\delta^{2}}{2}\iint\left(\dfrac{1}{8}e^{-\phi}\psi^{2}+\kappa(z,\bar{z})\psi\right)dzd\bar{z}\right].$
(19)

Thus, by choosing $\kappa=\psi/8e^{\phi}$ one can get the renormalized on-
shell action is given by

$S_{r}=S_{NMG}+S_{GH}+S_{ct}=-\dfrac{1}{8}\left(1+\dfrac{1}{2m^{2}}\right)\iint\left[\psi+\dfrac{\delta^{2}}{2}\psi^{2}e^{-\phi}\right]dzd\bar{z}.$
(20)

It is possible to rewrite the renormalized action in the following form

$S_{r}=\dfrac{1}{64\pi G}\left(1+\dfrac{1}{2m^{2}}\right)\int
dV\left(\partial_{i}\phi\partial^{i}\phi+\dfrac{\delta^{2}}{2}\left(\partial_{i}\partial^{i}e^{\frac{\phi}{2}}\right)^{2}\right),$
(21)

after integrating by part one can get

$S_{r}=\dfrac{1}{64\pi G}\left(1+\dfrac{1}{2m^{2}}\right)\int
dS_{n}\left[\phi\partial_{n}\phi+\dfrac{\delta^{2}}{2}\left(\partial_{n}e^{-\frac{\phi}{2}}\square
e^{-\frac{\phi}{2}}-e^{-\frac{\phi}{2}}\partial_{n}\square
e^{-\frac{\phi}{2}}\right)\right].$ (22)

To evaluate this integral we adopt

$z=re^{i\theta},\;\;\;\;\;\;\;e^{-\frac{\phi}{2}}=\dfrac{1}{n\ell}(r^{n+1}+r^{-n+1}-2r\cos(n\theta)),\;\;\;\;\;e^{-\phi}\psi^{2}=(\partial\bar{\partial}e^{-\frac{\phi}{2}})^{2}.$
(23)

Then one can get

$S_{EE}=\dfrac{1}{4G}\left(1+\dfrac{1}{2m^{2}}\right)\left(\dfrac{1-n^{2}}{n}\right)\left[\log\left(\dfrac{\ell}{\delta}\right)+\dfrac{\delta^{2}}{n\ell^{2}}\right],$
(24)

one finally arrives at

$S_{EE}=\dfrac{c}{3}\log\left(\sqrt{\dfrac{24\pi}{\varsigma
c}}\ell\right)+\dfrac{\varsigma c^{2}}{72\pi\ell^{2}},$ (25)

where

$\varsigma=\dfrac{8Gm^{2}\delta^{2}}{1+2m^{2}}.$ (26)

In the limit $m\to\infty$, $\varsigma=4\pi G\delta^{2}$. It should be notice
that the central charge of the deformed CFT is the same as the original CFT.
It is expected that the holographic entanglement entropy of deformed CFT is
also given by the RT-formula. By using $z=x+\tau$, $\xi=1/\eta$ and going to
the polar coordinate in (14), we have

$ds^{2}=\dfrac{1}{\eta^{2}}\left[d\eta^{2}+r^{2}d\tau^{2}+n^{2}dr^{2}\right]$
(27)

The entanglement entropy can be calculated using the presymplectic potential
near the special curve by replacing $\delta g_{\mu\nu}=\partial_{n}g_{\mu\nu}$
as

$S_{HEE}=\int_{\gamma_{A}\times
S^{1}}\Theta\left(\phi_{i},\partial_{n}\phi_{i}\right)_{n\to 1,r\to 0},$ (28)

which is a surface integral on $\gamma_{A}$ after integrating out the $\tau$
along the $S^{1}$. For NMG the presymplectic potential is given by

$\displaystyle\Theta^{\mu}_{NMG}$
$\displaystyle=\theta^{\mu}-\dfrac{1}{2}f\theta^{\mu}+f^{\rho\sigma}g^{\mu\nu}\bar{\nabla}_{\rho}(\delta
g_{\sigma\nu})-\dfrac{1}{2}f^{\rho\sigma}\bar{\nabla}^{\mu}(\delta
g_{\rho\sigma})-\dfrac{1}{2}f^{\mu\nu}g^{\rho\sigma}\bar{\nabla}_{\nu}(\delta
g_{\rho\sigma})$
$\displaystyle+\dfrac{1}{2}[\bar{\nabla}^{\mu}f^{\nu\rho}-2\bar{\nabla}f^{\mu\rho}+g^{\mu\nu}\bar{\nabla}^{\rho}f+g^{\nu\rho}\bar{\nabla}_{\sigma}f^{\sigma\mu}-g^{\nu\rho}\bar{\nabla}^{\mu}f]\delta
g_{\nu\rho},\;\;\;\;$
$\displaystyle\theta^{\mu}=g^{\mu\nu}\bar{\nabla}^{\rho}(\delta
g_{\nu\rho})-g^{\rho\sigma}\bar{\nabla}^{\mu}(\delta g_{\rho\sigma}).$ (29)

So, the presymplectic structure for metric (27) is obtained as

$\Theta^{r}=\dfrac{1}{8\pi
G}\left(1+\dfrac{1}{2m^{2}}\right)\dfrac{\eta^{2}}{rn^{3}}.$ (30)

Then, one can achieve the entropy as

$S_{HEE}=\int_{0}^{2\pi}d\tau\int\sqrt{-g}\Theta^{r}dr=\dfrac{1}{4Gn^{2}}\left(1+\dfrac{1}{2M^{2}}\right)\int_{\eta_{f}}^{\ell}\dfrac{d\eta}{\eta}=\dfrac{1}{4G}\left(1+\dfrac{1}{2m^{2}}\right)\ln\left(\dfrac{\ell}{\eta_{f}}\right),$
(31)

here we have used $\sqrt{-g}=\frac{nr}{\eta^{3}}$, $\eta_{f}=1/\xi_{f}$ and
$\ell$ is the interval length of subsystem $\mathcal{A}$. In the case of
$\delta\ll 1$, one can obtain

$S_{HEE}=\lim\limits_{\begin{subarray}{c}n\to 1\\\ r\to
0\end{subarray}}\dfrac{1}{4G}\left(1+\dfrac{1}{2m^{2}}\right)\left[\ln\left(\dfrac{\ell
e^{\frac{\phi}{2}}}{\delta}\right)+\dfrac{\psi}{4e^{\phi}}\delta^{2}\right].$
(32)

By using (23) one can arrive

$\lim\limits_{\begin{subarray}{c}n\to 1\\\ r\to
0\end{subarray}}e^{-\frac{\phi}{2}}=\dfrac{1}{\ell},\;\;\;\;\;\;\lim\limits_{\begin{subarray}{c}n\to
1\\\ r\to 0\end{subarray}}e^{-\phi}\psi=\dfrac{2}{\ell}.$ (33)

Inserting (33) into the (32), it arrives (25).

##  3 Entanglement Entropy for GMMG

The Lagrangian of GMMG is obtained by generalization the Lagrangian of
generalized massive gravity. The Lagrangian of GMMG model is [10]

$L_{GMMG}=-\sigma e.R+\dfrac{\Lambda_{0}}{6}e.e\times
e+h.T(\omega)+\dfrac{1}{2\mu}\left(\omega.d\omega+\dfrac{1}{3}\omega.\omega\times\omega\right)-\dfrac{1}{m^{2}}\left(f.R+\dfrac{1}{2}e.f\times
f\right)+\dfrac{\alpha}{2}e.h\times h\ .$ (34)

Here $m$ is the mass parameter of NMG term, $h$ and $f$ are auxiliary one-form
fields, ${\Lambda}_{0}$ is a cosmological parameter with dimension of mass
squared, $\sigma$ is a convenient sign, $\mu$ is a mass parameter of Lorentz
Chern$-$Simons term, $\alpha$ is a dimensionless parameter, $e$ is a dreibein
and $\omega$ is a dualized spin-connection. Once the auxiliary one$-$form
fields $f$ and $h$ are integrated out, the field equations can be written as

$\bar{\sigma}G_{\mu\nu}+\bar{\Lambda}_{0}g_{\mu\nu}+\frac{1}{\mu}C_{\mu\nu}+\frac{\gamma}{\mu^{2}}J_{\mu\nu}+\frac{s}{2m^{2}}K_{\mu\nu}=0\
,$ (35)

where $C_{\mu\nu}$ is the Cotton tensor, $K_{\mu\nu}$ is the Euler$-$Lagrange
derivative of the quadratic part of the NMG Lagrangian with respect to the
metric, and $J_{\mu\nu}$ is the quadratic in the curvature tensor introduced
in [11]. The parameter $s$ is sign, $\gamma$, $\bar{\sigma}$ and
$\bar{\Lambda}_{0}$ are the parameters which defined in terms of other
parameters like $\sigma,m$ and $\mu$.
The metric (14) is a solution for the field equations (35) under the condition

$\lambda=-\dfrac{4\sigma\mu^{2}m^{2}+\gamma m^{2}-s\mu^{2}}{4\mu^{2}m^{2}}.$
(36)

The Lagrangian (34) can be written as follows

$L_{GMMG}=-\left(\sigma+\dfrac{c_{f}}{m^{2}}\right)e.R+\dfrac{1}{2\mu}L_{CS}+c_{h}e.T+\left[\dfrac{\Lambda_{0}}{6}-\dfrac{c_{f}^{2}}{2m^{2}}+\dfrac{\alpha
c_{h}^{2}}{2}\right](e.e\times e),$ (37)

where we have used

${h}=c_{h}{e},\;\;\;{f}=c_{f}{e}.$ (38)

The dreibein components of the metric after Wick rotation can be chosen as

$e^{0}=\dfrac{d\xi}{\xi},\;\;\;\;\;\;\;e^{1}=\dfrac{\xi}{2}\left(dz-d\bar{z}\right),\;\;\;\;\;e^{2}=\dfrac{\xi}{2}\left(dz+d\bar{z}\right).$
(39)

Then, the spin connections would be

$\omega^{1}_{0}=\dfrac{1}{2}\xi(dz-d\bar{z}),\;\;\;\;\omega^{2}_{0}=\dfrac{1}{2}\xi\left(dz+d\bar{z}\right),$
(40)

and therefore the dualized spin-connections are given by

$\omega^{0}=0,\;\;\;\;\omega^{1}=\dfrac{\xi}{4}\left(dz+d\bar{z}\right),\;\;\;\;\omega^{2}=\dfrac{\xi}{4}\left(d\bar{z}-dz\right).$
(41)

The different terms of the action are given by

$e.R=\dfrac{\xi}{4}d\xi\wedge dz\wedge d\bar{z},\;\;\;\;\;\;e.e\times
e=\dfrac{\xi}{2}d\xi\wedge dz\wedge
d\bar{z},\;\;\;\;\;T=0,\;\;\;\;\;L_{CS}=0,\;\;\;\;\;\omega.e=-\dfrac{\xi^{2}}{2}dz\wedge
d\bar{z}.$ (42)

Then the on-shell action is given by

$\displaystyle S_{GMMG}=$
$\displaystyle\dfrac{1}{4}\left(-\sigma+\dfrac{\Lambda_{0}}{3}-\dfrac{c_{f}^{2}}{m^{2}}+\alpha
c_{h}^{2}-\dfrac{c_{f}}{m^{2}}\right)\left[\dfrac{1}{\delta^{2}}\iint
e^{\phi}dzd\bar{z}+\dfrac{1}{2}\iint\psi
dzd\bar{z}+\dfrac{\delta^{2}}{16}\iint e^{-\phi}\psi^{2}dzd\bar{z}\right].$
(43)

The boundary actions are given as

$\displaystyle S_{GH}$
$\displaystyle=\int-\left(\sigma+\dfrac{c_{f}}{m^{2}}\right)\omega.e+\dfrac{1}{2\mu}\omega.\omega+c_{h}e.e=$
$\displaystyle\dfrac{1}{2}\left(\sigma+\dfrac{c_{f}}{m^{2}}\right)\left[\dfrac{1}{\delta^{2}}\iint
e^{\phi}dzd\bar{z}+\dfrac{1}{2}\iint\psi
dzd\bar{z}+\dfrac{\delta^{2}}{16}\iint e^{-\phi}\psi^{2}dzd\bar{z}\right],$
(44) $\displaystyle S_{ct}$
$\displaystyle=-\dfrac{1}{4}\left(\sigma+\dfrac{c_{f}}{m^{2}}\right)\int\;e\;(1+\delta^{2}\kappa(z,\bar{z})).$
(45)

If $\frac{\Lambda_{0}}{3}-\frac{c_{f}^{2}}{m^{2}}+\alpha c_{h}^{2}=0$, then we
have

$\displaystyle
S_{r}=-\dfrac{1}{8}\left(\sigma+\dfrac{c_{f}}{m^{2}}\right)\left[\iint\psi
dzd\bar{z}+\dfrac{\delta^{2}}{8}\iint e^{-\phi}\psi^{2}dzd\bar{z}\right]$ (46)

by using (23), one can obtain

$S_{EE}=-\dfrac{1}{8}\left(\sigma+\dfrac{c_{f}}{m^{2}}\right)\left(\dfrac{1-n^{2}}{n}\right)\left[\log\left(\dfrac{\ell}{\delta}\right)+\dfrac{\delta^{2}}{n\ell^{2}}\right],$
(47)

one finally arrives at

$S_{EE}=\dfrac{c^{\prime}}{3}\log\left(\sqrt{\dfrac{24\pi}{\varsigma
c^{\prime}}}\ell\right)+\dfrac{\varsigma c^{\prime
2}}{72\pi\ell^{2}},\;\;\;\;c^{\prime}=\dfrac{c_{+}+c_{-}}{2}$ (48)

where

$\varsigma=-\dfrac{64Gm^{2}\delta^{2}}{c_{f}+\sigma
m^{2}},\;\;\;\;c_{\pm}=-\dfrac{3}{2G}\left(\sigma+\dfrac{\alpha
c_{h}}{\mu}+\dfrac{c_{f}}{m^{2}}\pm\dfrac{1}{\mu}\right).$ (49)

The dreibein components of metric (27) can be written as

$e^{0}=\dfrac{r}{\eta}d\tau,\;\;\;\;\;\;e^{1}=\dfrac{n}{\eta}dr,\;\;\;\;\;\;e^{2}=\dfrac{1}{\eta}d\eta.$
(50)

The dualized spin connections would be

$\omega^{0}=-\dfrac{n}{2\eta}dr,\;\;\;\;\;\;\omega^{1}=\dfrac{r}{2\eta}d\tau,\;\;\;\;\;\;\omega^{2}=\dfrac{1}{2n}d\tau.$
(51)

The presymplectic form of GMMG is given by [27]

$\Theta_{GMMG}=-\left(\sigma+\dfrac{c_{f}}{m^{2}}\right)\delta\omega.e+\dfrac{1}{2\mu}\delta\omega.\omega+c_{h}\delta
e.e.$ (52)

Then, we assume $\delta\omega=\partial\omega/\partial n$, $\delta e=\partial
e/\partial n$, one can get

$\Theta_{GMMG}=-\left(\sigma+\dfrac{c_{f}}{m^{2}}\right)\left[\dfrac{r}{2\eta^{2}}dr\wedge
d\tau-\dfrac{1}{2n^{2}\eta}d\tau\wedge d\eta\right].$ (53)

So, the entropy for GMMG is as follows

$S=\int_{0}^{2\pi}d\tau\int\sqrt{-g}\Theta^{r}dz=\int_{0}^{2\pi}d\tau\int_{\eta_{f}}^{\ell}\dfrac{1}{2n^{2}}\left(\sigma+\dfrac{c_{f}}{m^{2}}\right)\dfrac{d\eta}{\eta}=\dfrac{1}{4G}\left(\sigma+\dfrac{c_{f}}{m^{2}}\right)\ln\left(\dfrac{\ell}{\eta_{f}}\right).$
(54)

here $\eta_{f}=1/\xi_{f}$. In the case of $\delta\ll 1$, one can obtain

$S_{HEE}=\lim\limits_{\begin{subarray}{c}n\to 1\\\ r\to
0\end{subarray}}\dfrac{1}{4G}\left(\sigma+\dfrac{c_{f}}{m^{2}}\right)\left[\ln\left(\dfrac{\ell
e^{\frac{\phi}{2}}}{\delta}\right)+\dfrac{\psi}{4e^{\phi}}\delta^{2}\right].$
(55)

After using (23) and limiting, one can arrive (48).

### Entanglement Entropy for EGMG

Exotic general massive gravity is the exotic version of NMG which is a
parity$-$odd theory describing a propagating massive spin$-$2 fields in three
dimensions. The Lagrangian of the theory in terms of auxiliary fields $f$ and
$h$ is [13]

$\displaystyle L_{EGMG}=$
$\displaystyle-\dfrac{1}{m^{2}}[f.R(\omega)+\dfrac{1}{6m^{4}}f.f\times
f-\dfrac{1}{2m^{2}}f.D(\omega)f+\dfrac{\nu}{2}f.e\times e-m^{2}h.T(\omega)+$
$\displaystyle\dfrac{(\nu-m^{2})}{2}\left(\omega.d\omega+\dfrac{1}{3}\omega.\omega\times\omega\right)+\dfrac{\nu
m^{4}}{3\mu}e.e\times e],\;\;\;\;\nu=1-\dfrac{m^{4}}{\mu^{2}}.$ (56)

The field equation of the theory in the metric formalism is obtained as
follows

$R_{\mu\nu}-\dfrac{1}{2}g_{\mu\nu}R+\Lambda
g_{\mu\nu}+\dfrac{1}{\mu}C_{\mu\nu}-\dfrac{1}{m^{2}}H_{\mu\nu}+\dfrac{1}{m^{4}}L_{\mu\nu}=0,$
(57)

where

$H_{\mu\nu}=\epsilon_{\mu}^{\alpha\beta}\nabla_{\alpha}C_{\nu\beta},\hskip
14.22636ptL_{\mu\nu}=\dfrac{1}{2}\epsilon_{\mu}^{\alpha\beta}\epsilon_{\nu}^{\gamma\sigma}C_{\alpha\gamma}C_{\beta\sigma}.$
(58)

$\mu$ and $m$ are mass parameters and $H_{\mu\nu}$ and $L_{\mu\nu}$ are
traceless and symmetric tensors. The above Lagrangian can be rewritten by
using (38) as

$L_{EGMG}=-\dfrac{c_{f}}{m^{2}}e.R+\left(c_{h}+\dfrac{c_{f}^{2}}{2m^{4}}\right)(e.De)-\dfrac{1}{m^{2}}(\nu-m^{2})L_{CS}-\dfrac{1}{m^{2}}\left[\dfrac{c_{f}^{3}}{6m^{4}}+\dfrac{\nu
c_{f}}{2}+\dfrac{\nu m^{4}}{3\mu}\right](e.e\times e).$ (59)

By using (42), one can obtain

$S_{EGMG}=\dfrac{m^{2}}{8\mu}\iint\xi_{f}^{2}dzd\bar{z}$ (60)

The GH term for EGMG is given by

$L_{GH}=-\dfrac{c_{f}}{2m^{2}}e.\omega+\dfrac{1}{2}\left(c_{h}+\dfrac{c_{f}^{2}}{m^{4}}\right)e.e+\left(1-\dfrac{\nu}{m^{2}}\right)\omega.\omega,$
(61)

then the GH action is given

$S_{GH}=-\dfrac{m^{2}}{4\mu}\iint\xi_{f}^{2}dzd\bar{z},$ (62)

where we have used

$c_{h}=\dfrac{1}{2}\left(1-\dfrac{1}{m^{2}}\right)\left(1-\dfrac{m^{4}}{\mu^{2}}\right),\;\;\;c_{f}=-\dfrac{m^{4}}{\mu}.$
(63)

The counter term is given

$S_{ct}=\dfrac{m^{2}}{8\mu}\iint e(1+\delta^{2}\kappa(z,\bar{z}))dzd\bar{z}.$
(64)

The renormalized on-shell action by using cut-off surface is given as

$\displaystyle S_{r}=\dfrac{m^{2}}{8\mu}\left[\iint\psi
dzd\bar{z}+\dfrac{\delta^{2}}{8}\iint e^{-\phi}\psi^{2}dzd\bar{z}\right],$
(65)

then, similar to the previous section, using (23) we have

$S_{r}=-\dfrac{m^{2}}{8\mu}\left(\dfrac{1-n^{2}}{n}\right)\left[\log\left(\dfrac{\ell}{\delta}\right)+\dfrac{\delta^{2}}{n\ell^{2}}\right]$
(66)

one finally arrives at

$S_{r}=\dfrac{c^{\prime}}{3}\log\left(\sqrt{\dfrac{24\pi}{\varsigma
c^{\prime}}}\ell\right)+\dfrac{\varsigma c^{\prime
2}}{72\pi\ell^{2}},\;\;\;\;c^{\prime}=\dfrac{c_{+}+c_{-}}{2}$ (67)

where

$\varsigma=-\dfrac{64G\mu\delta^{2}}{m^{2}},\;\;\;\;\;\;c_{\pm}=\dfrac{3}{2G}\left[-\dfrac{m^{2}}{\mu}\pm\left(1+\dfrac{m^{2}}{\mu^{2}}-\dfrac{1}{m^{2}}\right)\right].$
(68)

The presymplectic form of EGMG is given [27]

$\Theta_{EGMG}=\dfrac{1}{2}\left[\left(c_{h}+\dfrac{c_{f}^{2}}{m^{4}}\right)\delta
e.e+\left(1-\dfrac{\varpi}{m^{2}}\right)\delta\omega.\omega-\dfrac{c_{f}}{m^{2}}\delta
e.\omega\right],$ (69)

this presymplectic using (50), (51) can be written as

$\Theta=\dfrac{c_{f}}{2m^{2}}\left[\dfrac{r}{2\eta^{2}}dr\wedge
d\tau+\dfrac{1}{2n^{2}\eta}d\tau\wedge d\eta\right].$ (70)

Then, one can obtain the entropy for EGMG as follows

$S=\int_{0}^{2\pi}d\tau\int\sqrt{-g}\Theta^{r}d\eta=\int_{0}^{2\pi}d\tau\int_{\eta_{f}}^{\ell}\dfrac{c_{f}}{4n^{2}m^{2}}\dfrac{d\eta}{\eta}=-\dfrac{m^{2}}{16G\mu}\ln\left(\dfrac{\ell}{\eta_{f}}\right),$
(71)

here $\eta_{f}=1/\xi_{f}$. In the case of $\delta\ll 1$, one can obtain

$S_{HEE}=-\lim\limits_{\begin{subarray}{c}n\to 1\\\ r\to
0\end{subarray}}\dfrac{m^{2}}{16G\mu}\left[\ln\left(\dfrac{\ell
e^{\frac{\phi}{2}}}{\delta}\right)+\dfrac{\psi}{4e^{\phi}}\delta^{2}\right].$
(72)

After using (23) and limiting, one can arrive (67).

##  4 Conclusion

In this paper we have calculated the entanglement entropy of
$T\bar{T}$-deformed CFT to leading order correction to the entropy due to the
finite cut-off of AdS3 in Poincare coordinates in the framework of NMG, GMMG
and EGMG theories. We obtained the on-shell action of each theory and expanded
it up to leading order of cut-off of spacetimes. This correction term is
correspond to the deformation which comes from the bulk term. We have also
obtained the entropy for the deformed theories using Song’s method [26]. We
find an agreement between the results in the two methods.

Acknowledgements
We thank Amin Faraji for reading the article and for his encouraging.
The authors acknowledge the support of Kurdistan University.

## References

  * [1] G. ’t Hooft, Conf. Proc. C 930308, 284-296 (1993) [arXiv:gr-qc/9310026 [gr-qc]].
  * [2] L. Susskind, J. Math. Phys. 36, 6377-6396 (1995) doi:10.1063/1.531249 [arXiv:hep-th/9409089 [hep-th]].
  * [3] J. M. Maldacena, Adv. Theor. Math. Phys. 2, 231-252 (1998) doi:10.1023/A:1026654312961 [arXiv:hep-th/9711200 [hep-th]].
  * [4] F. A. Smirnov and A. B. Zamolodchikov, Nucl. Phys. B 915, 363-383 (2017) doi:10.1016/j.nuclphysb.2016.12.014 [arXiv:1608.05499 [hep-th]].
  * [5] L. McGough, M. Mezei and H. Verlinde, JHEP 04, 010 (2018) doi:10.1007/JHEP04(2018)010 [arXiv:1611.03470 [hep-th]].
  * [6] B. Chen, L. Chen and P. X. Hao, Phys. Rev. D 98, no.8, 086025 (2018) doi:10.1103/PhysRevD.98.086025 [arXiv:1807.08293 [hep-th]].
  * [7] K. Allameh, A. F. Astaneh and A. Hassanzadeh, [arXiv:2111.11338 [hep-th]].
  * [8] E. A. Bergshoeff, O. Hohm and P. K. Townsend, Phys. Rev. Lett. 102, 201301 (2009) [arXiv:0901.1766 [hep-th]].
  * [9] E. A. Bergshoeff, O. Hohm and P. K. Townsend, Phys. Rev. D 79, 124042 (2009) [arXiv:0905.1259 [hep-th]].
  * [10] M. R. Setare, Nucl. Phys. B 898, 259-275 (2015) doi:10.1016/j.nuclphysb.2015.07.006 [arXiv:1412.2151 [hep-th]].
  * [11] E. Bergshoeff, O. Hohm, W. Merbis, A. J. Routh and P. K. Townsend, Class. Quant. Grav. 31, 145008 (2014) doi:10.1088/0264-9381/31/14/145008 [arXiv:1404.2867 [hep-th]].
  * [12] B. Tekin, Phys. Rev. D 92, no.2, 024008 (2015) doi:10.1103/PhysRevD.92.024008 [arXiv:1503.07488 [hep-th]].
  * [13] M. Özkan, Y. Pang and P. K. Townsend, JHEP 08, 035 (2018) doi:10.1007/JHEP08(2018)035 [arXiv:1806.04179 [hep-th]].
  * [14] G. Alkaç, M. Tek and B. Tekin, Phys. Rev. D 98, no.10, 104021 (2018) doi:10.1103/PhysRevD.98.104021 [arXiv:1810.03504 [hep-th]].
  * [15] S. Deser, R. Jackiw and S. Templeton, Phys. Rev. Lett. 48, 975-978 (1982) doi:10.1103/PhysRevLett.48.975
  * [16] S. Deser, R. Jackiw and S. Templeton, Annals Phys. 140, 372-411 (1982) [erratum: Annals Phys. 185, 406 (1988)] doi:10.1016/0003-4916(82)90164-6
  * [17] R. B. Mann, J. Oliva and S. N. Sajadi, JHEP 05, 131 (2019) doi:10.1007/JHEP05(2019)131 [arXiv:1812.09525 [gr-qc]].
  * [18] E. A. Bergshoeff, W. Merbis and P. K. Townsend, Class. Quant. Grav. 37, no.3, 035003 (2020) [arXiv:1909.11743 [hep-th]].
  * [19] G. Giribet and J. Oliva, Phys. Rev. D 99, no.6, 064021 (2019) doi:10.1103/PhysRevD.99.064021 [arXiv:1901.08457 [hep-th]].
  * [20] M. R. Setare and S. N. Sajadi, Phys. Lett. B 822, 136667 (2021) doi:10.1016/j.physletb.2021.136667
  * [21] M. R. Setare, S. N. Sajadi, S. Dengiz and E. Kilicarslan, Phys. Rev. D 104, no.6, 066004 (2021) doi:10.1103/PhysRevD.104.066004 [arXiv:2109.03633 [hep-th]].
  * [22] M. R. Setare, J. Oliva and S. N. Sajadi, [arXiv:2106.12040 [hep-th]].
  * [23] Fefferman, Charles, and C. Robin Graham. The Ambient Metric,” (AM-178). Princeton University Press, (2011).
  * [24] K. Skenderis and S. N. Solodukhin, Phys. Lett. B 472, 316 (2000).
  * [25] K. Krasnov, Class. Quant. Grav. 20, 4015 (2003).
  * [26] W. Song, Q. Wen and J. Xu, Phys. Rev. Lett. 117, no.1, 011602 (2016) doi:10.1103/PhysRevLett.117.011602 [arXiv:1601.02634 [hep-th]].
  * [27] M. R. Setare and H. Adami, Phys. Lett. B 760, 411-416 (2016) [arXiv:1606.02273 [hep-th]].