Evidencing Sustainability Design through Examples

Abstract

-Significant research has recently been undertaken within the Requirements Engineering (RE) community towards understanding, integrating, and evaluating sustainability concerns in software systems. However, there still is no single point of reference for either RE researchers or practitioners where the work on sustainability is gathered and exemplified. It is the aim of this paper to become such a reference point. Here we review the current work on RE and Sustainability, and gather both the set of available approaches and demonstrative examples on how each of the RE activities - from feasibility study to requirements management - can be undertaken with explicit support for sustainability. This paper aims to serve as a starting point for RE researchers and practitioners who wish to start to positively contribute to sustainability of the socio-technical systems via RE research or practice. Index Terms-Sustainability, sustainability design, requirements engineering, example

I. INTRODUCTION

Recently the Requirements Engineering (RE) research community has brought forward a number of methods, techniques and approaches for systematically engineering sustainability of software systems and their situated contexts through requirements engineering activities. Yet, there is still a shortage of reported case studies and examples on application of these techniques, and where available, such reports tend to focus on a single RE activity. As a result, those wishing to engage with the research and practice of sustainability engineering through RE lack a single integrated view on the current state of art and practice. The aim of this paper is to address this omission, and provide an integrated perspective on current techniques and approaches in RE for sustainability design.

Here sustainability is defined as the ability of a system to endure and prosper, thus, such a system will: be technically sound and adaptable (technical aspect of sustainability); positively contribute to its natural environment, or, at the very least, actively minimize its negative impact (environmental sustainability); positively contribute to the personal well-being and sense of worth of its users (human sustainability); positively contribute to cohesion and trust in the community of its users (social sustainability); support continued economic prosperity of its situated business (economic sustainability).

In this paper we have collated a number of techniques that aim to strengthen the above outlined sustainability aspects throughout the requirements engineering process. While the presented collection of techniques and approaches is not comprehensive, it does provide a good and encompassing overview of the major body of work related to requirements engineering activities for sustainability. The sources used for this paper have been taken from two recent systematic literature reviews on software engineering and sustainability [ 1 ], [ 2 ] and the latest work presented at RE4SuSy 2014 workshop [ 3 ].

The collected work is discussed and illustrated through two running examples from industry. We use the same example systems for illustrating the use of different techniques, explaining their application, and highlighting the peculiarities that handling sustainability concerns could cause throughout RE. Such an illustrative reference is crucial for convincing the practitioners of the validity of proposed methods and research results, as well as for helping the researchers to place their work within the current related work.

Outline: After introducing the illustrative examples: the DriveNow car sharing example and the ONE nursing system, we go through all major activities in RE (from feasibility study to requirements management) and describe how these can be undertaken while taking sustainability into consideration, and illustrate how this was done in the two respective example studies. Then we provide brief review of related work for each of the activities from the available research literature.

II. OVERVIEW OF THE KEY EXAMPLES

DriveNow is a car sharing platform from BMW Munich, currently offering its services in four countries. The business

Copyright c 2015 for this paper by its authors. Copying permitted for private and academic purposes. model is commercial car sharing for registered users with flexible drop-off points for the vehicles on public parking lots.

The car sharing system is composed of a web application for registration, reservation and billing, a car fleet maintained by a service partner where each car is equipped with a meter and a transponder, and a central database. In exchange for a one-time fee, members of the program can use DriveNow cars whenever needed. The nearest car can be located and reserved though an online application or via phone. Once reserved, the car is held free of charge for 15 minutes. Members only pay for the time they used the car, not needing to inform in advance about when they will need it for. At the end of a booking, the car can be dropped anywhere in a specified business area. Members can also choose the car model they want, incur no extra fuel costs, and park for free within city limits. DriveNow is an interesting example as it can show “a positive contribution towards sustainability and environmental protection” [ 4 ]. It is also highly dependent on technology, including the development of the infrastructure and of the diverse platforms that allow providers, partners and users to interact with the system.

The ONE is a public institution run by the Belgian government that supports children’s development from birth. Most services offered by ONE are free of charge. The institution is hierarchically structured in three layers (see Fig.1):

Layer one is the strategic management. Its main function

is to develop birth and childhood policies. It also supports functions like finance, IT, and training.

In layer two is the decentralized operational management which is located in six regions for coordinating the daily field work. The main functions at this level are to support children’s development within their families and social environment via prenatal consultations, medical and social children’s consultations, and outside of the family environment via day care. Additionally, information for future parents, training activities, and field studies is provided. These main functions are supported by two key roles: administrative referent and team coordinators. The third layer consists of teams executing the field work. The teams are composed of nurses working together with hired doctors. Each team is responsible for a small geographic location (for example a city district).

The overview of the organization is provided in Fig. 1.

