Engineering Requirements for Social Sustainability

Software is no longer a passive tool, but is an active agent in shaping modern communities. Yet, to date, software engineers do not endeavour to explicitly state requirements which a software system must fulfil if it is to positively contribute to the well-being (that is the social sustainability) of its user community. This paper presents a proposal on how to bridge this gap. It notes that social sustainability requirements stem from key societal values, such as equity, security, education, which can be elicited into value patterns. Such patterns can then serve as templates for software requirements specification. The viability of this proposal is demonstrated through formation of equity value patterns, which are instantiated as requirements to 6 sample studies. We observe that while each organisation and sub-community will have own diverse cultural and traditional values with respective requirements, the fundamental notions (such as equity, security, freedom) that serve as the core of social sustainability remain relatively stable. It is such values that we propose to elicit into patterns for requirements specification

Privacy Requirements: Past & Future

Software systems are increasingly more and more open, handle large amounts of personal or other sensitive data and are intricately linked with the daily lives of individuals and communities. This poses a range of privacy requirements. Such privacy requirements are typically treated as instances of requirements pertaining to compliance, traceability, access control, verification or usability. Though important, such approaches assume that the scope for the privacy requirements can be established a-priori and that such scope does not vary drastically once the system is deployed. User data and information, however, exists in an open, hyper-connected and potentially “unbounded” environment. Furthermore, “privacy requirements - present” and “privacy requirements - future” may differ significantly as the privacy implications are often emergent a-posteriori. Effective treatment of privacy requirements, therefore, requires techniques and approaches that fit with the inherent openness and fluidity of the environment through which user data and information flows are shared. This paper surveys state of the art and present some potential directions in the way privacy requirements should be treated. We reflect on the limitations of existing approaches with regards to unbounded privacy requirements and highlight a set of key challenges for requirements engineering research with regards to managing privacy in such unbounded settings

Privacy requirements: Present & future

Software systems are increasingly open, handle large amounts of personal or other sensitive data and are intricately linked with the daily lives of individuals and communities. This poses a range of privacy requirements. Such privacy requirements are typically treated as instances of requirements pertaining to compliance, traceability, access control, verification or usability. Though important, such approaches assume that the scope for the privacy requirements can be established a priori and that such scope does not vary drastically once the system is deployed. User data and information, however, exists in an open, hyper-connected and potentially 'unbounded' environment. Furthermore, 'privacy requirements - present'and 'privacy requirements - future' may differ significantly as the privacy implications are often emergent a posteriori. Effective treatment of privacy requirements, therefore, requires techniques and approaches that fit with the inherent openness and fluidity of the environment through which user data and information flows. This paper surveys state of the art and presents some potential directions in the way privacy requirements should be treated. We reflect on the limitations of existing approaches with regards to unbounded privacy requirements and highlight a set of key challenges for requirements engineering research with regards to managing privacy in such unbounded settings

Discovering "unknown known" security requirements

Security is one of the biggest challenges facing organisations in the modern hyper-connected world. A number of theoretical security models are available that provide best practice security guidelines and are widely utilised as a basis to identify and operationalise security requirements. Such models often capture high-level security concepts (e.g., whitelisting, secure configurations, wireless access control, data recovery, etc.), strategies for operationalising such concepts through specific security controls, and relationships between the various concepts and controls. The threat landscape, however, evolves leading to new tacit knowledge that is embedded in or across a variety of security incidents. These unknown knowns alter, or at least demand reconsideration of the theoretical security models underpinning security requirements. In this paper, we present an approach to discover such unknown knowns through multi-incident analysis. The approach is based on a novel combination of grounded theory and incident fault trees. We demonstrate the effectiveness of the approach through its application to identify revisions to a theoretical security model widely used in industry

Sustainability Design and Software: The Karlskrona Manifesto

Sustainability has emerged as a broad concern for society. Many engineering disciplines have been grappling with challenges in how we sustain technical, social and ecological systems. In the software engineering community, for example, maintainability has been a concern for a long time. But too often, these issues are treated in isolation from one another. Misperceptions among practitioners and research communities persist, rooted in a lack of coherent understanding of sustainability, and how it relates to software systems research and practice. This article presents a cross-disciplinary initiative to create a common ground and a point of reference for the global community of research and practice in software and sustainability, to be used for effectively communicating key issues, goals, values and principles of sustainability design for software-intensive systems.The centrepiece of this effort is the Karlskrona Manifesto for Sustainability Design, a vehicle for a much needed conversation about sustainability within and beyond the software community, and an articulation of the fundamental principles underpinning design choices that affect sustainability. We describe the motivation for developing this manifesto, including some considerations of the genre of the manifesto as well as the dynamics of its creation. We illustrate the collaborative reflective writing process and present the current edition of the manifesto itself. We assess immediate implications and applications of the articulated principles, compare these to current practice, and suggest future steps

Requirements: The Key to Sustainability

Software's critical role in society demands a paradigm shift in the software engineering mind-set. This shift's focus begins in requirements engineering. This article is part of a special issue on the Future of Software Engineering

Survey of Aspect-Oriented Analysis and Design Approaches

A number of Aspect-Oriented (AO) Requirements, Architecture, and Design approaches have emerged recently. In this report we survey the most significant of these approaches, considering their origins, aims, and contributions. Alongside the AO approaches, we also analyse some of the contemporary non-AO work in order to bring out the differences between two sets of techniques, and to understand the potential contributions of aspect-oriented analysis and design. We also provide some initial insights into processes for AO requirements engineering, analysis and design which may serve as basis for integration of the work of the AOSD- EUROPE project partners. We also outline some issues relevant to such integration

The First Rule of Software Sustainability: Do not talk about Software Sustainability?

<p>Principally associated with the field of ecology in order to address humanities increasing ecological footprint on the planet Earth, sustainability as a concept has emerged as an area of interest in the field of computing. While a number of related communities have attempted to understand and address the challenges of sustainability from their different perspectives, there is a fundamental lack of understanding of: the concept of sustainability; how it relates to software artifacts and software systems; and the wider implications of the software development process and the impact of software products on the different dimensions of sustainability. This position paper argues that current efforts to address the sustainment i.e. longevity, of software and software systems are futile because of a lack of a common definition of sustainable software, which results in a misalignment with established software engineering theory and best practice that enables software products to endure. While there have been a number of previous attempts to define sustainability no consensus has been reached. As a result, the term remains illusive and ambiguous. This paper argues that the primary barrier to making progress in the field of sustainable software systems engineering is the lack of a concrete definition, which lays the foundation to understand how to design software that is [technically] sustainable. As a basis for discussion we propose a definition of sustainable software as a first-class, composite, non-functional requirement that includes as its basic building blocks the base sub-characteristics of maintainability and extensibility.</p