Formal specification comprehension: the art of reading and writing z

Abstract

Formal Methods have been developed to provide systematic and rigorous techniques for software development. They found their place in document-driven development processes as well as in the agile world. However, reading, understanding and working with a formal specification still turns out to be a real challenge.This paper tries to identify the underlying cause and argues that comprehensibility of a specification is one of the key factors. It presents some first findings of an extensive study investigating the readability of Z specifications and comes up with a set of recommendations in writing formal specifications so that the syntactic gap between the mathematics and the natural language requirements description can be bridged more easily.

Process and progress of requirement formalization in Software Engineering

“…But, formal specifications are not documents that are writing once and generally not achieved at the beginning of the software development process. It needs time to create a first useful version that, after a lot of effort and reviews, allows develop a close specification to needs that clients have in mind [17] and Bollin and Raunner [35] argue that a good level of comprehension is a key matter as a quality attribute. To Wolf [36], using formal specification language, the system can be described with precision as soon as its functionality, concurrence, integrity, accuracy, … These means system properties can be analyzed without having to really run it.…”

“…Specification errors can be reduced drastically through the use of formal methods and, in consequence, the software engineer can create a specification more complete, coherent and unequivocal with conventional methods [20,38]. For they part, Bollin and Rauner [35] manifest that a good formal specification is syntactically and semantically correct, that allows a mapping without losses among all the specification concepts and the mental model of the specified system; also add that must be complete, coherent and proper and have into account that facility comprehension is an essential requirement to decide about its semantic correction.…”

“…Bollin and Rauner [35] Shows a series of recommendations to perform formal specifications, and identify that software reading facility of a specification is a factor to improve the software quality.…”

Proceso y evolución de los métodos formales en la ingeniería de requisitos

“…Pero las especificaciones formales no son documentos que se escriben una vez, y por lo general no se logran al principio del proceso de desarrollo de software. Se necesita tiempo para crear una primera versión de utilidad que, luego de mucho esfuerzo y revisiones, permita desarrollar una especificación cercana a las necesidades que los clientes tienen en mente [19]; al respecto, Bollin y Rauner [20] sostienen que un buen nivel de comprensión es una cuestión clave como atributo de calidad. Para Wolf [21], si se hace uso de un lenguaje de especificación formal, el sistema puede ser descrito con precisión en cuanto a funcionalidad, concurrencia, integridad y exactitud.…”

“…Serna y Serna [17] realizan una revisión de la literatura, hacen un recorrido por la esencia, la función, el uso y los inconvenientes de las técnicas de especificación formal, y analizan criterios de valoración y evaluación a sus debilidades. De igual manera, Bollin y Rauner-Reithmayer [20] muestran una serie de recomendaciones para realizar especificaciones formales, e identifican que la facilidad de lectura de una especificación es un factor clave para mejorar la calidad del software. [9] aplican gramática formal con anotaciones semánticas para formalizar requisitos, de tal forma que puedan ser analizados y procesados por el computador.…”