BISE – RESEARCH PAPER

Software TransparencySoftware transparency is a new and important concern that software developers must dealwith. This paper reports on initial findings on exploring the obstacles for enabling softwaretransparency. For providing a definition of transparency and understanding the semanticsof software transparency, a SIG (Softgoal Interdependence Graph) is used, which has beenrefined in three versions. Based on three example situations we demonstrate theapplication of the transparency SIG.

DOI 10.1007/s12599-010-0102-z

The Authors

Prof. Julio Cesar Sampaiodo Prado Leite Ph.D. (�)Departamento de InformáticaPontifíciaUniversidade Católicado Rio de JaneiroR. Marquês de São Vicente, 225Rio de Janeiro 22453-900Brasiljulio@inf.puc-rio.brurl: http://www.inf.puc-rio.br/~julio

Claudia Cappelli Ph.D.Departamento de InformáticaAplicadaUniversidade Federal do Estadodo Rio de JaneiroRio de Janeiro,Brasilclaudia.cappelli@uniriotec.br

Received: 2009-09-08Accepted: 2010-02-12Accepted after one revision by the ed-itors of the special focus.Published online: 2010-04-27

This article is also available in Ger-man in print and via http://www.wirtschaftsinformatik.de: Leite JCSP,Cappelli C (2010) Softwaretranspa-renz. WIRTSCHAFTSINFORMATIK.doi: 10.1007/s11576-010-0219-1.

© Gabler Verlag 2010

1 Introduction

Transparency is a concept related to in-formation disclosure, having been usedin different settings, mostly related to

the empowering of citizens with regardto their rights. We argue that, in orderto implement transparency, society willneed to address how software deals withthis concept. However, from the point ofview of information system design and itssupporting software, dealing with trans-parency poses new research questions.

We shall use a real scenario to intro-duce transparency and show how thelatter affects software, and as such, theprocess of software construction. In Oc-tober 2009, the city of Rio de Janeirowas chosen to host the 2016 OlympicsGames. Weeks later, the city mayor an-nounced an e-government service to al-low citizens to follow government ac-tions regarding the preparation for thegames. Special attention was to be givento the financial budget with detailed in-formation about city actions for the 2016games. The service, named “Transparên-cia Olímpica” (Olympic Transparency),can be accessed through the ad-dress http://www.transparenciaolimpica.com.br/.1 It lists the first contracts, withexpenditure scheduling and attached val-ues.

Given that this e-government service isrunning and citizens are using it, we de-cided to find out how users of the ser-vice are evaluating it. Instead of usingthe traditional survey or a questionnaireregarding users’ approaches, we lookedfor what they are saying about the ser-vice. Our approach was only possible pre-cisely because of the recent trend to-wards individual transparency, in whichcitizens at large are using the Web (viablogs and micro blogs) to disseminatetheir opinions or their observation ofreal life facts. As such, we query theWeb using a combination of the follow-ing keywords: “blogspot,” “wordpress,”

“twitter,” “transparência olímpica,” and“problemas” (problems), targeting con-tent providers for blogs and micro blogs(Blogspot, Wordpress and Twitter) andthe topic of interest. We have found sev-eral manifestations regarding the service,but selected a few individual instances tohighlight how citizens are dealing withthe service. We list four observations inthe form of complaints: (a) data was notbeing updated, (b) information had beendeleted because the Mayor had indicatedit to be confidential, (c) information wasnot accountable,2 (d) information wasnot detailed enough. Table 1 lists the Webaddresses for each of these observations.

We understand that these observationsreveal concerns regarding informationdisclosure. Citizens are complaining thatthe e-government service which was sup-posed to provide transparency is fail-ing. It is important to stress that eachof these observations was produced inde-pendently by different citizens. This sce-nario helps to show that the informationsystem built to deliver the e-governmentservice was not effective. Different issuesare at stake here. In (a), data quality isat fault due to lack of updating. In (c),an auditing process should be in place.In (d) the quality of data is challengedfor not being detailed enough. On theother hand, (b) shows that transparencyis not always desired, as it may conflictwith confidentiality.

This real situation is a demonstrationthat, as services are available for citizens,the latter, as users, will pose differentsorts of issues related to transparency. In-creasingly, information system designersand software engineers will need to ad-dress these quality issues. Organizationswill be required to ensure that their com-puterized processes be transparent. That

1Visited in December 2009.2That is, there were no explanations as to the origins of the information.

Business & Information Systems Engineering 3|2010 127

BISE – RESEARCH PAPER

Table 1 Addresses for the observations on the E-Government service

Observation Web Address Date

(a) http://twitter.com/fiscalizarj2016 Dec. 09

(b) http://esportebrasilis.blogspot.com/2009/10/transparencia-olimpica.html Dec. 09

(c) http://intra-cranianos.blogspot.com/2009/10/olimpiadas-2016-e-outros-assuntos-para.html Dec. 09

(d) http://www.imil.org.br/blog/portais-de-transparencia-nao-garantem-fiscalizacao-de-gastos-com-olimpiada/ Dec. 09

is, society will demand not only that in-formation being processed by softwarebe disclosed, but also will seek to knowabout the processes which produced theinformation. Our research addresses thefollowing research question: how shouldwe build software systems supporting thedemand for transparency? Our contri-bution is framed by a major insight:we understand that, to provide trans-parency, we must deal with it in the con-text of requirements specification. Giventhat providing transparency is a new re-quirement for software systems, we showhow our approach builds on top of pre-vious knowledge on requirements engi-neering, mainly the work related to Non-Functional Requirements (NFR).

Further to this Introduction, the pa-per has five sections. Section 2 pro-vides an overview of the literature topresent a general understanding of trans-parency levels and enumerate the prob-lems for achieving transparency. Sec-tion 3 describes why requirements engi-neering must play an important role insoftware transparency. Section 4 detailsa major result so far, the production ofan NFR catalogue for transparency, in-cluding its initial validation. Section 5provides an example of transparencyuse on an Information System process(workflow) and revisits the “Transparên-cia Olímpica” case. Section 6 concludes,stressing contributions and future re-search.

2 Transparency

2.1 Literature Review

