On the Concept of Transparency: A Systematic Literature Review

Over a decade since transparency was introduced as a first-class concept in computing, transparency is still an emerging concept that is quite poorly understood. Also, despite existing research contributions, transparency is yet to be incorporated into the software engineering practice, and the promise it holds remains unfulfilled. Although there is evidence of increasing stakeholders’ demand for software and process transparency, the realization of such demand is yet to be fully witnessed within the software engineering practice. There is a need to uncover transparency and how it has so far been conceptualized, operationalized, and challenges faced. We applied a systematic literature review method in search of articles published between January 2006 and March 2022. This study reports a systematic review of the explicit conceptualization and application of transparency in 18 articles out of a total of 162 selected for review. Our study found that transparency remains an under-researched non-functional quality requirement concept, especially as it impacts information and software systems development. Of the 18 articles reviewed, only three studies representing 16.67% conceptualized transparency in software development and focused on the transparency of software artifacts. The remaining 83.33% of studies conceptualized transparency in information systems, focusing on general information and fully functional information systems. Transparency is yet to be fully explored from a theoretical gathering point of view and as a non-functional indicator of software quality hence its slow adoption and incorporation into mainstream software practice. Apart from providing a catalog of transparency factors that stakeholders can use to evaluate transparency achievement, the paper proposed a roadmap to enhance transparency implementation and also provides future research directions.


I. INTRODUCTION
Though a term that has been long-established in other older disciplines, transparency remains an emerging concept that different software project stakeholders must consider. Transparency is a multifaceted concept that is commonly used to refer to the act of ''being open.'' Its use and interpretation depend on the context. For instance, transparency in governments, societies, and public organizations implies open business processes and the availability of information [1], [2], [3]. In computing, and from the business information systems point of view, process and information transparency refer to process disclosure and information disclosure, respectively [4], [5]. In software engineering, transparency relates The associate editor coordinating the review of this manuscript and approving it for publication was Shovan Barma . to the extent to which stakeholders within a software project can answer their questions about the software system under development [6], [7]. Transparency of software or software transparency also refers to fully disclosing all functions of the software to its users [8].
In other computing sub-disciplines, the notion of transparency offers varying meanings depending on the context. For instance, in networking and distributed systems, transparency is a descriptive heuristic (i.e., a mental short-cut to solving problems) that is used to explain the representation of high levels of abstractions, such as the invisibility of network interactions and seamless remote use of resources by users [9], [10]. In these examples, transparency itself is not explained. This study is not concerned with definitions and studies that only use transparency as a descriptive heuristic to describe or explain some form of anomalies like the VOLUME 10, 2022 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ definitions in [10], [11], [12], and [13], even more so as they are not considered from a theoretical standpoint. The research on transparency as a concept started over a decade ago by the Software Transparency research group [14] led by Professor Julio Cesar Sampaio do Prado Leite of Departamento de Informática, PUC-Rio, Brazil. Since its inception, it is instructive to assume that several studies about the concept of transparency would have been reported in the literature, especially in computing and its sub-disciplines. However, to the best of our knowledge, no study chronicled and comprehensively aggregated existing studies on transparency to provide a valuable body of knowledge that would further advance the concept of transparency and its practical application. The current study attempts to fill the vacuum.
Moreover, several years after its introduction, the promise transparency hold is yet to be fully explored and fulfilled. As an emerging concept, stakeholders, especially researchers and developers in the industry need to know the scientific and practical significance of transparency. Thus, introducing a concept such as transparency should not be an end, but a means to an end-transparency in engineering software. Concept and theory development are investments that remain crucial to software development success, even more so as computing and its various sub-disciplines lag behind other long-established disciplines in theory building. These two perspectives are, therefore, part of the motivation for this study.
The community, especially software project managers, developers, and requirements engineers, needs to explicitly implement and measure transparency during the software engineering process. In addition, they need to understand and know when transparency can be implicitly achieved based on their choices in information systems or software design and development approaches. Providing such knowledge in one study helps to raise awareness and stimulate further research efforts. Software practitioners can also benefit from such knowledge since it may help them create a transparency improvement program.
The current study investigates how transparency has been conceptualized and its extent of use from a conceptual perspective. We performed a systematic literature review (SLR) [15], starting with 1,362 potential peer-reviewed papers, and ultimately focused on 18 publications that studied transparency and evaluated its achievement based on its defining factors and variables. We deem our SLR to be a helpful guide for two audiences, including transparency researchers who propose, apply, and evaluate transparency achievement and all software industry stakeholders who are interested in implementing a transparency improvement initiative that adds value to software artifacts, software, and processes. Both audiences may want to use our review for the following reasons.
-A reference guide. We have compiled a list of transparency factors available in the literature. Researchers can see where authors of the factors further discussed and applied them.
-Providing a roadmap for conceptualizations and evaluation. The study proposes a conceptual blueprint or template that can be used to identify transparency objectively and understand how transparency may be achieved. It also identifies state-of-the-art conceptualizations that may help researchers view how their future proposals fit into the overall concept of transparency and its evaluation. -Source of inspiration and Call for further research. The review can act as a guideline to help inspire and encourage a new way of thinking about transparency conceptualization, operationalization, and evaluation. Based on the provided insights, researchers may explore the possibility of transforming transparency from a concept to a theory. Additionally, our findings may help reinvigorate new discussions and research.
The rest of the paper is structured as follows: Section II provides background on transparency. Related work is presented in Section III. Section IV presents the method adopted for the review. In section V, we provide the results of the review. Section VI discusses the review results, a blueprint for evaluating transparency achievement, and opportunities for further research. Finally, Section VII presents a conclusion of the study.

II. BACKGROUND
In this section, we present a background on transparency. Transparency has been conceptualized in terms of information disclosure or process disclosure [16]. From the point of view of software, information transparency means making the information the software deals with transparent [5]. Process transparency, on the other hand, means the software can reveal how it works, what it does, and how it does it [5]. Apart from software, an ''automated process,'' other general organizational or business processes that are not automated may be required to be transparent. Since transparency deals with information and processes, it becomes a quality attribute of software and other organizational or business processes. Transparency, therefore, is considered a requirement of the stakeholders of software and processes. Fig. 1 provides a pictorial overview of the dimensions of conceptualizations and operationalizations of transparency. A conceptualization is the formation of a concept [17], [18]. On the other hand, operationalization refers to implementing and measuring a concept using its measurable factors [17]. The operationalization of a concept helps to provide evidence of the practical significance of a concept in a real-world situation. Transparency may be measured by different factors that help its achievement.
Based on Fig. 1, transparency is the main quality that transparency factors can measure. Stakeholders would need to agree on what constitutes a transparency requirement that would require fulfillment via a suitable transparency factor. An established transparency requirements catalog will then be the target for transparency measurement by their respective factors. Through the operationalization of a transparency factor, software, software artifacts, and processes can be evaluated for transparency achievement. In the case of software development life cycle (SDLC) processes, the end goal of such an evaluation could be to have transparent processes that produce transparent software artifacts and deployable software.
Given the multifaceted and complex nature of transparency and how it has been achieved, we identified two dimensions (process and information) of conceptualization and operationalization (see Fig. 1). In this SLR, the process transparency (PT) dimension refers to the conceptualization and operationalization of transparency that focuses on automated (i.e., software) and unautomated (i.e., other organizational or business processes) processes. On the other hand, the information transparency (IT) dimension refers to the conceptualization and operationalization that focuses on software, especially the information it deals with, and software artifacts such as requirements documents, design documents, and code. Fig. 1 partly hints at a blueprint for transparency achievement, which will be provided later in the paper.

