No abstract

No abstract

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

No abstract

In a company producing off-the-shelf software for mass markets, the future development steps of the products cannot be negotiated with one or few customers. The decisions concerning the priorities of the requirements must be made within the company, the developer bearing all the financial risks included. This means that finding the right priorities for the requirements is important. However, requirements prioritization is recognized as a difficult activity in software 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 in industrial product development projects. In the first case, the users of the system evaluated the pair-wise comparison technique for prioritizing user needs. In the second case, practitioners evaluated Wiegers' method for change requests. In addition, we interviewed 11 practitioners from 6 companies about their current requirements prioritization practices and the models that they use as a basis of their prioritization decisions. Our findings indicate that prioritization methods may have limited ability to support decision-making in a complex area like requirements prioritization in market-driven product development. In addition, there are practical difficulties in the usage of methods, and therefore, prioritization results should be taken more as being indicative than as an ultimate truth.

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

No abstract

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