Cobbler’s children do not wear shoes. Software engineers build sophisticated software but we often cannot find the needed information and knowledge for ourselves. Issues are the amount of development information that can be captured, organizing that information to make them useable for other developers as well as human decision-making issues. Current architectural knowledge management systems cannot handle these issues properly. In this paper, we outline a research agenda for intelligent tools to support the knowledge management and decision making of architects. The research agenda consists of a vision and research challenges on the way to realize this vision. We call our vision on-demand architectural knowledge systems (ODAKS). Based on literature review, analysis, and synthesis of past research works, we derive our vision of ODAKS as decision-making companions to architects. ODAKS organize and provide relevant information and knowledge to the architect through an assistive conversation. ODAKS use probing to understand the architects’ goals and their questions, they suggest relevant knowledge and present reflective hints to mitigate human decision-making issues, such as cognitive bias, cognitive limitations, as well as design process aspects, such as problem-solution co-evolution and the balance between intuitive and rational decision-making. We present the main features of ODAKS, investigate current potential technologies for the implementation of ODAKS and discuss the main research challenges.

Continuous software engineering (CSE) is characterized by frequent changes. It is challenging for developers to change software while sustaining its high quality so that the software is always deployable to the users. Rationale management provides an opportunity to support the change process during CSE. However, rationale management is not well integrated into CSE. Even if the rationale is captured, e. g. in the issue tracking system, it is difficult to access in the context of requirements, code, and other software artifacts. In this paper, we present tool support called ConDec to make rationale explicit during CSE and to integrate rationale into a knowledge graph data structure consisting of requirements, code, and other software artifacts. The knowledge graph is visualized in various ways and the developers can access the knowledge views from software artifacts such as requirements and code. They can interact with and filter the knowledge views. In particular, they can use transitive links, for example, to access all the decisions made in the context of a particular requirement or code file. We demonstrate the usefulness of the knowledge views using a case study project.

Abstract Trace links between requirements and code are beneficial for many software engineering tasks such as maintenance, program comprehension, and re-engineering. If trace links are created and used continuously during a project, they need to have high precision and recall to be useful. However, manual trace link creation is cumbersome and existing automatic trace link creation methods are typically only applied retrospectively and to structured requirements. Therefore, they focus on recall and accept manual effort to cope with low precision. Such manual effort is not acceptable continuously. Furthermore, the maintenance of existing links along with changing artefacts in a project is neglected in most automatic trace link creation approaches. Therefore, we developed and evaluated an interaction log-based trace link creation approachILto continuously provide correct trace links during a project.ILlinks unstructured requirements specified in an issue tracker and source code managed in a version control system. In the latest version,ILCom, our approach uses the interactions of developers with files in an integrated development environment and issue identifiers provided in commit messages to create trace links continuously after each commit. In this paper, we presentILCom, its most recent evaluation study, and a systematic literature review (SLR) about trace link maintenance (TM). We also present a TM process forILCombased on two approaches from our SLR. In the evaluation study, we show that precision ofILComcreated links is above 90% and recall almost at 80%. In the SLR, we discuss 16 approaches. Our approach is the first trace link creation approach with very good precision and recall and integrated trace maintenance.

Continuous software engineering (CSE) evolved as a process for rapid software evolution. Continuous delivery enables developers to frequently retrieve user feedback on the latest software increment. Developers use these insights for requirements validation and verification. Despite the importance of users, reports about user feedback in CSE practice are sparse. We conducted 20 interviews with practitioners from 17 companies that apply CSE. We asked practitioners how they capture and utilize user feedback. In this paper, we detail the practitioners' answers by posing three research questions. To improve continuous user feedback capture and utilization with respect to requirements engineering, we derived five recommendations: First, internal sources should be approached, as they provide a rich source of user feedback; second, existing tool support should be adapted and extended to automate user feedback processing; third, a concept of reference points should be established to relate user feedback to requirements; fourth, the utilization of user feedback for requirements validation should be increased; and last, the interaction with user feedback should be enabled and supported by increasing developer-user communication. We conclude that a continuous user understanding activity can improve requirements engineering by contributing to both the completeness and correctness of requirements.

