-Manifestos in the history of computer science and software engineering have framed guiding principles upon which processes, methods and tools were developed. The Karlskrona Manifesto for Sustainability Design serves this same purpose as a guide for designing and developing sustainable software systems. The goal of this paper is to explore the derivation of good practices by applying the Karlskrona principles in sustainability requirements elicitation. How can the Karlskrona manifesto be translated into methods, processes and tools in the software requirements engineering domain? The result is a proposed list of best practices for software sustainability requirements elicitation. This will facilitate the application of the Karlskrona manifesto for sustainability requirements elicitation and engineering. Index Terms-Karlskrona Manifesto, requirements engineering, sustainable software, sustainability, best practice, best practice documentation, software requirements, sustainability requirement elicitation, sustainability design
Sustainability has become one of the major issues of society today because of the impact of human activity on our planet – this includes interactions in between individual persons, within communities, and between companies and users. Bonini et al. [1] report that sustainability is an important element in the program of many companies, but their environmental, social and governance activities are disconnected from their core strategy. The challenge for most companies is that there is little understanding of how sustainability can be understood by software and requirements engineering professionals to facilitate sustainability design as an established part of the software development process and, specifically, the requirements engineering process [2][3][4].
Users these days are willing to pay more for sustainable software products and services because of the increased awareness from different worldwide initiatives. One central initiative and set of guiding goals are the United Nations Sustainable Development Goals (SDGs), which state initiatives to tackle different crucial sustainability problems humanity faces [5]. Nielsen’s global online study [6] shows the percentage of consumers willing to pay extra for products and services from companies dedicated to positive environmental and social impact increased from 55% in 2014 to 72% in 2015.
Software is a core of all human activities today and a major facilitator in the way humans produce and use products and services [7]. The way the software is designed, the requireBirgit Penzenstadler ments to ensure sustainability are factors in software design and how software can support sustainability are still areas that are evolving with different challenges on how best to elicit sustainability requirements for software systems [8].
Consequently, requirements engineering has a major role to play in ensuring the sustainability of software in its broadest understanding. The challenge is that, compared to other types of software requirements like usability and security requirements, which have a well-defined systematic structure and principles on how to elicit system requirements [9], there is still less support on how sustainability requirements can be derived systematically.
One known guiding framework for software sustainability design is the Karlskrona Manifesto for Sustainability Design (KMSD). Following in the footsteps of other successful manifestos such as the Agile manifesto [10], the Business Rules manifesto [11] and the Recomputation manifesto [12], the Karlskrona Manifesto proposes principles that aim to serve as a guide – in this case on how to think of sustainability when it comes to software systems design.
Manifestos like the Agile manifesto are one example that has transitioned into processes, methodologies and tools to help practitioners using Agile in software development. Dick et al. [13] showed how the Agile method was used in software engineering processes to develop “greener” software systems supported by Agile software project management. Agile has different frameworks and approaches such as Scrum, Kanban, and Lean. Agile also has some best practices such as test-driven development (TDD), refactoring, continuous integration, and Pair programing [14].
Relating Agile to requirement engineering, Paetsch et al. [15] have studied the similarities and difference between traditional requirements engineering and agile approaches in order to complement agile with some methods from requirements engineering. Up to now, the Karlskrona Manifesto for Sustainability Design has put forward only limited research on transforming these principles into processes, methods and tools that can support software designers and developers during software systems development.
This paper explores a starting point for such a transition of the principles into processes and methods that can educate and encourage software system designers and developers in eliciting software sustainability requirements.
Section 2 covers the background on the Karlskrona Manifesto and best practice documentation. Section 3 presents the research design for the paper. Section 4 sketches the relation between the Karlskrona Manifesto and software development life cycle phases. Section 5 highlights the proposed method for documenting requirements engineering best practices. Section 6 covers the discussion and Section 7 provides concluding thoughts and future work.
The Karlskrona Manifesto for Sustainability Design (KMSD) was initiated through an initiative to create a common ground and a point of reference for the global community of research and practice in software and sustainability to effectively communicate major issues, goals, values and principles of sustainability for the design and development of software systems [16]. KMSD has its roots in the Third International Workshop on Requirements Engineering for Sustainable Systems (RE4SuSy) [17]. The motive for creating the KMSD was as a result of Christoph Becker’s contribution [18] on the relationship between the concerns of sustainability and longevity.
The first stakeholders that contributed, drafted and signed the manifesto were a number of researchers from various areas in the field of software engineering with sustainability research interests as described in [19] [20].
The Karlskrona Manifesto was conceived based on the following guidance [16]: Principles not techniques as a guide for building, developing and improving new/old techniques and tools to support sustainability design. Provide a broader scope to be all-inclusive and encompassing all aspects of sustainability. Bottom up approach to cover all emerging structure from contributions of all participants involved in the initiation of the manifesto. Discussion through participation and transparency to encourage broader engagement of different experts of sustainability and interested participants. Conversation over consensus to enable dialogue among the community of stakeholders and all interested participants. Minimal and adaptive process focussed on emergent content and structure. Synchronous collaboration. Contents of the manifesto were written through synchronous collaboration. Iterative evolution. A common vision was formulated to guide the incremental evolution of the manifesto.
Table 1 covers all the Karlskrona Manifesto principles and description for each principles.
Principles temic
The Karlskrona Manifesto as a guide has helped in increasing sustainability awareness amongst those interested in software systems design and development. However, the core challenge is how to exemplify these principles through practical application in software development. Requirements engineering as a starting point in any software development has a crucial role to play in exemplifying the use of the manifesto principles in software systems requirements elicitation and engineering. There have already been research strides on sustainability in requirements engineering stating the need for sustainability requirements in software systems such as the following research in chronological order:
Mahaux et al. [23] present an experience report about projects that treated sustainability as a first class quality requirements. The authors assessed the current techniques used in systematically eliciting, analyzing and documenting sustainability requirements and pointed at the need for a sustainability toolbox to support requirements engineers to better elicit sustainability requirements.
Roher et al. [21] are concerned with the lack of software engineering teams including environmental sustainability during software development proposed the use of sustainability requirements patterns (SRPs).
Penzenstadler et al. [9] support the consideration of sustainability as a nonfunctional requirement like safety and security that are considered as a system quality attribute.
Raturi et al. [22] focused on how to develop sustainability as a non-functional requirement (NFR) using NFR framework informed by sustainability models.
Becker et al. [24] explain the crucial role of requirements not only for software systems but also for how requirements for sustainability can impact the social-economic and natural environment.
Hinai et al. [25] proposed the use of requirements engineering methodology using social values to elicit social sustainability requirements for software systems.
As highlighted by Becker et al. [16], there are different concerns and dimensions of sustainability, software engineers focusing on the concerns of software qualities, business stakeholders looking at how to make profit and keep business afloat. Furthermore, there is the aspect of social wellbeing of people to ensure better living standards. This, at times, makes the global concern of sustainability difficult to elicit and engineer. Also, quoting Becker et al. [16] offering a way forward: “Rather than asking whether it is appropriate to balance these concerns, we should instead be asking What methods and tools are needed to explore inter-dependencies between these concerns, and to foster more integrated and long-term thinking?”
Oyedeji et al. [7] support this further, stating that without a standard for software sustainability requirements, it becomes difficult to identify the boundaries of the sustainability of software systems. A standard will lead to a unifying consensus that can foster sustainability quantification in software systems. Software sustainability has also gained attention as a quality attribute in which there is a proposal to extend the ISO/IEC quality model 25010 to address sustainability [26].
Therefore it is important to follow up on the Karlskrona Manifesto principles and propose examples of how these principles can be applied in software systems requirements elicitation and engineering. This could lay the foundation for a standard template that can encourage and educate requirements engineers for software sustainability requirements.
A “best practice” (BP) is a practice that is not only good but has proven to work well and produce good results and therefore is recommended as a model. According to Schatten et al.[27], a BP is the transfer of knowledge based on years of success, mistakes and failures from experienced developers to novice developers. These BP can be some good and bad decisions (antipatterns) from concrete projects that are presented as abstracted scenarios. Designing and developing well-structured software is a challenge especially for young and novice developers. With the use of BP, such challenges can be eased for them with knowledge of how best to develop well-designed software systems from proven procedures.
Fricker at al. [28] presented the best requirements techniques that became industrial best practice based on a survey of a large number of industry projects. One of their core findings showed that projects incorporated stakeholder workshops, the study of existing systems, and re-using specifications. Workshops dominated requirements elicitation practice. Only few projects used techniques like observation, ethnography, surveys, or data mining.
Mike Perks [29] from IBM describes best practices for software development projects from development processes, requirements, architecture, design, construction of code, peer reviews, testing, quality and defects management, deployment, system operations and support, project management, and measuring software project success.
In requirements documentation, one best practice is to use a single and consistent template that all development team members should adhere to in requirements gathering and software development [30].
Parker et al. [31] identified the best practices for managing requirements as the following: Naming conventions. Defining and maintaining conventions for identifying releases from the approved requirement set through to the baselined release to the emergency fix or patch. Baseline requirements. Requirements, like software releases, must be baselined and those baselines must map directly to the releases they produce. Well-defined and understood change control process. Once a baseline is created, changes must be controlled, tracked, traced, approved, and reviewed. Requirements review. There must be a requirements review process, and it must be enforced Expectation of changes. Make sure changes can be made easily, but under strict access control rules (that include having full traceability). Version management. Requirement history should be maintained using methods that make it easy for analysts to look back. Requirements traceability. Without the ability to trace a requirement from the idea through to its defined implementation, there is no ability to understand the impact of a proposed change. Information maintenance. Maintain attributes for dependencies, relationships, owners, stakeholders, users, funder, dates, costs, models, prototypes, diagrams, and governance about the requirement. Collaboration. Provide easy access to requirements information and automatically notify stakeholders of any change of status or change of the requirement to foster collaboration. Requirements in a single location. Keep requirements in a single location, preferably in a database designed to manage them.
For companies and organizations, BP are a key way for sharing knowledge and improving the quality of their operation processes [32]. Alwazae et al. [32] introduced the use of a best practice document template (BPDT) as a way for creating high quality documentation within organizations.
Learning from outside the software and requirements engineering domain, the United Nations food and agriculture organization (FAO) presented some good criteria for good practice which also considers sustainability [33].
This body of existing work around best practice documentation and templates was used as a foundation to develop the template presented in the paper at hand.
The first author performed a mapping of the Karlskrona Manifesto principles onto the Software Development Life Cycle (SDLC) phases and the second author reviewed the mapping.
Based on existing literature on best practice templates [28] [31] [32] [33], the first author developed a first version of the best practice template to document how those Karlskrona manifesto principles can be used in software development activities. This template and some example instances were presented and assessed in an expert evaluation with 15 software developers with at least 3 years of experience in industrial software development at a workshop in the Lappeenranta University of Technology. The workshop is a mentoring program to educate young developers interested in software development career.
The feedback from the developers (more straight-forward, more concrete examples) was incorporated and then presented to the experts again for re-evaluation. Table 2 provide background details of the expert evaluators.
Software Tester Requirement Engineer Programmer UI Designer Business Analyst Programmer IT Manager CEO / Software Developer ICT Engineer Programmer Product Tester / Integration Engineer Project Manager / UX expert Not Provided
Software Development Software Development Software Development Startup Software Development Telecom Finance HR Software ment Not Provided
Develop3 4 3 IV. KARLSKRONA MANIFESTO FOR SUSTAINABILITY DESIGN
AND SOFTWARE DEVELOPMENT
This section provides an overview of how the Karlskrona Manifesto principles can be mapped onto software development life cycle phases.
Table 3 shows the exemplary mapping. There may be additional matches where further principles can be applied within a specific SDLC phase but this mapping is sufficiently extensive for exploring the concepts. quirements are the first part of any system’s design, development and improvement.
V. METHOD FOR DOCUMENTING SOFTWARE SUSTAINABILITY
REQUIREMENTS BEST PRACTICE
This section covers details of the method for collecting and disseminating best practice for software sustainability requirements elicitation and engineering. Figure 1 shows the process flow of this method. conduct analysis of system design with consideration of sustainability in order to facilitate development of sustainable system.
P6- Application of this principle enables better visual and visible overview of the system from different levels of abstraction.
P8- This will provide better understanding during analysis to make better choices that will help the potential users of the system in present and in future when the system evolves.
P2- This will encourage developers during this phase to consider different sustainability dimensions especially technical, social and individual dimensions P4- Encourages the search for better avenues to make the system sustainable from the development perspective (developers) and also the functions of the system to aid longevity.
P2- Provides integration and test team to have a sustainability template that can be used to test the system for all sustainability dimensions based on the sustainability requirement output from phase 2, 3, and 4.
P4- Application of this principle will aid consideration of sustainability in this phase even if the primary focus of system is not about sustainability.
P5- Provides a beforehand reasoning for the development team to consider sustainability of the system, its production environment and when push live for use.
P7- The use of this principle will aid consideration of seeking the involvement of different stakeholders to make the actualization of the system sustainability possible in the production environment and when pushed live.
P9- At this stage, this principle helps to create / the conscious awareness so that when the system is in live environment, there will be continuous evaluation to assess the system sustainability and think of ways for optimizing and improving sustainability of the system from the different dimensions.
There has been progress on how to design the maintainability of software during/after development and how the security and usability can be improved over time. One thing lacking is how to consider the external impact of the software on the different dimensions of sustainability and engineering those considerations into the software. This is why it is important to conduct proper software sustainability requirements elicitation. The sustainability requirements process needed during SDLC is still evolving in terms of finding the most effective way to elicit software sustainability requirements.
After mapping the Karlskrona Manifesto principles to all the SDLC phases, the next section exemplifies the use of the Karlskrona principles during user and system requirements gathering in the first three phases of the SDLC. This will serve as a benchmark for the remaining SDLC phases because re
The proposed method is the first attempt towards exemplifying how the Karlskrona Manifesto principles can serve as a guide for eliciting sustainability requirements for software systems and how such process can be documented as good practice. Such documented good practice can then be reused or followed by software developers and different stakeholders interested in software sustainability.
The first step is to select from the nine Karlskrona principles a principle that relates to the system to be developed or improved. Table 3 shows our mapping of the Karlskrona manifesto to each software development phase.
The second step is to use the selected principle in generating sustainability goals for the system. These goals will serve as a base for creating the system requirements.
The third step involves deriving software sustainability requirements based on all the sustainability goals. These requirements must be measurable and tangible.
The fourth step involves tagging each of the derived sustainability requirements with each sustainability dimension (economic, environment, social, individual and technical).
The fifth step involves using the template that will be proposed in this paper to document the requirements using the good requirement practice template.
The sixth step validates the saved requirement practice using the following criteria [33]: Effective and successful: A “good practice” has proven its strategic relevance as the most effective way in achieving a specific objective; it has been successfully adopted and has had a positive impact on individuals and/or communities. Environmentally, economically and socially sustainable: A “good practice” meets current needs, in particular the essential needs of the world’s poorest, without compromising the ability to address future needs. Technically feasible: Technical feasibility is the basis of a “good practice”. It is easy to learn and to implement. Inherently participatory: Participatory approaches are essential as they support a joint sense of ownership of decisions and actions. Replicable and adaptable: A “good practice” should have the potential for replication and should therefore be adaptable to similar objectives in varying situations. Reducing disaster/crisis risks, if applicable: A “good practice” contributes to disaster/crisis risks reduction for resilience.
Based on these criteria, the collected requirements are validated, and if all necessary good practice criteria are satisfied the requirements are published as good requirements practice. If there is need for improvement, the requirements are refined again and cross-validated before being published as good requirements practice. Table 4 provides the best practice template. Table 5 presents an example of the instantiated template for the sustainability best practice - how the Karlskrona Manifesto principles influenced the requirements elicitation process between the requirements engineer, the end user, the programmer, and the business analyst.
The field ‘requirements’ uses sample requirements from the illustrative case study of a web application for online hospitality service to rent homes for short stays. What were the requirements used in the best practice? How was sustainability considered in the requirement? How was the best practice validated? Did the best practice fulfil the best practice criteria? What there an impact in the application of the best practice? What are the key take away from the application the best practice? What are the dimensions of sustainability covered in the best practice application? What is contact details of those responsible for the best practice?
VI. DISCUSSION
The systematic mapping of the Karlskrona Manifesto aids requirements engineers and software developers in understanding how the Karlskrona Manifesto for software sustainability design relates to the software development life cycle (see Table 3). The template (see Tables 4 and 5) provides a typical example of how best practices for software sustainability requirements can be documented. Table 4 provides details of what is expected in the template and Table 5 shows the template usage for documenting both functional and non-functional requirements. This best practice uses the example of an online hospitality web application.
In addition, with the work presented in this paper, we partially respond to research challenges identified by Chitchyan et al. [2] from the state of practice for software sustainability design in requirement engineering. They noted the following:
There is a lack of methodological support for sustainability design in requirement engineering because it is not part of most companies practice [2]. The method presented in this paper serves as support for helping requirements engineers, software developers and all stakeholders in documenting best practices from sustainability design in requirements engineering using a structured methodology.
They also noted a need for a mentality change to make people transition from their old ways of eliciting requirements and developing software to new way of sustainability design in requirements engineering. Documenting best practices using the proposed template presented here educates and promotes awareness among those involved in the requirements engineering process of software development. This can be one way of persuading them to see benefits of eliciting software requirements and developing software system in a new way with support for sustainability design.
Overall, the mapping of the Karlskrona Manifesto principles in Table 3, the method (see Figure 1), and the template for documenting (see Table 4) provide guidance to support requirements engineers and software developers in software sustainability requirements elicitation and in documenting best practices from the requirements process.
In our opinion, instantiating the Karlskrona Manifesto for sustainability design for software processes, practices and methods will go a long way to create awareness about software sustainability and increase broader engagement for different stakeholders within academia and industry.
The following are some of the limitations of our work: The mapping of the Karlskrona Manifesto principles to software development process phases in this current version may be incomplete as of now and require a further iteration of the mapping process (meaning: there could be principles that are not listed for a specific phase despite being applicable), but the mapping is sufficiently complete to provide solid grounds for discussion. The template may be too restrictive and not capture all relevant information potentially provided by those documenting the best practice. However, if templates get too lengthy, which can easily occur when trying to accommodate all possibilities, they are less likely to be picked up by practitioners (see next point).
If structure and guidance become too detailed, engineers may refuse to use them, find them too specific to apply, or apply the principles without putting sufficient critical thought into it. Consequently, that is why the template for documenting best practices has been simplified for straightforward and self-explanatory documentation.
This paper presents a mapping of the application of the Karlskrona Manifesto principles to software development activities and a template for documenting their usage in best practices, supported by an example instance of its usage. An expert group evaluated this template in two iterations.
The proposed approach can be used as guide by requirements engineers during software requirements elicitation and documenting software sustainability requirements best practices. Furthermore, software developers can also benefit from using it for rethinking how they develop software using the mapped Karlskrona Manifesto principles as guide during each stage of the software development life cycle.
Future work includes the application of the proposed methodology in industrial case studies and using the template to document best practices from those case studies. Specifically, during the evaluation, the expert group requested a mapping of the Karlskrona Manifesto to agile software development method, especially to Scrum. Consequently, we plan this mapping and adaptation for the first industry case study. [1] [2] [3] [4] [5] [6] [7]