A. DEMAND FOR SOFTWARE TRANSPARENCY AND GENERAL DEMAND FOR TRANSPARENCY IN SOFTWARE ENGINEERING
There is a global demand for transparency in various human endeavors, whether government, private or social enterprises [1]. The Volkswagen carbon emission scandal [19] and Boeing's 737 Max plane crashes [20] are some incidents that have reiterated the call for more transparency in software. To answer whether there is a demand for software transparency, Portugal et al. [21] relied on the data about bills proposed to the Brazilian Congress to identify the demand for transparency. They argued that there is a ''real future demand for software transparency.'' Several studies [6], [8], [16], [22], [23], [24] have addressed the need for software transparency. Transparency has been considered a key driving force for open-source software development. According to Dabbish et al. [23], transparency, as it concerns software engineering promises to be an enabler of collaboration and coordination. However, in the software engineering process, the demand has not received much attention except as the reported works by Tu et al. [6], [7] indicate.
In [16], the demand for transparency is categorized as stakeholders' demand for the internal transparency of software, software processes, and the mediators of software and the information produced by software systems. Tu et al. [6], [7] opined that transparency could benefit other SDLC stages apart from the requirements engineering phase. Furthermore, the studies in [4] and [25] emphasized the benefits of introducing transparency as a requirement from the process and information points of view. Moreover, as the prevalence of code over models persist due to the adoption of social coding platforms such as GitHub and Agile methodologies, Leite [26] argued that this trend might be mitigated with transparency.

B. TRANSPARENCY AS A PRIMARY CONCEPT
The multifaceted and complex nature of transparency makes transparency a concept that is seldom approached as a primary concept like other well-established concepts [13], [27], [28], [29]. Transparency as a primary or first-class concept means considering transparency as a monolithic and independent concept explained by well-defined factors. Some studies [27], [28], [29] conceptualized transparency as a second-class concept in union with other antagonizing (i.e., concepts that negate the principle of openness, which signifies transparency) concepts such as privacy and security. Since transparency positively connotes the act of making a given process or software open to stakeholders, it is qualified by equally positive factors (e.g., availability, accessibility) that helps to explain and achieve it. The studies reported in [6], [16], [24], [30], [31], and [32] conceptualized transparency as a primary concept.

C. TRANSPARENCY AS A SECONDARY CONCEPT
Several studies [22], [27], [28], [29], [33], [34], [35], [36], [37], [38] considered transparency as a secondary concept but in union with other major concepts. For instance, transparency is conceptualized as a secondary concept under another primary concept, such as accountability, privacy, and security. Addressing the challenge of antagonizing concepts such as privacy and security is deemed a significant investment since these concepts, by their rights, contribute to transparency. By this, we mean that stakeholders' transparency requirements that border on privacy, for example, must also be addressed while at the same time trying to achieve transparency.
As previously explained, though transparency is positively understood to mean being open, antagonizing transparency measurement factors on the face of it may appear to negate VOLUME 10, 2022 the typical idea of openness, but they yet help the fulfillment of transparency concerns that border on the preservation of privacy and security of information. A transparency achievement initiative would, therefore, aim to achieve typical transparency requirements and antagonizing transparency requirements as provided in [39].

III. RELATED WORK
Chazette [40] reported an SLR of 13 papers, which partly aimed to provide evidence on how transparency has been approached in requirements engineering. First, the author grouped the existing approaches under six themes: modeling, requirements analysis; requirements elicitation; concept models; trust and privacy, and trust and transparency. Then based on the SLR strategy, and as part of a proposed future study, the author proposed three research questions regarding the challenges towards realizing transparency in requirements engineering. However, apart from Chazette, to the best of our knowledge, we did not find any prior secondary study that provided a systematic compilation of transparency-related studies as our SLR aims to deliver.

IV. RESEARCH METHODOLOGY
This section presents the methodology adopted in the current systematic literature review (SLR) study. The SLR study follows the guidelines proposed by Kitchenham et al. [15]. The guidelines have established themselves as a popular and widely accepted standard for conducting literature reviews in software engineering (SE). The SLR process (see Fig. 2) consists of several activities that can be grouped into three major phases: design, conducting, and reporting the review findings.

A. RESEARCH QUESTIONS
This study aims to investigate the existing conceptualizations of transparency and the extent of its operationalization. We, therefore, sought to retrieve and analyze relevant and credible studies that relate to transparency. The research questions and their motivations are as follows:

1) RQ1
How has transparency been conceptualized in information systems and software engineering? Transparency is a concept that is rarely approached from a theoretical point of view [41], [42]. As previously mentioned, the common use of transparency as a descriptive heuristic lacks any theoretical underpinnings that explain and support transparency. The consequence is that stakeholders find it difficult to identify what represents transparency and how it can be achieved. This indication partly motivated RQ1. Though the findings from the studies mentioned above are outside the computing field, they are relevant to our study because transparency is multidisciplinary, complex, and multifaceted. Also, since the above findings cannot be generalized to computing and its sub-disciplines, it also motivates the current SLR as it aims to x-ray the information and software systems landscape to arrive at findings that reflect the current state of affairs of transparency conceptualization. In order to better address RQ1, we provided sub-research questions RQ1.1 to RQ1.5. We aimed to identify existing definitions of transparency and investigate factors that help explain transparency. Stakeholders need to understand and ascertain the factors that can be used to define and measure transparency. When software project stakeholders become aware of these transparency-describing factors, they may consider their actual operationalization. If factors of transparency are investigated, it is reasonable to consider the research approach and context of transparency conceptualizations and the methods used to evaluate transparency.

2) RQ2
What are the existing operationalizations of transparency?

a: RATIONALE
The purpose of RQ2 is to investigate the practical examples of transparency operationalizations (i.e., the implementations and measurement of transparency achievement) and analyze the extent of the operationalization of transparency. As an emerging concept, stakeholders need to know in practical terms how information or software systems development, for instance, can ultimately benefit from transparency to deliver software projects more successfully.

3) RQ3
What are the challenges with operationalizing transparency? a: RATIONALE RQ3 is motivated by the need to investigate existing challenges in implementing transparency. As an emerging and multifaceted concept, stakeholders need to know the challenges that accompany the implementation and measurement of transparency and how such challenges may be mitigated.

B. SEARCH PROCESS
The search was carried out via the conventional manual process as provided by the search engines. Table 1 provides a list of digital library sources searched. The first author performed the search of articles in the order listed in Table 1 from February 2, 2022, to March 7, 2022. The second and third author supervised the search process and its outcome. These database sources were considered to be among the reputable leaders in digital collections. Databases such as Google Scholar, Web of Science and Scopus provide broad access to electronic papers and have the capacity to return a high search result on the execution of a search query than other smaller and more focused sources. We also provide a flow chart representing the search process in Fig. 3. The papers identified during the paper identification stage include journal articles, book chapters, and conference papers. The resulting papers are, therefore, papers that meet the established inclusion criteria. Though Fig. 3 presents the general search process flowchart, Fig. 4 (see Section IV-C3) complements it as it further captures a detailed paper identification and study selection process following well-established guidelines provided in [43].
As part of an SLR protocol development, Kitchenham and Charters [15] suggested a model for framing SLR research questions. This model is known as PICOC (Population, Intervention, Comparison, Outcome, Context) and was initially proposed by Hunt [44]. We next present how we adopted the model.

1) POPULATION
The current study considers peer-reviewed journal articles, conference papers, book chapters and workshops that report the conceptualizations and operationalizations of transparency in software engineering and information systems.

2) INTERVENTION
The intervention's objective was to collect theoretical (theory or concept formulation) and empirical evidence related to the various factors of transparency, conceptualization approaches, operationalization areas, and challenges with implementing transparency.

3) COMPARISON
The comparison criterion does not apply to the current study.

4) OUTCOME
Expected outcomes include a catalog of transparency factors that stakeholders may use to implement, assess and improve transparency. Also included are approaches that may further be used to conceptualize transparency, the operationalizations of transparency, and the current challenges of dealing with transparency.

