DOCUMENTOS PARA ESPECIFICACIÓN FORMAL DE REQUISITOS

La Especificación de Requisitos Software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso  que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales . Además de los casos de uso, la ERS también contiene requisitos no funcionales  (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación (Como por ejemplo restricciones en el diseño o estándares de calidad).

Hay muchas técnicas para extraer información útil de documentos escritos en un lenguaje natural que nos permiten construir documentos más precisos y formales, los cuales expresan los requerimientos del sistema de manera menos ambigua. Algunas de estas técnicas incluyen la creación de los casos de uso del sistema. Un caso de uso es una secuencia de acciones que proveen una cierta funcionalidad a un actor del sistema. Un caso de uso describe una manera en la cual un actor del mundo real interactúa con el sistema. Cada una de estas formas de interacción es un evento al cual el sistema deberá dar una respuesta. Podemos entonces establecer una correspondencia entre los casos de uso del sistema y una lista de eventos del sistema.Por otro lado, sabemos de los beneficios de contar con especificaciones formales en las primeras etapas de desarrollo del sistema. Nuestro trabajo consiste en desarrollar una técnica para obtener a partir de un conjunto de casos de uso, bajo la forma de lista de eventos, a una especificación formal inicial escrita en RSL (the RAISE Specification Language) [RLG92, RLM95], consistente en signaturas de funciones de más alto nivel del sistema y tipos expresados como sorts. Cabe destacar que la misma técnica puede ser aplicada para cada caso de uso, para de esta manera derivar no sólo las signaturas sino también el cuerpo de las funciones de más alto nivel del sistema.

En la práctica es común describir los requerimientos en un documentollamado Especificación de Requerimientos del Software (SRS -Software Requirements Specification).

¿Para qué sirve un SRS?

• Comunicar de manera precisa los requerimientos, objetivos y presunciones del dominio

• Contrato

– legal, documento interno o a modo de memorando

• Base para estimación (tamaño, costo, tiempo) y planificación de proyecto

• Base para evaluación de producto final

– verificación y validación

– Debería tener suficiente información para decidir si el producto final es aceptable

(satisface los requerimientos)

• Base para el control de cambios

– Requerimientos cambian, software evoluciona, el entorno evoluciona.

Lectores de un SRS

• Clientes y Usuarios

– Interesados en validar objetivos del sistema y descripción de alto nivel de la funcionalidad

– Generalmente no interesados en los requerimientos detallados del sistema.

• Analistas (de sistemas, de requerimientos),

– Escribirán especificaciones de otros sistemas que interactúan con este.

– El SRS sirve mas allá de la puesta en producción!

• Desarrolladores (ej. arquitectos, diseñadores,programadores, ...)

– Deben implementar los requerimientos

• Testers (V&V’ers)

– Deben determinar la satisfacción de los requerimientos

• Gerentes

– Medir y controlar el proceso desarrollo