A modelling language for transparency requirements in business information systems

A Modelling Language for Transparency Requirements in Business Information Systems Mahmood Hosseini, Alimohammad Shahri, Keith Phalp, and Raian Ali

Bournemouth University, UK

Satu

rday

, Ju

ne

25

, 20

16

1

Agenda

• Introduction • Transparency as a requirement • What is missing?

• Transparency reference models • Transparency Stakeholders’ Wheel • Transparency Depth Pyramid • Transparency Achievement Spectrum • Information Quality in Transparency

• TranspLan: a transparency modelling language • Modelling constituents and representations • TranspLan mathematical definition • Shield Diagram • Sitreq Specification • Infolet Specification • Transparency requirements analysis

• Case study: university marking scheme • Conclusion

• Conclusion • Acknowledgements

Satu

rday

, Ju

ne

25

, 20

16

2

Transparency as a requirement

• Transparency is a requirement of democratic societies

Satu

rday

, Ju

ne

25

, 20

16

3

Introduction Reference Models TranspLan Case Study Conclusion

Image courtesy of The Independent, 12 Dec 2015


• Poor handling of transparency can lead to crises

• Financial crisis of 2008, as a result of lack of transparency

• Ashley Madison and Panama Papers incidents, results of unwanted transparency Sa

turd

ay, J

un

e 2

5, 2

01

6

4


Image courtesy of FinFacts Ireland, 8 Oct 2008

Image courtesy of News.com.au, 24 Apr 2016

Image courtesy of Time, 14 Apr 2016


• Transparency is the requirement of the younger generation and the millennials

• They live in a more transparent world

• They are more transparent (e.g., through sharing in social media)

• They demand more transparency

Satu

rday

, Ju

ne

25

, 20

16

5


Image courtesy of TheViewInside.me, 25 Sep 2013 Image courtesy of Tru Access Blog, 16 Dec 2013

What is missing?

• The literature on transparency in general, and in computer sciences in particular, lacks a critical focus, i.e., systematic modelling and analysis of transparency requirements

• Transparency is usually studied alongside its adjacent concepts related to information, e.g., privacy.

• There is a lack of rigorous conceptual models or reference models for transparency.

• There has been no domain-specific languages proposed for transparency requirements.

Satu

rday

, Ju

ne

25

, 20

16

6


Transparency Stakeholders’ Wheel

(Presented in RE 2015)

Satu

rday

, Ju

ne

25

, 20

16

7


Transparency Depth Pyramid

• It discusses transparency meaningfulness.

(Facets Presented in REFSQ 2016)

Satu

rday

, Ju

ne

25

, 20

16

8


Transparency Achievement Spectrum

• It discusses transparency usefulness.

(Facets Presented in REFSQ 2016)

Satu

rday

, Ju

ne

25

, 20

16

9


Information quality in transparency

(Kahn et al, 2002)

Satu

rday

, Ju

ne

25

, 20

16

10

[1] B. K. Kahn, D. M. Strong, R. Y. Wang, Information quality benchmarks: product and service performance, Communications of the ACM 45 (4) (2002) 184–192.


Modelling constituents and representations

• TranspLan is based on the four reference models of transparency

• TranspLan is mathematically defined, but it also has the following visual representation and specifications:

• StakeHolders’ Information Exchange Layout Diagram (or Shield Diagram)

• INFOrmation eLEment Transparency specification (or Infolet Specification)

• Stakeholders’ Information Transparency REQuirements specification (or Sitreq Specification)

Satu

rday

, Ju

ne

25

, 20

16

11


Modelling constituents and representations

• TranspLan constituents:

• Stakeholders

• Information elements

• types: data, process, policy

• Stakeholder-information relationships

• types: production, obligation, optionality, restriction, undecidedness

• Decomposition relations

• types: and, or, xor

• Information exchanges

Satu

rday

, Ju

ne

25

, 20

16

12


TranspLan mathematical definition

Satu

rday

, Ju

ne

25

, 20

16

13


Shield Diagram

Satu

rday

, Ju

ne

25

, 20

16

14


Sitreq Specification

Satu

rday

, Ju

ne

25

, 20

16

15


Infolet Specification

Satu

rday

, Ju

ne

25

, 20

16

16


Transparency requirements analysis

• Transparency Meaningfulness Mismatch

Satu

rday

, Ju

ne

25

, 20

16

17


Transparency requirements analysis

• Transparency Leakage

Satu

rday

, Ju

ne

25

, 20

16

18


University marking scheme specification

• 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.

Satu

rday

, Ju

ne

25

, 20

16

19


Analysis of the transparency model

• 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.

Satu

rday

, Ju

ne

25

, 20

16

20


Analysis of the transparency model

• Running the first algorithmic analysis on transparency mismatch detection:

• 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:

• 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.

Satu

rday

, Ju

ne

25

, 20

16

21


Case study: Shield Diagram

Satu

rday

, Ju

ne

25

, 20

16

22


Case study: Sitreq Specification

Satu

rday

, Ju

ne

25

, 20

16

23


Case study: Infolet Specification

Satu

rday

, Ju

ne

25

, 20

16

24


Conclusion

• We proposed TranspLan, which is a domain-specific language for engineering transparency requirements.

• The language is based on an extensive literature study and on our four reference models of transparency.

• It provides a graphical language for transparency requirements engineers along with specification sheets.

• A case study, as a proof of concept, shows the feasibility and potentials of TranspLan for modelling and analysis of transparency requirements in a business information system.

Satu

rday

, Ju

ne

25

, 20

16

25


Acknowledgements

• The research is supported by an FP7 Marie Curie CIG grant (the SOCIAD project).

Satu

rday

, Ju

ne

25

, 20

16

26

Questions

Satu

rday

, Ju

ne

25

, 20

16

27

[email protected]

A modelling language for transparency requirements in business information systems

Engineering