III. REQUIREMENTS ENGINEERING WITH

SUSTAINABILITY CONCERN: A WALKTHROUGH

In the following we briefly discuss each of the RE activities in turn (such as, feasibility study, stakeholder identification etc.) along with very brief summaries of accepted RE techniques for handling them. Relevance of sustainability to each such activity is also commented upon. Then, using the above discussed example cases, we outline how these activities can be handled while explicitly considering sustainability. Finally, for each activity some additional related work is summarized.

1) Overview of feasibility study and its relevance to sustainability: A feasibility study is carried out to check if it is feasible to implement the desired system. During this activity the project goals are defined and contradictions between these goals and the existing organizational values explored. In summary, a cost/benefit analysis is conducted on undertaking the project. Should these analysis indicate expected loss from the project, the project will be canceled or substantially modified. The following issues need to be addressed during the feasibility study for a software system project: Does the system contribute to overall objectives of the organization (which objectives, and how)? Are there any better alternative such that the system is not necessary? What problems will be addressed through the system? Can the system be implemented with given technology and within given cost? Is the organization able and willing to accept new/different technology? Can the system be integrated with other systems already used in the company?

To answer these questions, the techniques used are, for example, a quick SWOT (strengths, weaknesses, opportunities, and threats) or TELOS (technical, economic, legal, operational, schedule) or Business Model Canvas (BMC) analysis.

When sustainability is treated as an explicit concern in a feasibility study, the threats to and opportunities for all aspects of sustainability of the organization and its situated societies need to be considered. Similarly, so do the effects of the intended system (including its immediate, indirect, and systemic effects). Moreover, one needs to question if the system goals align with the values of the intended customers, users, and its situated societies.

2) Illustrative Examples: DriveNow: To undertake the feasibility study of the DriveNow system, the Business Model Canvas (BMC) technique is used. The BMC method creates a one page graphical model that helps understand the structure of a business [ 5 ] by asking how an enterprise creates, delivers and captures value.

The BMC of the DriveNow system is shown in Fig.2. Since sustainability is considered as an explicit concern, such value proposition of the business as the “Environmentally Sustainable Transportation” and “Integrated Transport” are identified, as this business “seeks to minimize the use of scarce resources and maximize the use of more sustainable, low impact forms of travel” [ 6 ]. Education on Environmental Sustainability is also identified as a value provision stream: aiming to increase uptake of this car sharing through educating customers on its green credentials. Moreover, the value for human sustainability aspect is supported via “Flexibility” of the customers as well as their fulfillment via “Driving Premium Cars”.

Whether the system has an explicit purpose for sustainability or not, it will cause some impact on sustainability. The feasibility study should also consider the three-order effects of the system [ 8 ]. For the DriveNow system, first-order effects are caused by the resource consumption of the system itself (e.g., the energy use). The second order effects arise from cars being shared, which decreases the overall consumption of resources (e.g., no need to bring own car to the city and use extra gas, or use up parking space for long time). The third-order effects arise from system leading to reduction in the number of cars produced (as less cars are individually owned), greater availability of parking spaces and, less congested streets.

ONE: The SWOT analysis for the ONE example highlighted that the main strength of a software system development is in improved access of the families with young children to the relevant information and care services, as well as in improved utilisation of the staff time. The system will also provide an opportunity to deliver the relevant information to young immigrant families with limited French/English language skills, as well as those with limited mobility. Main threats here are in missing out relevant requirements and viewpoints which may jeopardies acceptance of the new system by the intended users.

A number of sustainability goals have been identified for the ONE, such as:

Reduce need to travel for nurses

Optimize format of consultations delivery (at fixed centres, periodic visits,via bus, at home); Ensure equal access for all, especially for the families requiring more help and disabled; Reduce paper flow (electronic reporting, claims, statistics, etc); Minimize language barriers (e.g. multilingual electronic information, interpreters available at designated centers).

For the ONE system, first-order effects arise, for instance, through the resource consumption via different devices the application is used on and the database servers for it (environment), or the change of work practice of the nurses, and access to multilingual information and interpreter for nonnative speakers (individual).

The 2nd order effects include reduced emissions by the organisation due to reduced travel, increased number of families reached and children/prospective parents consulted, better customized support for young families, reduced paper and printing materials use.

The systemic effects include, for instance, less congested health centres, decrease in personal stress in young families, better children’s welfare and, in the end, a higher welfare of the society. Overall the system aligns well with the social values of the organisation as well as of its situated community.