5) CONTEXT
Review of studies that treat transparency as a primary concept within software engineering and information systems subdisciplines. VOLUME 10, 2022 The first author constructed several search strings based on the research questions and the use of synonyms. Initial search strings were constructed and used to perform a pilot search. The search strings were refined, and more strings that fit the purpose were constructed, considering the pilot search outcome. The following two queries were used to search relevant databases based on titles, keywords, and abstracts.
String The second query was used to search for papers in the ScienceDirect database due to the restriction set by Sci-enceDirect on the number (8) of Boolean variables and words supported for searching.

6) STOPPING HEURISTIC PROCEDURE
Since reviewing all the results is not feasible in some cases, especially when the returned results are running in hundreds of thousands, we applied a stopping heuristic [45] as follows: 1) For the first search query, execute the search on all six digital sources. 2) Rank the results by relevance.
3) Assess the search results until reaching ten consecutive, irrelevant results. 4) Otherwise, continue to the next 10 results (as in step 3).

C. REVIEW PROCESS
In this section, the paper presents aspects of the review protocol necessary for conducting the SLR. Before proceeding, the paper provides a background on how it identified the concept of transparency in the literature.

1) IDENTIFICATION OF THE CONCEPT OF TRANSPARENCY
It is important to emphasize that a transparency conceptualization demonstrates scientific significance. In this paper, scientific significance implies evidence of other related concepts, hypotheses, and theories that may have been generated to support transparency. Hypotheses bordering transparency may have been empirically (or otherwise) validated to support transparency. This rationale informed the need also to consider studies that reported any experiment or any other evaluation of transparency. On the other hand, the practical significance of transparency demonstrates transparency operationalizations.
In order to identify and describe the concept of transparency, this paper borrowed some of the structural components of theory employed in identifying and describing theories from [46], [47]. The structural components include the means via which a theory is represented, the specified constructs of the theory, and the specified relationships between the constructs. It is noted that constructs and their relationship constitute the essential parts of a theory or a concept. Though the SLR aims to identify the concept of transparency, using the structural components and descriptions for theories is instructive since concepts also require a means of representation, constructs, and relationships.
Furthermore, towards identifying the concept of transparency, the SLR considered factors and their corresponding relationships together with the variables and associations that represent them. Therefore, this paper uses ''factor'' to refer to the attributes or constructs or factors or softgoals that help describe or explain the concept of transparency. It should be noted that the use of notion, attribute, factor, or construct is interchangeable in the literature. However, the paper will mostly use the term factor for consistency.

2) INCLUSION AND EXCLUSION CRITERIA
This section presents the criteria for including or excluding a primary study. The criteria are partly explained in Section IV-C4 and fully in Section IV-C5. Table 2 presents the inclusion and exclusion criteria. We considered all papers published between Jan 2006 and March 2022. This time frame is because transparency as a concept appeared to have been introduced in 2007. The paper also considered that a 16-years span is an extended period, sufficient to consider a compilation of studies and the aggregation of the body of knowledge regarding transparency.

3) STUDY SELECTION
This section discusses the study selection procedures.

a: FIRST STAGE: TITLES, ABSTRACTS, AND KEYWORDS
The first author performed the search for papers based on titles and keywords using the search queries. We aimed to be as inclusive as possible since abstracts were not read during this stage. The first stage produced the data presented in Table 3. The ''Total Results'' column in Table 3 represents the search engine's self-reported total number of results upon executing the query. The ''Reviewed Results'' column is the outcome of executing the heuristic procedure outlined in Section IV-B6. The inclusion and exclusion criteria applied are IC1, and EC1, respectively. Of the 33,656 papers returned by the search engines, 1,362 papers were examined. Of the 1,362 papers, 493 duplicates were removed by the first author resulting in 869 papers that were included for screening by the authors. Based on title, abstract, and keywords, the first author included 162 papers for full-text review. The second and third author further reviewed the included papers. Where there were disagreements, the authors decided on a consensus.

b: SECOND STAGE: FULL TEXTS
This stage involves a full review and deciding on the full text of each 162 titles retained in the first stage. Full-text consideration was guided by the inclusion and exclusion criteria which, at this stage, were applied fully. The first author selected potential papers for full-text review based on the inclusion criteria (IC2, IC3) and exclusion criteria (EC2, EC3). The second and third author reviewed the papers included by the first author. An external researcher was also engaged during this stage to evaluate the included and excluded papers by the authors to avoid bias. The evaluation outcome by the external research returned in favor of the authors' papers already selected.
The first author further performed a random re-evaluation of papers to ensure that the inclusion and exclusion criteria were followed. During this stage, any disagreement that arose was resolved through a consensus between the authors and the external researcher.
Finally, in this stage, of the 162 sources, the researchers agreed on 18 full texts, and 144 were excluded from further review. This final selection did not include sources from ACM and Web of Science databases. ACM did not have papers that were suitable for full-text review. Web of Science had ten papers that were eligible for full-text review but were considered duplicates or overlaps of papers already selected from their primary sources and therefore not included. Duplicates from Google Scholar and Scopus were similarly removed.
Summarily, the authors searched a population of over thirty thousand sources, examined 1,362 titles, and selected 162 titles based on their relevance to our research objective. Of the 162 relevant titles, the authors then used the full text of the 162 papers to decide on 18 papers reported in the SLR. As part of the study selection process, this paper applied the ''PRISMA Statement for Reporting Systematic Reviews and Meta-Analyses of Studies'' reported in [43]. The application of PRISMA guidelines resulted in Fig. 4. Fig.4 indicates the number of papers obtained from each targeted database and the statistics on the number of papers included and excluded in each stage of the selection process.

4) QUALITY ASSESSMENT CRITERIA
As part of the SLR process, primary studies that have been obtained must be assessed to determine their actual relevance [15]. In the current SLR, 18 primary studies were obtained and included in the SLR. The paper defined five quality assessment questions to assess the quality of the primary studies retained. Table 4 presents a summary of the quality assessment questions.

a: JUSTIFICATION FOR QUALITY ASSESSMENT CRITERIA
The data extraction guidelines this paper adopted from Hannay et al. [46] and Gregor [47] informed the development of the quality questions. The rationale for also basing the quality assessment on these five criteria stems from the fact that Stakeholders need to know what helps explain transparency in terms of factors. Primary studies should explain transparency using factors that are clearly defined. Because transparency is a concept, the studies on transparency may  define the relationships between factors of transparency and how the factors help measure transparency. This expectation is usually a requirement for conceptualization and theory formulation Hannay et al. [46] and Gregor [47]. The scoring was performed as follows: Yes (Y) = 1; Partly (P) = 0.5; No (N) = 0; The reason for providing quality assessment questions is, therefore, to avoid bias in the conduct of the review, in addition to auditing both the internal and external review validation process.

5) DATA COLLECTION
This section describes the type of data identified and collected based on our research questions and the overall objective of our SLR.

a: DATA EXTRACTION OF TRANSPARENCY CONCEPTS
To extract transparency concepts, we look out for explicit statements in the literature related to factors of transparency and their definitions. Additionally, to also identify and include the concept and definition of transparency in our review, we relied on some of the data extraction criteria provided in [46] and [47] as previously mentioned. Because transparency is an emerging concept in information systems and software engineering, some data extraction attributes for theories such as theory's structural representations and theory's role were not considered in this SLR. Table 5 provides a summary of data attributes for the extraction of transparency concepts from the reviewed papers. We next describe the procedure for extracting data attributes that may not be selfexplanatory.

b: METADATA
Concept names and references are obtained from the reviewed articles, where possible. Though the commonly used name for the concept under investigation is transparency, this study envisages that some articles may use other synonyms such as openness or disclosure to refer to the same concept. Reference records the source of the transparency conceptualization. Since transparency is characterized as a complex and multifaceted concept, the Reference Discipline attribute records the sources of the factors used to describe and achieve transparency.

c: STRUCTURAL COMPONENTS
The Means of Representation attribute is used to indicate how the concept of transparency is presented typographically. The Factors and Relationships attribute values are determined based on the understanding provided in Section IV-C1. When possible, this paper records only what is perceived to be factors and relationships based on the reviewed article. The data collected from each primary study would enable us to address the SLR's research questions.

