<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Social Responsibility in System Design</article-title>
      </title-group>
      <contrib-group>
        <aff id="aff0">
          <label>0</label>
          <institution>Delft University of Technology</institution>
          ,
          <country country="NL">The Netherlands</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>During the design of a new technology (and, subsequently, software) many design choices need to be made at a high level of detail. These detailed design decisions shape the nature of the resulting software. The reasoning underlying each decision is ultimately based on abstract social and organisational values like, e.g., integrity, trust, security or fairness. These values are, however, typically only implicitly involved in the design process. As a result, the software might exhibit different characteristics than were foreseen because it is not in compliance with these abstract values. To ensure compliance, values should be systematically incorporated in the design. We propose a Value Sensitive Design approach to incorporating social responsibility in software. The problem in current software development approaches is that values are only implicitly involved in the development process. The link between the values and the application is, at best, implicit in the decisions made and the choices taken. In the requirements elicitation process [3], the values are translated to concrete requirements. These requirements are then used throughout the development process, and the related value is lost. However, due to their abstract nature, values can be translated to design requirements in more than one way. If the values and their translation to requirements are left implicit in the development process, one loses the flexibility of using alternative translations of those values. In this paper, we propose a first framework for describing the links between values, requirements and software design. Making these links explicit allows for improvements in the traceability of (the effects of) the values throughout the development process. This traceability greatly increases the maintainability of the application. That is, if a value is to be implemented differently, the explicit links between the values and the application make it much easier to determine which parts of the application should be updated. We illustrate the use of the framework with an use-case example.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>
        The recognition that values have an impact on the development of technology comes