3) Other Work on Feasibility: Mahaux et al. [ 9 ] present a study focused on minimising the impact of an event organization business (Yellow Events) on environmental sustainability. Here the feasibility study is undertaken through a “rich picture” style context model. This technique allowed to broaden the context considered for the system-to-be from the product to the “environment-at-large”; the main actors and the material/information flows between actors were captured in the picture so that the impact of the business on environmental sustainability can be visualized. This model was used to identify opportunities to (1) minimize transportation of physical artifacts, (2) perform environmental calculations (e.g., carbon footprint), (3) check what has been tackled to lower the environmental impact, (4) help the environmental specialists to assess current impact, and (5) communicate with all stakeholders on improvements and alternatives.

Penzenstadler et al. [ 10 ] model a system for medication adherence. The project followed the template according to business case method used at the Harvard Business School.

First, the problem was defined, then the current situation was analyzed, which was followed by review of other solution options and cost-benefit analysis. The Business Case Analysis reveals the perspective of the stakeholders’ view on the problem that will be solved by the software system under development. In addition to the core elements (problem, analysis, solutions, recommendations, and project description), the Business Case Analysis for this requirement specification also included a section devoted to how the project will contribute to sustainability.

4) Summary Feasibility Study for RE with Sustainability Concern: In summary, when undertaking a feasibility study, one should consider the strength, opportunities, threats and weaknesses that the system-to-be will pose to the full set of sustainability dimensions, both through its direct use, and in the longer term, due to its enabling and systemic effects.

The same techniques and tools that are already used for feasibility analysis (SWOT, TELOS, BMC, rich picture, etc.) can be applied, as long as an explicit consideration is given to each aspect of sustainability.

1) Overview of stakeholder identification and its relevance to sustainability: Any (group of) individual(s), organization or any entity that has interest or could be affected by the software system-to-be is a stakeholder to that system. Since stakeholders are the primary source of requirements, collaboration with the right set of stakeholders ensures that the right requirements are identified and a useful system is implemented. Traditionally, stakeholder identification is carried out by selecting those entities who can be affected by or affect the project. It can also be done through analysis of system goals and strategies to fulfill these goals, or through analysis of roles and interactions with the system, by using reference lists and models (such as Onion model), business process or rich picture analysis. Stakeholders can also be discovered by complying conventional theory of power, legitimacy and urgency [ 11 ].

In order to integrate the right sustainability requirements into a given system, it is necessary to identify the appropriate sources for such requirements, i.e., their stakeholders. While a good set of relevant sustainability requirements (e.g., those related to human, social, or economic concerns) can be elicited from the traditional stakeholders, additional stakeholders are necessary to present the otherwise silent interests, such as environmental, or longer-term effects of the system on future stakeholders. This can be done through establishing a role of sustainability advocate, or including surrogate stakeholders for marginalised or currently unavailable groups, such as a representative for future generations, or (at the very least) by referring to a domain expert on environmental standards, legislation, and regulations.

2) Illustrative Examples: In the DriveNow system a number of stakeholder groups were identified through traditional reference lists, goal analysis, and semi-structured interviews with known stakeholders. Additionally, a sustainabilityspecific stakeholder reference list was used [ 12 ] to find the missing sustainability stakeholders. The stakeholder model for the DriveNow system then included additional stakeholders that advocate sustainability or serve as domain experts for life cycle analysis, environmental concerns and regulations, or social standards.

For the ONE case, the existing organization was used to identify stakeholders, then business process modeling commenced from a process cartography, which became progressively more detailed. After this, goal modeling (in connection with a specific project) was applied - working with the known key stakeholders to identify additional context specific stakeholders. A context diagram was used to picture information flow to identify current and future information producers and consumers. The set of identified stakeholders also included those that advocate social sustainability, childcare “concerns”, legislation for medical regulations, and social standards. The set of so identified stakeholders is shown in Fig.3 below. It includes those that advocate social sustainability, childcare “concerns”, legislation for medical regulations, and social standards.

3) Other Work on stakeholder identification: In Mahaux et al. [ 9 ], stakeholders for the Yellow Events were identified using the Volere checklist [ 14 ], which already included the role of “Environmental Specialist”. Additionally, authors defined “green thinking” and “anti-green thinking” clients and event participants. They suggest that most of the classical roles of stakeholders could have a “green” counterpart: green user, green client, green champion, and green finance specialist, etc.

Penzenstadler et. al., [ 15 ] propose that stakeholders for sustainability can be found from four potential information sources through the following simple approaches: 1) Analyzing sustainability dimensions (e.g., via goals/softgoals) for the given system to find roles of responsibility, and match them top-down to the context of the system-to-be; 2) Instantiating generic lists of sustainability stakeholders

for the concrete context; 3) Inspecting the context, understanding which concrete roles are involved, and matching them bottom-up to the dimensions; 4) Iteratively analyzing and refining a generic sustainability

model.