Four books were influential in our un-derstanding of transparency. Holzner andHolzner (2006) provide an in-depthstudy from the social and historical per-spectives on what they see as a move-ment to open government, in whichtransparency is key to achieving moreopen and democratic societies. Hen-riques (2006) examines different con-stituents of transparency as a concept and

frames them in the context of organi-zations, claiming that transparency willbe essential for successful organizations.Lord (2006) provides arguments showingthat increasing levels of transparency donot imply more democracy and peace, assuch insights are located at the limits oftransparency. Fung et al. (2007) use theconcept of target transparency as a wayfor organizations to reduce specific risksor performance problems through selec-tive disclosure and does this by provid-ing a careful analysis of the constituentsof transparency.

The issues of transparency are di-rectly linked to information process-ing or information technology. Law-makers are aware of its increasing roleand several laws have been written withrespect to data protection (Directive95/46/EC of the European Parliament;European Commission 1995), data avail-ability (Brazilian habeas data legislation;Republic of Brazil 1997), and access to in-formation (FOIA-Freedom of Informa-tion Act; United States Department ofJustice n.d.). Even more specific legis-lation, in special concerning the finan-cial sector, has been written (Sarbanes-Oxley Act; U.S. Government Printing Of-fice 2002). Weber (2008), from the pointof view of law analysis, describes theICANN (Internet Corporation for As-signed Names and Numbers) documen-tation’s problems with regard to trans-parency. Weber’s (2008) framework anal-ysis sees three types of transparency: pro-cedural, decision and subjective.

Few works have dealt with the trans-parency theme in the software con-text. Meunier (2008) states that soft-ware transparency is a condition in whichall software functions are disclosed tousers, and he argues that transparencyis a pre-condition for proper risk man-agement. Camp (2006) noticed that theopen source movement does provide away of disclosing software information:“The critical feature of open code is thatit can be read by humans. Open codeenables informed discourse about digitalprocess application, and the assumptions

underlying both,” and she also observesthat both law and computer programsare both called “code.” Camp (2006) citesStallman (1999) “. . .computer code con-trols and enables the actions of users, andfor users to have true autonomy, theymust be able to examine, alter, and re-distribute the code” and stresses that thisstatement is key when government activ-ities are embedded in computer code.

Notwithstanding, as Camp observes:open code does not guarantee trans-parency. Several situations may occur: forinstance, if open code is provided as bi-nary code, it would certainly not be eas-ily read by humans. Source code may bewritten in such a way that it would bevery hard to read; Camp cites a contestheld at CMU IOCCC (2009) the objec-tive of which being to produce obfus-cated code, which is very hard-to-readcode. Since source code may be writtenin different computer programming lan-guages, then the issue of literacy in thatspecific programming language may alsobe an issue contributing to obfuscation.Of course, that code which is protectedor which is not open is obfuscated. It isalso true that open code does not war-rant that the source code is the one themachine is using. Literature on electronicvoting stress this as a key point (Bishopand Wagner 2007; Paul and Tanenbaum2009), in particular, Paul and Tanenbaumhave delved into the issue, mostly fromthe point of view of security, but mak-ing sure a process is in place to considervoting process transparency, by means offree software (Stallman 2009).

A report to the National ResearchCouncil (Jackson et al. 2007), producedby a team of scientists chaired by DanielJackson identified transparency as thekey issue with respect to dependabil-ity, a crucial quality for software sys-tems. They argue that software produc-ers should disclose their claims of de-pendability by making their claims, cri-teria and evidence available. This disclo-sure will provide users or customers withthe grounds for informed choice. A man-ifesto by Weitzner et al. (2008) believes

128 Business & Information Systems Engineering 3|2010

BISE – RESEARCH PAPER

Fig. 1 Transparencycontexts (Wikipedia 2009)

that transparency is related to the rightcustomers have to see their data and as-sociates transparency with accountabil-ity, as it requires that information usagebe transparent.

2.2 Key Concepts

The literature review helped us to un-veil abstract key concepts, which summa-rize our understanding of transparencyin general, as well as in the software con-text. First, we present an organizationalview of transparency contexts. Second,we stress the importance of differentiat-ing information transparency and pro-cess transparency. Third, we point outkey issues that are related to software.

The literature mixes different trans-parency contexts. We have mapped thesecontexts into an “onion” chart (Fig. 1)to characterize the reach of transparency(Wikipedia 2009). In that Figure, we seethat Social Transparency is geared to-wards citizens in general; Target Trans-parency aims at consumers of some ser-vice or goods, and Organizational Trans-parency focuses on an organization’sstakeholders. Since automation is a keyfactor in modern society, software trans-parency will need to deal with the differ-ent focuses shown below, being orthogo-nal to these contexts.

Although most of the literature focuseson information transparency, at least We-ber (2008) deals explicitly with processtransparency. A better understanding oftransparency makes it clear that the pro-cesses that produce information shouldthemselves be transparent. This is partic-ularly important in the case of software.

Let’s use a set of possible situations toexemplify the importance of stressing thedifference made between transparency ofexisting information and transparency ofhow things happen. Suppose informationdoes exist in a company regarding safetyemission levels for a certain artifact. Re-quiring that the information be availableto customers is a form of transparencypolicy enabling access to the information.On the other hand, supposed one wishedto know how the artifact is assembled. Inthis case, one will need information onthe process used to assemble the artifact;one will require that this process be trans-parent. A citizen may be willing to buy acertain artifact with some level of radia-tion, as informed by company owner, butmay not be willing to buy that product ifpeople in the assembly line were exposedto higher levels of radiation. In the In-troduction, one of the observations, (c),from citizens, was that the informationwas not verifiable, that is, the citizen wasinterested in knowing about the processwhich would guarantee the information.