Continuous software engineering (CSE) is an agile process that supports lightweight, flexible, and rapid software development.Decision-making is crucial for CSE, and developers need to know the decisions made and the related rationale to evolve the software.This knowledge is called decision knowledge.The management of decision knowledge in CSE environments remains unexplored.The agile manifesto suggests to value working software over comprehensive documentation as well as individuals and interactions over processes and tools.What does this mean for the documentation, exploitation, and sharing of decision knowledge?We report on results from an interview study with 24 practitioners from 17 companies on how decision knowledge is managed during CSE.The practitioners mainly capture decision knowledge in an informal way, for example, in natural language discussions.Wiki and issue tracking systems represent the preferred medium to preserve decision knowledge.Mentioned benefits are an improved decision-making process, accountability, knowledge sharing, and reuse.However, the exploitation of the captured decision knowledge remains partly unclear.

Knowledge about features and their relations to detailed requirements or code is important and useful for many software engineering activities such as for performing change impact analysis and tracking feature progress.Documenting feature knowledge is challenging, as companies document features and requirements in issue tracking systems (ITS) and work on code in integrated development environments (IDE).Managing feature knowledge over time is challenging, as features, requirements, and code continuously change.Also, managing the relationships through trace links is challenging, as creating links manually is too time-consuming, and recovering links retrospectively is too error-prone.We developed an approach and tool TAFT to document feature knowledge in ITS and IDE continuously.TAFT uses feature tags to indicate relations between feature descriptions, requirements, work items, and source code.Currently, TAFT comprises a dashboard to track the feature progress, a recommendation system to suggest feature tags for specifications, an inheritor to apply feature tags automatically, and capabilities to navigate in feature knowledge.The tool is integrated into the developers' work environments Jira and Eclipse.In this paper, we present details on the tool support for TAFT, and we report on the results of a case study, which indicates its acceptance.

Abstract Continuous software engineering (CSE) emerged as a process that is increasingly applied by practitioners. However, different perceptions impede its adoption in industry. Furthermore, opportunities through utilizing usage and decision knowledge remain unexploited. We conducted a semi‐structured interview study with 24 practitioners from 17 companies to study how practitioners apply CSE during software evolution and how usage and decision knowledge can support CSE. Regarding the application of CSE, we identified five perspectives on CSE with tool‐ and methodology‐driven definitions most prevalent. Automated tests, involved users, and shared rulesets are perceived as most relevant for CSE. Practitioners report more positive than negative experiences; however, more than half of their responses were neutral. Practitioners' future plans for CSE focus on enhancement, expansion, and on‐demand adaption. Regarding the integration of usage and decision knowledge into CSE, practitioners perceive accountability and traceability as major benefits, while raising concerns about its feasibility and user groups. As short‐term extensions, practitioners expect improvements regarding automation and role aspects, while long‐term additions to integration and experimentation capabilities are demanded. We conclude that CSE remains partially difficult to capture for practitioners, while their attitude toward integrating usage and decision knowledge into CSE is positive.

Continuous software engineering (CSE) emerged as a process that is increasingly applied by practitioners. However, different perceptions of CSE among practitioners might impede its adoption in industry. We aim to support practitioners by giving a comprehensive overview of current CSE practices. Our observations provide guidance for practice on how to establish, assess, and advance CSE in their company. We conducted an interview study with 24 practitioners from 17 companies during 20 interviews. Following a semi-structured approach, we asked for their definition of CSE, most relevant elements for CSE, their experiences, and plans for further additions to their CSE process. From the practitioners' statements, we identified five perspectives on CSE and found tool- and methodology-driven definitions most prevalent. Automated tests, involved users, and a shared ruleset are perceived as most relevant for CSE. Practitioners' positive experiences with CSE are more frequent than negative ones; however, more than half of the responses were neutral. Practitioners' future plans focus on enhancement, expansion, and on-demand adaption of current practices. We conclude that CSE remains partially difficult to capture for practitioners. Therefore, we structure CSE in a model, the Eye of CSE.

The goal of RE Cares is to apply our requirements engineering and design and prototyping skills to a problem of societal importance to stakeholders residing in the RE conference locale.