6) DATA SYNTHESIS
Because the SLR aimed to investigate the concept of transparency and the extent it has been conceptualized and operationalized, we deemed it appropriate to adopt a qualitative method to synthesize the data that will be obtained from each included primary study. A qualitative synthesis relies on a narrative and textual approach to summarize, analyze, and assess the data needed to answer the review questions.

V. RESULTS AND ANALYSIS
Our study selection process resulted in 18 studies (see Appendix) that met the inclusion criteria. Data from the studies were extracted following the data extraction criteria described in Section IV-C5. Before presenting the results and analysis of each research question, we provide an overview of the studies' general characteristics and depict the quality assessment outcome. 89894 VOLUME 10, 2022  [46], [47].

A. CHARACTERISTICS OF STUDIES
The selected studies were published between 2006 and 2022. it no longer appears to trend as a topic for research hence the papers' motivation. Based on the temporal view analysis, it is reasonable to conclude that the number of studies about transparency conceptualization and applications appeared trim through the years.
Our finding corroborates an earlier observation that transparency is rarely approached from a theoretical perspective. The limited number of studies also confirms the view of Hosseini et al. [PS4,PS6]. Most of the papers we excluded from the review only used transparency as a descriptive heuristic, lacking the required theoretical underpinnings a concept should reflect. The outcome also indicates the paucity of transparency-related studies, as Hosseini et al. [30] also observed.
The types of publications included in this study are conferences, book chapters, workshops, and journals. Many of the studies are conference papers (9 studies; 50.00%), followed by journal articles (6 studies; 33.33%), book chapter publications (2 studies; 11.11%), and one (1) workshop publication (5.56%). Table 6 presents a summary of the papers from each electronic database in terms of the distribution of the included papers. The Total column represents the total number of studies included in the corresponding database; the Overlapping column captures the number of papers that overlap from other databases; the Unique column represents unique papers that originally appeared in the corresponding database. The % of Unique Papers shows the percentage of unique papers from the database. A majority (58.56%) of the included papers were obtained from the Springer database. This is followed by IEEEXplore, which recorded four (22.22%) papers. GoogleScholar and ScienceDirect recorded two articles each, respectively, representing 11.11% in each case.  Table 7 indicates the scores awarded to each primary study (PS) under each corresponding quality question based on the five quality assessment questions presented in Section IV-C4. The first author performed the assessment under the supervision of the second and third author. All disagreements that ensued were resolved via consensus.
The %Total Score (obtained by Total/Total Score * 100) row indicates the points in percentage (over the highest score of 5) obtained by the selected studies for the overall quality assessment questions. As an example, %TotalScore for QA3 is computed as: (6.5/64.5) * 100).
Assuming that each selected study recorded the maximum score of one (1), %MaxQA is obtained by dividing the total maximum scores for all studies under a QA question by the total points (i.e., Total row) recorded for all studies under the same QA question and multiplying the outcome by 100. As an example, %MaxQA for QA2 is computed as (6/12) *100).
The Total Score column presents the total score recorded for each primary study across all QAs. The percentages reported here are, therefore, maximum percentages recorded against each study and for all QAs. For example, only two studies [PS2, PS3] scored 4.5, representing 90% of the maximum score of five (5) a PS may obtain. Next in the ranking are studies [ PS4, PS10, PS17, PS18], scoring four (4) and representing approximately 80% of the maximum score. This is followed by PS5, PS7, PS11, PS12, PS13, PS14 and PS16, all of which scored 3.5, representing 70% of the maximum score. Finally, primary studies [PS1, PS6, PS8, PS9, and PS15] all scored 3, representing 60% of the maximum score. The results generally indicated that the studies recorded scores above average (50%). The results also give confidence that the papers have good quality and can be used for the SLR.
The %MaxQA indicates the points in percentage obtained from the scores recorded by each quality assessment question over the highest score attained. A percentage of 100 means the paper has good quality and will contribute positively to the SLR outcomes. Papers with a 50% score and above will be considered of good quality. It is important to note that though different papers may score any point between 0 and 1 for a given QA, they all contribute to the overall score (i.e., %MaxQA), which is then interpreted as provided above. The evaluation of each PS based on each of the quality assessment questions in Table 6 is as follows: -For quality criterion QA1 (well-defined transparency factors.) A 100% score was obtained for all primary studies.
-For QA2 (well-described relationships between factors). The result obtained for all primary studies is 50%. This is an average result in our view. It indicates that the relationships between transparency describing factors are yet to be well conceptualized, especially in SE, as observed in [PS2, PS3]. Establishing and understanding the relationships between the factors of a phenomenon is one of the theory formulation requirements [48], [49], [50]. The studies [e.g., PS4, PS5, PS7, PS10, PS13, PS18] from IS perspective provided more details about the relationships between transparency factors. The IS studies contributed largely to the overall score because they are more than the SE studies. However, their descriptions (e.g., goal modeling as provided in PS10) of relationships between transparency factors do not fulfill the requirement of theory formulation.
-For QA3 (experiment or evidence showing an operationalization of transparency conceptualization). The result obtained is 77%, which is well above the average of 50%. Only PS2 and PS3 reported an experiment as they formulated hypotheses that required empirical testing. The other studies, which are IS-based, reported evaluation of a process in one case and the information produced by information systems.
Based on the reviewed studies, the view of transparency as information and process improving concept, operationalized in some context, implies that controlled experiments may not be necessary as a validation method. However, in an information context that focuses on the transparency of software artifacts, a controlled experiment has proved useful as a means of validation. Some of the reviewed studies [e.g., PS1, PS4, PS5, PS13, PS14, PS16] scored either zero or low for QA3 because they did not provide any evaluation. This lack of assessment may be that the studies were in their preliminary stages, or evaluation was provided later in another related study.
-For QA4 (research limitations documented). 79% was obtained. We find this result positive (above average) for all the primary studies. Therefore, this result is equally positive.
-Concerning QA5 (challenges of measuring transparency documented). The result obtained was 71%, which is also positive. However, of all the primary studies evaluated, only QA2 yielded an average result because some reviewed studies did not provide concrete descriptions of the relationships between transparency factors.
Overall, the quality assessment is considered positive, and we can be confident about the studies retained and the outcome of the SLR study.

C. THREATS TO VALIDITY
In this section, we analyze the threats to the validity of our SLR study. In identifying and analyzing the threats, we applied Wohlin et al.'s [51] 4-points categorization of threats, including construct, internal, external, and conclusion validity threats.

1) CONSTRUCT VALIDITY
According to Wohlin et al., construct validity is related to generalizing the research outcome to the construct, concept, or theory that motivated the study. To minimize the effect of this threat, we followed the same approach in [52] by utilizing several synonyms representing the primary constructs of transparency in our SLR search string and the whole study. In addition, we normalized the term researchers used to present and describe transparency during the data synthesis phase. We further used the most common terms in our report and sometimes interchangeably. Finally, given that transparency is complex, we established two primary contexts of transparency conceptualization and application: information and process transparency. This delineation enabled us to retrieve studies about transparency.

2) INTERNAL VALIDITY
This threat concerns arriving at a wrong conclusion when investigating causal relationships [51]. An SLR's conduct aims to minimize internal validity threats in the research [12], [57]. We implemented a study selection approach to mitigate internal validity threats that reduced personal biases by enlisting an external researcher's opinion and random evaluation of selected primary studies.
The quality assessment of selected primary studies also helped to minimize internal threats to validity. Sequential and sometimes iterative conduct of the study selection process also helped to mitigate this threat. We searched seven major digital libraries covering computing and its related subdisciplines. This is also in addition to manually searching the related work sections of the studies we selected based on the abstract.