In the system for medication adherence from Penzenstadler et. al., [ 10 ], the stakeholders involved in the development and operation of the system are depicted, along with their relations to the system with regards to contribution to all five dimensions of sustainability through first, second, or third order effects. Ten stakeholder types are identified with some directly interacting with the system, others taking on passive role, but still affected by it.

4) Summary of stakeholder identification for RE with Sustainability Concern: In order to represent sustainability requirements in the software systems, the relevant stakeholders must be identified and engaged into the RE process. This can be done by complementing the traditional stakeholders with sustainability-specific ones through dedicated reference lists for sustainability stakeholders (See Penzenstadler and Femmer [ 12 ] for a generic model for a generic list of sustainability stakeholders); business and operational context and goal analysis to identify relevant roles for the present and future, or explicitly accounting for a “green” and “anti-green” counterparts of each identified stakeholder. Additionally, relevant requirements will be elicited from more traditional stakeholders, if they are made aware of sustainability and its relevance to the specific stakeholders. It is evident that this process will lead to identification of many more stakeholders than “normal” with often new roles emerging to take responsibility for sustainability. Yet, if the costs and opportunities of sustainability were considered in the project feasibility study, the sustainability stakeholders will provide an invaluable source of capitalizing on these opportunities and learning how to counter their respective threats and weaknesses.

C. Requirements elicitation

1) Overview of requirements elicitation and its relevance to sustainability: Requirements elicitation is the phase where the stakeholders are interviewed, workshops are held to derive usage scenarios, legal documents and standards are scanned for identifying constraints, and users are questioned with regard to their objectives, wishes, and needs. There is a plethora of methods for this task, from observation to creativity techniques, from storyboarding to analysing feature requests, all with the objective to find out what the requirements for the system-to-be are.

Requirements elicitation is crucial for sustainability, as this is the task where the requirements engineer is actively in touch with all the stakeholders. If sustainability is acknowledged as a key topic at this point in the conversation with the stakeholders, it will be integrated into the requirements which will define what the system is and does. In short, if recognised and elicited as a set of necessary requirements, sustainability will be designed into the system.

2) Illustrative Examples: DriveNow: Elicitation of requirements in DriveNow is supported via goal decomposition, where a goal is an objective the system under consideration should achieve. Here the objectives were elicited by considering the dimensions of sustainability and how they can be reflected with regard to the system. The set of original goals was collected through a number of semi-formal interviews with relevant stakeholders.

ONE: Goal-based elicitation technique was also utilised in case of ONE. Here functional and some quality goals were identified from business process models with structured template requirements. Several of these goals (such as volume of information, paper flow, statistics, need for travel) directly reflect sustainability concerns. An excerpt for the ONE goal model is shown in Figure 4 below. An example issue identified via the this goal analysis is the substantial difference in work organisation, depending on geographical characteristics of the locality. Thus, in cities, due to very high density of population, fixed deployment of nurses and doctors was preferred. In rural areas with lower population density regular-frequency consultations (i.e. once a week) were chosen. In remote areas, with very low population density, a specially equipped bus was preferred where bus stops had to be customised to the current demand.

3) Other Work on requirements elicitation: In the Yellow Events study [ 9 ], author use and misuse case analysis [ 16 ] was used in elicitation of sustainability requirements. Since this study was focused on environmental sustainability, for each use case two questions were explicitly considered: What is (or might be) harmful to the environment here? and How to mitigate the identified harm? This resulted in identification of new use cases and/or modification of previously developed ones.

Penzenstadler et. al., [ 10 ] uses goal modelling to explore how the medication adherence system could improve the five dimensions of sustainability, though human sustainability, aiming to improve patient’s well-being, which is the project’s central sustainability goal.

Ahmed and Khaled [ 17 ] suggest to first raise awareness on a particular sustainability topic amongst the stakeholders, and only then gather the sustainability requirements. They describe how such requirements have been collected from users and stakeholders after an informal workshop about alternative energy sources such as wind or solar energy.

4) Summary of requirements elicitation for RE with Sustainability Concern: Requirements elicitation can be accomplished through interviews, observation, participatory workshops, as well as through goal elaboration, etc. The key guideline here is an explicit and deliberate treatment of sustainability as a topic of relevance to other areas of requirements. This can be facilitated by either explicitly looking for misuse of the system-to-be with respect to sustainability (either through use/misuse cases, or through goal/anti-goal analysis), and following general “good practice” for sustainability requirements identification. These practices include, for instance [ 18 ], a few specific guidelines in requirements elicitation, such as: (1) consider the estimated service time of the software and expect to run it on legacy hardware to avoiding disposing of existing hardware; (2) avoid using screens with bright colors (as they consume more power) or colors that might harm user eyes; (3) requirements should include switching off the devices or operating in low power mode when not in use; (4) avoid throwaway prototyping to elicit and understand requirements, due to its unnecessary use of power, paper and custom hardware.