Despite past efforts, we have little understanding and limited research efforts on how architects make decisions in the real-world settings. It seems that software architecture researchers make implicit assumption that decision making by software architects can be a rational and prescribed process. Such an assumption is disputed in other fields such as economics and decision research. This paper studies the current state of software architecture decision making research in terms of human behaviors and practice. We carried out a literature review on software architecture decision making. We classified papers into decision making behavior and decision making practice and identified the research relationships between them. We found that decision making is a mental activity. Research into the behavioral aspects of software architecture decision making for incorporation into architectural design practices is required. We suggest three research topics on human aspects to improve software architecture practices.

Continuous software engineering (CSE) includes activities to continuously evolve software artifacts. Along with these activities, developers employ knowledge such as usage and decision knowledge. Usage knowledge helps developers to understand how users apply software, while decision knowledge comprises all decisions taken during CSE and their rationale. However, due to the frequency, extent, and complexity of knowledge in CSE environments, accessing and processing knowledge is challenging for developers. We propose a dashboard for developers that visualizes knowledge from various sources. This enables developers to follow, reflect, interact, and react on knowledge in CSE environments. We introduce springboards that serve as knowledge selectors while the selected extract of knowledge is visualized in widgets. Widgets allow developers to gain insight into knowledge. We suggest three widget classes: spot, compare, and range. We discuss dashboard extensions such as interaction triggers to add, modify, or combine knowledge. We plan to implement the dashboard and evaluate it with teams during software development projects in an industrial setting.

Communication about requirements is often handled in issue tracking systems, especially in a distributed setting. As issue tracking systems also contain bug reports or programming tasks, the software feature requests of the users are often difficult to identify. This paper investigates natural language processing and machine learning features to detect software feature requests in natural language data of issue tracking systems. It compares traditional linguistic machine learning features, such as "bag of words", with more advanced features, such as subject-action-object, and evaluates combinations of machine learning features derived from the natural language and features taken from the issue tracking system meta-data. Our investigation shows that some combinations of machine learning features derived from natural language and the issue tracking system meta-data outperform traditional approaches. We show that issues or data fields (e.g. descriptions or comments), which contain software feature requests, can be identified reasonably well, but hardly the exact sentence. Finally, we show that the choice of machine learning algorithms should depend on the goal, e.g. maximization of the detection rate or balance between detection rate and precision. In addition, the paper contributes a double coded gold standard and an open-source implementation to further pursue this topic.

Software readability and comprehension are important factors in software maintenance. There is a large body of research on software measurement, but the actual factors that make software easier to read or easier to comprehend are not well understood. In the present study, we investigate the role of method chains and code comments in software readability and comprehension. Our analysis comprises data from 104 students with varying programming experience. Readability and comprehension were measured by perceived readability, reading time and performance on a simple cloze test. Regarding perceived readability, our results show statistically significant differences between comment variants, but not between method chain variants. Regarding comprehension, there are no significant differences between method chain or comment variants. Student groups with low and high experience, respectively, show significant differences in perceived readability and performance on the cloze tests. Our results do not show any significant relationships between perceived readability and the other measures taken in the present study. Perceived readability might therefore be insufficient as the sole measure of software readability or comprehension. We also did not find any statistically significant relationships between size and perceived readability, reading time and comprehension.

Software-intensive systems are subject to continuous change due to modification of the systems themselves and their environment.Methods for supporting evolution are a competitive edge in software engineering as software is operated over decades.Empirical research is useful to validate the effectiveness of these methods.However, empirical studies on software evolution are rarely comprehensive and hardly replicable.Collaboration in empirical studies may prevent these shortcomings.We analyzed the support for such collaboration and examined existing studies in a literature review.Based on our findings, we designed CoCoMEP-a platform for supporting collaboration in empirical research on software evolution by shared knowledge.We report lessons learned from the application of the platform in a large research programme.

