From domain to requirements

Source: CONCURRENCY, GRAPHS AND MODELS: ESSAYS DEDICATED TO UGO MONTANARI ON THE OCCASION OF HIS 65TH BIRTHDAY Book Series: LECTURE NOTES IN COMPUTER SCIENCE Volume: 5065 Pages: 278-300 Published: 2008We first present a summary of essentials of domain engineering, its motivation, and its modelling of abstractions of domains through the modelling of the intrinsics, support technologies, management and organisation, rules and regulations, scripts, and human behaviour of whichever domain is being described. Then we present the essence of two (of three) aspects of requirements: the domain requirements and the interface requirements prescriptions as they relate to domain descriptions and we survey the basic operations that “turn” a domain description into a domain requirements prescription: projection, instantiation, determination, extension and fitting. An essence of interface requirements is also presented: the “merging” of shared entities, operations, events and behaviours of the domain with those of the machine (i.e., the hardware and software to be designed)

ELICA: An Automated Tool for Dynamic Extraction of Requirements Relevant Information

Requirements elicitation requires extensive knowledge and deep understanding of the problem domain where the final system will be situated. However, in many software development projects, analysts are required to elicit the requirements from an unfamiliar domain, which often causes communication barriers between analysts and stakeholders. In this paper, we propose a requirements ELICitation Aid tool (ELICA) to help analysts better understand the target application domain by dynamic extraction and labeling of requirements-relevant knowledge. To extract the relevant terms, we leverage the flexibility and power of Weighted Finite State Transducers (WFSTs) in dynamic modeling of natural language processing tasks. In addition to the information conveyed through text, ELICA captures and processes non-linguistic information about the intention of speakers such as their confidence level, analytical tone, and emotions. The extracted information is made available to the analysts as a set of labeled snippets with highlighted relevant terms which can also be exported as an artifact of the Requirements Engineering (RE) process. The application and usefulness of ELICA are demonstrated through a case study. This study shows how pre-existing relevant information about the application domain and the information captured during an elicitation meeting, such as the conversation and stakeholders' intentions, can be captured and used to support analysts achieving their tasks.Comment: 2018 IEEE 26th International Requirements Engineering Conference Workshop

Change Impact Analysis for SysML Requirements Models based on Semantics of Trace Relations

Change impact analysis is one of the applications of requirements traceability in software engineering community. In this paper, we focus on requirements and requirements relations from traceability perspective. We provide formal definitions of the requirements relations in SysML for change impact analysis. Our approach aims at keeping the model synchronized with what stakeholders want to be modeled, and possibly implemented as well, which we called as the domain. The differences between the domain and model are defined as external inconsistencies. The inconsistencies are propagated for the whole model by using the formalization of relations, and mapped to proposed model changes. We provide tool support which is a plug-in of the commercial visual software modeler BluePrint

From ARTEMIS Requirements to a Cross-Domain Embedded System Architecture

International audienceThis paper gives an overview of the cross-domain component-based architecture GENESYS for embedded systems. The development of this architecture has been driven by key industrial challenges identified within the ARTEMIS Strategic Research Agenda (SRA) such as composability, robustness and integrated resource management. GENESYS is a platform architecture that provides a minimal set of core services and a plurality of optional services that are predominantly implemented as self-contained system components. Choosing a suitable set of these system components that implement optional services, augmented by application specific components, can generate domain-specific instantiations of the architecture (e.g., for automotive, avionic, industrial control, mobile, and consumer electronics applications). Such a cross-domain approach is needed to support the coming Internet of Things, to take full advantage of the economies of scale of the semiconductor industry and to improve productivity

Declarative Specification

Deriving formal specifications from informal requirements is extremely difficult since one has to overcome the conceptual gap between an application domain and the domain of formal specification methods. To reduce this gap we introduce application-specific specification languages, i.e., graphical and textual notations that can be unambiguously mapped to formal specifications in a logic language. We describe a number of realised approaches based on this idea, and evaluate them with respect to their domain specificity vs. generalit

Multi-domain product modelling: from requirements to cad and simulation tools.

Today, in a very competitive industrial context, different companies have difficulties to respect delays in design and manufacturing of multi-domain product. These difficulties are most of time due to the non respect of requirements defined at the beginning of the project development, during the Function Performance Specifications phase. Furthermore, an important problem during multi-domain products design and development process is the communication between experts of different domains. To answer to this problem, the authors propose in this paper to describe and analyze this problematic through a meta-model. They focus only on mecatronic product. From the proposed meta-model analysis, they develop two possible links between both mechanical and electronic domains in a model: (1) between models and (2) between analysis tools of different domains. The application of this model to a concrete example shows that we can link all the main common data of a product design and development to the modeling and simulation tools of different domains