www.utdallas.edu/~chung/, www.inf.puc-rio.br/~julio Abstract. Essentially a software system’s utility is determined by both its functionality and its non-functional characteristics, such as usability, flexibility, performance, interoperability and security. Nonetheless, there has been a lop-sided emphasis in the functionality of the software, even though the functionality is not useful or usable without the necessary non-functional characteristics. In this chapter, we review the state of the art on the treatment of non-functional requirements (hereafter, NFRs), while providing some prospects for future directions.

Abstract Context-aware applications monitor changes in their operating environment and switch their behaviour to keep satisfying their requirements. Therefore, they must be equipped with the capability to detect variations in their operating context and to switch behaviour in response to such variations. However, specifying monitoring and switching in such applications can be difficult due to their dependence on varying contextual properties which need to be made explicit. In this paper, we present a problemoriented approach to represent and reason about contextual variability and assess its impact on requirements; to elicit and specify concerns facing monitors and switchers, such as initialisation and interference; and to specify monitoring and switching behaviours that can detect changes and adapt in response. We illustrate our approach by applying it to a published case study.

Goal models are effective in capturing stakeholder needs at the time when features of the system-to-be have not yet been conceptualized. Relating goals to solution-oriented features gives rise to a requirement traceability problem. In this paper, we present a new model-driven extension to an Early Requirements Engineering tool (OpenOME) that generates an initial feature model of the systemto-be from stakeholder goals. Enabled by such generative mapping, configuration constraints among variability features can be obtained by reasoning about stakeholder goals.

Abstract. Self-contextualizability refers to the system ability to autonomously adapt its behaviour to context in order to maintain its objectives satisfied. In this paper, we propose a modeling framework to deal with self-contextualizability at the requirements level. We use Tropos goal models to express requirements; we provide constructs to analyse and represent context at each variation point of the goal model; and we exploit the goal and context analysis to define how the system satisfies its requirements in different contexts. Tropos goal analysis provides constructs to hierarchically analyse goals and discover alternative sets of tasks the system can execute to satisfy goals; our framework extends Tropos goal model by considering context at its variation points, and provides constructs to hierarchically analyse context and discover alternative sets of facts the system has to monitor to verify a context. A self-contextualizable promotion information system scenario is used to illustrate our approach. Key words: GORE, Context Analysis, Self-Contextualization 1

Abstract. The continuous growth of interest in mobile applications makes the concept of location essential to design and develop software systems. Location-based software is supposed to be able to monitor the surrounding location and choose accordingly the most appropriate behavior. In this paper, we propose a novel conceptual framework to model and analyze location-based software. We mainly focus on the social facets of locations adopting concepts such as actor, resource, and location-based behavior. Our approach is based on Tropos methodology and allows the analyst to elicit and model software requirements according to the different locations where the software will operate. We propose an extension of Tropos modeling and adapt its process to suit well with the development of location-based software. The proposed framework also includes automated analysis techniques to reason about the relation between location and location-based software. 1

Abstract. The success of a business process (BP) depends on whether it meets its business goal as well as non-functional requirements associated with it. BP specifications frequently need to accommodate changing business priorities, varying client preferences, etc. However, since business process goals and preferences are rarely captured explicitly in the dominant BP modeling approaches, adapting business processes proves difficult. We propose a systematic requirements-driven approach for BP design and configuration management that uses requirements goal models to capture alternative process configurations and provides the ability to tailor deployed processes to changing business priorities or customer preferences (i.e., non-functional constraints) by configuring their corresponding goal models at the goal level. A set of design time and runtime tools for configuring business processes implemented using WS-BPEL is provided, allowing to easily change the behaviour of deployed BP instances at a high level, based on business priorities and stakeholder preferences. 1

Abstract. Advances in size, power, and ubiquity of computing technology, sensors, and communication technology made possible the development of so-called mobile or nomadic information systems. A mobile information system has the potential to autonomously change its behaviour according to different location settings. Variability of location and system behaviour is a central feature of such new generation of information systems. This paper stresses the importance of modeling and analyzing variability of location as a basis for variability of software. We describe graphical and formal techniques to model location information, show their usage in conjunction with the goal-oriented framework i*/Tropos, and propose three analysis techniques on location-based goal models.

Abstract. Advances in size, power, and ubiquity of computing, sensors, and communication technology made possible the development of mobile or nomadic information systems. Variability of location and system behavior is a central issue in mobile information systems, where behavior of software has to change and re-adapt to the different location settings. This paper concerns modeling and analysis of the complementary relation between software and location variability. We use graphical and formal location modeling techniques, show how to elicit and use location model in conjunction with Tropos goal-oriented framework, and introduce automated analysis on the location-based models. 1

Abstract. Various characteristics of the problem domain define the context in which the system is to operate and thus impact heavily on its requirements. However, most requirements specifications do not consider contextual properties and few modeling notations explicitly specify how domain variability affects the requirements. In this paper, we propose an approach for using contexts to model domain variability in goal models. We discuss the modeling of contexts, the specification of their effects on system goals, and the analysis of goal models with contextual variability. The approach is illustrated with a case study. 1

Abstract—Requirements can differ in their importance. As such the priorities that stakeholders associate with requirements may vary from stakeholder to stakeholder and from one situation to the next. Differing priorities, in turn, imply different design decisions for the end system. While elicitation of requirements priorities is a well studied activity, though, the modeling and reasoning side of prioritization has not enjoyed equal attention. In this paper, we address this by extending a traditional goal modeling notation to support the representation of optional and preference requirements. In our extension, optional goals are distinguished from mandatory ones. Then, quantitative prioritizations of the former are constructed and used as criteria for evaluating alternative ways to achieve the latter. A state-of-the-art preference-based planner is utilized to efficiently search for alternatives that best satisfy the given preferences. This way, analysts can acquire a better understanding of the impact of high-level stakeholder preferences to low-level design decisions. Keywords-requirements engineering, preferences, variability