The Requirements Apprentice: automated assistance for requirements acquisition

Reubenstein, Howard; Waters, Richard C.

doi:10.1109/32.75413

Cited by 197 publications

(76 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…In the area of software engineering, in particular software reuse, domain abstractions have been utilized in several forms, e.g. clichés [Reubenstein91], reusable patterns [Biggerstaff87], generalised application frames [Constantopoulos92], and analysis patterns [Fowler97]. We believe that an important class of domain abstractions is the one consisting of schemas for communicative structures, and that a language with deontic and illocutionary constructs is adequate for describing such domain abstractions.…”

Section: Discussionmentioning

confidence: 99%

Modelling agent communication in a first order logic

Johannesson

Wohed

1998

Accounting, Management and Information Technologies

View full text Add to dashboard Cite

In the design of information systems, the notion of agent has proven useful. When modelling communication among agents, deontic concepts, such as obligations, permissions, and prohibitions are essential. The dynamics of obligations, i.e., how obligations are created and destroyed, can effectively be described by means of notions from speech act theory. In this paper, we present a language that includes deontic and illocutionary constructs for the modelling of communication between agents. The language is a logic programming language, which gives it a simple semantics and makes it executable. A distinguishing feature of the language is that it is able to represent time explicitly, which is required to give an adequate semantics for deontic constructs.

show abstract

Section: Discussionmentioning

confidence: 99%

Modelling agent communication in a first order logic

Johannesson

Wohed

1998

Accounting, Management and Information Technologies

View full text Add to dashboard Cite

show abstract

“…This support can either be explicit and through specific requirements traceability components in the workbench (e.g., a Coupling Module in AGE [Keys 1991]), or implicit from having carried out other activities using the workbench tools (e.g., the Requirements Apprentice [Reubenstein & Waters 1991]). CASE workbenches which accept requirements documents as a starting point, from which to drive design and implementation, commonly provide coarse-grained requirements traceability between requirements and their realisation in subsequent phases.…”

Section: Workbenchesmentioning

confidence: 99%

An analysis of the requirements traceability problem

Gotel

Finkelstein

Proceedings of IEEE International Conference on Requirements Engineering

799

533

View full text Add to dashboard Cite

In this paper, we investigate and discuss the underlying nature of the requirements traceability problem. Our work is based on empirical studies carried out with over a hundred practitioners and an evaluation of current support for requirements traceability. We introduce the distinction between pre-requirements specification traceability and post-requirements specification traceability, to demonstrate why an all-encompassing solution to the problem is unlikely, and to provide a framework through which to understand its multifaceted nature. We report how the majority of the problems attributed to poor requirements traceability are mainly due to the lack of (or inadequate) pre-RS traceability and explain the fundamental need for improvements here. In the remainder of the paper, we present an analysis of the main barriers confronting such improvements in practice, identify relevant areas in which advances have been (or can be) made, and make recommendations for further research.

show abstract

“…§ Generar casos de prueba y oráculos desde la especificación [38][39]. § Soportar la reutilización formal de los componentes mediante la especificación correspondiente [40][41]. § Ser la base para la ingeniería inversa y para la evolución del software desde el código [42].…”

Section: Ventajas De La Formalizaciónunclassified

La especificación formal en contexto: actual y futuro

A²

2014

Ingeniare. Rev. chil. ing.

View full text Add to dashboard Cite

RESUMENLa especificación formal es un área de investigación activa en la ingeniería de software de este siglo, en la que se aplica en diversas configuraciones y técnicas, y aunque su uso industrial todavía es limitado, la comunidad científica tiene actualmente una comprensión diferente acerca de su utilidad y necesidad. Hasta el momento el trabajo de los investigadores se focaliza en la especificación escrita durante el diseño del modelo funcional preliminar, por lo que se centra principalmente en evaluar las herramientas relacionadas. En este trabajo se realiza una revisión a la literatura, se hace un recorrido por la esencia, la función, el uso y los inconvenientes de las técnicas de especificación formal y se analizan algunos criterios de valoración y de evaluación a sus debilidades. Los resultados se convierten en la base para formular trabajos futuros, con el objetivo de buscar que la especificación formal se afiance como actividad básica de investigación.Palabras clave: Técnicas formales, especificación formal, métodos formales, ciencias computacionales, ingeniería de software. ABSTRACT

show abstract

The Requirements Apprentice: automated assistance for requirements acquisition

Cited by 197 publications

References 23 publications

Modelling agent communication in a first order logic

Modelling agent communication in a first order logic

An analysis of the requirements traceability problem

La especificación formal en contexto: actual y futuro

Contact Info

Product

Resources

About