Abstract. Requirements evolution is a main driver for systems evolution. Traditionally, requirements evolution is associated to changes in the users' needs and environments. In this paper, we explore another cause for requirements evolution: assumptions. Requirements engineers often make assumptions stating, for example, that satisfying certain sub-requirements and/or correctly executing certain system functionalities would lead to reach a certain requirement. However, assumptions might be, or eventually become, invalid. We outline an approach to monitor, at runtime, the assumptions in a requirements model and to evolve the model to reflect the validity level of such assumptions. We introduce two types of requirements evolution: autonomic (which evolves the priorities of system alternatives based on their success/failure in meeting requirements) and designersupported (which detects loci in the requirements model containing invalid assumptions and recommends designers to take evolutionary actions).

Recently, there has been a growing interest in self-adaptive systems. Roadmap papers in this area point to feedback loops as a promising way of operationalizing adaptivity in such systems. In this paper, we define a new type of requirement -called Awareness Requirement -that can refer to other requirements and their success/failures. We propose a way to elicit and formalize such requirements and offer a requirements monitoring framework to support them.

No abstract

No abstract

The use of Requirements at Runtime (RRT) is an emerging research area. Many methods and frameworks that make use of requirements models during software execution can be found in the literature. However, there is still a lack of a formal and explicit representation of what RRT are and what are the primary goals of their use. Still, most RRT proposals have their own modeling languages and ways to represent, specify and make use of requirements at runtime, thus resulting in a domain with overloaded concepts. In this paper, we intend to clarify the main notions involved in RRT, establishing an explicit common conceptualization regarding this domain. To do so, we need first to understand what software execution is, as well as what requirements are. Thus, we present three related domain ontologies: the Software Ontology (SwO), an ontology about software nature and execution, the Reference Software Requirements Ontology (RSRO), which addresses what requirements are and types of requirements, and the Runtime Requirements Ontology (RRO), which extends SwO and RSRO to represent the nature and context of RRT. For developing these ontologies, we follow SABiO, a well-established Ontology Engineering method. Moreover, all the three ontologies are grounded in the Unified Foundational Ontology (UFO) and are integrated into the Software Engineering Ontology Network (SEON). Finally, as prescribed by SABiO, the ontologies are evaluated using ontology verification and validation techniques.