Andrea Herrmann

Requirements Prioritization Based on Benefit and Cost Prediction: An Agenda for Future Research

In early phases of the software cycle, requirements prioritization necessarily relies on the specified requirements and on predictions of benefit and cost of individual requirements. This paper presents results of a systematic review of literature, which investigates how existing methods approach the problem of requirements prioritization based on benefit and cost. From this review, it derives a set of under-researched issues which warrant future efforts and sketches an agenda for future research in this area.

MOQARE: misuse-oriented quality requirements engineering

This work presents MOQARE (misuse-oriented quality requirements engineering), a method to explore quality requirements. The aim of MOQARE is to support intuitive and systematic identification of quality requirements. It was developed by integrating and adapting concepts from other methods (like Misuse Cases). It provides a general conceptual model of quality requirements, and a checklist-based process for deriving them in a top-down fashion. This derivation starts from business goals and vague quality requirements and delivers detailed requirements. MOQARE applies to requirements on the system to be developed requirements, but also derives requirements on the development process, including administration and maintenance. It considers normal and extreme use. The relationships among these requirements are modeled in a Misuse Tree. MOQARE has shown its merits in several case studies, one of which is presented here.

Do We Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study

Requirements prioritization is an essential mechanism of agile software development approaches. It maximizes the value delivered to the clients and accommodates changing requirements. This paper presents results of an exploratory cross-case study on agile prioritization and business value delivery processes in eight software organizations. We found that some explicit and fundamental assumptions of agile requirement prioritization approaches, as described in the agile literature on best practices, do not hold in all agile project contexts in our study. These are (i) the driving role of the client in the value creation process, (ii) the prevailing position of business value as a main prioritization criterion, (iii) the role of the prioritization process for project goal achievement. This implies that these assumptions have to be reframed and that the approaches to requirements prioritization for value creation need to be extended.

A conceptual model and process for client-driven agile requirements prioritization

Continuous customer-centric requirements reprioritization is essential in successfully performing agile software development. Yet, in the agile RE literature, very little is known about how agile reprioritization happens in practice. Generic conceptual models about this process are missing, which in turn, makes it difficult for both practitioners and researchers to reason about requirements decision-making at inter-iteration time. This paper presents a Grounded Theory study on agile requirements prioritization methods to yield a conceptual model for understanding the inter-iteration prioritization process in terms of inputs and outcomes. The latter is derived by using qualitative empirical data, published earlier by other authors. Such a conceptual model makes explicit the concepts that are used tacitly in different agile requirements prioritization methods and can be used for structuring future empirical investigations about this topic.

A conceptual model of client-driven agile requirements prioritization: results of a case study

Requirements (re)prioritization is an essential mechanism of agile development approaches to maximize the value for the clients and to accommodate changing requirements. Yet, in the agile Requirements Engineering (RE) literature, very little is known about how agile (re)prioritization happens in practice. Conceptual models about this process are missing, which, in turn, makes it difficult for both practitioners and researchers to reason about requirements decision-making at inter-iteration time. We did a multiple case study on agile requirements prioritization methods to yield a conceptual model for understanding the inter-iteration prioritization process. The model is derived by using interview data from practitioners in 8 development organizations. Such a model makes explicit the concepts that are used tacitly in the agile requirements prioritization practice and can be used for structuring future empirical investigations about this topic, and for analyzing, supporting, and improving the process in real-life projects.

Practical challenges of requirements prioritization based on risk estimation

Requirements prioritization and risk estimation are known to be difficult. However, so far, risk-based requirements prioritization has not been investigated empirically and quantitatively. In two quantitative experiments, we explored practical challenges and needs of risk estimations in general and of our method MOQARE specifically. In the first experiment, ten students made individual estimations. In the second one, twenty-four students estimated risks in seven moderated groups. The students prioritized the same requirements with different methods (risk estimation and ranking). During the first experiment, we identified factors which influence the quality of the prioritization. In the second experiment, the results of the risk estimation could be improved by discussing risk estimations in a group of experts, gathering risk statistics, and defining requirements, risks and prioritization criteria more tangibly. This first quantitative study on risk-based requirements prioritization helps to understand the practical challenges of this task and thus can serve as a basis for further research on this topic.

Using Storytelling to record requirements: Elements for an effective requirements elicitation approach

Existing requirements elicitation approaches have proven insufficient to record complete, consistent, and correct requirements. Studies conducted have shown that 40% of defects in software projects are due to incorrect recorded requirements. Therefore, some innovative approaches have been developed to deal with the lack of addressing the above-mentioned issues including video-based methods. Recent approaches using Storytelling to elicit requirements started to emerge in the field of requirement engineering. However, few experiences have been conducted to investigate which elements of the Storytelling technique are needed to conduct elicitation activities, and how effective Storytelling is in supporting, improving, and complementing existing techniques for the requirements elicitation phase. In this paper, we report on an experiment involving twenty-five domain experts from various industrial companies to collect requirements using a Storytelling technique for a particular ticket machine case. In particular, we investigate the effectiveness of using a Storytelling technique compared to a traditional brainstorming technique. We then sketch out the experimental design of the case study; outline various observations, results, and finally we lay out important findings about telling stories in the context of collecting requirements.

Introducing the Common Non-Functional Ontology

Enterprise systems interoperability is impeded by the lack of a cohesive, integrated perspective on non-functional aspects (NFA). We propose to respond to the fragmentation in NFA research by supporting a shared, common understanding. For this purpose:- first, we propose a common NFA ontology, which generalizes and integrates the different non-functional aspects under a common top-level ontology. Second, we introduce a series of specialized ontologies on specific non-functional aspects, such as trust, risk, privacy, threat and misuse. By fostering a consensual and shared view of the non-functional aspects domain, we aim to move closer to enhancing semantic enterprise interoperability. This shared perspective on what non-functional aspects are and how they relate to the other ‘functional’ aspects of enterprise systems, is the key towards enterprise interoperability.

Practical relevance of experiments in comprehensibility of requirements specifications

Recently, the Requirements Engineering (RE) community has become increasingly aware of the importance of carrying out industry-relevant research. Researchers and practitioners should be able to evaluate the relevance of their empirical research to increase the likely adoption of RE methods in software industry. It is in this perspective that we evaluate 24 experimental studies on comprehensibility of software requirements specifications to determine their practical value. To that end a checklist based on Kitchenhams approach was operationalized from a practitioners perspective and an analysis with respect to the main factors that affecting on comprehensibility was carried out. Although 100% of the papers reviewed reported statistically significant results, and 96% of them take examples from a real-life project. 80% of the papers do not scale to real life, 54% of the papers do not specify the context in which the results are expected to be useful. We also found that there is a lack of underlying theory in the formulation of comprehensibility questions.

Die SIKOSA-Methodik

KernpunkteDie SIKOSA-Methodik beschreibt einen durchgängigen Lösungsansatz zur Softwareentwicklung.Die Methodik überführt funktionale und nicht funktionale Prozessanforderungen in entsprechende testbare Unternehmenssoftware-Anforderungen und erhöht die Validität.Die Methodik wird vor dem Hintergrund eines industriellen Beschaffungsprozesses veranschaulicht.AbstractThe SIKOSA method addresses the consistency of quality assuring methods in software engineering processes. To support an industrial business software production a new consistent and quality-oriented method was developed. Regarding business processes, which have to be supported, functional and non-functional requirements of business software are specified and transferred into automated test cases and test data.