A Modelling Language for Transparency Requirements in Business Information Systems

Abstract

Transparency is a requirement of businesses and their information systems. It is typically linked to positive ethical and economic attributes, such as trust and accountability. Despite its importance, transparency is often studied as a secondary concept and viewed through the lenses of adjacent concepts such as security, privacy and regulatory requirements. This has led to a reduced ability to manage transparency and deal with its peculiarities as a first-class requirement. Ad-hoc introduction of transparency may have adverse effects, such as information overload and reduced collaboration. We propose a modelling language for capturing and analysing transparency requirements amongst stakeholders in a business information system. Our language is based on four reference models which are, in turn, based on our extensive multi-disciplinary analysis of the literature on transparency. As a proof of concept, we apply our modelling language and the analysis enabled by it on a case study of marking exam papers.

1 Introduction

Transparency, and transparent decision-making, is generally considered to be a requirement of democratic societies [15]. Recently, transparency has received a lot of attention, e.g., following the financial crisis of 2008 which was the result of the lack of transparency in financial environments [4], or the Ashley Madison incident which was the result of unnecessary, unwanted transparency [11]. The escalated attention to transparency is supported by the fact that the millennials and the younger generation live in a more transparent world [16] and demand even more transparency [10].

With transparency requirements on the rise, one expects to find a vast body of literature studying transparency, its causes and its effects. This is not far from the truth. The literature on transparency spans several fields of study, such as politics [3], sociology [1], and management [13]. In computer sciences, transparency has also been occasionally studied. For example, transparency is frequently observed as a requirement of various stakeholders within a business information system (BIS) which must be satisfied [6, 7].

However, the literature on transparency in general, and in computer sciences in particular, still lacks a critical focus, which is a systematic modelling of transparency. Without a rigorous and systematic model, several other problems cannot be duly addressed. The first problem is that a transparency model can facilitate a consistent method for eliciting transparency requirements of stakeholders. Second, a transparency model can provide methods for analysing transparency, which could be automated as well. Third, a rigorous transparency model can also make way for automated validation and evaluation of transparency. Such a model, however, does not still exist for transparency.

Based on our extensive multi-disciplinary literature study on transparency and our transparency facets [8], in this paper we propose TranspLan, a language for modelling and analysing of transparency requirements in a BIS. This language facilitates different aspects of transparency requirements elicitation, modelling and analysis. We define the TranspLan language mathematically, provide a graphical representation for it, and enrich it with two specification models.

The rest of the paper is structured as follows. In Sect. 2 we explain the background study for our transparency language. In Sect. 3 we introduce our transparency language, formally define it and provide its mathematical definition. In Sect. 4 we evaluate our language using a case study involving transparency requirements of different stakeholders in a coursework marking exam in a university. We conclude our work in Sect. 5.

2 Background

Few studies in the field of computer science have attempted to model transparency, mostly from a requirements perspective. [2] is amongst the first works on transparency modelling, which argues that NFR Framework [5] and i* modelling [17] can manage transparency requirements. Interestingly, the paper concludes that i* modelling is not the ultimate answer to transparency, and augmentations to this model might be needed for a more efficient management of transparency requirements. This work has also led to a more detailed work on transparency in [12], which discusses software transparency using Softgoal Interdependence Graph (SIG). This paper also proposes a transparency ladder, which contains five non-functional requirements that must be met in order to reach transparency. Finally, [14] proposes the use of Argumentation Frameworks to elicit transparency requirements of stakeholders.

We introduce three reference models for engineering transparency, based on transparency facets [8], advocating these models are needed alongside a fourth dimension, i.e., information quality [9]. These reference models are as follows:

Fig. 1.

Transparency actors wheel with transparency classifications

Fig. 2.

Transparency depth pyramid (meaningful transparency)

Fig. 3.

Transparency achievement spectrum (useful transparency)

• 1. Transparency Actors Wheel: This reference model discusses the stakeholders involved during transparency provision. Based on their position in information disclosure, these stakeholders are categorised as: (1) information provider, (2) information receiver, (3) information entity, and (4) information medium. A summary of this reference model can be viewed in Fig. 1.