When working with goal models, a generic sustainability goal model [ 12 ] can be instantiated for a specific system, if sustainability is considered a major purpose of the system-tobe. When sustainability is one among a number of equally important objectives, it is more appropriate to develop an overall goal model for the system and to detail the sub-model for the objective of sustainability by using the sustainability dimensions and the generic sustainability model as a reference.

D. Analysis and Negotiation

In [ 27 ] a rich picture of the medication adherence system vision was used to take the input from the stakeholders and goals and use this as a basis for the system use discussion.

This approach is used to give an overall view of the functions of the system and how the stakeholders interact with it, as well as for communication with a whole range of technical and non-technical stakeholders.

Kocak [ 28 ] used the ANP based framework to prioritize green software criteria in order to conduct trade-off analysis. The framework can facilitate the identification of interdependencies between non-functional requirements and green requirements, and their mutual influence as well as interactions with the environmental sustainability concerns. The priority weights, provided by the stakeholders for a number of attributes, may be used to analyze trade-offs between conflicting product quality and environmental requirements.

4) Summary of analysis and negotiation for RE with Sustainability Concern: As with analysis and negotiation for other requirements, points of conflict, risks, or uncertainties identified for sustainability requirements need to be resolved.

In many cases the established negotiation techniques (such as conflicts between goals, or AHP) can be used. However, one of the main peculiarities of sustainability requirements is their longer time span. In view of this, additional future forecasting techniques, such as IMAGINE scenario development or use of system vision can prove very useful.

1) Overview of analysis and negotiation and its relevance to sustainability: In this activity, the elicited requirements are reviewed to uncover problems, such as inconsistencies and incompleteness, and identify risks, such as safety hazards, security threats, and development risks [ 19 ]. These problems are then taken back to stakeholders be resolved through negotiation. A number of methods and techniques can be used in this phase, such as checklists for identifying problems, fault trees for risk analysis [ 20 ], qualitative and quantitative reasoning for evaluating multiple options [ 21 ], and analytic hierarchy process for requirements prioritization [ 22 ], among others. All these techniques could be used with sustainability requirements as well, yet, a more desirable solution often is to consider this as an opportunity for creative win-win solutions.

Sustainability often is seen as competing with other system goals [ 23 ] or as a trade-off between the present and the future, as reinforced by the Brundtland report [ 24 ]. Analysing and negotiating requirements with respect to sustainability, requires considering its various perspectives, stakeholders, and impact orders [ 8 ], as well as trying to find strategies that attend both the present and future needs.

2) Illustrative Example: DriveNow: In this case [ 4 ] used E. Documentation the IMAGINE scenario development technique [ 25 ] (adapted 1) Overview of documentation and its relevance to sustainfrom the sustainable development domain). Here sustainabil- ability: Requirement documentation is the process of speciity indicators and their boundaries were elicited from stan- fying requirements and constraints clearly and as precisely as dards, regulations and press publications, as well as from possible. A good documentation defines how software will the stakeholders. The most relevant sustainability indicators interact with system hardware, other programs and human were then chosen through stakeholder prioritization. Indicators users in a wide variety of real-world situations. Documentation and boundaries were used to define minimum and maximum is used to establish an agreement between the customers sustainable scenarios, and to analyse the current status of the and the suppliers on what the software product is to do, system against a desired future one. These were represented for estimating costs and schedule, providing a baseline for in the AMOEBA diagram shown in Fig.5. validation and verification as well as to support maintenance

ONE: For ONE, the negotiation centred around such ob- and future extension [ 29 ]. Documenting sustainability requirestacles as specific hardware needs or legal signature require- ments is not much different form documenting other (quality) ments preventing transformation of paper documents flow requirements. However, presently it may prove impossible to into electronic versions. Negotiation involved a conversation provide a measurable and specific specification for a number between several stakeholders with different goals and lead to of sustainability requirements (such as those related to soreviewing the current business processes, refactoring them, and cial sustainability or long-term human sustainability), as the converging to a new set of processes. quantification frameworks for these are yet to be developed.

3) Other Work on analysis and negotiation: In the Yellow Where quantification is possible (e.g., environmental impact Events system [ 9 ], the positive and negative goal contributions measured in in terms of CO2 emissions) documentation (as for from the goal models were used as drivers for negotiation. any other requirements) should normally be completed using The lower level goals were used to identify the list of impacts set templates, such as those provided by ISO standards [ 29 ]), between goals as well as the possible resolution actions, and or templates for use cases [ 30 ], and Volere Shell [ 31 ]. compensation programs. 2) Illustrative Examples: DriveNow:

The work of Gu et. al., [ 26 ] uses a Green Strategy Model to In this study [ 7 ] the Volere Shell requirement specification break “green goals” (i.e., those with ecological implications) template [ 31 ] was used to document system requirements; the down into (a number of) “green actions”. This model can be environmental sustainability dimension was considered a nonused for the sustainability goal elaboration and negotiation on functional requirement. The used template consists of parts the actions to be taken in order to reach these goals. describing the requirement type, its brief description and a rationale; it is also checked for representability, completeness, and concretization.

Further details on the documentation of DriveNow include use case specifications [ 32 ], sustainable system vision, feature descriptions and purpose of the features, preconditions, and variations that enable users to carpool.

ONE: In case of ONE, the results of the analysis of business processes, management processes, and support processes were documented in two,100 page specifications that adhered to a standardized template (based on the ARIS method) using organizational diagrams as well as UML models. These also include use cases templates, process modeling in activity diagrams, etc. Furthermore, the documents comprise a detailed description of the surrounding operational environment, i.e. the systems that interact with the system-to-be through a variety of interfaces.

3) Other Work on documentation: For Yellow Events [ 9 ], a number of RE documents have been used, including richcontent context diagram, use case diagram, goal models, template-based textual requirements specification as well as class diagrams, glossary, and business process models. Sustainability requirements were documented in many of these.

In work on the Green Strategy Model [ 26 ], it is suggested that domain experts should codify the green actions and describe each actions in terms of different fields, such as type, short descriptions, long description in the spreadsheet. The objective of creating such a spreadsheet is to collect green actions of each goal, and then share and communicate with other application fields.

In [ 27 ] a categorisation for sustainability requirements and constraints is proposed that groups these into four categories: process requirements, deployment requirements, system constraints, and quality requirements. Further concerns for the system or the project may be managed in a risk list.

4) Summary of documentation for RE with Sustainability Concern: As with all documentation, the main consideration when documenting sustainability requirements is in striking the right balance with detailed specification which avoids duplication. Whichever technique is used for documentation, the longer term consequences and the systemic nature of sustainability requirements must be considered. For instance, uses of systems that would arise after a period of system exploitation could be considered, as is done with the system vision and IMAGINE techniques. Similarly, the cumulative effect of individual uses of the system must be reviewed, which would lead to defining minimum and maximum operational parameters for a given system and safe failover in case of under-use or overflow should be designed into the software.

F. Validation

1) Overview of validation and its relevance to sustainability: Validation is an activity whereby previously elicited and consolidated requirements (aggregated from elicitation, analysis, negotiation, documentation) are fed back to the system stakeholders to make sure the requirements still corresponds to stakeholder needs. This is because, given the changing (and possibly iterative) requirements engineering process, these could have been substantially altered.

Validation is carried out through requirements walkthroughs, inspections, and desk checks, as well as through prototyping. This activity is particularly important to ensure that the utility of the intended system in maximized. It is also particularly relevant for sustainability requirements, given that sustainability goals often mandate engagement and cooperation of multiple stakeholders, and it is essential to ensure that they all agree and remain committed to the same sustainability requirements.

2) Illustrative Examples: DriveNow: Validation for the car sharing system was mainly performed by presenting the models developed in the previous stages to the main stakeholder from BMW, the project manager of the DriveNow.

There were two requirements meetings which were kicked off with presentations by the BMW stakeholder, followed by long QA sessions with the requirements engineers. After the requirements analysis, specification and documentation in each phase, there was a validation workshop with presentations by the requirements engineers and clarifying questions.

With respect to sustainability, the following steps were taken: (1) to evaluate current status of the system and the opportunities for improvements in each of the sustainability indicators, and (2) plan corrective actions, in order to achieve the desired system state. In particular, points that needed to be improved for the DriveNow system were: the number of cars to be saved (for the environmental perspective), the system availability (for the technical perspective), and the market acceptance (for the economical perspective).

ONE: Validation at ONE was carried out iteratively and with different level of stakeholder participation: first by a requirements analyst with one of the stakeholder parties, then internally by the manager with the relevant doctors and nurses team, from which feedback was given to the requirements engineer, and, finally, with participation of all stakeholders together. Through these activities, it was observed that the regional differences lead to very different perspective of some sustainability requirements. Thus permanent, static, fully equipped admission rooms were required in cities, but only regular visits or bus trips in rural areas; continuous internet connection and desktop-based applications were needed in permanent locations, but mobile devices and even simply phonebased interaction was required for others. Thus, the validation activities allowed to segregate locations-based variability in the interpretations of sustainability goals (previously considered homogeneous for all), and to take respective design actions.

3) Other Work on validation: In related work [ 10 ] Penzenstadler et. al. reported that consulting with the Environmental Protection Agency and a sustainability expert gave their project an opportunity to validate goals and the relations between the goals and the five dimension of sustainability.