With regard to software we havelearned that transparency may be re-quired for different reasons, may be re-lated to different quality issues and isa complex matter. In Bishop and Wag-ner (2007) and Paul and Tanenbaum(2009) transparency is claimed to be nec-essary for e-vote applications, in Meu-nier (2008) it is seen as demanded byrisk management and in Camp (2006)as necessary for software dealing withgovernment activities. With respect toquality characteristics, we see it relatedto dependability (Jackson et al. 2007),to trust (Bishop and Wagner 2007; Pauland Tanenbaum 2009), to accountabil-ity (Weitzner et al. 2008) and to secu-rity (Paul and Tanenbaum 2009). Dealingwith so many implications and differenttypes and contexts is a complex endeavor,which will require specialized knowledge.The next section will detail the researchchallenges related to the matter.

2.3 Research Questions

Early use of the term transparency incomputing was misleading.3 The expres-sion “transparent to the user” commonlyreferred to a situation where the user wasusing a black box, with internal detailshidden away. Although the correct mean-ing of the word transparency is finding itsway in Computer Science jargon, as seen

3The Wikipedia entry for transparency (computing) (http://en.wikipedia.org/wiki/Transparency(computing)) and the IBM Terminology(http://www-01.ibm.com/software/globalization/terminology/tu.jsp#t19) are examples of this usage (visited in December 2009).

Business & Information Systems Engineering 3|2010 129

BISE – RESEARCH PAPER

in the literature cited, there is still the is-sue of what transparency means exactlyin the context of research and practice.

What does it mean having software thatis transparent? How to implement trans-parency? What is the implication of pro-ducing transparent software? What typeof methods and tools will be neededto fulfill this demand? How does trans-parency relate to other quality character-istics? How does transparency relate toquality characteristics that seem to op-pose transparency? What level of abstrac-tion should we be dealing with? Is codetransparency (Camp 2006) sufficient?

Our approach towards these questionsis framed by our perception that dealingwith software transparency should be re-garded as a new quality requirement. Thenext section argues why we believe thatrequirements engineering should be theproper context in which to address soft-ware transparency.

3 Attaching Requirementsto Software

It is interesting to note that Camp’s dis-cussion of information disclosure (Camp2006) is centered at the code level. Thisdisclosure is not just of the code as in-formation, but also of the process that itentails. In the previous sections, we haveoutlined arguments showing that codelevel is not the correct abstract if we wishto avoid the code level of detail, avoidthe peculiarity of different programminglanguages, and target transparency to abroad reach beyond programmers.

However, process transparency re-quires that the transformation steps ofthe process be transparent, to say that itis possible to understand its enactment.The problem is compounded when deal-ing with process information, since thefocus is not just on understanding data,but also one involving processes and ac-tors, as well. Similarly, in the softwareproduction context, requirements en-gineering is fundamental to understandwhat is required from the automated pro-cess, i.e., software. This line of reasoningleads us to believe that software engi-neers must deal with transparency dur-ing requirements definition. Moreover,Mylopoulos observes,4 when presentedto the idea of software transparency, that:

“transparency is an interesting qualitybecause it makes it necessary to attachrequirements models to software.”

With this insight, Mylopoulos positsthat requirement models are a right vehi-cle for the openness necessary for trans-parency. In addition, it demands that re-quirements models need to be attachedto software, which brings up the issue oftrust and traceability of the code.

Using as lemma the fact that code isimplementing requirements models, ifthe requirements models are transparent,then the code will be transparent. Thisassumption brings the problem of soft-ware transparency to a high level of ab-straction. It is important to note that, byMylopoulos’ observation, the fact of at-taching requirements models to code isnecessary – but it is not stated that thisis sufficient. In order for the lemma men-tioned above to be true, we have to makesure that the code conforms to the re-quirements and that traceability back andforth is possible in order to support veri-fication tasks.

This argumentation brings the prob-lem of software transparency to the realmof requirements, posing new challengesin an area that has evolved rapidly sinceits characterization in 1993, with theFirst IEEE International Symposium onRequirements Engineering. As such, wecould understand that some of the ques-tions raised in Sect. 2 should be an-swered mainly from the perspective ofrequirements engineering, making surethat requirements models are transpar-ent. Preliminary work on the suitabilityof modeling languages to transparencyrequirements (Cappelli et al. 2007) con-cluded that an intentional model5 (Leiteand Cappelli 2008; Yu 1994) is bet-ter for the task, since who (actors) andwhy (goals) are explicitly represented.As such, dealing with transparency wasframed as dealing with a quality require-ment, i.e., a non-functional requirement(Chung et al. 2000), or a softgoal, usingthe terminology of intentional modeling(Mylopoulos et al. 1992). Understand-ing transparency as a non-functional re-quirement and framing the problem ofachieving transparency in the context ofintentional modeling brings forth differ-ent possibilities for exploring the issuesraised before. The central one, provid-ing a definition of transparency, is rewrit-

ten as finding a SIG, a Softgoal Interde-pendence Graph (Chung et al. 2000). InSect. 4, we detail how this SIG was builtand validated over a series of versions.

Another consequence of explicitly rep-resenting non-functional requirementsas softgoals is the capability of reasoning(Giorgini et al. 2002) about contributionlinks, which is basically the problem ofrequirements interaction (Robinson et al.2003), and dealing with antagonistic re-quirements (Cappelli 2009). We will dealwith these issues in Sect. 5. The issue ofhow to attach requirements to software isdealt with in Sect. 6.

4 Transparency as an NFR

Why should we treat transparency asa non-functional requirement? Differentreasons make us believe this is a properposition. First, it is a quality issue; that is,it is orthogonal to the software function-ality. Having transparency or not havingtransparency will not impact what thesoftware does. Second, the characteristicis general, and as such, spreads to dif-ferent parts of a given software system.Although quality issues can be modular-ized, as for instance by means of aspect-oriented ideas, it is usually required bydifferent functional parts of a given arti-fact. Third, it is not amenable to the typ-ical measurement treatment as the oneapplied to functional characteristics; thatis, we cannot say that something is or isnot transparent. We will need to use a lessobjective judgment, like almost transpar-ent, or transparent enough, and so on. Inthat sense, transparency is a kind of char-acteristic that defies the notion of satis-faction in the traditional sense. The NFRuses Simon’s ideas to understand the de-gree of how a softgoal is fulfilled. Simon(1969) coined the term “satisfice,” whichis central to his theory of decision behav-iors. Fourth, our group has been workingwith the NFR framework for some timenow (Cysneiros et al. 2003; Chung andLeite 2009).

Why should we use The Non-Functional Requirements Framework(Chung et al. 2000) to represent trans-parency? The NFR Framework (Chunget al. 2000) was devised to promote thenon-functional requirements as first citi-zens in requirements models. It has been

4Personal communication.5Intentional modeling refers to requirements modeling languages that explicitly deal with goals. Kaos (van Lamsweerde 2009) and i∗ (Yu 1994) arethe most prominent ones.

130 Business & Information Systems Engineering 3|2010

BISE – RESEARCH PAPER

widely used and evolved in requirementsengineering research, mainly due to itsuniqueness in dealing with the inter-actions of requirements, being uniquein this approach. Instead of modelingrequirements just as functions to be per-formed, the framework addresses qualityattributes such as: security, usability, per-formance and precision, for example.As it promoted these characteristics, theNFR framework acknowledged their sub-stantial difference with respect to func-tional characteristics and used Simon’sideas of “satisfice.” This difference led tothe characterization of non-functionalrequirements as softgoals, that is, goalsthat could be achieved but would needa notion of “satisfice” instead of the tra-ditional satisfaction to measure its de-gree of achievement. As such, the NFRframework and its main model, the SIG,Softgoal Interdependence Graph, is aninstance of intentional modeling, andwell suited to deal with a soft concept, asis the case of transparency.

A SIG is composed of nodes and links.The nodes are either a softgoal or anoperationalization of a softgoal’s nodesthat are named with the type (quality) ofthe softgoal and the topic (the context inwhich the softgoal is being applied). Typeis the jargon used by the NFR frameworkto distinguish between the title of thesoftgoal and the topic to which it is ap-plied. Links are either contributions linksor correlations links. Links are labeledto describe their strengths (make, help,hurt, break), or whether they are decom-position (AND) links or specializationlinks (OR). Contribution links are solidarrows and correlation links are dashedarrows. Contribution links are used todescribe a hierarchy of softgoals, and cor-relations are used to describe relationsamong different hierarchies.

In this section, we describe the sev-eral interactions we performed andtheir according versions for finding atransparency SIG. Each version wasbuilt and validated by a differentstrategy. The denotation of each typewas, mainly, extracted from Wordnet(http://wordnet.princeton.edu/) withsome adaptations and is shown in Ta-ble 2.

4.1 Version 1

We have reported our first attempt to en-code transparency as a network of non-

functional requirements in Cappelli et al.(2007).

The SIG is the representation used inthe NFR framework for showing the re-lationships among different softgoals. InFig. 2 SIG we have used the “some+”edge, meaning that there is a positive con-tribution of unknown strength from thenodes towards their ancestors. This graphhas 34 softgoals, including transparencyitself, and four softgoals were factored:Usability, Auditability, Accessibility andInformativeness. This graph depicts thatthese quality factors contribute to the no-tion of transparency, and, as such, theirfulfillment, through the notion of “satis-fice,” will provide a degree of how trans-parency would be “satisficed.”

In order to produce this graph, we havefollowed a process composed of threemain steps.

(1) The first step used an elicitationstrategy based on the systematic reviewprocedure (Biolchini et al. 2005). A sys-tematic review is a process to guide liter-ature review using well established crite-ria. It has been used in the research areaof software experimentation.

The following characteristics drove thesystematic process for literature review:� Keywords: transparency, organizational

transparency, software transparencyprocess transparency.

� Paper and book Sources: Internet(Google Portal) and our universitycentral library

� Intervention: In the search the similar-ity between concepts will be observed.

� Effect: At the end of this systematic re-view, a collection of characteristics tobetter define transparency concepts inorganizational context should be avail-able.

� Application: The organizations willknow what is expected from themwhen someone or some organism ex-pects transparency.

� Experimental Design: The literaturein different knowledge areas will bestudied to extract the meaning oftransparency in this reference context.Then characteristics cited about trans-parency will be analyzed and orga-nized, thereby identifying their com-monality.

� Source Selection: To be wide-rangingthe search began on the Internet usingthe Google portal to discover whichareas use the term “transparency.” Tocomplement this first step, another

search was made at the central library.During this work, we discovered theuse of this term in some areas, suchas: Computer Science, Communica-tion, Sociology, Physical, Cinema andPolitic Science.

� Source Identification: The informationobtained in the books at the library wasmanually collected through reading.We have used Google with the follow-ing keywords: transparency, organi-zational transparency, software trans-parency and process transparency.

� Inclusion and exclusion criteria: The pa-pers and books must be available onthe Internet or at the library, providea transparency definition and explaintransparency characteristics aiming toanswer the first two questions.

� Preliminary study selection process:Each publication obtained had its ab-stract or summary analyzed and, basedon the inclusion and exclusion criteria,some were selected.

The review identified 10 sites, 20 books6

and 15 scientific papers and, followinganalysis, 3 sites, 5 books and 1 scien-tific paper were selected as informationsources. By using these sources, we haveproduced a list of quality terms associatedwith transparency.

(2) The second step compared the listproduced by step one with the Chung etal. (2000) non-functional requirementslist. The intersection of these two listsproduced a list of types related to trans-parency.

(3) The third step was the constructionof the graph shown in Fig. 2. The fol-lowing heuristics were used to producethe graph: (a) First, we studied relationsamong the types and separated them intogroups, (b) and for each group we identi-fied the dependencies between the types.(c) If one type depends on others to beachieved, then this one will be placed on ahigher level. The resulting SIG was com-prised of 34 nodes arranged in 3 levels.

The second level of decomposition wasformed by the following softgoals: Us-ability, Auditability, Accessibility and In-formativeness. All of the softgoals weremapped as “some+”, a relationship de-noting a positive contribution in order toachieve the higher softgoal.

6The books (Holzner and Holzner 2006; Henriques 2006, Fung et al. 2007) were not included in this survey. We have found them very recently.

Business & Information Systems Engineering 3|2010 131

BISE – RESEARCH PAPER

Table 2 Definitions for the types used in the Transparency SIG

NFR Framework characteristics Definitions

Accessibility The quality of being easy to meet deal with

Portability The quality of being light enough to be carried

Availability The quality of being at hand when needed

Publicity The quality of being open to public view

Usability The quality of being able to provide good service

Uniformity The quality of lacking diversity or variation

Simplicity The quality of being free from difficulty or hardship or effort

Operability The quality of being treated by surgical operation

Intuitiveness The quality of being spontaneously derived from or prompted by a natural tendency

Perform ability The ability of giving a good performance

Adaptability The ability to change (or be changed) to fit changed circumstances

User-friendliness The ability to use easily

Informativeness The quality of providing or conveying information

Clarity The ability to be free from obscurity and easy to understand

Completeness The quality of being complete and entire; having everything that is needed

Correctness The quality of being conform to fact or truth

Current The quality of occurring in or belonging to the present time

Comparable The ability to be compared

Consistency The ability to express logical coherence and accordance with the facts

Integrity The quality of being undivided or unbroken completeness, or totality with nothing wanting

Accuracy The quality of being near to the true value

Understandability The quality of comprehensible language or thought

Conciseness The ability to express a great deal in just a few words

Composability The ability to put together out of existing material

Decomposability The ability of separating into constituent elements or parts

Extensibility The quality of being protruded or stretched or opened out

Dependability The quality of being dependable or reliable

Auditability The ability to examine carefully for accuracy with the intent of verification

Validity The quality of being valid and rigorous

Controllability The ability of being certain of something

Verifiability The quality of being tested (verified or falsified) by experiment or observation

Traceability The quality of following, discover, or ascertain the course of development of something

Accountability The quality of being explained; made something plain or intelligible

4.2 Version 2

Later on, we re-organized the trans-parency SIG using a collaboration pro-cess with six software engineering re-searchers. The goal of the process wasto discuss the SIG previously produced.The process used clustering techniquestogether with a consensus meeting. Theparticipants were: two Ph.Ds, two Ph.D.candidates and two Masters’ degree can-didates, all of them working in the soft-ware engineering field. Each subject wasasked to review the existing SIG and to

propose a new clustering of the soft-goals. At this time, the group understoodthat, instead of using the “some+” con-tribution, we should follow the Chunget al. (2000) decomposition strategy forSIG catalogues, and, as such, we haveused the AND relationship which is astronger linkage than “some+”. Eachsubject brought his or her proposal toa meeting and presented to the group.A moderator used the whiteboard to con-solidate the consensus. After drawing dif-ferent alternatives, the group reached anagreement over a new SIG (Fig. 3). The

resulting SIG was composed of 33 nodesarranged in 3 levels. The second level ofdecomposition was formed by the fol-lowing softgoals: Accessibility, Usability,Informativeness, Understandability andAuditability. As can be seen in the secondlevel, one more node was created. Thethird level nodes were redefined and re-arranged.

Fig. 3 was submitted to 16 interna-tional modeling experts,7 who used aquestionnaire to evaluate the proposedSIG (Fig. 3) and to suggest some changes.It is interesting to note that one of the

7A number of participants of the February 2008 IFIP 2.9 meeting and participants of the 3rd International i∗ Workshop.

132 Business & Information Systems Engineering 3|2010

BISE – RESEARCH PAPER

Fig. 2 Softgoal interdependency graph (SIG) – Version 1

Fig. 3 Transparency network (Leite and Cappelli 2008) – Version 2

suggestions was the replacement of theAND by the “Help” contribution.

4.3 The Final Version

Cappelli (2009) continued refining theSIG, using questionnaire responsessubmitted to 16 international model-ing experts and including the corre-lations among leaf softgoals in differ-ent sub-trees (see Fig. 4). These cor-relations were found based on the ap-plication of an on-line questionnaire(http://pes.inf.puc-rio.br/questionario/),which was answered, anonymously, byapproximately 20 people.

The Transparency SIG (Cappelli 2009)is the first systematization of trans-

parency of which we are aware; this hasbeen done using the NFR Frameworksemantics of decompositions, collabora-tions and operationalizations (Chung etal. 2000). Operationalization, in the NFRFramework (Chung et al. 2000), is thelinkage of a non-functional requirementto possible “implementations” in func-tional terms. The next Section, in whichwe explore the use of the TransparencySIG, shows an example of an operational-ization.

5 Applying the Transparency SIG

This Section is organized by the presenta-tion of three distinct examples. The first

one is based on Cappelli’s thesis of bring-ing transparency to business processes;the second one is based on the analysis ofdifferent types of elections systems; andthe third is based on the e-governmentservice case, “Transparência Olímpica.”

5.1 Bringing Transparency to BusinessProcesses

Cappelli (2009) refined the third levelof SIG, by defining possible operational-izations of each of the leaf softgoals inthe context of her doctoral thesis on ap-plying the transparency concept towardsbusiness processes. Fig. 5 shows a possi-ble operationalization of the softgoal Ac-countability within the domain of busi-

Business & Information Systems Engineering 3|2010 133

BISE – RESEARCH PAPER

Fig. 4 Transparency SIG (Cappelli 2009) – final version

Fig. 5 The operationalization of accountability (Cappelli 2009)

ness processes, and, as such, the topic“Business Process” is part of the nodename. It is important to notice that, inthis case, Accountability is seen as help-

ing Auditability, which “Helps” Trans-parency.

Using a partial description of a soft-ware acquisition process, we have ap-

plied three operationalizations from theTransparency SIG (Fig. 5) to illustrate anew version of the process which willbe “more” transparent, for the Account-

134 Business & Information Systems Engineering 3|2010

BISE – RESEARCH PAPER

Fig. 6 A software acquisition process

ability operationalizations included inthe process will “Help” the Auditabil-ity, which will “Help” Transparency (seeFig. 4).

Fig. 6 provides, using a BPMN (Busi-ness Processing Modeling Notation), apartial description for a software acqui-sition process in an organization. In thisversion, the process does not consider theissue of Auditability and, as such, bears aproblem with Transparency.

Fig. 7 shows a new description forthe software acquisition using two Ac-countability SIG activities (Fig. 5): Iden-tify decisions in the process (marked withI) and Justify decisions in the process(marked with J). As such, two new activ-ities are added to the process (Fig. 7, ac-tivities A and B). Another Accountabilityoperationalization function, Identify in-formation used in the process (markedwith D), requires the addition of threedocuments to the process (Fig. 7, docu-ments C, D, E).

If we do compare the two versions ofthe process, it is reasonable to claim thatthe second version, Fig. 7, makes the con-tract analyst perform two activities thatwill be of fundamental importance forany auditing operation in the future. It isalso reasonable to claim that, by makingthe documents in the process explicit, the

organization is making sure that account-ability is being enforced.

This is only a small example of the rolethat Transparency SIG may have in theefforts towards making processes moretransparent. Note that if process descrip-tions do consider transparency, these re-quirements will need to be cast on thesupporting software as well.

5.2 Analyzing Correlationsin the Context of Electoral Systems

An electoral system is an information sys-tem that supports an election process.In Cappelli et al. (2010) we exploredhow transparency would interact with se-curity as desired quality characteristicsof three types of election processes. Wecompared the Transparency SIG (Fig. 4)with a Security SIG taken from (Chung etal. 2000) in the analysis involving an in-direct elicitation strategy entailing sevenstakeholders.

The purpose of the elicitation was tofind correlations among softgoals. As wecan see from Fig. 8, we elicited sev-eral correlations in the Transparency andSecurity SIG. Most of them, surpris-ingly, are positive correlations, with onlytwo negatives, which are those involvingConfidentiality and Traceability and Au-ditability and Confidentiality. This exam-

ple shows a way of dealing with the rela-tionship of transparency with other qual-ity characteristics, even if they seem tooppose transparency. Of course the re-sults found in Cappelli et al. (2010) arebound by the processes examined as wellas by the viewpoint of the stakeholdersconsulted.

The point in this example is that anal-ysis of transparency relationships can bedone early on. The NFR analysis stressedthe negative impact of confidentialityover traceability and of auditability overconfidentiality, so that designers and cus-tomers of an electoral system will moreclearly see that opting for a given qualitywill impact another. In particular, it willprovide a starting point for the discussionof possible implementations. Of course,the mapping of these interactions bringsmore complexity towards requirementsanalysis, but also may uncover problemsthat will be hard to deal later during soft-ware design. It also helps to uncover therationale for design decisions.

5.3 Transparency in the Caseof “Transparência Olimpica” Site

In the Introduction, we have reportedon the site “Transparência Olímpica” asa government service provided by themayor of Rio de Janeiro to inform about

Business & Information Systems Engineering 3|2010 135

BISE – RESEARCH PAPER

Fig. 7 A software acquisition process instantiated for transparency

Fig. 8 Security versusTransparency (Adaptedfrom Cappelli et al. 2010).Some “Help” contributionsof the Transparency SIG andsome “And” contributionsfrom the Security SIG wereleft out of the graph so asnot to clutter it

the ongoing works for the 2016 games.We have also mentioned that, by query-ing the Web, we have found several mani-festations regarding the quality of the ser-vice.

In that particular case, it is interestingto note that all the comments about theservice could be mapped to our Trans-parency SIG. As such it is reasonable toposit that, if the designers of the service

used the proposed SIG, all of these com-ments could have been addressed at theservice definition time.

The following argumentation servesthe goal of showing a possible answer tothe question of what it means to havetransparent software and how to imple-ment it. Let us look at each observa-tion and argue about how the SIG (seeFig. 6 and Table 2) could have helped. In

(a), the criteria, quality of data being up-dated, is exactly the softgoal Current that“Help” Informativeness to “Help” Trans-parency. In (b), an antagonistic anal-ysis, similar to the one performed inSect. 5.2, could have shown that Avail-ability to “Help” Accessability to “Help”Transparency would “Hurt” Confiden-tiality; thus requiring operationalizationsthat would point to policies of what

136 Business & Information Systems Engineering 3|2010

BISE – RESEARCH PAPER

is considered confidential and, as such,would not be available. In c), there isthe case of Accountability to “Help” Au-ditability to “Help” Transparency; herealso requiring operationalizations that,certainly, would be similar to those enu-merated in Sect. 5.1 (see Fig. 5).

On the other hand, we have also ob-served that the service does not fulfill thesoftgoal of Publicity to “Help” Accessibil-ity that “Help” Transparency. We checkedthe “Transparência Olímpica” site usingBrazilian software (daSilva), which worksfor Portuguese; the software checks forcompliance with the WCAG 1.0 recom-mendation issued by the W3C. We foundthree occurrences of the lack of textualdescription for images used in the site.This fact will be an obstacle for voicebrowsers, a tool used by persons with vi-sual impairment. A proper operational-ization for Publicity should refer to theW3C guidelines.

6 Conclusion

We have argued that transparency is aconcern that information system design-ers must address as society demandsmore openness. We described an existinge-government service and showed howcitizens demand transparency from thisservice. Our literature review is evidenceBased on available knowledge, we havestressed the key concepts: of transparencycontexts, of differentiating informationtransparency and process transparency,and of software transparency.

Fig. 9 The Transparency environment

Since transparency is a quality charac-teristic we have argued that in the contextof information system design, it is properto be dealt with during the requirementsdefinition, and as such posing the chal-lenges in the context of requirements en-gineering. In that context, the usage ofthe NFR framework is well justified asthe basis for treating transparency. Thebulk of our work has been trying to pindown the semantics of software trans-parency using the NFR framework. Be-ing able to deal with the constituents oftransparency, it will be possible to betterevaluate the degree of transparency of agiven software. Although our taxonomy,expressed by Transparency SIG, may beseen as incomplete, we have shown itsutility by examples in the analysis of dif-ferent situations. It is also important tostress that our taxonomy allows for vari-ability by the combination of topic andoperationalizations. So, for different top-ics, we may have different operational-izations, as seen in Sect. 5. We have alsoshown, in Sect. 5, the handling of antag-onistic requirements by using the correla-tion links associated with strength labels.

Regarding future work, Fig. 9 depictsan environment we have been investigat-ing as to support software transparency.It inherits the baseline idea from a pre-vious work (Leite et al. 1997), and usesa mix of intentional modeling (i∗; Yu1994) with a scenario and light ontology(Language Extended Lexicon; Breitmanand Leite 2003). Other investigators alsohave pursued the combination of inten-tional models with a scenario-oriented

model in requirements engineering (Rol-land and Salinesi 2009; Castro et al.2009). We understand that in our con-text, the idea of traceability automationis key, that is, the traces are automaticallygenerated by the environment. Some firstresults already are available in this area(Egyed and Grünbacher 2002), and wehave implemented a similar scheme inour lexicon and scenario editor (Fernan-des et al. 2005). So, by taming the tracingaspect we are dealing with importantsupport for helping the Auditability sub-tree (Fig. 5), which, however, comprisesjust 6/33 of the problem.

Of importance as well is exploringthe issue of reusability, since the Trans-parency SIG with proper operationaliza-tions by topic is a first step towards build-ing a transparency catalogue (Cysneiroset al. 2003; Chung et al. 2000) and, assuch, rendering the enactment of quality-based reusability possible (Leite et al.2005).

Bringing the focus of transparency to-wards a requirements perspective is im-portant to allow the inheritance of severalresults of an area, which since its incep-tion has been looking outside the realmof software engineering. In a recent re-port on the challenges of requirementsin the context of high complex systems,Jarke et al. (2009) have noticed the evo-lution from “user” to “citizen” and theconsequences of this observation. As wehave pointed out in Fig. 9, the upperarea where software has to communicatewith citizens and abide with the softgoalsof Understandability, Usability and Infor-mativeness is, undoubtedly, a complex is-sue in terms of software design.

Based on the fact that software trans-parency must be dealt with and buildingon our first efforts to deepen the under-standing of what transparency is, we be-lieve that the most pressing issues are thefollowing ones:� The issue of trust is a major road-

block to software transparency. Sci-ence (Kramer 2007), as well as po-ets,8 have taught the importance of ab-straction. We cannot deal with trans-parency if we will have to look atevery single line of code. The vol-ume and complexity would be enor-mous. We will need abstractions faith-ful to the real code. As such, the is-sue of trust is essential. How to guar-antee that the requirements, which

8See “On Exactitude in Science” by Jorge Luis Borges (http://en.wikipedia.org/wiki/On_Exactitude_in_Science).

Business & Information Systems Engineering 3|2010 137

BISE – RESEARCH PAPER

AbstractJulio Cesar Sampaio do Prado Leite,Claudia Cappelli

Software Transparency

Software transparency is a new and im-portant concern that software develop-ers must deal with. As society moves to-wards increased automation, if citizenswish to exercise their right to know,the transparency of public services andprocesses acquires fundamental im-portance. Informed discourse is onlypossible if processes affecting the pub-lic are open to evaluation. Achievingsoftware transparency to this level ofopenness faces several roadblocks. Thepaper reports on initial findings on ex-ploring the obstacles for enabling soft-ware transparency.

Keywords: Software, Transparency, In-formation transparency, Open society,Requirements engineering

will bring transparency to the pro-cesses, are being executed as planned?

� The issue of cost is a major roadblock.We, software engineering researchers,have to find ways of providing trans-parency without increasing the costof producing software. It seems thatthe collaborative movement behind anopen source is a promising startingpoint.

� The issue of performance is also amajor concern. How to assure trustwithout interfering with system per-formance? Remember that in an idealworld people would like to be in-formed about how software executesits processes.

� Another challenge is how to deal withcitizens as our “customers,” as notedbefore. Software engineers have notbeen too keen on human-computer in-teraction, which was delegated to an-other research area (HCI), in whicha great deal of progress has certainlybeen made. However, we foresee thatdealing with transparency “customers”requires different sorts of models andstrategies than needed for just deal-ing with users, even in a general sense,such as when dealing with interfacesfor the Web. On the other hand, inthe Web services context (Hendler etal. 2008), we will also have to considersoftware agents as demanding trans-parency for proper collaboration.

Of course, achieving transparency forprocesses – and, in particular for software– is a challenging endeavor. But we envi-sion that this important and pressing is-sue must be taken under consideration byboth researchers and industry. By outlin-ing the results and the challenges for Soft-ware Transparency, we are aligned witha number of observations made by Jarkeet al. (2009) with respect to requirementsfor facing engineering challenges.

Acknowledgements

The authors are grateful to the editorsand reviewers. Their positive criticismand their assistance in helping us expressour ideas were fundamental in achiev-ing a much better text. Financial supportfor this work was provided by Faperj andCNPq.

References

Biolchini J, Mian PG, Natali AC, Travassos GH(2005) Systematic review in software en-gineering: relevance and utility. Technical

report ES67905, PESC – COPPE/UFRJ, 2005.http://cronos.cos.ufrj.br/publicacoes/reltec/es67905.pdf

Bishop M, Wagner D (2007) Risks of e-voting.Communications of the ACM 50(11):120–120. doi:10.1145/1297797.1297827

Lamsweerde A van (2009) Requirements en-gineering: from system goals to UML mod-els to software specifications. Wiley, NewYork

Breitman K, Leite JCSP (2003) Ontology as arequirements engineering product. In: 11thIEEE international conference on require-ments engineering. IEEE Comp Soc Press,Los Alamitos, pp 309–319

Camp LJ (2006) Varieties of software andtheir implications for effective democraticgovernment. In: Proceedings of the Britishacademy, vol 135, pp 183–185

Cappelli C (2009) An approach for businessprocesses transparency using aspects. Dis-sertation, Departamento de Informática,PUC-Rio, Ago (in Portuguese)

Cappelli C, Oliveira AP, Leite JCSP (2007) Ex-ploring business process transparency con-cepts. IEEE Comp Soc Press, Los Alamitos,pp 389–390

Cappelli C, Cunha H, Gonzalez-Baixauli B,Leite JCSP (2010) 25th transparency ver-sus security: early analysis of antagonisticrequirements. In: ACM symposium on ap-plied computing, requirements engineer-ing track. Sierre (accepted)

Castro J, Kolp M, Liu L, Perini A (2009)Dealing with complexity using conceptualmodels based on tropos. In: Conceptualmodeling: foundations and applications.Springer, Berlin, pp 335–362

Chung L, Leite JCSP (2009) On non-functionalrequirements in software engineering. In:Borgida A, Chaudhri V, Giorgini P, Yu E (eds)Conceptual modeling: foundations and ap-plications. Springer, Heidelberg, pp 363–379

Chung L, Nixon B, Yu E, Mylopoulos J (2000)Non-functional requirements in softwareengineering. Kluwer, Norwell

Cysneiros LM, Yu E, Leite JCSP (2003) Cat-aloguing non-functional requirements assoftgoal networks. In: Proc. of requirementsengineering for adaptable architectures.11th international requirements engineer-ing conference, pp 13–20

Egyed A, Grünbacher P (2002) Automating re-quirements traceability: beyond the record& replay paradigm. In: Proc. 17th IEEE in-ternational conference on automated soft-ware engineering. IEEE Comp Soc, Wash-ington, p 163

European Commission (1995) Directive95/46/EC of the European parliament– data protection. http://ec.europa.eu/justice_home/fsj/privacy/index_en.htm

Fernandes L, Leite JCSP, Breitman K (2005)C&L uma ferramenta de apoio à engen-haria de requisitos. Revista de InformáticaTeórica e Aplicada 12(1):23–45

Fung A, Graham M, Weil D (2007) Full dis-closure, the perils and promise of trans-parency. Cambridge University Press, Cam-bridge

Giorgini P, Mylopoulos J, Nicchiarelli E, Se-bastián R (2002) Reasoning with goal mod-els. In: Proc. ER 2002. 21st international con-ference on conceptual modeling. Springer,Berlin, pp 167–181

Hendler J, Shadbolt N, Hall W, Berners-Lee T,Weitzner D (2008) Web science: an interdis-ciplinary approach to understanding theweb. Communication of the ACM 51(7):60–69 doi:10.1145/1364782.1364798

138 Business & Information Systems Engineering 3|2010

BISE – RESEARCH PAPER

Henriques A (2006) Corporate truth the limitsto transparency. Earthscan, London

Holzner B, Holzner L (2006) Transparency inglobal change: the vanguard of the opensociety. University of Pittsburgh Press, Pitts-burgh

IOCCC (2009) International Obfuscated CCode Contest. http://ioccc.org/main.html

Jackson D, Thomas M, Millett L (2007) Soft-ware for dependable systems: sufficientevidence? The National Academies Press,http://www.nap.edu/catalog.php?record_id=11923#toc

Jarke M, Loucopoulos P, Lyytinen K, My-lopoulos J, Robinson W (2009) Manifesto– high-impact requirements for software-intensive systems In: Dagstuhl seminar pro-ceedings – 08412, 1862–4405. http://drops.dagstuhl.de/opus/volltexte/2009/2028/pdf/08412.SWM.Paper.2028.pdf

Kramer J (2007) Is abstraction the key tocomputing? Communications of the ACM50(4):36–42

Leite JCSP, Yu Y, Liu L, Yu E, MylopoulosJ (2005) Quality-based software reuse. In:CAiSE, pp 535–550

Leite JCSP, Rossi G, Balaguer F, Maiorana V, Ka-plan G, Hadad G, Oliveros A (1997) Enhanc-ing a requirements baseline with scenarios.Requirements Engineering 2(4):184–198

Leite JCSP, Cappelli C (2008) Exploring i∗characteristics that support softwaretransparency In: Proc 3rd international i∗

workshop, CEUR workshop proceedings,vol 322, pp 51–54. http://CEUR-WS.org/Vol-322/

Lord KM (2006) The perils and promise ofglobal transparency. State University ofNew York Press, New York

Meunier P (2008) Software transparencyand purity. Communications of the ACM51(2):104. doi:10.1145/1314215.1314232

Mylopoulos J, Chung L, Nixon B (1992)Representing and using nonfunctional re-quirements: a process-oriented approach.IEEE Transactions on Software Engineering18(6):483–497

Paul N, Tanenbaum AS (2009) Trustwor-thy voting: from machine to system.Computer 42(5):23–29. http://dx.doi.org/10.1109/MC.2009.169

Republic of Brazil (1997) Lei N° 9.507, de 12 deNovembro de 1997. http://www.planalto.gov.br/ccivil/Leis/L9507.htm

Robinson WN, Pawlowski SD, Volkov V (2003)Requirements interaction management.ACM Computing Surveys 35(2):132–190.doi:10.1145/857076.857079

Rolland C, Salinesi C (2009) Support-ing requirements elicitation throughgoal/scenario coupling. In: Conceptualmodeling: foundations and applications.Springer, Berlin, pp 398–416

Simon HA (1969) The sciences of the artificial.MIT Press, Cambridge

Stallman R (1999) The GNU Manifesto.Originally written in 1984; later ver-sion available. In: DeBona C, Ock-man S, Stone M (eds) Open codes:voices from the open code revolu-tion. O’Reilly, Cambridge, pp 53–70.http://www.gnu.org/gnu/manifesto.htmlv

Stallman R (2009) Why ‘Open Source’misses the point of free software. Com-munications of the ACM 52(6):31–33.doi:10.1145/1516046.1516058

United States Department of Justice (nd)Freedom of Information Act (FOIA). http://www.usdoj.gov/oip/index.html

US Government Printing Office (2002) Publiclaw 107–204 – Sarbanes-Oxley Act of 2002.http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/content-detail.html

Weber RH (2008) Transparency and the gover-nance of the internet. Computer Law & Se-curity Report 24(4):342–348

Weitzner DJ, Abelson H, Berners-Lee T,Feigenbaum J, Hendler J, Sussman GJ(2008) Information accountability. Com-munications of the ACM 51(6):82–87.doi:10.1145/1349026.1349043

Wikipedia (2009) Transparency (social).http://en.wikipedia.org/wiki/Transparency_(social)

Yu E (1994) Modeling strategic relation-ships for process reengineering. Disserta-tion, University of Toronto, Graduate De-partment of Computer Science, pp 124 ff

Business & Information Systems Engineering 3|2010 139