Requirements analysis includes a preliminary acquisition step where a global model for the specification of the system and its environment is elaborated. This model, called requirements model, involves concepts that are currently not supported by existing formal specification languages, such as goals to be achieved, agents to be assigned, alternatives to be negotiated, etc. The paper presents an approach to requirements acquisition which is driven by such higher-level concepts. Requirements models are acquired as instances of a conceptual meta-model. The latter can be represented as a graph where each node captures an abstraction such as, e.g., goal, action, agent, entity, or event, and where the edges capture semantic links between such abstractions. Well-formedness properties on nodes and links constrain their instances - that is, elements of requirements models. Requirements acquisition processes then correspond to particular ways of traversing the meta-model graph to acquire approp...

Recently a number of requirements engineering languages and methods have flourished that do not only address what questions but also why, who and when questions. The objective of this paper is twofold: (i) to assess the strengths and weaknesses of one of these methodologies on a non-trivial benchmark, and (ii) to illustrate and discuss a number of challenging issues that need to be addressed for such methodologies to become effective in supporting real, complex requirements engineering tasks. The problem considered here is that of a distributed meeting scheduler system; the methodology considered is the KAOS goal-directed language and method. The issues raised from this case study include goal identification, the "deidelization" of unachievable goals, the handling of interfering goals, the impact of early formal reasoning, the merits of early reuse of abstract descriptions and categories, requirements traceability and the need to link requirements to retractable assumptions, and the potential benefits of hybrid acquisition strategies.

An increasing volume of research in e-commerce is concerned with the development of tools and environments to support various aspects of business-to-business electronic contract formation and performance. This paper is mainly concerned with the latter and takes up the suggestion that automated execution of an agreement between (at least) two parties can be effected through a central control mechanism (a so-called e-marketplace). We revisit modal action logic to model an agreement as a state-based system and specify acceptable and unacceptable states of a business transaction. Unacceptable states result from violations of contractual obligations or prohibitions and call for appropriate recovery mechanisms to be specified, so that they can be enforced by the central control mechanism. We comment on the relations between contract violations (and their associated recovery mechanisms) and the concepts of fault tolerance and recovery arising in the broader distributed systems context, on the one hand, and contrary-to-duty structures from the (theoretical) deontic logic perspective, on the other.

ion. Requirements may be distinguished based on the abstraction level of their description. A requirement may be further defined by add new details defined in more specialized subrequirements. Through specialization of abstract requirements, or generalization of detailed requirement, a requirement abstraction hierarchy can be defined. . Development p roperties . Requirements may be distinguished based on their development properties. For example, a requirement may have just been proposed. Late r, it may be accepted or rejected. . Representational properties. Requirements may be distinguished based on their representation. A requirement may begin as an informal sketch, then become a natural language sentence (e.g., "The system shall ..."). Finall y, more formal representations, such as UML, Z, or predicate cal- Requirements Interaction Management - Definition and scope 6 1999 William N. Robinson Requirements Interaction Management GSU CIS 99-7 culus, may be used to express a requir...

Goal based systems are well suited for creating systems in which there is a well-defined set of goals. These goals easily allow the designer specify what the system should do when the goals of the system are static and very clear-cut. A problem with current goal-based systems is that the goals and system invariants are elicited during requirements. These goals are used during analysis of invariants, but these goals and invariants are not used during the runtime of the system. The lack of use of the goals during the runtime leads to one of two options for software designers. They either will not do the analysis because it will not be used later on, or they will invest time working on requirements that are of no use in the runtime. The lack of incentive to use analysis is a problem because analysis is key in reducing errors in software. To help solve these two problems we propose a goal model that both is dynamic in nature and that ensures that properties verified through analysis hold during the runtime of the system. The dynamic nature of the goal model will allow systems to be designed that are more flexible in nature. The model also allows the designer of the system to specify the goals and properties of these goals. Properties that are specified during the design phase can be proven to hold while the system is

tions. Keywords: Conceptual modelling, software engineering, knowledge engineering 1. Introduction The software development process is a kind of problem-solving process. Problem, here, means a context, environment or situation where a software system shall be developed and operated. For a successful software system development, Software Engineers (and Knowledge Engineers) shall understand all problem components, relations, rules, constraints, etc. Such an understanding is a hard and time-consuming process, which requires specialised tools for being 2 Handbook of Software Engineering and Knowledge Engineering performed. These tools, which allow the Software/Knowledge Engineer to understand the problem to solve, are known as conceptual models (CMs). The process of creating CMs in software development is generally referred to as conceptual modelling, although it may be given other pet names depending on the actual discipline in wh

Event-B is a language for the formal development of reactive systems. At

This deliverable surveys the state of the art in all areas related to the engineering of service-based applications with particular focus on all aspects related to adaptivity. Moreover, it provides an overview of various aspects concerning the way human beings interact with each other and with the computerized systems. This second aspect, even if not directly related to the Service-Oriented Computing context is being analyzed in order to understand if it could be a good source of inspiration for new challenges and new issues for service-based applications. The deliverable provides some initial thoughts about these challenges and issues. Further analysis and research will be developed in the following of the S-Cube project. Copyright © 2008 by the S-CUBE consortium – All rights reserved. The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/2007-2013] under grant agreement n ° 215483 (S-Cube). File name: PO-JRA-1.1.1Final.docS-CUBE Software Services and Systems Network PO-JRA-1.1.1