The complexity of today's software systems is constantly increasing. As a result, requirements for these systems become more comprehensive and complicated. In this setting, requirements engineers struggle to capture consistent and complete requirements of high quality. We propose a feedback-centric requirements editor to help analysts controlling the information overload. Our HeRA tool provides analysts with important data from various feedback facilities. The feedback is directly given based on the input to the editor. On the one hand, it is based on heuristic rules, on the other hand, on automatically derived models. Thus, when new requirements are added, the analyst gets important information on how consistent these requirements are with the existing ones.

When developing a Service-Oriented Architecture(SOA), analyzing the business process is even more important than in normal software projects. Nevertheless, most of the requirements artifacts used in normal software projects apply to SOA-projects, too. This results in competing requirement models (like use cases and business processes) that duplicate information in parts. Even worse, these models are often contradictory, belong to different types of stakeholders, and need much effort to be synchronized. However, these inconsistencies are an important source for requirements. We propose to deliberately switch between different perspectives onto the requirements to clarify them as soon as possible. In this way we a) enrich feedback and b) improve existing models as a by-product by confronting stakeholders with new perspectives. User interface mockups, data models, and business processes complement, enrich, and facilitate a pure use case perspective. We present a set of computer-supported techniques that leverage this friction between models and share our experiences in applying them.

Teaching (and therefore learning) eXtreme Programming (XP) in a university setting is difficult because of course time limitations and the soft nature of XP that requires first-hand experience in order to see and really learn the methods. For example, iterations are either shorter or fewer than appropriate. In this paper we present the properties to tune when designing an eXtreme Programming course. These are the properties we gathered by conducting three XP labs as part of our software engineering teaching. Within this paper we describe our set-up as well as the important properties. Lecturers and teachers can use this property system and combine it with their own constraints in order to derive a better XP lab for their curriculum.