The tutorial provides a comprehensive survey of information quality issues in the general domain of information systems that encompass data of heterogeneous type. It will introduce the general theme and provide a detailed discussion on motivations for addressing the area of Data, Information and Image Quality (in brief DI2Q), both in research and real-life applications. The tutorial will also propose and discuss a general and unified framework that can help researchers and practitioners keep track of the quality factors involved in the management of heterogeneous types of electronic information distributed in multimedia resources. Then, for each relevant type of information, the tutorial will define and characterize the most used specific dimensions: intrinsic soundness, context-dependent usability and time-related dimensions. For each of these DI2Q dimensions, the tutorial will also discuss the main quality assessment methods and the related metrics. Finally, significant examples related to real life cases will be discussed, and open research problems will be addressed.

This tutorial will provide an overview of techniques for problem-driven requirements engineering. Starting point is the standard model of requirements engineering in which a solution, such as a software system, interacts with an environment in order to achieve stakeholder goals. Solution-oriented requirements consist of a specification of solution properties, usually divided into a specification of functional and nonfunctional properties. Problem-oriented requirements consist of a specification of the environment and stakeholder goals, and of the way in which the solution must interact with the environment in order to achieve these goals. The tutorial will review the role of problem-oriented requirements engineering in systems engineering, show how to define and analyze problem structures, and review ways in which goal analysis and problem diagnosis can be used to justify solution specifications. We illustrate goal analysis by using techniques from well-known methods such as KAOS, i* and Tropos, and we illustrate problem diagnosis by using techniques from causal loop modeling. We also show which role classical conceptual modeling techniques play in modeling problem structures.

Domain models capture the common knowledge gained while developing applications in the domain as well as the possible variability allowed among them. Hence, domain models may assist in the creation of valid applications, improving productivity and software quality and reducing the domain and development expertise needed. However, the creation of such domain models is not a trivial task: it requires expertise in the domain, reaching a very high level of abstraction, and providing flexible, yet formal, artifacts. The field of domain engineering (also known as product line engineering) aims at identifying, modeling, constructing, cataloging, and disseminating the commonalities and differences among applications in a specific domain. Several domain engineering methods have been proposed over the years, but most of them can be criticized as making the domain engineer the only responsible for the development of domain models and artifacts. Since domains may cover broad areas and are usually understood only during the development process, some aids are required to help domain engineers perform their modeling tasks. The purpose of this tutorial is to answer the question "can domain modeling become automatic?" In particular, we will present and discuss domain modeling concepts, methods, problems, and solutions, where the focus will be on automating these issues.

The success of your work in (re) designing and (re) engineering business processes heavily depends on the profundity of your understanding of these processes. Unfortunately, the kind of understanding you need cannot be drawn from the rich sources of the organizational and management sciences because of their predominant functional orientation. Functional knowledge is sufficient (and necessary) if you only need to use or control an organization, like you use the car you are driving in. But your task is to change the business processes or to improve their efficiency by applying information and communication technology. To do so, you need knowledge of the construction and the operation of organizations, like a car mechanic needs to know how a car is constructed and how it operates. But even if you take the constructional perspective, the complexity of the problems you are faced with and the high pressure on timely delivery of high quality solutions makes that you cannot come off any longer with drawing informal and/or too detailed process diagrams as a basis for re-design and re-engineering. Doing your work in a professional way requires a solid scientific methodology. In this tutorial you will learn how the DEMO methodology (Design and Engineering Methodology for Organizations) reveals the deep essential structure of business processes. Business processes need not be mind-boggling railroad yards; they can be crystal structures of ‘atoms’ and ‘molecules’. The question only is how to reveal these structures, how to extract them from the observable surface structures that blur the sight on them.