Requirements monitoring in dynamic environments

Fickas, Stephen; Feather, Martin S.

doi:10.1109/isre.1995.512555

Cited by 204 publications

(161 citation statements)

References 5 publications

Supporting

Mentioning

160

Contrasting

Order By: Relevance

“…The primary difference between the related work above [24][25][26] and ours is that we monitor problem variations in addition to requirements. This requires us to explicitly represent the core requirements R, the problem contexts, the specifications and the relevant concerns that might not be apparent in considering the requirements alone.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Specifying Monitoring and Switching Problems in Context

Salifu

Nuseibeh

2007

15th IEEE International Requirements Engineering Conference (RE 2007)

View full text Add to dashboard Cite

Section: Related Workmentioning

confidence: 99%

“…The need to monitor application software's operating environment to assess the continual satisfaction of requirements was recognised by Fickas and Feather [24]. The primary focus of their work is on assumptions about the operating environment whose failure is likely to invalidate the requirements.…”

Section: Related Workmentioning

confidence: 99%

Specifying Monitoring and Switching Problems in Context

Salifu

Nuseibeh

2007

15th IEEE International Requirements Engineering Conference (RE 2007)

View full text Add to dashboard Cite

“…Requirements monitoring adds specific code to a running system to gather information, mainly about the computational performance, and reason if the running system is always meeting its design objectives, and reconcile the system behaviour to them if a deviation occurs [8]. The objective is to have more robust, maintainable, and self-evolving systems.…”

Section: Related Workmentioning

confidence: 99%

“…Goal models have been used to represent the rationale of both humans and software systems [7] and they provide useful constructs to analyse high level requirements (goals) and discover ways to satisfy them. Such features are essential for the analysis and design of a software system that reflects the stakeholders' rationale and their adaptation to a dynamic sys-tem environment [8,9]. Moreover, goal models help to identify alternative software functionalities to satisfy goals.…”

Section: Introductionmentioning

confidence: 99%

Requirements-driven deployment

2012

View full text Add to dashboard Cite

Deployment is a main development phase which configures a software to be ready for use in a certain environment. The ultimate goal of deployment is to enable users to achieve their requirements while using the deployed software. However, requirements are not uniform and differ between deployment environments. In one environment, certain requirements could be useless or redundant, thereby making some software functionalities superfluous. In another environment, instead, some requirements could be impossible to achieve and, thus, additional functionalities would be required. We advocate that ensuring fitness between requirements and the system environment is a basic and critical step to achieve a comprehensive deployment process. We propose a tool-supported modelling and analysis approach to tailor a requirements model to each environment in which the system is to be deployed. We study the case of contextual goal model, which is a requirements model that captures the relationship between the variability of requirements (goal variability space) and the varying states of a deployment environment (context variability space). Our analysis relies on sampling a deployment environment to discover its context variability space and use it to identify loci in the contextual goal model where a modification has to take place. Finally, we apply our approach in practice and report on the obtained results.

show abstract

“…This process is enacted by jointly anticipating deviations at specification time and solving unpredicted situations at runtime, and examine the latter option using the requirements monitoring framework FLEA [16]. FLEA is used in conjunction with the goal-driven specification methodology KAOS [3].…”

Section: Related Workmentioning

confidence: 99%

An Architecture for Requirements-Driven Self-reconfiguration

Dalpiaz

Giorgini

Mylopoulos

2009

Notes on Numerical Fluid Mechanics and Multidisciplinary Design

View full text Add to dashboard Cite

Abstract. Self-reconfiguration is the capability of a system to autonomously switch from one configuration to a better one in response to failure or context change. There is growing demand for software systems able to self-reconfigure, and specifically systems that can fulfill their requirements in dynamic environments. We propose a conceptual architecture that provides systems with selfreconfiguration capabilities, enacting a model-based adaptation process based on requirements models. We describe the logical view on our architecture for selfreconfiguration, then we detail the main mechanisms to monitor for and diagnose failures. We present a case study where a self-reconfiguring system assists a patient perform daily tasks, such as getting breakfast, within her home. The challenge for the system is to fulfill its mission regardless of the context, also to compensate for failures caused by patient inaction or other omissions in the environment of the system.

show abstract

Requirements monitoring in dynamic environments

Cited by 204 publications

References 5 publications

Specifying Monitoring and Switching Problems in Context

Specifying Monitoring and Switching Problems in Context

Requirements-driven deployment

An Architecture for Requirements-Driven Self-reconfiguration

Contact Info

Product

Resources

About