Software developers make various decisions when implementing software.For instance, they decide on how to implement an algorithm most efficiently or in which way to process user input.When code is revisited during maintenance, the underlying decisions need to be understood and possibly adjusted to the current situation.Common documentation approaches like JavaDoc neither cover knowledge related to decisions explicitly, nor are they integrated closely with knowledge management.In consequence, decision knowledge is rarely documented and therefore inaccessible, especially when developers have left the team.So, effective maintenance is hindered.We have developed an annotation model for decision knowledge and integrated it with the knowledge management tool UNICASE.The approach enables developers to document decisions within code without tool switches to lower their documentation effort.Afterwards, maintainers can exploit the embedded decision knowledge and follow links to external knowledge.This paper presents the approach and evaluation results of a first case study, which indicate its practicability.

Methods for supporting evolution of software-intensive systems are a competitive edge in software engineering as software is often operated over decades. Empirical research is useful to validate the effectiveness of these methods. However, empirical studies on software evolution are rarely comprehensive and hardly replicable. Collaboration may prevent these shortcomings. We designed CoCoMEP — a platform for supporting collaboration in empirical research on software evolution by shared knowledge. We report lessons learned from the application of the platform in a large research programme.

Software repository data, for example in issue tracking systems, include natural language text and technical information, which includes anything from log files via code snippets to stack traces.

[Context and motivation] In practice, trace ability links between requirements and code are often not created, because this would require increased development effort. To address this weakness, we developed in previous work an approach that semi-automatically captures trace ability links between requirements and code during development. We do this by using work items from project management that typically are stored in issue trackers. [Question/problem] Practitioners and researchers have discussed the practice of using work items to capture links between requirements and code, but there has been no systematic study of this practice. [Principal ideas/results] In this paper, we present such an empirical study based on the application of our approach. We applied our approach in three different software development projects conducted with undergraduate students. We evaluated the feasibility and practicability of our approach and its tool support. The feasibility results indicate that our approach creates correct trace ability links between all artifacts with high precision and recall during development. At the same time the practicability results indicate that the subjects found our approach and its tool support easy to use. [Contribution] The empirical evaluation in this paper contributes valuable insights into the tracing of requirements and code during software development.

Support of end-user needs is an important success factor for a software application. In order to optimize the support of end-user needs, developers have to be aware of them and their evolution over time. But a communication gap between developers and users leads to ignorance of developers about how users use their application. Also, developer assumptions about user behavior are rarely tested and corrected if they are wrong. Consequently, many software applications have a mediocre support of user needs and user problems as well as changes in user needs are detected rather late. In this paper, we present a research agenda addressing this problem by comparing use case descriptions to monitored user actions. More specifically, we propose to monitor user actions using instrumentation, detect the current use case of a user using machine learning, and compare use case steps to monitored user actions. By detecting differences between both, we identify mismatches between user behavior and developer assumptions reflected in use case descriptions. Those mismatches can serve as starting points to identify software improvements, to test the use case specification and identify updates, and to revise training programs. Finally, we sketch a plan to evaluate our approach.

Access protection is an important requirement for systems, which handle confidential data. This paper describes an approach for the requirements engineering of an access protection using the example of an open system. A major problem of open systems is that many users with different roles access it. Moreover, the open system is connected to the Internet and has ports for connecting hardware like an external storage medium. Therefore, it is easy to steal or misuse confidential data from open systems if access protection is not existent. First, we used Task and Object-Oriented Requirements Engineering (TORE) in order to specify functional requirements on the access protection. For the elicitation of non-functional requirements, we applied Misuse-Oriented Quality Requirements Engineering (MOQARE), on which this paper is focused. Furthermore, we used the German IT-Safety and Security Standard Handbook in order to ensure the completeness of the solution requirements. For consideration of architectural requirements, we used Integrated Conflict Resolution and Architectural Design (ICRAD). It allows to analyze which design can realize which requirements and therefore to identify the most suitable one. Combining these three requirements engineering methods ensured a complete and appropriate solution.

In this paper we discuss the challenges of software quality for medical software and present some ideas for improving medical software quality requirements through software engineering methods. We apply the quality requirements engineering method MOQARE to elicit specific quality requirements for an imaginary drug advisory system and report our lessons learned.

Software processes often focus on artifacts, activities and roles, treating decisions to be made during the software development process only implicitly. However, awareness of these decisions increases their quality by forcing the decision-makers to search for alternatives and to trade off between them. In this paper, we propose a decision hierarchy for the testing process. This hierarchy comprises all decisions made during testing and reflects dependencies between them. Additionally, we present the results of four case studies to which we applied this decision hierarchy.

