Recent studies have highlighted transparency and explainability as important quality requirements of AI systems. However, there are still relatively few case studies that describe the current state of defining these quality requirements in practice. This study consisted of two phases. The first goal of our study was to explore what ethical guidelines organizations have defined for the development of transparent and explainable AI systems and then we investigated how explainability requirements can be defined in practice. In the first phase, we analyzed the ethical guidelines in 16 organizations representing different industries and public sector. Then, we conducted an empirical study to evaluate the results of the first phase with practitioners. The analysis of the ethical guidelines revealed that the importance of transparency is highlighted by almost all of the organizations and explainability is considered as an integral part of transparency. To support the definition of explainability requirements, we propose a model of explainability components for identifying explainability needs and a template for representing explainability requirements. The paper also describes the lessons we learned from applying the model and the template in practice. For researchers, this paper provides insights into what organizations consider important in the transparency and, in particular, explainability of AI systems. For practitioners, this study suggests a systematic and structured way to define explainability requirements of AI systems. Furthermore, the results emphasize a set of good practices that help to define the explainability of AI systems.

The rise of agile software development methods has led to the abandonment of many traditional practices especially in requirements engineering (RE). Agile RE is still a relatively new research area and the growing use of agile methods in large projects is forcing companies to look for more formal practices for RE. This paper describes experiences gained from a case study of a large agile project. The goal of this case study was to explore how prototyping can solve the challenges of agile RE. Our findings indicate that while prototyping can help with some challenges of agile RE such as lack of documentation, motivation for RE work and poor quality communication, it also needs complementary practices to reach its full potential. These practices include reviewing the big picture regularly, keeping track of quality requirements, and using ATDD (Acceptance Test Driven Development).

Evaluating the multidimensional and dynamic nature of IT business value is a continuous challenge. This paper examines how system dynamics can be used in evaluating IT business value in a company level. We approach IT business value as a web of impacts, where benefits and sacrifices are ultimately evaluated against company earnings logic. This study is based on an action research and covers a pilot project within two co-operating companies. System dynamics was utilised to construct a value creation model for an existing Gaming Management System. This value creation modelling covered two dimensions: 1) structural evaluation of IT impacts with cause-and-effect models, 2) dynamic evaluation and simulation of value realisation over time. As a result, value creation modelling was able to provide a visual overview of how IT impacts were linked to business value through value paths, and how much and when value was realised. Value creation modelling enabled prototyping of value realisation that can provide value based insights for development activities like requirements elicitation and analysis. The examined approach proved its potential for providing a common language for technology and business parties, thus improving IT business alignment.

Roadmapping has been recognized as a critical activity for combining a business strategy with release planning. Furthermore, the marketing literature has placed increasing emphasis on the importance of understanding customers' processes and customer value. This paper presents an action research study on the roadmapping problems of two software product companies. The key findings were that customer knowledge was fragmented across different functions of the companies and that roadmapping neglected service development. To solve these problems, analysis of customer value and customers' processes was integrated into roadmapping. Facilitated workshops with cross-functional teams were used to analyze the customers' processes in their entirety and to create a holistic view to roadmapping. The lessons learned offer practical means with which software companies can shift their focus from the prioritization of software features to the analysis of customers' processes and the prioritization of customers' activities. The shift promotes value creation from the customers' perspective and the discovery of new service business opportunities.

Peer reviews have been identified as one of the best practices in requirements engineering. The most formal peer review technique - inspection - has been found to be effective for the discovery of defects in documents. Nonetheless, many software companies practice inspections infrequently or not at all. For instance, some engineers consider inspections to be uncreative work that adds costs. This paper describes the success factors and challenges involved in persuading review teams to document inspections. The case study utilized an action research approach over a 10-year period, during which two separate attempts were made to address inspection practices. Document inspections did not gain a sustainable position in the study. Consequently, key success factors and challenges were identified in order to explain how the review teams changed their perception throughout the adoption of document inspection. Long-term engagement to document inspection requires motivation and commitment on the part of the teams, and the favorable development culture of an organization, dedicated champions, and the careful tailoring of inspection practices seem to positively influence this. In the long run, it can be challenging to keep document inspections consistent with the existing values, previous experiences, and needs of the software development teams.

Requirements engineering and testing offer two complementary views of system development, and can, therefore, benefit from each other. This paper describes the lessons Metso learned from jointly improving requirements and testing processes. The goal of the process improvement was to increase the quality of R&D work. The new requirements and testing processes were piloted in an R&D project. The usage of the new processes removed the risk of doing double work, improved the visibility of the project status and the effectiveness of the project. The experiences of the pilot project suggest that the good results were mainly due to linking requirements and testing concurrently at process, people, and practice levels. It was essential that the new requirements and testing processes were integrated throughout the entire R&D project. In order to integrate the requirements and testing activities, critical roles and responsibilities were defined. Furthermore, we identified a set of good practices that helped perform the new processes.

Usability and requirements engineering both provide means for discovering, analyzing, and fulfilling users' needs. In practice, it is difficult to manage and control user-centered design and system development processes separately. Based on a case study conducted in two software product companies, we have aimed to understand the role of usability specialists in the requirements engineering (RE) process. Our findings indicate that usability is still often seen as user interface design instead of a more comprehensive characteristic of a software product. Therefore, usability specialists had difficulties participating in early RE activities. To integrate usability as a natural part of the RE process, the usability teams have started to organize training in their companies. The main purpose of the training is to ensure that usability is not relying solely on the work of specialists but becomes a common responsibility for the whole product development organization.