3) EXTERNAL VALIDITY
This validity seeks to establish a generalization of the SLR findings [52]. It is related to the extent to which the included primary studies are representative of the topic and goal of the review. In the context of an SLR study, the assessment of external validity will depend on the selected primary studies to the extent that, if an included primary study is not externally valid, neither is the synthesis of its content [53]. To minimize this threat, we opted not to include papers from the grey literature-this formed part of our paper inclusion criteria. We arrived at our search process after an initial investigation and several rounds of pilot searches. In addition, we included studies that considered transparency as a first-class concept from January 2006 to March 2022. The exclusion of studies that did not treat transparency as a first-class concept may affect the SLR result's generalizability.

4) CONCLUSION VALIDITY
This validity aims to show and ensure that an SLR study's procedures can be repeated and the same results produced [54]. Our SLR was conducted following Kitchenham and Charters' guidelines [15], which helped mitigate conclusion validity threats. However, there is already an assumption by the guidelines to the effect that not all relevant existing primary studies can be identified in the literature. To reduce this threat, an SLR protocol was defined and validated for use in the actual conduct of the SLR. The validation helped reduce the risk and exclude irrelevant papers while keeping with the SLR study's goal. This effort is in addition to utilizing various synonyms that fit the description of the notion of transparency. We also conducted a manual search by searching the related work section of the included studies based on abstracts

D. RQ1. HOW HAS TRANSPARENCY BEEN CONCEPTUALIZED IN INFORMATION SYSTEMS AND SOFTWARE ENGINEERING?
This main research question aims at ascertaining the extent to which transparency in IS and SE has been conceptualized. VOLUME 10, 2022 To effectively answer RQ1, sub-research questions RQ1.1 to RQ1.5 were identified. The answers to the sub-research questions are provided next.  Table 8 indicates the definitions of transparency. Other reviewed studies [PS4, PS15] provided appropriate definitions of transparency adopted from the same referenced source.

2) RQ1.2-WHAT ARE THE EXISTING FACTORS OF TRANSPARENCY AND THEIR STRUCTURAL RELATIONSHIPS?
This question aims to identify and analyze the factors proposed to measure transparency. Table 9 presents the various factors of transparency and their corresponding definitions. The Proposed Application indicates the context in the factor may be operationalized. The factors that do not have definitions are left blank because the primary study did not provide a definition. Since the concept of transparency and its factors are described using various terminologies in different studies, our SLR aims to normalize these standard terms and use them consistently in the paper. Therefore, we use factors to refer to attributes, notions, or softgoals of transparency.
It is important to note that Table 9 does not indicate relationships between factors, and all factors are at the same level of abstraction. We show relationships between factors and their levels of abstraction in the later part of this section. Also, factors were extracted from all included primary studies. Therefore, some factors could be semantically equivalent to other factors because different authors similarly proposed them. Therefore, Table 9 should be considered a general catalog of transparency describing factors.
Furthermore, it is worth noting that not all primary studies may be included as part of the overall result. For instance, studies that did not propose any transparency factor but only applied it based on another study would not be referenced. In addition, based on our data extraction criteria and categorization (see Table 5), studies may be included in more than one category.
The factors in Table 9 are partly a direct response to RQ1.2. The factors were extracted based on the data extraction criteria previously presented in Table 5. The factors of transparency provided by primary studies [PS9, PS10] appear to be repetitive in some papers. We, therefore, captured such factors once. We also applied the same criteria to other primary studies that have repeated factors. The repetition of some of the factors arose because they and their corresponding relationships are a product of several decomposition, aggregations, and refinements during the research. Some of the factors are common to the non-functional requirements framework reported in [55] since they were mapped to the framework. The authors conceptualized transparency based on the framework. We consider some factors (e.g., understandability, portability) as non-functional software quality factors [56]. As provided by the authors in [PS4, PS6, PS7], the factors of transparency did consider the information and process transparency requirements and the channel of communication.
The authors in [PS13] also proposed factors, some of which are common to the other reported studies. The reference sources of the factors are part of the general references for the SLR provided in the references section. Table 10 further provides commonly proposed factors of transparency and notion that are unique to the reviewed paper. For readers, especially those interested in implementing transparency, Table 10 can serve as a reference for widely applied factors that can also be used to evaluate related stakeholders' transparency requirements they desire to achieve.

a: NAME OF TRANSPARENCY CONCEPTS AND REFERENCE
The SLR also aimed compile the names of transparency concepts provided in the reviewed article and their reference sources. Based on the reviewed articles, transparency appeared to be the most common name used by researchers when conceptualizing transparency. We did not encounter any other terms such as openness or disclosure that have commonly referred to as transparency.

b: TERMINOLOGIES USED
Depending on some approaches (e.g., goal modeling, IEEE metric methodology) used to conceptualize transparency, transparency researchers have introduced several terminologies, all of which appear to refer to the same properties or characteristics of transparency. Concerning the terminologies used, the reviewed articles presented various conceptualizations and descriptions of transparency using terms such as ''concept'' and ''softgoals'' [PS10], ''notion'' and attributes [ PS1], ''facets,'' and ''reference models'' [PS4], ''factor,'' ''sub-factor,'' ''metric'' [ PS14]. For example, in [PS10], transparency is described as a ''soft concept'' that consists of interrelated softgoals that help its achievement. Softgoals are non-functional requirements that can also be considered attributes or factors such as accessibility and usability, all of which contribute to transparency. In primary studies [P1, PS3], transparency is presented as a concept with describing properties termed factors.
The primary study [PS5] described transparency as a concept and used the term ''facets'' and ''properties'' to refer to the four main dimensions of transparency that may be achieved. Each facet consists of several sub-dimensions of transparency that should be fulfilled while evaluating transparency. Based on the four facets (transparency usefulness, transparency meaningfulness, transparency stakeholders, and information quality) of transparency proposed in [PS5], the authors further used the term ''reference models'' to refer to and also define various conceptual models of transparency in [PS4]. Four reference models were proposed -each reference model corresponding to each transparency facet. A reference model is an abstract framework for understanding essential relationships amongst the entities of a particular phenomenon, property, or system [57].
We observed that, though the sub-dimensions of each transparency facet could be regarded as factors of transparency based on their names and definitions, the authors used the term ''steps'' to refer to each factor and the order to evaluate it in the case of Transparency Usefulness property. It is also worth noting that the Transparency Stakeholders facet and its accompanying dimensions are not provided in Table 9 because it does not appear to be at the level of other transparency factors. The transparency stakeholders facet only serves to identify stakeholders and entities involved in transparency implementation. This explanation is also applicable to Transparency Recipients in [PS16].
In [PS16], transparency is presented as a concept that may be assessed through several factors. Though Transparency Recipients is not a property of transparency, its sub-dimensions are in the form of questions (e.g., ''Do the recipients depend on information providers?) that appear under transparency factors (e.g., information dependability, value, consistency) and, therefore, considered as such. As earlier provided in our criteria, the concept of transparency may be defined based on well-defined properties that enable its evaluation. By adopting the term factor, we have normalized the various terms used by researchers to conceptualize and measure transparency.

c: MEANS OF REPRESENTATION
Concerning the means of representation, the concept of transparency and its describing factors was generally represented as diagrams with texts. The primary studies reviewed provided various means of representation. For example, Furthermore, PS14 defined and modeled several metrics for assessing transparency via its various describing factors. Finally, the authors in [PS15] used text to describe a proposed framework for achieving transparency. Since some of the primary studies are later publications of the same authors, there was no need to multi-count the number of studies that indicated a means of representation. Furthermore, the indication of a means of representation in one primary study may not be captured in the authors' later publications, and such representations do not necessarily need to be captured. This also applies to other cases.