Runtime testing is important for improving the quality of software systems. This fact holds true especially for systems which cannot be completely assembled at development time, such as mobile or ad-hoc systems. The concepts of built-in-test (BIT) can be used to cope with runtime testing, but to our knowledge there does not exist an implemented infrastructure for BIT. The MORABIT project realizes such an infrastructure and extends the BIT concepts to allow for a smooth integration of the testing process and the original business functionality execution. In this paper the requirements on the infrastructure and our solution are presented

Today component- and service-based technologies play a central role in many aspects of enterprise computing. However, although the technologies used to define, implement, and assemble components have improved significantly over recent years, techniques for verifying systems created from them have changed very little. The correctness and reliability of component-based systems are still usually checked using the traditional testing techniques that were in use before components and services became widespread, and the associated costs and overheads still remain high. This paper presents an approach which addresses this problem by making the system verification process more component-oriented. Based on the notion of built-in tests - tests that are packaged and distributed with prefabricated, off-the-shelf components - the approach and supporting infrastructure help to automate some of the testing process, thereby significantly reduces system testing effort. After providing an introduction to the principles behind component-based verification, and explaining the main features of the approach, we show by means of a small example how it can reduce system verification effort

This paper describes an experience in requirements engineering for an open source E-learning tool selection. The process meets the challenges of software selection such as the intertwining of requirements acquisition and product evaluation, the level of detail or the information collection. In addition, it is user-driven and just-in-time. Despite their time constraints the stakeholders were able to contribute throughout the whole process. The decisions and the effort for preparing these decisions were postponed to the latest possible point in time. This process seems also suitable for open source software development

In order to solve requirements conflicts when developing or enhancing an IT system, it is essential to understand its architecture. Frequently, the costs for the realization of certain requirements are a decision criterion. Requirements negotiation and architectural design must be treated together, as conflicts cannot be solved before the architecture has been designed. So far, no integrated process exists which clearly defines input and output among these activities, and which takes into account a variety of different types of dependencies among requirements and between requirements and architecture. In this paper, we develop a detailed iterative process named ICRAD (Integrated Conflict Resolution and Architectural Design). ICRAD integrates requirements negotiation and architectural design and takes into account nine types of dependencies. We define three types of requirements conflicts. We also present a case study.

Software engineering courses often use industrial modeling tools for their infrastructure, as it exposes students to the state-of-the practice and increases their awareness about the complexity of their craft. However, this approach has the risk of expending a disproportionate amount of effort on tools as opposed to teaching concepts. Moreover, industrial tools often do not include didactic concepts needed for education. In this paper, we discuss our experience with an integrated, rationale-based modeling tool in a variety of software engineering courses. By providing an integrated modeling environment, students use a single tool for requirements, system design, test planning, and collaboration. By attaching rationale to the models, students are encouraged to reflect on their work while instructors can monitor them and provide more insightful feedback

Ad-hoc recycling between requirements documents of product variants is a major source of requirements defects. We present an approach for systematic requirements recycling based on a combination of abstraction (in terms of a template) and traceability (between requirements). The main features of our approach are the use of conceptual models to determine relationships necessary for correct recycling and the focus on minimizing link selling. This approach can also be used to develop abstraction and traceability guidelines tailored to other application domains and traceability goals, such as change or project management.

Component-based software engineering is widely expected to revolutionize the way in which software systems are developed and maintained. However, companies who wish to adopt the component paradigm for serious enterprise software development face serious migration obstacles due to the perceived incompatibility of components with traditional, commonly used development approaches. This perception is reinforced by contemporary methods and component technologies, which typically view components as merely "binary-level" modules with little relevance beyond the implementation and deployment phases of development. The authors present a method known as KobrA that embraces the component concept at all phases of the software life-cycle, and allows high-level components (described in the UML) to be implemented using conventional software development approaches, as well as the latest component technologies (e.g. JavaBeans, CORBA, COM). The approach therefore provides a practical vehicle for applying the component paradigm within the context of a model driven architecture. After explaining the noteworthy features of the method, the paper briefly presents an example of its use in the development of an enterprise resource planning system.