Engineering and verifying agent-oriented requirements augmented by business constraints with \({\mathcal{B}}\) -Tropos

0 N. Zannone Eindhoven University of Technology , Eindhoven, The Netherlands 1 V. Bryl FBK-IRST, Povo, TN, Italy We propose B-Tropos as a modeling framework to support agent-oriented systems engineering, from high-level requirements elicitation down to execution-level tasks. In particular, we show how B-Tropos extends the Tropos methodology by means of declarative business constraints, inspired by the ConDec graphical language. We demonstrate the functioning of B-Tropos using a running example inspired by a real-world industrial scenario, and we describe how B-Tropos models can be automatically formalized in computational logic, discussing formal properties of the resulting framework and its verification capabilities. Requirements engineering provided a number of approaches that address various aspects of information systems modeling. In particular, agent-oriented approaches support the understanding of the organizational setting in which a system will operate [9,13,24,52], and goaloriented approaches support the modeling and analysis of stakeholders' strategic goals and thus they allow one to represent the rationale beyond the introduction of the system and the - design choices made [7,16,17]. Some requirements engineering methodologies have also been used to address the definition of business processes [12,27,35], but most of them result to be inadequate to represent all aspects of business processes, especially when spanning across different organizations (or different divisions of the same organization) [8,31]. Early requirements engineering techniques such as those we will refer to in this paper, are concerned with early stage requirements elicitation. At the far end of information systems design, we find implemented systems, and tools that support synthesis (system prototyping and simulation), run-time execution, monitoring and analysis. In between these two activities of information systems development, a number of other activities span from high-level architectural to low-level detailed design. Among them we find business process modeling and specification. Each one of these design activities typically relies on its own tools, languages and methodologies. The differences and variety in the approaches are justified by the different aims that each activity has. Early requirements focus on why questions, in order to support the definition of a model of an information system and on the corresponding goal model. Declarative business process modeling focuses on what questions, to specify in a declarative way the business process of an information system starting from a highlevel model. The purpose of operational model development and tools is to throw bridges between what is declaratively specified and how this is operationally achieved, and to support execution-level tasks such as prototyping and system monitoring and analysis. Such heterogeneous aspects are typically not to be found in a single unified design framework. Business process modeling is a fundamental part of the software development process [37]. However, understanding whether or not defined business processes provide support for the business strategies of an organization is still a challenge [8]. This issue has been partially addressed in both requirements engineering and business analysis research areas, but separately. The lack of interaction between these two areas caused that the duties of requirements engineers and business analysts, and their role in the software development process are not clear [43]. For instance, Haglind et al. addressed the issue of the integration of business analysis and requirements engineering by means of the impact that business analysis has on ensuring requirements engineering activities [23]. To allow for a systematic design of business processes, we have to understand the business goals and requirements of an organization, its structure and the dependencies among business partners, and then link business processes to business goals [31]. Many problems might also arise from organizational theory and strategic management perspectives due to limits on particular resources (e.g., cost, time, etc.). In this setting, if business processes are defined before identifying business goals and eliciting business requirements, the defined business processes may not meet the actual needs and capabilities of individual business partners participating in the process. In our previous works [11], we have proposed B-Tropos to facilitate the interaction between requirements engineers and business analysts in order to bridge the gap between requirements analysis and business process modeling. In particular, we proposed to model and analyze business goals and then define business processes upon goal models. To this end, we have extended Tropos [9], an agent-oriented, goal-oriented software engineering methodology, with declarative business process-oriented constructs inspired by DecSerFlow [46] and ConDec [45]. One of the main features of Tropos is the prominent role given to early requirements analysis that concerns the understanding of the domain by studying the organizational setting within which the system will operate. However, a drawback of Tropos, as well as of many other agent-oriented and goal-oriented approaches, is that it does not clearly define how to move from requirements models to business process models. For example, Tropos does not allow modeling temporal and data constraints between the tasks an agent is assigned to, which is essential when specifying the partial ordering between activities of a business process [29]. The integration with declarative business process languages provides Tropos with these capabilities. In [11] we have also shown how these complementary aspects (i.e., agent-, goal-, and process-oriented) can be formalized in the SCIFFframework [6], a computational logic-based framework for the specification and verification of interaction protocols in an open multi-agent setting. In particular, we have demonstrated how the mapping of B-Tropos into SCIFF can be used to implement the skeleton of logic-based agents. Since [11] was published, the application of the framework to a case study in collaboration with industrial partners has allowed us to evaluate its expressiveness and usability, and prove its applicability in industry. The attempt to capture and analyze the issues raised by the case study has pointed out a number of drawbacks in our initial proposal, which have demanded for a revision and an extension of B-Tropos. In particular, bringing B-Tropos up to capturing challenges of the case study has required to: revise the modeling constructs to increase the readability and manageability of the framework by industry partners; provide industry partners with analysis tools. This paper presents a comprehensive and consolidated description of B-Tropos that addresses the challenges raised from its application to the case study together with theor (...truncated)