Marie-Therese Christiansson

Naming the pain in requirements engineering

Requirements Engineering (RE) has received much attention in research and practice due to its importance to software project success. Its interdisciplinary nature, the dependency to the customer, and its inherent uncertainty still render the discipline difficult to investigate. This results in a lack of empirical data. These are necessary, however, to demonstrate which practically relevant RE problems exist and to what extent they matter. Motivated by this situation, we initiated the Naming the Pain in Requirements Engineering (NaPiRE) initiative which constitutes a globally distributed, bi-yearly replicated family of surveys on the status quo and problems in practical RE. In this article, we report on the qualitative analysis of data obtained from 228 companies working in 10 countries in various domains and we reveal which contemporary problems practitioners encounter. To this end, we analyse 21 problems derived from the literature with respect to their relevance and criticality in dependency to their context, and we complement this picture with a cause-effect analysis showing the causes and effects surrounding the most critical problems. Our results give us a better understanding of which problems exist and how they manifest themselves in practical environments. Thus, we provide a first step to ground contributions to RE on empirical observations which, until now, were dominated by conventional wisdom only.

Inter-organizational Public e-Service Development: Emerging Lessons from an Inside-Out Perspective

E-service development has grown to become a daily practice in most public organizations as a means for realizing digital agendas and e-government initiatives on different levels local, regional, national and transnational governmental levels. Public e-service development is often an inter-organizational IO effort with multiple actors and organizations involved in the multi-faceted dimensions of design, development and delivery decisions. Still, there is a lack of research focusing on IO public e-service development practices in particular. In order to address this lack we elaborate on reported challenges and their implications for IO public e-service development in practice. By returning to two empirical cases of IO public e-service development, the IO dimension is evolved. Our purpose is to highlight challenges in IO public e-service development with implications for research and practice. Findings are presented as eight emerging lessons learned from an inside-out perspective related to phases in IO public e-service development processes.

Testing Communicability in Public e-Services : Process and Outcomes

In this paper, a case of testing public e-Service communicability is analysed in terms of process as well as outcomes. Key elements in test processes are defined, together with the meaning of communicability identified in terms of information-oriented metrics. The purpose of our paper is to develop knowledge about how e-Service providers should improve their ability to communicate and support users in finding, understanding and using e-Services. The reconstructed test process design is based of an analysis of gaze replays in citizen test sessions by means of eyetracking technology. Empirical findings on communicability metrics are further grounded in theory. Our main contribution to the research community and the field of practice, are a test process and a communicability framework to support the assessing of e-Service information. The use of wireframes for the e-Service five layers, together with a multifunctional template for data collection, analysis and presentation are introduced.

Elements for Tailoring a BPM Maturity Model to Simplify its Use

Although research exists on Business Process Management (BPM) maturity models, few studies report on their practical use. This paper explores the situational needs and practitioner’s views on assessing BPM maturity. Data triangulation uncovered different applications in Swedish industry and public sector organizations through three phases: (1) data collection in a practitioner-driven BPM maturity model design, (2) validation of the design in a workshop and follow-up interviews, and (3) testing the BPM maturity model by practitioners. The basic assumption is that a generic BPM maturity model will most likely not fit all organizations. Therefore, a framework is presented with elements (e.g. scope and measures) for a BPM maturity model to be customized to an organization’s needs, supplemented by a practical ‘tailoring template’. The framework and template contribute to the BPM discipline with a Swedish example, and allows twelve design propositions with recommendations to simplify the application of BPM maturity models and enhance their fit.