Building Social Sustainability into Software: Case of Equality
Social Sustainability, Value sensitive design
Authors: Maryam Al Hinai, Ruzanna Chitchyan
Year: 2015
Published in: 2015 IEEE fifth international workshop on requirement patterns.
Read me: DOI: 10.1109/RePa.2015.7407735. Website.
Abstract: Equality is an important aspect in todays diverse communities, which plays a significant role in communities social sustainability. This paper looks into modeling equality as a social sustainability dimension using a generic model of sustainability. Patterns of equality requirements are identified in this generic model. This model and respective patterns are then used in software requirements elicitation of a case study.
Bibtex (copy):Annotation
By Nils van den Honert.
Social sustainability is key proponent of wellbeing created by software. However, creating the requirements for building social sustainability into software is not an easy task. Using equality as the main socials sustainability aspect, a process of requirements elicitation is shown. Equality is here defined as the right for all participants in society to access (public) resources with discrimination of any kind. Value sensitive designs exist, but are mostly unused in everyday software development. The authors generate an initial equality value pattern, based on the generice sustainability model with its 5 domains (economical, social, individual, technical and environmental). They showcase the Goal, its Dimension and associated values, and the regulations and activities that have an impact on theses values. These activities can be measured through an indicator, which allows us to quantify our goal and identify system stakeholders. After this, we can focus on these stakeholders and discover ways to satisfy the values that we have chosen to focus on. By taking a bigger stakeholder group and differentiating over this group, we can find unique groups of users that have special wishes and accomodate to this in the scope of our bigger goal. This can lead to both functional and non-functional requirements. In a case study, they observe Health Watcher, which displayed this way of requirement elicitation. Here, they observe that different value patterns can lead to different requirements, which can be either abstract or detailed and either functional or non-functional. It seems to be the case that more abstract values lead to more abstract requirements, but this needs to be confirmed with more case studies.