Using scenarios to systematically support goal-directed elaboration for information system requirements

Kavakli, Evangelia; Loucopoulos, Pericles; Filippidou, D

doi:10.1109/ecbs.1996.494543

Cited by 13 publications

(5 citation statements)

References 19 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Another important line of work concerns the integration of goal-driven method fragments to other non-goal-oriented approaches. Indeed, the ability to represent goal-driven methods in a modular way enables their treatment as reusable components that can be deployed in a variety of contexts, including agentbased approaches [36], or scenario-based approaches [24,[37][38][39][40].…”

Section: Conclusion and Further Workmentioning

confidence: 99%

Goal-Oriented Requirements Engineering: A Unifying Framework

Kavakli

2002

Requirements Eng

View full text Add to dashboard Cite

The study of contemporary requirements engineering (RE) methodologies indicates that modelling of organisational goals constitutes a central activity of the RE process. In particular, goals provide the rationale and drive the elaboration of the requirements that operationalise them. They also provide the criteria against which the completeness and correctness of the requirements specification is validated. In other words, requirements implement goals in the same way that programs implement design specifications. Despite the significance of goals in RE, research in the field is fragmented. No research has so far taken place in order to define the overall role that goals play in RE. This paper puts forward a unifying view of goal analysis in the context of RE. This allows the identification of similarities and differences between the different conceptions of goal used by different approaches and promotes the understanding of the overall role of goal analysis in RE. Based on this understanding the various approaches can be put together, thus leading to a stronger goal-driven RE framework that takes advantage of the contributions from the many streams of goaloriented research.

show abstract

Section: Conclusion and Further Workmentioning

confidence: 99%

Goal-Oriented Requirements Engineering: A Unifying Framework

Kavakli

2002

Requirements Eng

View full text Add to dashboard Cite

show abstract

“…Dichas inconsistencias se validan y se depuran para contar con un Discurso de Usuario Refinado (DUR). Estas inconsistencias se ponen de manifiesto en el DU como consecuencia de un lógico "grado de subjetividad" que, muy probablemente, siempre esté presente en el relato del usuario, y que por lo tanto, se ven reflejadas en los EU [3], [20], [46], [47].…”

Section: B) Técnica De Refinamiento Del Diagrama De Escenarios De Usuunclassified

Modelo de Proceso de Conceptualización de Requisitos

Hossian¹

2014

Revista Latinoamericana De Ingenieria De Software

View full text Add to dashboard Cite

Resumen -El proceso de captura de requisitos constituye un proceso con connotaciones sociales relacionadas con diferentes personas (stakeholders), una circunstancia que hace que se presenten ciertos problemas cuando se lleva adelante la conceptualización de requisitos. En este trabajo se propone un Proceso de Conceptualización de Requisitos que se estructura en dos fases: (a) Análisis Orientado a al Problema: cuyo objetivo es comprender el problema dado por el usuario en el dominio en el que este se lleva a cabo, y (b) Análisis de Orientado al Producto: cuyo objetivo es obtener las funcionalidades que el usuario espera del producto de software a desarrollar, teniendo en cuenta la relación de estas con la realidad expresada por el usuario en su discurso. Se proponen seis técnicas que articulan cada una de las tareas que componen las fases de proceso propuesto.Palabras Clave -Proceso de captura de requisitos, conceptualización de requisitos, proceso de conceptualización de requisitos, análisis orientado a al problema, análisis de orientado al producto, técnicas de modelado. I. INTRODUCCIONEn estadios tempranos de la Ingeniería de Requerimientos, Alford [1], Yeh y Zave [2] y Davis [3] identificaron la necesidad de obtener una representación intermedia de la información obtenida -conceptualización de los requisitos -, facilitando de esta manera una captura adecuada del problema a resolver por parte del profesional de ingeniería de software antes de pasar a la construcción de los modelos conceptuales, habida cuenta de que una correcta construcción de estos modelos es fundamental para el éxito en el desarrollo del proyecto software, mientras que su incorrección puede perjudicar seriamente a las organizaciones implicadas [4].Asimismo cabe señalar, que la escasa existencia de trabajos referidos a la elaboración de representaciones intermedias de los caudales de información obtenidos a lo largo de la actividad de educción, tendientes a una búsqueda de reducción de la complejidad de la realidad y su problemática expresada por el cliente y/o usuario en su discurso, agravan aún más este problema.En este sentido y en lo que se refiere a la gestión de requisitos en el campo de los sistemas de información, se pueden citar algunos principios fundamentales de estructuración de la información -"Partición, Abstracción y Proyección" -, los cuáles proporcionan una estructura de conocimiento a fin de contribuir a una visión simplificada de la realidad y su problemática [5]. Los elementos que suelen utilizarse para este análisis de problemas son los objetos, las funciones y los estados, pudiendo éstos describirse en múltiples niveles de detalle. Dado que hay tantas relaciones que pueden existir entre todos los elementos, se hace necesario disponer de una estructura de conocimiento (colección estructurada de conceptos y sus interrelaciones) que permita la captura estas relaciones.A partir de la partición, es posible capturar la relación estructural "agregación/parte de" entre objetos, funciones o estados en el dominio del problema. A p...

show abstract

“…The Weld of goal based requirements engineering (see [1,3,11]) is focused on the elicitation of goals intended to become requirements at some point, i.e., working from the top down. For example, Wiegers [24] and Lauesen [14] describe that requirements can be of diVerent types pertaining to what they should be used for.…”

Section: Related Workmentioning

confidence: 99%