Laura Lehtola

Requirements Prioritization Challenges in Practice

Requirements prioritization is recognized as an important activity in product development. In this paper, we describe the current state of requirements prioritization practices in two case companies and present the practical challenges involved. Our study showed that requirements prioritization is an ambiguous concept and current practices in the companies are informal. Requirements prioritization requires complex context-specific decision-making and must be performed iteratively in many phases during development work. Practitioners are seeking more systematic ways to prioritize requirements but they find it difficult to pay attention to all the relevant factors that have an effect on priorities and explicitly to draw different stakeholder views together. In addition, practitioners need more information about real customer preferences.

Using the focus group method in software engineering: obtaining practitioner and user experiences

This paper reflects on three cases where the focus group method was used to obtain feedback and experiences from software engineering practitioners and application users. The focus group method and its background are presented, the methods weaknesses and strengths are discussed, and guidelines are provided for how to use the method in the software engineering context. Furthermore, the results of the three studies conducted are highlighted and the paper concludes in a discussion on the applicability of the method for this type of research. In summary, the focus group method is a cost-effective and quick empirical research approach for obtaining qualitative insights and feedback from practitioners. It can be used in several phases and types of research. However, a major limitation of the method is that it is useful only in studying concepts that can be understood by participants in a limited time. We also recommend that in the software engineering context, the method should be used with sufficient empirical rigor.

The role of user involvement in requirements quality and project success

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.

Empirical Evaluation of Two Requirements Prioritization Methods in Product Development Projects

Requirements prioritization is recognized as an important but difficult activity in product development. The literature offers methods for requirements prioritization, but many authors report that practices in companies are mostly informal. In this study, we evaluated two requirements prioritization methods from the requirements engineering literature in industrial product development projects. In the first case, the users of the system evaluated the pair-wise comparison technique [5] for prioritizing user needs. In the second case, practitioners evaluated Wiegers’ method [18] for change requests. The findings from the cases provide information about the suitability of the prioritization methods for product development work. In addition, our findings indicate why it might be challenging for practitioners to employ a requirements prioritization method.

Linking the business view to requirements engineering: long-term product planning by roadmapping

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 companys 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.

Linking business and requirements engineering: is solution planning a missing activity in software product companies?

A strong link between strategy and product development is important, since companies need to select requirements for forthcoming releases. However, in practice, connecting requirements engineering (RE) and business planning is far from trivial. This paper describes the lessons learned from four software product companies that have recognized the need for more business-oriented long-term planning. The study was conducted using the action research approach. We identified five practices that seem to strengthen the link between business decisions and RE. These are (1) explicating the planning levels and time horizons; (2) separating the planning of products’ business goals from R&D resource allocation; (3) planning open-endedly with a pre-defined rhythm; (4) emphasizing whole-product thinking; and (5) making solution planning visible. To support whole-product thinking and solution planning, we suggest that companies create solution concepts. The purpose of the solution concept is to provide a big picture of the solution and guide RE activities.

The challenge of release planning

Size and complexity of todays software products are continuously growing. This has made it increasingly difficult to decide which features shall be implemented in a products next version. Consequently, release planning, the process of planning for the next release of an evolving product has been recognized as a wicked problem. Existing studies on wicked problems suggest that it would be too simple to deal with them with intelligence gathering, linear thinking and rational decision making. Yet, it appears that this is precisely how many companies are currently trying to plan their forthcoming product releases. Although the characteristics of release planning challenges are visible and documented in the literature, is this challenge really seen? This paper reviews existing release planning practices introduced in the literature in order to understand the underlying assumptions they have been built on. The identified assumptions are then compared with reported release planning characteristics. As a result, the paper identifies the gap between the problem characteristics and the current solutions, and outlines conditions for more adequate release planning approaches to deal with release planning as complex wicked problems.

From Feature Development to Customer Value Creation

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.

Investigating the State of User Involvement in Practice

Involving users in software development has been reported to increase the probability of product and project success, as well as user satisfaction. User involvement can occur in the tasks of several different organizational functions, including a dedicated user-centered team. This article presents the results of a case study conducted to understand the current state of user involvement practice in a company producing software solutions for consumers, enterprises, and service providers. The company has recently established a centralized user experience team to provide user-centered practices for the entire development organization. Feedback was found as the most common type of user information, while concrete user participation in the development process was lacking. However, it was perceived that an organized way of involving users in the development process is needed. We hope the detailed findings and insights of this case study will act as the basis for user involvement research in the future.

Roadmapping problems in practice: value creation from the perspective of the customers

Roadmapping has been recognized as a critical activity for adding business value to a software product. The marketing literature has placed increasing emphasis on customer value and that value is created in customers’ everyday activities. 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, the 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 for software companies to shift their focus from the prioritization of software features to the analysis of customers’ processes and the prioritization of customers’ activities. That shift can promote value for customers and uncover new service business opportunities. Accordingly, this paper provides a six-step approach to adopt the value-creation logic from the customers’ perspective into the existing roadmapping process of a company.