from the field of philosophy (ethics, in particular). Especially the topic of Value
Sensitive Design (VSD) has seen much development recently. While VSD is applicable to
? This paper is an abstract of the work presented in [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
many engineering disciplines [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], in the area of ICT it has mainly been applied to the
analysis of the reasons for resisting the introduction of ICT solutions in organisations
or society [5]. Such resistance can be the result of not taking into account potential
conflicts that the solution might have with human values (e.g., security vs. privacy).
To avoid such failures, investigations have been done on the relationship between
specific values and technology (e.g., see [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]). Unfortunately, VSD has so far remained at
a philosophical level: focussing on analyses and lacking formalisation of the relations
between the values and the technology.
      </p>
      <p>
        In [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] we propose the Value Sensitive Software Development (VSSD) framework
(see figure 1) to integrate the principles of Value Sensitive Design with Service
Oriented Architectures (SOA) into the design of software systems. The framework aims to
bridge the gap between abstract values and concrete systems. VSSD consists of three
views described at three different abstraction levels. First, the Value View describes the
organisational values, norms, rules and procedures. This view largely overlaps with the
values hierarchy concepts of [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. Secondly, the Domain View models the context of the
system based on domain specific elements, for example, existing system blueprints.
Finally, the Modelling View defines the system’s architecture based on the values and the
domain characteristics. This view builds heavily on existing theory from SOA-based
computing (see, e.g., [6]).
      </p>
      <p>VSSD considers the software as an organisation of services to integrate the values
into the SOA design. It considers three levels of abstraction. First, the Abstract Level
describes the organisation at a high level of abstraction, where most of the contextual,
domain-specific, information is left out. This level includes, for example, generic
properties of organisations and an ontology to provide the meaning of the most primary
concepts. Next, the Concrete Level takes into account the context of the organisation,</p>
      <sec id="sec-1-1">
        <title>Concrete( Level(</title>
        <p>Implementa0on( Procedures)
Level(</p>
        <sec id="sec-1-1-1">
          <title>Service Orchestration</title>
          <p>Value(View(
Values)</p>
        </sec>
      </sec>
      <sec id="sec-1-2">
        <title>Modeling(View(</title>
      </sec>
      <sec id="sec-1-3">
        <title>Business(View(</title>
        <sec id="sec-1-3-1">
          <title>Service Organisation</title>
          <p>e
o Requirements!
p
c
s
Norms)</p>
          <p>Service Choreography
n
o
it
n
e
it
n
s
e
ir
a
d
n
u
o
b
n
o
iitt
a
n
a
t
s
n
i
t
n
e
m
e
n
ifr
e
n
o
it
a
z
il
a
e
r</p>
          <p>Func%onal)
constraints)
Exis%ng)
Systems)
and describes the norms and rules. Lastly, the Implementation Level corresponds to the
implementation process and contains the most detailed information.
3</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-2">
      <title>Case Study</title>
      <p>As illustration, we present an example of designing a web page for the Delft University
of Technology to offer massive open online courses (MOOCs). From the requirements
elicitation we got the (functional) requirement that we request users the permission to
store information in a cookie. The cookie is required to provide a more user-friendly
browsing experience; for example, the site could remember which courses you already
followed. Let us assume that there is another requirement to provide support for
impaired people; we could, for instance, include a text-to-speech functionality to read out
loud parts of the website to people with visual impairments.</p>
      <p>There are two hidden values at stake here: privacy and equality. The former, because
the data we store in the cookies is of a personal nature, and consent has to be given
before storing such data. The latter, because the inclusion of a text-to-speech functionality
to assist impaired users is based on the idea that everyone should be able to use the
website. Storing personal data while ensuring privacy also requires the upholding of
another value: security. The relations between the software, the requirements and the
underlying values is represented in figure 2 below.</p>
      <p>Social'
Welfare'</p>
      <p>Equality'
Security'</p>
      <p>Privacy'</p>
      <p>Data'
Protec2on'</p>
      <p>Data'Consent'</p>
      <p>Easy'access'</p>
      <p>for'all'
Anonymise'</p>
      <p>Data'</p>
      <p>Store'user'</p>
      <p>data'
Ensure'secure'
communica2on'</p>
      <p>Ask'permission'
to'store'cookie'</p>
      <p>Hash'data'
before'sending'</p>
      <p>Assist'
impaired'</p>
      <p>Stakeholders:'TU'DelC,'</p>
      <p>Students,'Lecturers,'
Internet'Service'Provider'
Architectural'decisions:'
Register'&gt;'Overview'&gt;'
Selec2on'&gt;'Payment'&gt;'</p>
      <p>Access'
Enactment'decisions:'
Use'of'iDEAL'service'for'
payment,'etc.'</p>
      <p>L  Increase'awareness'of'</p>
      <p>TU'DelC'
L  'Disseminate'knowledge'
L  24/7'access'to'course'</p>
      <p>materials'
L'Register'before'allowing'
access'to'course'
L'Personalise'browsing'
experience'</p>
      <p>TextLtoL
speech'service' iDEAL'service'</p>
      <p>PayPal'service' …'</p>
      <p>The values, on the left-hand side of figure 2 represent the motivations and
underlying values of the application. The requirements, and domain restrictions, are represented
on the right-hand side of figure 2; they represent the manner in which the domain
restricts the application design, which existing infrastructures (services) are available, and
in what way the objectives should be achieved. The middle part of figure 2 represents
the implementation choices that end up in the runtime of the application. These are the
characteristics of the software, describing concrete execution features of the
application.</p>
      <p>The strength of VSSD is in the explicit representation of the links between these
layers (in figure 2, only shown explicitly in the vertical dimension of the Values View).
Keeping explicit the motivations for particular design choices, either in the execution,
or in the requirements, means alternative implementations can easily be explored
without the need to redesign the application ground-up. The links explain the reasons why
particular execution elements exist (because they implement a particular value) and/or
why particular software behaviour was formulated (because that particular procedure
was required by a high level norm or value). When changing the application, e.g., from
a web page to an tablet app, these explicit links to the motivations can help you find the
appropriate redesign steps. For example, in the redesign, instead of asking for cookies
(which are not used on tablet apps), you could enable a secure connection for
registration, and then perform all communication between the client (the tablet) and the server
in an anonymised manner. Since the data stays on the tablet, and one can assume that
the user owns that device (and is thus responsible for its security), these choices also
implement the required value of privacy.</p>
      <p>Since the above example is rather simple, the relation between the requirements
and (hidden) values is quite straightforward. For more complex applications, with many
more requirements, these relations might not be so obvious, and explicit links between
the values, requirements and execution are direly needed to ensure the value sensitivity
of the application.
4</p>
    </sec>
    <sec id="sec-3">
      <title>Conclusions</title>
      <p>The conceptual framework proposed in this abstract presents the first step into the
explicit use of values in the design and implementation of systems, thereby achieving
social responsibility in software. Next steps include the investigation and formalisation
of the relations between the Views of the VSSD framework to create design procedures
to guide the implementation and verification of value sensitive software. In future work,
we will formalise the links present in figure 1, explore the verification of systems build
with VSSD, and evaluate VSSD by modelling more use-cases.
5. Jeroen van den Hoven. Ict and value sensitive design. In Philippe Goujon, Sylvian Lavelle,
Penny Duquenoy, Kai Kimppa, and Vronique Laurent, editors, The Information Society:
Innovation, Legitimacy, Ethics and Democracy In honor of Professor Jacques Berleur s.j.,
volume 233 of IFIP International Federation for Information Processing, pages 67–72. Springer
Boston, 2007.
6. Olaf Zimmermann, Pal Krogdahl, and Clive Gee. Elements of service-oriented analysis and
design: An interdisciplinary modeling approach for soa projects. IBM developerWorks, 2004.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <given-names>Huib</given-names>
            <surname>Aldewereld</surname>
          </string-name>
          , Virginia Dignum, and
          <article-title>Yao hua Tan. Design for values in software development</article-title>
          .
          <source>In Jeroen van den Hoven</source>
          et al., editor,
          <source>Handbook of Ethics, Values, and Technological Design</source>
          . Springer-Verlag,
          <year>2015</year>
          . forthcoming.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <given-names>Batya</given-names>
            <surname>Friedman</surname>
          </string-name>
          ,
          <string-name>
            <surname>Peter H. Kahn</surname>
            , and
            <given-names>Alan</given-names>
          </string-name>
          <string-name>
            <surname>Borning</surname>
          </string-name>
          .
          <article-title>Value sensitive design and information systems</article-title>
          .
          <source>Advances in Management Information Systems</source>
          ,
          <volume>6</volume>
          :
          <fpage>348</fpage>
          -
          <lpage>372</lpage>
          ,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <given-names>Ian</given-names>
            <surname>Sommerville</surname>
          </string-name>
          and
          <string-name>
            <given-names>Pete</given-names>
            <surname>Sawyer</surname>
          </string-name>
          .
          <article-title>Requirements engineering: a good practice guide</article-title>
          . John Wiley &amp; Sons, Inc.,
          <year>1997</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4. Ibo van de Poel.
          <article-title>Tranlating values into design requirements</article-title>
          .
          <source>Philosophy and Engineering: Reflections on Practice, Principles and Process</source>
          , pages
          <fpage>253</fpage>
          -
          <lpage>266</lpage>
          ,
          <year>2013</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>