Requirements Engineering in Complex Domains

  title={Requirements Engineering in Complex Domains},
  author={Matthias Jarke and Ralf Klamma and Klaus Pohl and Ernst Sikora},
  booktitle={Graph Transformations and Model-Driven Engineering},
Complexity in the application domains of software-intensive systems is continuously growing due to at least two reasons. Firstly, technical complexity grows as hardware and software have to interact in individual or even communicating embedded systems. Secondly, social complexity grows as the process organizations of the 1990's are gradually being replaced by loosely coupled networks of actors, often organized around community platforms. In this chapter, we discuss recent solution attempts for… 
Using software theater for the demonstration of innovative ubiquitous applications
This work proposes a new way of demonstration called Software Theater, based on ideas from theater plays, that aims at presenting scenario-based demonstration in a theatrical way to highlight new features, new user experience and new technical architecture in an integrated performance.
An Enhanced Negotiation-Style Framework for Requirements Change
On the basis of the Mu's framework, a selection strategy for selecting the negotiation scheme, which perfected the part that can be improved and managed the software requirements changes flexibly and effectively is presented.
Software Theater—Teaching Demo-Oriented Prototyping
This work combines agile methods, scenario-based design, and theatrical aspects into software theater, an approach to present visionary scenarios using techniques borrowed from theater and film, including props and humor.
Responsible Design for Sustainable Innovation: Towards an Extended Design Process
An alternative way to understand and represent the design process, especially oriented to develop innovations that are aligned with the social, environmental, and cultural demands the world is facing now and it will face in the future is proposed.
Mapping feature models onto domain models: ensuring consistency of configured domain models
An approach to model-driven software product line engineering which is based on feature models and domain models is presented and constraints on the annotations of inter-dependent domain model elements are defined to ensure consistency.
Evaluation on Architecture Engineering Quality Based on Set Pair Analysis Method
The result has indicated that set pair analysis model is not only easy calculation but also has merits of high usability of information in the course of evaluation, objective and reasonable system and confidence, etc.


Weaving Together Requirements and Architectures
The spiral life-cycle model addresses many drawbacks of a waterfall model by providing an incremental development process, in which developers repeatedly evaluate changing project risks to manage unstable requirements and funding.
A requirements engineering environment within a tightly integrated SDE
The tools discussed are editors, analysers, executors, monitors, and integration tools of different characteristics for horizontal integration (within RE) and vertical integration (to architecture modelling) that work incrementally, therefore allowing different forms of construction and modification processes and giving substantial support.
Supporting the Consistent Specification of Scenarios across Multiple Abstraction Levels
This paper presents a systematic approach for developing scenarios at multiple abstraction levels supported by automated consistency checks of scenarios across these abstraction levels and evaluated the approach by applying it to a (simplified) adaptive cruise control system.
COSMOD-RE: Supporting the Co-Design of Requirements and Architectural Artifacts
  • K. Pohl, E. Sikora
  • Computer Science
    15th IEEE International Requirements Engineering Conference (RE 2007)
  • 2007
This paper presents the key ideas of the method COSMOD-RE for supporting the co-design of requirements and architectural artifacts, a hierarchy of four abstraction layers that defines three co-Design processes and five sub-processes for each co- design process.
On the Development of Reactive Systems
The recently proposed statechart method is recommended for finding satisfactory methods for behavioral description in reactive systems, observing that most reactive systems cannot be developed in a linear stepwise fashion, but, rather, give rise to a two-dimensional development process, featuring behavioral aspects in the one dimension and implementational ones in the other.
Establishing Visions in Context: Towards a Model of Requirements Processes
A model of requirements determination as the process oi establishing visions in context explains how both new ideas and existing habits influence diversity in a family of information systems
No Silver Bullet Essence and Accidents of Software Engineering
This article shall try to show why there is no single development, in either technology or management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.
Towards modelling and reasoning support for early-phase requirements engineering
  • E. Yu
  • Computer Science
    Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering
  • 1997
This paper argues that a different kind of modelling and reasoning support is needed for the early phase of requirements engineering, which aims to model and analyze stakeholder interests and how they might be addressed, or compromised, by various system-and-environment alternatives.
Designing socio-technical systems: from stakeholder goals to social networks
A tool-supported process of requirements analysis for socio-technical systems is proposed, which adopts planning techniques for exploring the space of requirements alternatives and a number of social criteria for their evaluation.
Structuring the Co-design of Requirements and Architecture
This paper proposes a method for the co-design of requirements and architectural artefacts based on two viewpoints, the system usage viewpoint and the system architecture viewpoint, which consists of five sub-processes that support the development of each viewpoint.