Results 11 - 20
of
28
Goal-oriented requirements communication in new product development
- in 2nd International Workshop on Software Product Management held in conjunction with the 16th IEEE International Conference on Requirements Engineering
, 2008
"... Product development organizations often distribute the responsibilities for requirements engineering over several roles. The collaboration of product manage-ment, concerned with market needs, and product de-velopment, concerned with the technological aspects of a product, is well established. Such s ..."
Abstract
-
Cited by 2 (2 self)
- Add to MetaCart
(Show Context)
Product development organizations often distribute the responsibilities for requirements engineering over several roles. The collaboration of product manage-ment, concerned with market needs, and product de-velopment, concerned with the technological aspects of a product, is well established. Such shared responsibil-ity provides advantages in the utilization of specific knowledge, skills, and resources. However, the colla-boration leads to increased demands on coordination. Novel concepts and models need to be investigated to support such collaborative requirements engineer-ing. In this paper we focus on requirements communi-cation from product management to a development team by proposing and evaluating the model of goal-oriented requirements communication. The model explains how efficiency and effectiveness of require-ments communication can be increased and allows the utilization of established requirements engineering knowledge in a new way to address the task of re-quirements communication. 1.
AutoFOCUS 3: Tooling Concepts for Seamless, Model-based Development of Embedded Systems
"... Abstract-This paper presents tooling concepts in AUTO-FOCUS 3 supporting the development of software-intensive embedded system design. AUTOFOCUS 3 is a highly integrated model-based tool covering the complete development process from requirements elicitation, deployment, the modelling of the hardwa ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
(Show Context)
Abstract-This paper presents tooling concepts in AUTO-FOCUS 3 supporting the development of software-intensive embedded system design. AUTOFOCUS 3 is a highly integrated model-based tool covering the complete development process from requirements elicitation, deployment, the modelling of the hardware platform to code generation. This is achieved thanks to precise static and dynamic semantics based on the FOCUS theory In this paper, we demonstrate how tooling concepts on different steps in the development process look like, based on these integrated models and implemented in AUTOFOCUS 3.
Human-Friendly Line Routing for Hierarchical Diagrams
"... Hierarchical diagrams are well-suited for visualizing the structure and decomposition of complex systems. However, the current tools poorly support modeling, visualization and navigation of hierarchical models. Especially the line routing algorithms are poorly suited for hierarchical models: for exa ..."
Abstract
-
Cited by 1 (1 self)
- Add to MetaCart
(Show Context)
Hierarchical diagrams are well-suited for visualizing the structure and decomposition of complex systems. However, the current tools poorly support modeling, visualization and navigation of hierarchical models. Especially the line routing algorithms are poorly suited for hierarchical models: for example, they produce lines that run across nodes or overlap with other lines. In this paper, we present a novel algorithm for line routing in hierarchical models. In particular, our algorithm produces an esthetically appealing layout, routes in real-time, and preserves the secondary notation of the diagrams as far as possible. 1
Domain system statecharts: The good, the bad, and the ugly
, 2006
"... This paper presents the results of case studies evaluating our method of unifying use cases (UCs) to derive a unified StateChart (SC) model of the behavior of the domain system (DS) of a proposed computer-based system. An evaluation of the unification method, the obtained SC model of the DS, the met ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
(Show Context)
This paper presents the results of case studies evaluating our method of unifying use cases (UCs) to derive a unified StateChart (SC) model of the behavior of the domain system (DS) of a proposed computer-based system. An evaluation of the unification method, the obtained SC model of the DS, the method’s and model’s feedback on the UCs themselves, and how the method is used in requirements engineering practice was carried out by examining 46 software requirements specifications produced by 149 upper-year undergraduate and graduate students. The results of our studies independently confirm some of the benefits of building a unified SC mentioned in the works of Glinz; Whittle and Schumann; and Harel, Kugler, and Pnueli, who have developed formal treatments of unifying UCs using SCs and, in two cases, have built tools implementing their treatments. 1.
Tool Support for the Navigation in Graphical Models
"... Graphical models are omnipresent in the software engineer-ing field, but most current graphical modeling languages do not scale with the increasing size and complexity of today’s systems. The navigation in the diagrams becomes a ma-jor problem especially if different aspects of the system are scatte ..."
Abstract
- Add to MetaCart
(Show Context)
Graphical models are omnipresent in the software engineer-ing field, but most current graphical modeling languages do not scale with the increasing size and complexity of today’s systems. The navigation in the diagrams becomes a ma-jor problem especially if different aspects of the system are scattered over multiple, only loosely coupled diagrams. In this paper we present the hierarchical navigation capa-bilities of the Adora modeling tool. The user of this tool can freely control the level of detail in different parts of the model to reduce the size and complexity of the diagrams be-ing displayed. Our fisheye visualization technique makes it possible to integrate all modeling aspects (structure, data, behavior, etc.) in one coherent model while keeping the size and complexity of the diagrams within reasonable limits.
Extending a Graphic Modeling Language to Support Partial and Evolutionary Specification
"... The notion of partial and evolutionary specification has gained attention both in research and industry in the last years. While many people regard this just as a process issue, we are convinced that it is as well a language problem. Unfortunately, UML is not expressive enough to deal with evolution ..."
Abstract
- Add to MetaCart
(Show Context)
The notion of partial and evolutionary specification has gained attention both in research and industry in the last years. While many people regard this just as a process issue, we are convinced that it is as well a language problem. Unfortunately, UML is not expressive enough to deal with evolutionary information in the system. In this paper, we propose an extension to a graphic modeling language called ADORA which is developed in our research group. We conservatively extend the semantics of some ADORA constructs so that intentional incompleteness can be expressed in the language and define a calculus for refining such specifications. With the help of these extensions, evolutionary specifications can be written in a controlled and systematic way. As the language and its extensions are formally defined, the consistency of evolutionary refinements can be checked mechanically by a tool. 1
Extending a Graphic Modeling Language to Support Partial and Evolutionary Specification
"... The notion of partial and evolutionary specification has gained attention both in research and industry in the last years. While many people regard this just as a process issue, we are convinced that it is as well a language problem. Unfortunately, UML is not expressive enough to deal with evolution ..."
Abstract
- Add to MetaCart
(Show Context)
The notion of partial and evolutionary specification has gained attention both in research and industry in the last years. While many people regard this just as a process issue, we are convinced that it is as well a language problem. Unfortunately, UML is not expressive enough to deal with evolutionary information in the system. In this paper, we propose an extension to a graphic modeling language called ADORA which is developed in our research group. We conservatively extend the semantics of some ADORA constructs so that intentional incompleteness can be expressed in the language and define a calculus for refining such specifications. With the help of these extensions, evolutionary specifications can be written in a controlled and systematic way. As the language and its extensions are formally defined, the consistency of evolutionary refinements can be checked mechanically by a tool. 1
Should Requirements Be Objects?
"... Abstract. This position paper discusses arguments in favor and against regarding requirements as objects. As there are good arguments for both standpoints, a partial synthesis is developed. The synthesis is based on the idea of not treating requirements as objects, but using objects for organizing a ..."
Abstract
- Add to MetaCart
Abstract. This position paper discusses arguments in favor and against regarding requirements as objects. As there are good arguments for both standpoints, a partial synthesis is developed. The synthesis is based on the idea of not treating requirements as objects, but using objects for organizing and understanding requirements. Introduction: A naive approach to the problem When we take a naive approach to the problem, we can easily demonstrate that every requirement is an object. Just consider Figure 1, which is a rather simplified model of a requirements specification. In this model, every requirement is an object. However, it is not this kind of objects that we are interested in. Moreover, if we examine the model in Figure 1 more closely,
ABSTRACT Scenario-Driven Modeling and Validation of Requirements Models
"... Requirements models for large systems typically cannot be developed in a single step, but evolve in a sequence of iterations. We have developed such an iterative modeling process which is based on the interactive simulation of yet incomplete and semi-formal models. Missing parts are completed intera ..."
Abstract
- Add to MetaCart
(Show Context)
Requirements models for large systems typically cannot be developed in a single step, but evolve in a sequence of iterations. We have developed such an iterative modeling process which is based on the interactive simulation of yet incomplete and semi-formal models. Missing parts are completed interactively by the user simulating the model. We start by modeling type scenarios (i.e. use cases) and simulate these interactively before having specified any system behavior. Such simulation runs yield exemplary system behavior in form of message sequence charts (MSCs). The modeler can then generalize this recorded partial behavior into statecharts. The resulting model is simulated again, (i) for validating that the modeled behavior matches the previously recorded behavior, and (ii) for recording new yet unspecified behavior in a next iteration step. Thus, recording MSCs by playing-through the scenarios and transforming MSCs to statecharts stimulate and drive each other. In this paper we focus on two elements of our approach: firstly, we describe the syntax and semantics of our scenario language. Secondly, we give an example how our modeling process works.
Systematically Combining Specifications of Internal and External System Behavior Using Statecharts
"... In contemporary model-based specifications, we typically find a naive combination of models of the externally visible behavior of a system (typically expressed as scenarios or use cases) and of the internal system behavior (partially represented in explicit state models and partially expressed as da ..."
Abstract
- Add to MetaCart
In contemporary model-based specifications, we typically find a naive combination of models of the externally visible behavior of a system (typically expressed as scenarios or use cases) and of the internal system behavior (partially represented in explicit state models and partially expressed as data). However, a systematic combination and integration of the two behavior aspects has not yet been investigated. In this paper, I sketch a systematic approach for modeling both external and internal behavior of a system with statecharts in an integrated, non-redundant way. The main idea is to start with statecharts that model external behavior in the form of use cases or type scenarios and then add statecharts that model internal behavior only where the scenario/use case statecharts do not suffice for expressing the behavior of the system. 1.