d: TRANSPARENCY FACTORS AND STRUCTURAL RELATIONSHIPS
We relied on the framework provided in Table 5 to present the factors of transparency. Structural relationships refer to how the factors of transparency are defined and how they relate structurally with each other to offer meaning to transparency.We consider the number of factors that can be identified for a given concept of transparency to indicate the transparency concept's clear presentation.
Primary studies [PS2, PS5, PS10, PS14, PS17] provided several transparency primary factors together with their sub-factors in most cases. These sub-factors were grouped in a manner that indicates a proposed relationship, and together they help assess transparency via their respective primary factors. The factors and relationships we have identified are provided in Table 11. As Table 11 further indicates, transparency can be assessed by one or more main factors. These primary factors are further evaluated by sub-factors that can directly be measured.

3) RQ1.3-WHAT ARE THE REFERENCE DISCIPLINES OF TRANSPARENCY FACTORS?
The purpose of this sub-research question is to identify and analyze the various reference disciplines (i.e., the origins of transparency factors) where transparency factors were initially proposed.
Besides the structural factors of transparency, Table 11 also provides the reference disciplines for the various factors of transparency. Based on the paper's indications, we determined the reference disciplines (i.e., origins of the transparency factors). The transparency factors have been derived from computing disciplines such as IS, SE, and HCI. Other non-computing fields include business management (Bus Mgt.), business and information management    (Bus & Info Mgt.), philosophy, law, business administration (Bus Admin), health information systems (HIS), government and organizational behavior. This array of disciplines shows that transparency is a global concept that permeates different disciplines. These contributing disciplines also indicate that transparency is a multidisciplinary concept and equally multifaceted.
We observed that the complexity of the concept implies that when adopted, it will require new argumentation to fit the peculiarities of the domain and context it is applied. For VOLUME 10, 2022 instance, in IS, PS10 conceptualized transparency and provided operationalizations for factors such as accessibility and usability. In SE [PS3], the factors of accessibility, understandability, and relevance were operationalized. However, the factors of transparency that may be used to evaluate transparency at the process level may not be used for assessing transparency at the product level. For example, the transparency metrics proposed in [PS13] cannot be generalized to SE. This difference in operationalizations explains why there are different conceptual argumentation and operationalizations of transparency.

4) RQ1.4-WHAT ARE THE MAIN RESEARCH APPROACHES USED IN CONCEPTUALIZING TRANSPARENCY AND THE CONTEXT OF CONCEPTUALIZATION?
For RQ1.4, Table 11 also shows the two primary contexts in which transparency has been conceptualized and the main research approaches used. The contexts are information and process transparency contexts. The approaches are either qualitative, quantitative, or both.

a: RESEARCH APPROACHES
Two notable approaches found in the primary studies reviewed are qualitative and quantitative. Primary studies [PS4, PS5, PS7, PS8, PS10] used the former approach, which incorporated modeling and survey. Primary study PS13 followed a quantitative approach by defining metrics to evaluate the transparency of information produced by an information system. Their approach also employed modeling. Primary study PS3 adopted a quantitative approach that incorporated experiment and survey. Very few primary studies adopted a quantitative research approach to conceptualizing transparency.

b: DIMENSIONS OF CONCEPTUALIZATION
Based on the reviewed papers, there are two main dimensions in which transparency has been conceptualized: information (information transparency) and process (process transparency) contexts. Most of the conceptualizations reported in the primary studies (e.g., PS10, PS4) have focused on achieving information transparency using a qualitative research approach. Such conceptualizations appeared outside the information or software systems development process. Also, primary studies PS3 and PS13 followed a quantitative research approach in conceptualizing transparency from the context of information transparency.
Concerning the achievement of transparency during software development, only one primary study [PS3] conceptualized transparency in an information context by evaluating the effectiveness of software requirements specifications. Therefore, the operationalization and the approach adopted, therefore, emphasizes the transparency of software artifacts. Furthermore, it further distinguishes the focus of SE transparency conceptualization from IS conceptualizations that have so far been reported in the literature.

5) RQ1.5-WHAT ARE THE METHODS USED TO EVALUATE TRANSPARENCY?
This sub-research question aims to identify and analyze the methods used in evaluating transparency after its conceptualization. If transparency factors are investigated, it is reasonable to consider how such factors are evaluated. In other TABLE 11. Structural factors of transparency and their relationships. VOLUME 10, 2022 words, the method used to evaluate the implementation of each transparency factor. For instance, factors such as accessibility, relevance, understandability can be evaluated through a survey or experiment. Existing studies on transparency may report different methods to assess transparency achievement.
All the 18 primary studies were assessed for any form of evidence that demonstrates transparency achievement evaluation. Primary studies that did not provide any assessments are not included as part of this category.

a: EXPERIMENTS WITH TRANSPARENCY
In this study, we systematically reviewed the conceptualization and operationalization of transparency. In this vein, retrieving and assessing primary studies that reported experiments using transparency formed part of our research questions (RQ1.5) in addition to other studies that reported other forms of evidence outside experiments.
In order to identify what constitutes an experiment, we borrowed the definition and view provided in [58], [59], and [60]. According to Sjøberg et al. [60], ''controlled'' experiments are undertaken by either individuals or a group of individuals by conducting tasks to compare treatments in terms of varying processes, populations, and methods, for instance. As explained in Cook et al. [61], we also considered randomized and quasi-experiments since they are also used in SE.
All included primary studies were assessed for experiments. However, only two primary studies [PS2, PS3] from the same authors reported a controlled experiment. Primary study PS2 is a conference paper that was later extended and published as an article [PS3] in the Empirical Software Engineering journal.

b: CASE STUDY, SURVEY, AND FRAMEWORK
To not be biased in our review, we also included studies that employed other methods for evaluating transparency. We understand that since transparency is multifaceted, evaluating its achievement need not necessarily involve performing controlled experiments, as is often the case when concepts or theories are formulated. Primary studies [PS10, PS4] evaluated transparency using various case studies together with surveys. In [PS13], the authors' defined metrics were used to evaluate transparency achievement in their case study. In [PS7], a framework that combines a transparency modeling language was proposed, and an evaluation was performed using a case study. In [PS15], the researchers also presented a framework to evaluate transparency, but the actual evaluation was yet to be reported.

E. RQ2-WHAT ARE THE EXISTING OPERATIONALIZATIONS OF TRANSPARENCY?
Previously in Section V-D, we provided the existing factors of transparency. This section presents various operationalizations of transparency based on the proposed factors. As previously explained in Section II, operationalization involves the actual use of the factors of a concept in measuring the achievement of the concept. An operationalization, therefore, provides evidence of the practical significance of the concept that is being examined in a real-world scenario. It also analyses the extent of the use of the transparency concept. Thus, transparency remains a valuable concept. All the articles reviewed in this study demonstrated the usefulness of transparency.
c: OPERATIONALIZATIONS Table 12 presents a summary of the implementations and measurement of transparency. It also indicates whether the operationalization was within an information or process transparency dimension. Transparency has been proven useful in improving business processes, as reported in Leite and Cappelli [PS10]. Transparency has also been applied in analyzing election systems with security and e-government

d: EXTENT OF OPERATIONALIZATION
Concerning the extent of the operationalization of transparency, we considered primary studies that adopted existing concepts of transparency to further research on transparency by applying it to other domains or providing new conceptual argumentation. As an emerging concept, we found the extent of the operationalization of transparency to be minimal. For example, in SEP, only studies by Tu et al. [PS2,PS3], to the best of our knowledge, have attempted to consider the achievement and evaluation of transparency in the SDLC requirements engineering phase. We did not encounter any primary study that used the conceptualization by Tu et al. to further research transparency. For instance, the primary study PS15 applied the transparency conceptualization provided in [PS4, PS5].
Though other studies (e.g., PS4, PS5, PS10) from the information systems point of view focused on managing transparency requirements in information transparency and process transparency contexts, Tu et al. instead focused on achieving transparency requirements in an IT context but considering the transparency of software artifacts. Their work shows that transparency can also be realized in the way functional requirements of a system are represented as requirements and design documents by choosing requirements or a design development paradigm that encourages transparency.

