Formalization and Validation of Safety-Critical Requirements

The validation of requirements is a fundamental step in the development process of safety-critical systems. In safety critical applications such as aerospace, avionics and railways, the use of formal methods is of paramount importance both for requirements and for design validation. Nevertheless, while for the verification of the design, many formal techniques have been conceived and applied, the research on formal methods for requirements validation is not yet mature. The main obstacles are that, on the one hand, the correctness of requirements is not formally defined; on the other hand that the formalization and the validation of the requirements usually demands a strong involvement of domain experts. We report on a methodology and a series of techniques that we developed for the formalization and validation of high-level requirements for safety-critical applications. The main ingredients are a very expressive formal language and automatic satisfiability procedures. The language combines first-order, temporal, and hybrid logic. The satisfiability procedures are based on model checking and satisfiability modulo theory. We applied this technology within an industrial project to the validation of railways requirements

Business Modeling with the Support of Multiple Notations in Requirements Engineering

Requirements specification should not be concerned only with the software specification, but should also be able to integrate with the organizational models describing the environment in which the system will function. Agent–oriented conceptual modeling notations such as i* represents an interesting approach for modeling early phase requirements which includes organizational contexts, stakeholder intentions and rationale. Business Process Modeling notations such as BPMN are used to effectively conceptualize and communicate important process characteristics to relevant stakeholders. On the other hand, Unified Modeling Language (UML) is suitable for later phases of requirement capture which usually focus on completeness, consistency, and automated verification of functional requirements for the new system. In this paper, we illustrate the use of a methodology that facilitate and support the combined use of notation for modeling requirement engineering process in a synergistic fashion in a complex project for a large government Department. The notations we used were i*, BPMN and UML Use Case

Fusing Quantitative Requirements Analysis with Model-based Systems Engineering

A vision is presented for fusing quantitative requirements analysis with model-based systems engineering. This vision draws upon and combines emergent themes in the engineering milieu. “Requirements engineering” provides means to explicitly represent requirements (both functional and non-functional) as constraints and preferences on acceptable solutions, and emphasizes early-lifecycle review, analysis and verification of design and development plans. “Design by shopping” emphasizes revealing the space of options available from which to choose (without presuming that all selection criteria have previously been elicited), and provides means to make understandable the range of choices and their ramifications. “Model-based engineering” emphasizes the goal of utilizing a formal representation of all aspects of system design, from development through operations, and provides powerful tool suites that support the practical application of these principles. A first step prototype towards this vision is described, embodying the key capabilities. Illustrations, implications, further challenges and opportunities are outlined

Combining i* and BPMN for business process model lifecycle management

The premise behind ‘third wave’ Business Process Management (BPM1) is effective support for change at levels. Business Process Modeling (BPM2) notations such as BPMN are used to effectively conceptualize and communicate process configurations to relevant stakeholders. In this paper we argue that the management of change throughout the business process model lifecycle requires greater conceptual support achieved via a combination of complementary notations. As such the focus in this paper is on the co-evolution of operational (BPMN) and organizational (i*) models. Our intent is to provide a way of expressing changes, which arise in one model, effectively in the other model. We present constrained development methodologies capable of guiding an analyst when reflecting changes from an i* model to a BPMN model and vice-versa. 1 Introductio

Correlating Business Process and Organizational Models to Manage Change

Business Process Management (BPM) provides the methods, tools and modelling notations to support a processcentric organizational view and management capability. As organizations grow in size and complexity, process improvement initiatives may involve change that has direct / significant impact across an organization. Thus, we provide methods and extensions to existing process modelling notations to analyse change against high- level models of the organization. Our approach permits improved analysis against higher-level organizational structures, motivations, inter-dependencies and capabilities that should be ideally considered as primary requirements during process design. Additionally, the organizational model becomes the ‘scaffolding’ with which to construct effective process architectures and management portfolios. This paper discusses our approach in the context of two modelling notations – the i* framework as an organizational modelling notation, and the BPMN notation for business process modelling

Combined Approach for Supporting the Business Process Model Lifecycle

Business processes evolve throughout their lifecycle of change. Business Process Modeling (BPM2) notations such as BPMN are used to effectively conceptualize and communicate important process characteristics to relevant stakeholders. Agent-oriented conceptual modeling notations, such as i*, effectively capture and communicate organizational context. In this paper we argue that the management of change throughout the business process model lifecycle can be more effectively supported by combining notations. In particular, we identify two potential sources of process change, one occurring within the organizational context and the other within the operational context. As such the focus in this paper is on the co-evolution of operational (BPMN) and organizational (i*) models. Our intent is to provide a way of expressing changes, which arise in one model, effectively in the other model. We present constrained development methodologies capable of guiding an analyst when reflecting changes from an i* model to a BPMN model and vice-versa

Customizing choreography: Deriving conversations from organizational dependencies

Evolving business needs call for customizable choreographed interactions. However, choreography descriptions do not capture the problem-domain knowledge required to perform the customization effectively. Hence, we propose performing the customization to models of organizational requirements motivating the interaction. To facilitate the derivation of the resulting choreography description, we propose an alignment between conversations and organizational dependencies. We employ the domain knowledge and formal semantics of requirements models to find customization alternatives and reason about them. Using the alignment, we derive constraints on conversations systematically from customized requirements models