• 2. Transparency Depth Pyramid: This reference model explains the level of transparency meaningfulness based on the content of disclosed information. These levels are: (1) data transparency, (2) process transparency, and (3) policy transparency. A summary of this reference model can be viewed in Fig. 2.

• 3. Transparency Achievement Spectrum: This reference model describes the steps of reaching transparency usefulness based on stakeholders’ ability to act upon the disclosed information in order to make informed decisions. These steps are: (1) information availability, (2) information interpretation, (3) information accessibility, (4) information understandability, (5) information perception, (6) information acceptance, and (7) information actionability. A summary of this reference model can be viewed in Fig. 3.

3 TranspLan: A Transparency Modelling Language

Based on the proposed reference models for providing transparency, we introduce Transparency Modelling Language, or TranspLan, which helps a BIS in engineering their transparency requirements. TranspLan consists of StakeHolders’ Information Exchange Layout Diagram (Shield diagram) for the visual representation of information exchanges amongst stakeholders and their transparency requirements. TranspLan is also accompanied by two descriptive specification models for information elements and stakeholders, called INFOrmation eLEment Transparency Specification (Infolet specification) and Stakeholders’ Information Transparency REQuirements Specification (Sitreq specification), respectively. These specification models explain the information elements and the stakeholders with their elicited transparency requirements in the Shield diagram.

3.1 Modelling Constituents and Representations

The TranspLan language is mainly built based on three different constituents: stakeholders, information elements, and the relationships between stakeholders and information elements. Relationships can be decomposed using decomposition relations. An information exchange is a combination of all these constituents and illustrates the flow of information amongst different stakeholders. These constituents are described as follows.

• Stakeholders are the people, departments, organisations, etc., which are involved in providing, receiving, or requesting transparency in any information exchange amongst stakeholders. When categorising stakeholders, they are commonly represented as one entity, e.g., Student or Finance Department. However, the exchanged information within an information exchange system may concern all the stakeholders within that system, or it may even concern the public audience.

• Information elements are pieces of information exchanged amongst stakeholders. Stakeholders’ transparency requirements affect the way information elements should be formed and presented to other stakeholders. Information elements have a type, which is related to their transparency meaningfulness. These types can be the data type, the process type, or the policy type.

• Stakeholder-information relationships exist between stakeholders and information elements, and they describe how the information element is associated with the stakeholder. The production relationship denotes that the stakeholder produces the information element for other stakeholders. The obligation relationship denotes that the stakeholder provides the information element based on coercive supply or requests the information element based on legal demands. The optionality relationship denotes that the stakeholder provides the information element based on voluntary supply or requests the information element based on personal demands. The restriction relationship denotes that the information element should not be available to the stakeholder. The undecidedness relationship denotes that the relationship between the stakeholder and the information element is not known or decided yet.

• Decomposition relations exist between some relationships and can be one of the following: the and decomposition relation, the or decomposition relation, and the xor (exclusive or) decomposition relation.

• Information exchanges illustrate the flow of information from an information provider to an information receiver or requester. An information exchange system is a collection of all information exchanges in a BIS.

3.2 TranspLan Mathematical Definition

The TranspLan language and its constituents can be defined using the ordinary mathematical language as follows:

Definition 1

(Information element). Let $IE=\{ie_{1},ie_{2},...,ie_{m}\}$ be the set of information elements, and IE_Label and IE_Name be sets of unique labels and names respectively. Every $ie_{i} \in IE$ can be defined as follows:

$IE=\{ie|ie=(ietype,ielabel,iename,ieused)\ \wedge \ ietype \in IE\_type\ \wedge \ ielabel \in IE\_label\ \wedge \ iename \in IE\_name\ \wedge \ ieused \subset ielabel\}$

$IE\_type=\{data,process,policy\}$

Definition 2

(Stakeholder). Let $S=\{s_{1},s_{2},...,s_{n}\}$ be the set of stakeholders, $IE=\{ie_{1},ie_{2},...,ie_{m}\}$ be the set of information elements, and $R=\{r_{1},r_{2},...,r_{l}\}$ be the set of stakeholder-information relationships. The set of stakeholders and two subsets of S, called PS and RS, can be defined as follows:

$S=\{s|s\ is\ a\ stakeholder\}$

