An Analysis-Revision Cycle to Evolve Requirements Specifications by Using the SCTL-MUS Methodology

Authors:
Jorge García-Duque;José J. Pazos-Arias;Ana Belén Barragáns-Martínez
Affiliations:
-;-;-
Venue:
RE '02 Proceedings of the 10th Anniversary IEEE Joint International Conference on Requirements Engineering
Year:
2002

Citing 0
Cited 6

Eliciting requirements and scenarios using the SCTL-MUS methodology: the shuttle system case study

SCESM '05 Proceedings of the fourth international workshop on Scenarios and state machines: models, algorithms and tools
Formal support for merging and negotiation

Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering
Formal specification applied to multiuser distributed services: experiences in collaborative t-learning

Journal of Systems and Software
On the interplay between inconsistency and incompleteness in multi-perspective requirements specifications

Information and Software Technology
Tracing integration analysis in component-based formal specifications

FMOODS'05 Proceedings of the 7th IFIP WG 6.1 international conference on Formal Methods for Open Object-Based Distributed Systems
Managing ad-hoc networks through the formal specification of service requirements

COORDINATION'06 Proceedings of the 8th international conference on Coordination Models and Languages

Quantified Score

Hi-index	0.00

Visualization

Abstract

The development of requirements specifications can be supported by a cycle composed of two phases: analysis and revision. In this paper, we use the SCTL-MUS methodology to bridge the gap between these two phases. Analysis phase provides diagnostic information if a desirable property is not satisfied by the current system specification. A crucial aspect of the analysis-revision cycle is how to use the diagnostic information provided to generate alternative system refinements which can be included in the system specification to satisfy the property in question (revision phase). Our approach allows translating the diagnostic information into system requirements refinements closed to the system domain. It facilitates to the stakeholders the decision of what system requirements refinements must be included in the system requirements specification.