Marketing experts emphasize that the creation of superior customer value is a key element for companies' success. Understanding how to create value for customers, however, is not trivial in practice. The purpose of this paper is to analyze the role of requirements engineering (RE) in customer value creation. The paper describes experiences gained from six Finnish companies that develop software-intensive products and services for global markets. In practice, the focus of RE activities is mainly on product features. Customer value creation is, however, more than developing a competitive set of product features. It is important for companies to understand customers' processes and develop solutions that support these processes. To enable practitioners to change the focus from feature development to customer value creation, we propose a set of RE practices.

An increasing number of organizations are interested in binding requirements and testing more closely together. Based on a series of practitioner interviews conducted in five Finnish organizations, this paper presents a set of good practices that can be applied to create a stronger link between requirements engineering and testing. These practices include early tester participation particularly in requirements reviews, setting up traceability policies, taking feature requests from testers into account, and linking testing personnel with requirement owners. Due to reported hardships in implementing complete test traceability to requirements, communication links between testers and requirement owners are suggested in order to overcome the deficiencies of document links.

Product lines should be based on the business reality in the selected market segments. Since the success of the product line is determined by the success of the resulting products, it is essential to guarantee that the key requirements of each identified market segment are satisfied. A critical issue for any company pursuing product line development is the competitiveness of their products against products from other manufacturers. The competitiveness can be realized by carefully managing the differentiating requirements during the initial analysis of the product line requirements. For industrial scale product lines, the number of initial requirements can be large, seriously hindering the analysis. In this paper, we first discuss the economic foundation of differentiating requirements. Then we show how to identify the key requirements for a product line and in which way we can reduce the set of requirements that needs to be discussed during the analysis. Finally, we demonstrate our approach with a worked example where we analyze the key requirements in terms of differentiation among the products.

Under today's fiercely competitive conditions, companies are seeking new means to develop innovative products that satisfy customer and user needs. In order to understand how requirements engineering (RE) can support innovations, we observed RE activities in six Finnish companies. Our observations indicate that RE can play a vital role in the development of innovative products. We identified three main opportunities for innovations: 1) discovering hidden customer and user needs, 2) inventing new product features that satisfy these needs, and 3) supporting feature development with an innovative technical solution. Based on our observations, as well as on existing innovation and business-management literature, we have concluded that RE research can gain significant results by investigating how to discover and model hidden customer and user needs. We believe that this would allow RE to much better support those innovation practices that provide real competitive advantage.

Long-term product planning (i.e. roadmapping) is an approach that companies operating in the software product business have used to bridge the gap between business planning and product development. A strong link between strategy and product development is important, since companies developing software products need to select requirements for forthcoming releases based on the business decisions of the company. However, in practice, connecting requirements engineering decisions and business management is far from trivial. This paper reports lessons learned from four software product companies that recognize the need for more business-oriented long- term product planning. The study was conducted using the action research approach. We identified four practices that seem to strengthen the link between business decisions and requirements engineering. These are: 1) explicating the planning levels and time horizons needed in product planning, 2) separating the planning of business goals relating to products from R&D resource allocation, 3) conducting open-ended planning by pre-defined rhythm and 4) emphasizing whole-product thinking.

User involvement is the key concept in the development of useful and usable systems and has positive effects on system success and user satisfaction. This paper reports the results of interviews and a survey conducted to investigate the role of user involvement in defining user requirements in development projects. The survey involved 18 software practitioners working in software related development projects in 13 companies in Finland. In addition, eight software practitioners working in three companies were interviewed. By combining qualitative and statistical analysis, we examine how users are involved in development projects and how user involvement influences projects. The analysis shows that, although it is rare in development projects, early user involvement is related to better requirements quality. The analysis also shows that involving users and customers as the source of information is related to project success.

Companies moving into the software product business and growing in size face new challenges that cannot be tackled completely with old practices. For example, the future development steps of the off-the-shelf products cannot be negotiated with just one or a few customers any more. This means that practitioners should be able to take aspects such as their company's own strategy and available market information more effectively into account in such decision-making. However, usually the company or business unit strategy is so high level that the gap to single requirements documents is far too long. Roadmapping is one technique that companies have used for long-term product planning in order to link the business view to requirements engineering (RE), and to make more business oriented product development decisions. In addition, roadmapping has been used to share a common understanding about the future development steps of products with different stakeholders. However, the application of the technique is not always easy. This paper gives an overview of roadmapping as a technique, and describes lessons learned from one Finnish software product company that has developed and evaluated its own roadmapping processes in their organization.

Introducing requirements engineering appears to involve a cultural change in organizations. Such a cultural change requires that requirements are defined and managed systematically, not only from a technical point of view, but also from the customers' and users' points of view. This paper describes experiences gained from four Finnish organizations that have started to introduce requirements engineering to their product development. The goal of this study was to evaluate which factors support, and which prevent, a cultural change. Linking business goals to technical requirements via user needs and user requirements was one of the key improvement actions that supported cultural change. Eliciting needs directly front real users and representing user requirements in the form of use cases were also key activities. However, bringing about a change of culture was challenging because both managers and product development engineers held beliefs that prevented active user need elicitation and systematic user requirement documentation.