$PS=\{s|s \in S\ \wedge \ ie \in IE\ \wedge \ (s,ie,production) \in R\}$

$RS=\{s|s \in S\ \wedge \ ie \in IE\ \wedge \ rt \in \{obligatory,optional,restricted,undecided\}\ \wedge \ (s,ie,rt) \in R\}$

Definition 3

(Stakeholder-information relationship). Let $R=\{r_{1},r_{2},...,r_{l}\}$ be the set of relationships where each relationship is between stakeholder $s_{i} \in S$ and information element $ie_{j} \in IE$. Every $r_{i} \in R$ can be defined as follows:

$R=\{r|r=(s,ie,rtype)\ \wedge \ s \in S\ \wedge \ ie \in IE\ \wedge \ rtype \in R\_type\}$

$R\_type=\{production,obligatory,optional,restricted,undecided\}$

Definition 4

(Decomposition relation). Let $Rel=\{rel_{1},rel_{2},...rel_{k}\}$ be the set of relations where each relation is between two or more relationships $R_{1},R_{2}, ...,R_{j} \in R$. Every $Rel_{i} \in Rel$ can be defined as follows:

$Rel=\{rel|rel=(r_{1},r_{2},..,r_{j},reltype)\ \wedge \ r_{1},r_{2},..,r_{j} \in R\ \wedge \ reltype \in Rel\_type\}$

$Rel\_type=\{and,or,xor\}$

Definition 5

(Information exchange). Let $IEX=\{iex_{1},iex_{2},...,iex_{t}\}$ be the set of information exchanges amongst stakeholders where one stakeholder $s \in PS$ produces some information elements $IESet \subset IE$ that is received or requested by a group of other stakeholders $RSSet \subset RS$ and $s \notin RSSet$. Every information exchange $iex_{i}$ can be defined as follows:

$IEX=\{iex|iex=((s_{i},ie_{i},r_{i}),(s_{j},ie_{i},r_{j}))\ \wedge \ s_{i} \in PS\ \wedge \ s_{j} \in RS\ \wedge \ r_{i}=production\ \wedge \ (s_{i},ie_{i},r_{i}), (s_{j},ie_{i},r_{j}) \in R\}$

3.3 Shield Diagram

The Shield diagram is the graphical representation of the TranspLan language. The constituents of the TranspLan language can be illustrated in the Shield diagram as follows.

Stakeholders are illustrated in one of the four following ways.

• One stakeholder can be illustrated by a circle with the stakeholder’s name inside the circle.

• All stakeholders within an information exchange system can be shown by two nested circles, labelled All. This is mainly for the purpose of facilitating a more efficient, clutter-free visual design.

• The previous notion is further enriched by the exclusion notation, which uses brackets inside the two nested circles with an All label to refer to those stakeholders who are excluded from the information exchange. For example, two nested circles with the label ‘All [Supervisor]’ will indicate that information is received by or requested by all stakeholders inside the information exchange system, except the supervisor.

• Three nested circles, labelled Public, are also utilised in this diagram to refer to the public, i.e., all stakeholders inside and outside the information exchange system under study.

Information elements are illustrated by a three-part rectangle. In the left-side part, the type of information element is written. This type shows the meaningfulness of the information element in the transparency setting, and can hold one of the following values, or it can be left empty if the nature of the information is unknown during the diagram design.

• Data illustrates an information element containing only data.

• Process illustrates an information element containing processes (and data).

• Policy illustrates an information element containing policies (and processes and data).

The middle part of the information element is used for the information element label and information element name. The label is a unique tag that can be used to identify the information element. The right-side part is used to list all the other information element tags which use, partly or completely, the current information element. This can be used to track how information travels and can also be used to check whether information is received by stakeholders who are not meant to receive it.

Stakeholder-information relationships are illustrated by either simple lines, dotted arrows, or double lines, and always connect stakeholders to information elements.

• Simple lines imply the production of information by a stakeholder.

• Dotted arrows with a black head show obligatory information flow that arises either from coercive information provision, or legal information requests.

• Dotted arrows with a white head denote optional information flow that is the result of voluntary information provision or personal information demands.

• Dotted arrows with a circle head illustrate information flows whose nature (i.e., obligatory, optional) is undecided at the time of diagram design.