F. RQ3-WHAT ARE THE CHALLENGES WITH OPERATIONALIZING TRANSPARENCY?
One of the key challenges in applying transparency is inherent in the concept itself. It is a complex concept with varying ambiguities [PS10, PS4, PS13]. For instance, the demand and provision of transparency should not antagonize security and confidentiality requirements [39], [62]. This aspect is beyond the scope of our study. However, Serrano et al. [62] provided how transparency might be achieved without compromising the security and confidentiality of information.
Out of the 18 primary studies reviewed, four primary studies [PS3, PS10, PS4, PS13] provided clear challenges with implementing transparency. For example, Leite and Cappelli [PS10] outlined the challenges of incorporating transparency in the SEP. These challenges include trust in requirements that are intended to provide transparency, the cost of incorporating transparency in SEP without increasing overall development cost, performance in terms of the assurance of trust without interference with the performance of the system itself and lastly, how to deal with the public as ''customers.'' According to the authors, the last challenge stems from the fact that software engineers appear not to be too familiar with dealing with people in the real sense of a ''customer'', which requires different strategies.
According In [PS13], the authors opined that the design and implementation of transparency could result in risk exposure since information systems and their information are made transparent to stakeholders. There is, therefore, a need to have technically skilled people who can understand and deal appropriately with the information. The authors also suggested using tools that can aid stakeholders in this regard.
As it concerns software engineering, transparency appears to be in its formative stage. The challenge with achieving it is providing appropriate transparency requirements and measures that the stakeholders can utilize during information or software system development. The authors in [PS2, PS3] have explicitly called for transparency measures to be provided in this regard.

VI. DISCUSSION
In this section, we discuss the SLR findings and the limitations of the review and provide future research directions.

A. DISCUSSION ON HOW TRANSPARENCY HAS BEEN CONCEPTUALIZED IN INFORMATION SYSTEMS AND SOFTWARE ENGINEERING (RQ1)
In order to investigate how transparency has so far been conceptualized in IS and SE sub-disciplines of computing, it was reasonable to compile the existing definitions of transparency (RQ1.1); identify the current factors of transparency, and their relationships (RQ1.2); the origins or reference disciplines of the constructs (RQ1.3); identify fundamental research approaches used in conceptualizing transparency and the context of conceptualization (RQ1.4), and the methods used to evaluate transparency achievement (RQ1.5). The answers to these questions have already been provided in the previous section.
The primary studies we have reviewed in this SLR have conceived transparency as a non-functional requirement (NFR) and a new quality of information or software systems and processes they support. Transparency, therefore, stands as an additional quality concept to be considered among other NFRs provided in [55]. The SLR, thus, explores transparency from the point of view of concepts and then highlights the need for theories that support transparency. The studies in [41] and [42] have further shown why transparency should be approached from a conceptual and theoretical point of view. Adopting such an approach enabled us to identify the concept of transparency in terms of its describing factors, means of representation, structural components, and relationships between factors.
Early research on transparency argued that transparency is a concept that is best approached as a requirements engineering (RE) activity. All the reviewed studies appeared to agree with the approach. This approach is motivated because requirements engineering is the first and crucial phase of software or information systems development. During this phase, we believe that stakeholders' transparency requirements can be elicited and analyzed by a transparency implementation and evaluation team (TIET) that would need to be set up within an organization. Therefore, we envisage that an organization serious about incorporating transparency in its software development or organizational process would need to establish TIET for that purpose.
Furthermore, it is essential to note that transparency requirements can sometimes be related to the functional and non-functional requirements of a software or information system. After an elicitation activity, the TIET would have to identify appropriate transparency factors and sub-factors that may be used to evaluate the transparency and the evaluation method. The current SLR catalogs existing factors of transparency that will be useful in this regard. Since the catalog may not address all transparency requirements in all domains and contexts of interest, additional factors would have to be developed. Transparency's complex and multifaceted nature presents different opportunities for its operationalization during information or software systems development. An operationalization of transparency involves an actual implementation of any of the factors of transparency in a specific domain of interest and context. Stakeholders, especially developers, may utilize the factors of transparency we have cataloged in this paper when transparency achievement is being considered. The catalog, therefore, serves as a reference point for transparency operationalization.
Based on the reviewed studies, there are very few operationalizations of transparency. The reason may be that transparency is still yet to be supported by theories that enhance its understanding, thereby making it more useful. Operationalizations that followed a conceptual or theoretical point of view appeared very limited. Apart from the few previously highlighted examples of transparency operationalizations, other aspects of the information or software development process, including organizational processes, can also benefit from transparency operationalization.

C. DISCUSSION ON THE CHALLENGES WITH OPERATIONALIZING TRANSPARENCY (RQ3)
The complex characteristics of transparency require that when operationalized by TIET, it must be adapted to address the concerns of the domain and context in which it is being operationalized. This expectation is even more as there is an abundance of factors that helps the operationalization of transparency, as the catalog of factors indicates. The challenge concerning the cost of incorporating transparency into the general information or software systems development implies that any initiative that aims to introduce transparency must factor in the cost concerning the budget earmarked for the whole software development project. Apart from the financial cost, a transparency initiative should be such that it does not affect the project's delivery time.
There is also a need to address the problem of trust on the part of clients when stakeholders' transparency requirements are introduced and the reorientation of software developers to handle clients as customers. Since transparency operationalization and evaluation will be conducted based on stakeholders' transparency requirements, stakeholders must agree on a set of transparency requirements that should be evaluated and how the assessment could be achieved. This approach helps to overcome some of the challenges. The SE-based primary studies have shown a need to provide a measurement for transparency during software development. Providing a measurement in this regard will involve adopting a quantitative research approach and conducting experiments to ascertain the level of transparency achievement.

D. RESEARCH LIMITATION
In order to identify the concept of transparency and its various conceptualizations and operationalizations, this study relied on well-established guidelines for identifying theories and concepts [46], [47]. The data extraction criteria were also motivated by the same guidelines and the research questions. The SLR identified transparency as a concept in terms of describing factors and relationships between the factors. The SLR did not accommodate studies on transparency that do not consider it a concept. It is also important to emphasize that several studies that did not consider transparency as a first-class concept were also not included in the SLR. Studies that treated transparency in union with antagonizing concepts such as security and privacy were not considered in the current SLR. We hope to embark on another SLR that would accommodate such studies.

E. PROPOSED ROADMAP FOR TRANSPARENCY CONCEPTUALIZATION AND EVALUATION
The findings from the SLR make it imperative to provide a plan or template that will not only enable the evaluation of transparency achievement but stimulate further research on transparency conceptualization. Since the SLR did not find a clear plan to understand and evaluate transparency, this finding motivated and informed the roadmap to inspire and stimulate more interest in transparency research. The proposed roadmap is presented in Fig. 6. It captures a sequence of steps and essential constructs necessary to achieve a transparency conceptualization and the evaluation of transparency achievement. These steps, including the valuable constructs involved, are briefly explained as follows.

1) INITIAL CONCEPTION
Our approach to achieving transparency in software engineering aligns with the view that it should be conceived as a requirements engineering activity. This approach is inspired by Professor John Mylopoulos, who opined in [5] that ''transparency is an interesting quality because it makes it necessary to attach requirements models to software.'' Since transparency is a requirement of the stakeholders of an information or software system or process, it is reasonable to initiate its implementation and measurement during the requirements engineering phase of the software engineering process. During the requirements engineering phase, transparency requirements analysts can elicit stakeholders' transparency requirements and other normal requirements demanded of the software artifacts and software itself.
Though the SLR identified several existing definitions of transparency, the findings from this study and our belief in approaching transparency achievement from a transparency requirements engineering activity inspire us to provide a new definition to help our understanding and operationalization of transparency further. In this study, transparency refers to the degree to which information about a process or software/software artifact is made open to the stakeholders of a software engineering project. The process, as used here, includes automated or unautomated business or organizational processes such as software life cycle processes. As a caveat, a successful operationalization of the proposed definition will depend on establishing stakeholders' transparency requirements as a prerequisite to transparency operationalization. It is the fulfillment of the transparency requirements that would ensure the openness of information to stakeholders.