4) Summary of validation for RE with Sustainability Concern: When undertaking validation of sustainability-related requirements, one needs to ensure that all stakeholders concerned with the given sustainability requirement have a consistent, shared view on its content and implications. The importance of this point is demonstrated by the above discussed case of ONE, where the initial agreement on sustainable service delivery goal was found to imply very different implementations depending on population density of a given location.

Furthermore, given the fast changing notion of sustainability, it is likely that the understanding of such requirements will evolve and change quite frequently, which will lead to change of the system vision and IMAGINE scenarios, which were discussed previously for the DriveNow example. Thus, repeated validation from multiple perspectives is advisable where external stakeholders (such as domain experts on environmental or social sustainability) can also provide an invaluable input.

G. Management

1) Overview of management and its relevance to sustainability: Requirements management is the activity focused on maintenance and control of requirements’ information of a software system for the duration of that system’ lifetime. It is primarily concerned with change control, integrity preservation, and traceability of requirements. This tends to be a rather challenging task due to difficulties in maintaining consistency and integrity within and between the continuously evolving requirements. While this activity can, to some degree, be supported with tools (such as DOORS or IBM Rational), the maintenance process cannot be fully automated and is ultimately dependent on the consistency and commitment and of the requirements engineering team. For sustainability requirements such commitment will be even more important given that it is a very fast changing domain.

2) Illustrative Examples: In the DriveNow project, requirements were documented through a consistent template by all teams. Following the initial basic set of requirements, several teams of requirements engineers developed specifications for the best system extension in a competition. Consequently, they managed their requirements in a distributed way. Yet, there was no central repository other than the final delivered specifications, or change and traceability management support.

In the ONE project, requirements were managed inside the ARIS toolset. The project was aligned with a larger inhouse cartography method (called “GPS”) to collect the organisational structure, existing business processes, information flows, and related IT applications. ARIS allowed to share items across different models and to generate reports able to link goals and business processes. However there was no company wide sustainability view explicitly encoded in the repository.

3) Other Work on management: In [ 33 ], a conceptual reference model is developed for the development, usage and “end of life” of sustainable software. Among other things, the authors propose that system performance with respect to its requirement must be monitored, measured, and, where possible, supported. Although the specific metrics and actions for each requirement will be quite different, what matters here, is the explicit expectation of change in sustainability requirements, which will have to be supported via RE change management.

4) Summary of management for RE with Sustainability Concern: As noted before, sustainability requirements are not only multi-faceted (i.e., related to 5 different dimensions of sustainability), but are also shared and affected by several simultaneous stakeholders, and so can change due to change in perception of one of these stakeholders. Thus, to achieve a shared understanding, validation workshops, as well as consistent record keeping (i.e., documentation) of the stakeholder or environmental change, could be very useful.

IV. CONCLUSIONS

This paper serves as a single point of access for RE researchers and practitioners to the currently available techniques for handling sustainability in RE. It also shows examples of application of some of these techniques in two case studies: a car sharing system and a nursing service system.

The major insight from our contribution is that over the past few years our research community has accumulated a number of approaches and methods that may well serve as a starting point for practitioners to integrate sustainability into their daily development activities on a broader scale. As software engineering educators, we have the responsibility to integrate new research insights into our teaching, and to thereby improve the knowledge of the future generation of software engineers.

As future work, we are planning to publish an extended version of this report with more encompassing details and analysis of the examples. Furthermore, we are intending to elaborate a set of studies in collaboration with industry to get further feedback on recently proposed methods for integrating sustainability into requirements. Finally, we envision an assessment model that helps compare those different approaches with regard to effectiveness, usefulness and usability.

V. ACKNOWLEDGEMENTS

This work is partially supported by the European Social Fund; Ministry of Science, Research and the Arts BadenWu¨ rttemberg; FP7 ASCETiC project (No. 610874); FAPERJ and CNPQ funding agencies.

References

[1] B. Penzenstadler and et. al., “Sustainability in software engineering: A systematic literature review , ” in Int. Conf. on EASE , 2012 .

[2] B. Penzenstadler and et. al, “ Systematic Mapping Study on Software Engineering for Sustainability (SE4S),” in Intl . Conf. on EASE , 2014 .

[3] RE4SuSy .

[4] A. Rodriguez and B. Penzenstadler , “ An assessment technique for sustainability: Applying the imagine approach to software systems .” in RE4SuSy@ RE. Citeseer, 2013 .

[5] A. Osterwalder and Y. Pigneur , Business model generation: a handbook for visionaries, game changers, and challengers . John Wiley & Sons, 2010 .

[6] M. LLC. ( 1999 ) MS Windows NT kernel description . [Online]. Available: http://web.archive.org/web/20080207010024/http: //www.808multimedia.com/winnt/kernel.htm