• Double lines indicate that the information element is not meant for the specified stakeholder and must be hidden from them.

Arrows are intentionally chosen to be dotted in order to emphasise that such information flow may or may not serve its transparency purpose because its usefulness must be decided through complicated procedures and involvement with stakeholders which simply cannot be captured through such diagrams. For this reason, we use two specifications, as described in the next subsections.

Decomposition relations describe the relationship amongst relationships. Relationships of any kind can have the following relations amongst them.

• And relation is the default relation.

• Or relation is shown by a line amongst relationships.

• Xor (exclusive or) relation is shown by double lines amongst relationships.

Information exchange system is illustrated by a rectangle divided into four parts and is illustrated as follows.

• The top left part is reserved for the information exchange system name.

• The top right part is used to write extra notes regarding the information exchange system.

• The bottom left part is used to list all the stakeholders in the information exchange system, including two pre-defined All and Public stakeholders.

• The bottom right part is the main part and is used to draw the information exchange amongst the stakeholders, using the notation described above.

Figure 4 illustrates the summary of the aforementioned building blocks used in a Shield diagram.

Fig. 4.

Building blocks of Shield and their interpretations

3.4 Sitreq Specification

Every stakeholder in the Shield diagram is accompanied by Stakeholder’s Information Transparency REQuirements Specification (Sitreq), as illustrated in Fig. 5. Sitreq is a descriptive tool for stakeholders and their transparency requirements in the Shield diagram. Sitreq explains how stakeholders are related to certain information elements, their transparency requirements on those information elements, and other stakeholders involved in the process.

Fig. 5.

Stakeholder’s Information Transparency REQuirements Specification (Sitreq)

Fig. 6.

INFOrmation eLEment Transparency Specification (Infolet)

3.5 Infolet Specification

Every information element in the Shield diagram is accompanied by a INFOrmation eLEment Transparency Specification (Infolet), as illustrated in Fig. 6. Infolet is a descriptive tool for information exchanges in the Shield diagram. It describes each information element (IE) in the diagram, providing more in-depth information on them. Infolet is meant to capture all the four reference models of transparency, along with general modelling information required for each information element, as follows. The numbers on parentheses illustrate the corresponding segments in Infolet.

• 1. General modelling requirements (1, 2, 4, 5, 13)

• 2. Transparency depth pyramid (3)

• 3. Transparency actors wheel (6, 7, 8, 9, 10)

• 4. Transparency information quality (11)

• 5. Transparency achievement spectrum (12)

3.6 Transparency Requirements Analysis

Our modelling language, TranspLan, and its components, the Shield diagram and Sitreq and Infolet specifications, provide a viable solution for addressing several problems that a BIS may encounter during transparency provision, because they enable automated transparency analysis and tool support. The automated analysis enables algorithmic investigation of transparency in order to identify issues such as transparency shortage or abundance [7] in an information exchange system and amongst stakeholders. In the following subsections, we provide two algorithms for the analysis of transparency requirements.

Transparency Meaningfulness Mismatch. Transparency meaningfulness mismatch happens when the level of meaningfulness provided by a stakeholder does not match with the level that is requested by another stakeholder. Failure in reaching the required transparency level (e.g., disclosing the actions without giving the rationale behind them) may reduce accountability, while exceeding the required transparency level (e.g., disclosing the reasons for a particular action when only the data obtained from the action is needed) may introduce information overload. The following algorithm finds and lists all information elements where there is a transparency meaningfulness mismatch.

Transparency Leakage. In this context, transparency leakage refers to the availability of information elements to stakeholders who initially were not meant to receive that information because of the restricted nature of other stakeholders’ transparency requirements. Transparency leakage can produce several adverse effects, e.g., it can affect stakeholders’ trust in the BIS negatively. The following algorithm finds and lists all the instances where transparency leakage has occurred.

4 Case Study: University Marking Scheme

As a proof of concept, we conducted a case study on an information exchange system, namely university marking scheme. The full evaluation process, the Shield diagram and all the Sitreq and Infolet specifications are available upon request of the readers and researchers.

4.1 University Marking Scheme Specification