2) IDENTIFICATION OF STAKEHOLDERS
In this step, it is important to identify all stakeholders of the software system or the organizational process who may express various concerns regarding transparency. Transparency may not be achieved if all stakeholders who demand transparency are not involved in the transparency implementation and evaluation process.

3) TRANSPARENCY REQUIREMENTS
From a transparency requirements engineering point of view, for software processes and software/software artifacts to be made open to stakeholders, a set of stakeholders' transparency requirements will have to be established. Software processes and software/software artifacts would be deemed transparent or open to stakeholders if the set of preestablished stakeholders' transparency requirements is fulfilled. Therefore, in this step, it is necessary to collect all stakeholders' transparency requirements related to either the software that is being developed or any other business process (e.g., software life cycle processes) that may not be automated. To this end, it is the achievement of these transparency requirements that would be evaluated.

4) IDENTIFICATION OF TRANSPARENCY FACTORS
This step is concerned with identifying transparency factors that can be used to evaluate the achievement of the requirements provided in the preceding step. Successful identification and collection of transparency factors mean that operationalizations that demonstrate the usefulness of each factor in assessing transparency requirements can be considered. Since operationalization is the empirical measurement of a concept such as transparency, it would indicate the practical significance of each transparency-defining factor.

5) TRANSPARENCY METRICS
This step focuses on identifying measures and metrics that, in turn, assess the transparency factors identified in step 5. This step involves the actual operationalization of each factor of transparency towards the fulfillment of a targeted stakeholders' transparency requirement. The benefits of transparency conceptualization and operationalization will be incomplete if the transparency metrics are not used to improve stakeholders' transparency. For example, a poor transparency evaluation outcome would mean that the transparency of the evaluated software/software artifact or process will need to be improved upon. These identified critical elements of the proposed roadmap feed into a conceptual framework currently being developed as part of the first author's PhD work.
Summarily, the proposed roadmap serves as an early blueprint or steps that can be followed to evaluate transparency. Opportunities for further transparency research are provided in the next section.

F. OPPORTUNITIES FOR FURTHER RESEARCH
One of the significant findings of this study is that transparency has been majorly conceptualized as a non-functional requirement. It is also a non-functional requirement that is VOLUME 10, 2022 seldom approached from theory and empirical points of view. We also found from the reviewed studies that transparency is under-researched and under-applied, at least from the standpoint of our SLR study. This outcome lends credence to similar findings reported in [41] and [42] but in another domain outside computing. In this vein, our SLR may serve as evidence and a reference for transparency conceptualization in SE and IS.
More than a decade after its initial conceptualization, transparency appears not to have progressed in academia and the industry from our research perspective. This outcome is evident from the limited number of primary studies we found to have conceptualized and applied transparency in various contexts and disciplines, especially in IS and SE. The limited number of primary studies also appears to suggest a lack of interest in transparency research.
The current study also found that the operationalizations of transparency are limited. As most of the primary studies reported, the applications we encountered mostly served as proofs-of-concept. Beyond these applications, transparency is yet to be fully recognized and incorporated as a requirement that improves an organization's software development process, software artifacts, and the software itself. There is, therefore, a need to establish a recognizable and valuable transparency improvement model or standard that organizations can adapt to any existing software engineering process improvement program.

1) NEED FOR TAILORED CONCEPTUALIZATIONS AND OPERATIONALIZATIONS
The study identified several factors of transparency, including their proposed relationships. Given the numerous factors we have cataloged, achieving all stakeholders' transparency requirements is impossible without overburdening the software engineering process. To reduce the burden, there is a need for research that provides tailored argumentation of transparency in the software engineering context. Also, because transparency is complex and multifaceted, a transparency solution is hardly a one-size-fits-all solution; hence tailored transparency conceptualizations and operationalizations are needed for software, software artifacts, and processes (including other organizational processes) that give birth to them.

2) NEED TO EXPLORE OTHER PHASES OF INFORMATION OR SOFTWARE SYSTEMS DEVELOPMENT
Only one primary study conceptualized transparency in an information transparency context and within the requirements engineering phase. Therefore, the study results cannot be generalized to the other phases of the software development process. A transparency realization initiative within the software development process should consider the various phases of development in software engineering. The benefit of achieving transparency during software development is yet to be fully explored as other phases of development remain unexplored. The reviewed primary study evaluated the transparency of software requirements specifications. Further studies can investigate how other software artifacts such as design documents and code and their corresponding process models could benefit from transparency.

3) NEED FOR MORE EXPERIMENTS AND FORMALIZATION OF TRANSPARENCY
In SE, transparency has witnessed limited research and application, unlike IS, with more published studies and applications of transparency. However, we still considered the IS studies to be few, given the period of our SLR coverage. Based on our results, only two primary studies reported an experiment on transparency evaluation by stakeholders in SEP. A single experiment is not sufficient for providing scientific evidence that supports the usefulness of transparency in software development.
In software development, providing scientific and practical evidence (formalization) that supports transparency would make transparency interesting to the research community and valuable in the industry. Also, such evidence can potentially serve as a pathway to the development of a standard or model for a transparency implementation and improvement program that complements the software engineering process capability maturity model that is in use by most software companies. Our proposed roadmap lays a foundation for our quest to formalize and create a standard for a transparency improvement initiative.

VII. CONCLUSION
In this study, we conducted a systematic literature review of the conceptualization and operationalization of transparency. Our findings revealed that transparency had been conceived as a non-functional quality of the stakeholders of software or processes. Based on the reviewed studies, most researchers opined that the best approach to achieving transparency is to consider it a requirements engineering activity. In SE and IS, transparency is yet an emerging concept, which remains rarely approached from a theoretical and empirical standpoint. It also revealed that research on transparency and its practical applications is limited, especially in SE. The paucity of papers could suggest that transparency no longer trends as a concept of research in computing.
Most of the articles we reviewed have conceptualized transparency in an information context. Only three SE studies focused on conceptualizing and applying transparency to the software engineering process as they focused on the transparency of software artifacts. We did not find any study that altogether provided empirical evidence showing cause-effect relationships between the structural factors from a theory point of view. The lack of empirical studies presents a challenge, especially when considering the transparency of software and software artifacts. There is a need for further research on transparency, especially its formalization. We hope the current study will help stimulate further research and reawaken interest in transparency research. BASSEY ISONG (Member, IEEE) received the B.Sc. degree in computer science from the University of Calabar, Nigeria, in 2004, the M.Sc. degrees in computer science and software engineering from the Blekinge Institute of Technology, Sweden, in 2008 and 2010, respectively, and the Ph.D. degree in computer science from North-West University, in 2014. He is currently an Associate Professor with the Department of Computer Science and a Faculty Member of the North-West University, Mafikeng Campus, South Africa. His research interests include and are not limited to software engineering, security, software-defined wireless sensor networks, low power wide area networks, cloud computing, the Internet of Things, machine learning, and big data. He is also a member of the IEEE Computer, Communication, and Education Societies and the ACM.

APPENDIX
FRANCIS LUGAYIZI received the Doctor of Philosophy (Ph.D.) degree in computer science from North-West University/Noordwes-Universiteit. He is currently an Experienced Senior Lecturer with a demonstrated history of working in the higher education industry. He has skilled in computer networking and database systems. He strives to become an Independent Academic and a Researcher to contribute to the ever-changing quality of service (QoS) and quality of experience (QoE) of next generation computer and communication networks within ICT. After completing his Ph.D. training and research activities in next generation networks (NGNs), in October 2016, his intention is to develop a research and curriculum leadership capacity to analyze, criticize, recommend and spearhead either the enhancement of existing or the development of new optimization techniques of the network and application layers to ensure improved end-user perceived QoS, with main reference to next generation computer networks.