[7] I. Krasnov , “ Artefacts and techniques to support environmental sustainability in specifying a car sharing platform ,” 2012 . [Online]. Available: https://www4.in.tum.de/ penzenst/sources/2012 Krasnov BA RE SUST.pdf

[8] F. Berkhout and J. Hertin , “ Impacts of information and communication technologies on environmental sustainability: Speculations and evidence,” Report to the OECD, Brighton , vol. 21 , 2001 .

[9] M. Mahaux , P. Heymans , and G. Saval, “ Discovering sustainability requirements: an experience report,” in Requirements engineering: foundation for software quality . Springer, 2011 , pp. 19 - 33 .

[10] B. Penzenstadler , J. Mehrabi , and D. Richardson , “ Supporting physicians by re4s: Evaluating requirements engineering for sustainability in the medical domain,” in GREENS . IEEE, 2015 .

[11] C. Pacheco and E. Tovar, “ Stakeholder identification as an issue in the improvement of software requirements quality , ” in Advanced Information Systems Engineering . Springer, 2007 , pp. 370 - 380 .

[12] B. Penzenstadler and H. Femmer , “ A generic model for sustainability with process-and product-specific instances,” in GREENS . ACM, 2013 , pp. 3 - 8 .

[13] S. S. Christophe Ponsard , Annick Majchrowski, “ Requirements and processes for one child care and related support,” INCA Delivrable 1 , Office de la Naissance et de l' Enfance (in French) , 2013 .

[14] J. Robertson and S. Robertson , “Volere requirements template,” http://www.volere.co.uk. [Online]. Available: http://www.volere.co.uk

[15] B. Penzenstadler , H. Femmer , and D. Richardson , “ Who is the advocate? stakeholders for sustainability,” in GREENS . IEEE, 2013 , pp. 70 - 77 .

[16] G. Sindre , “ A look at misuse cases for safety concerns ,” in Situational Method Engineering: Fundamentals and Experiences. Springer, 2007 , pp. 252 - 266 .

[17] F. Ahmed and K. Shuaib , “ Incorporating green it concepts in undergraduate software requirements engineering course: An experience report,” in Information Systems and Technologies . IEEE, 2012 , pp. 1 - 4 .

[18] S. S. Shenoy and R. Eeratta , “ Green software development model: An approach towards sustainable software development,” in INDICON . IEEE, 2011 , pp. 1 - 6 .

[19] I. Sommerville and G. Kotonya , Requirements engineering: processes and techniques . John Wiley & Sons, Inc., 1998 .

[20] N. G. Leveson , Safeware: system safety and computers . ACM , 1995 .

[21] L. Chung , B. Nixon , E. Yu , and J. Mylopoulos , “ Non-functional requirements in software engineering -kluwer academic publishers,” MIT, USA, 2000 .

[22] T. Saaty , “ Ahp: The analytic hierarchy process ,” 1980 .

[23] D. Stefan and E. Letier, “ Supporting sustainability decisions in large organisations,” in ICT4S . Atlantis Press, 2014 .

[24] U. U. N. W . C. on Environment and Development, “Our common future (brundtland report ), ” Tech. Rep. , 1987 .

[25] S. Bell and S. Morses , Sustainability Indicators: Measuring the immeasurable . Earthscan , London, 2008 .

[26] Q. Gu , P. Lago , and S. Potenza , “ Aligning economic impact with environmental benefits: A green strategy model,” in GREENS . IEEE Press, 2012 , pp. 62 - 68 .

[27] B. Penzenstadler , “ From requirements engineering to green requirements engineering ,” in Green in Software Engineering. Springer, 2015 , pp. 157 - 186 .

[28] S. A. Koc ¸ak, G. I. Alptekin, and A. B. Bener , “ Evaluation of software product quality attributes and environmental attributes using anp decision framework,” in RE4SuSy , pp. 37 - 44 ), 2014 .

[29] 29148 : 2011 - 12 (E), “Systems and software engineering - systems and software engineering - life cycle processes-requirements engineering ,” 2011 .

[30] S. Adolph , A. Cockburn , and P. Bramble , Patterns for effective use cases . Addison-Wesley Longman Publishing Co., Inc., 2002 .

[31] J. Robertson and S. Robertson , “Volere,” Requirements Specification Templates, 2000 .

[32] B. Penzenstadler , “ Infusing green: Requirements engineering for green in and through software systems , ” Tech. Report UCI-ISR-14-2 June , 2014 .

[33] S. Naumann , M. Dick , E. Kern, and T. Johann, “ The greensoft model: A reference model for green and sustainable software and its engineering,” Sustainable Computing: Informatics and Systems , vol. 1 , p. 294 - 304 , 2011 .