For modelling and analysis of transparency requirements, we used the following marking scheme specification which concerns university students’ examinations and assignments assessment and marking process. The specification was elicited from university officials involving unit leaders and framework leaders.

During and at the end of each semester, students’ understanding of a unit is evaluated by a combination of coursework and exams, hereby called assignment. The marking is generally performed by two markers. The first marker is the unit leader by default, and the second marker performs marking for quality assurance purposes. The marking is performed using a marking scheme provided by the university as a general guideline. Feedback on assignments is also provided by the first marker to students. Besides, students may ask the first marker to give them statistics about markings. Sometimes, an external examiner is also involved in the marking process by marking the assignments in order to evaluate the quality of the marking performed by the first and second marker. The external examiner also provides feedback on marking of the first and second marker. Furthermore, a teaching committee is in charge of reviewing all the markings and accepting or refusing them.

If any inconsistencies arise between the two markers, or between the two markers and the external examiner, then an exam board will review the markings and decide the final marking. The exam board also investigates students’ complaints about their marks, which must not be disclosed to the unit leader, and investigates the marking refusal if the teaching committee refuses the marking. The exam board decision on students’ marking will be final.

4.2 Building the Transparency Model

Based on the university marking scheme specification, we identified seven stakeholders (marked in the specification as bold) and 14 information elements (marked in the specification as italics). We used the information about stakeholders, information elements, and the possible relationships amongst them to build the initial transparency model. We observed that the initial model suffers from several gaps related to transparency provision. For example, Some data regarding the nature of the information elements, and regarding the relationship amongst stakeholders and information elements was missing and needed to be elicited from the stakeholders. The transparency model also provided the starting point for our transparency requirements analysis.

Fig. 7.

The complete Shield diagram for the case study

Fig. 8.

A sample of Sitreq specification for the case study

Fig. 9.

A sample of Infolet specification for the case study

4.3 Analysis of the Transparency Model

After building the initial transparency model, we identified several gaps and issues in transparency provision which was highlighted by our transparency model. These issues are as follows:

• The analysis of Sitreq specifications revealed that several transparency meaningfulness types were missing, i.e., the level of transparency meaningfulness (i.e., data, process, or policy) required by the stakeholders was unknown. Furthermore, some Infolet specifications missed the same information, meaning that the level of transparency some information elements provide was not investigated, irrespective of the stakeholders’ requirements.

• The analysis of Sitreq specifications also showed that several transparency provision types were missing, i.e., whether the transparency is coercive or voluntary supply, or legal or personal demand, could not be identified.

• The use of Infolet specifications helped the detection of negligence in information quality checks for information elements.

• The use of Infolet specifications also facilitated the discovery of inattention to transparency usefulness.

• Running the first algorithmic analysis on transparency mismatch detection revealed some issues in transparency provision. For example, while the first marker’s feedback on assignments contained the spotting and revealing of the mistakes students had made on their assignments (i.e., ‘data’), students requested that the first marker also emphasises on why they think one solution is wrong and how these mistakes could be avoided (i.e., ‘policy’).

• Running the second algorithmic analysis on transparency leakage detection revealed some problems in transparency provision. For example, the students did not want their complaints to be seen by the first marker. The exam board, however, provided the first marker with their decisions on complaints, literally revealing the complaints to the first marker. While this is not a privacy issue or a security problem, it can put pressure on students and probably discourage them from making further complaints.

These issues and gaps in the transparency model necessitated the clarification of transparency requirements by consulting with the stakeholders and filling in the missing information in our transparency model.

4.4 Updating the Transparency Model and Further Analysis

After consulting with the stakeholders and eliminating the gaps in transparency provision, the transparency model was updated and analysed once again to ensure no inconsistencies have remained. The updated Shield diagram is illustrated in Fig. 7, and an instance of Sitreq specification and an instance of Infolet specification are illustrated in Figs. 8 and 9, respectively.

5 Conclusion

In this paper, we proposed TranspLan, a language for modelling and analysis of transparency. TranspLan is based on our extensive literature study on transparency and our conceptual models of transparency. It uses a graphical language and provides several benefits for transparency engineering, including automated reasoning. Our case study, as a proof of concept, demonstrated the feasibility and potentials of TranspLan for modelling and analysis of transparency in a BIS.