Resumen del paper EARS

Alumno: Daniel Canessa Valverde Carnet: 201137483

Es comn encontrarse con compaas que necesitan desarrollo de programas

complejos, de seguridad crtica y con tiempos de desarrollo ms cortos cada vez.

Es comn que cuando las partes que necesitan el software intentan expresar sus

requerimientos lo hacen en un lenguaje natural, sin estructura, esto desemboca

varios problemas de requerimientos como por ejemplo: ambigedad (varios

significados en un requerimiento), imprecisin, complejidad, omisin (especialmente

de requerimientos que manejan comportamientos no deseados), duplicados,

palabrera, implementacin inapropiada, inestabilidad (con requerimientos que no

se pueden probar cuando el sistema es implementado).

Algunos expertos recomiendan el uso de notaciones ms formales para evitar esos

problemas, se pueden destacar notaciones como: Z, Petri Nets, UML, SysML, etc.

Se debe tomar en cuenta que el traslado de los requerimientos resulta complejo y

puede introducir errores adicionales. Adems complicar el entendimiento de las

partes de los requerimientos, por la notacin y agregar un overhead por la

introduccin de algunas notaciones. Hay una hiptesis de que con la introduccin

de un pequeo conjunto de estructuras simples de requerimientos habra una forma

eficiente y prctica para mejorar la escritura de requerimientos de alto nivel de las

partes interesadas.

El caso de estudio que trata el paper es la certificacin de especificacin para

motores de aviacin, basndose en un documento que contiene un nmero

relativamente pequeo de requerimientos complejos y simples, junto con el diseo

y los estados de verificacin e informacin de apoyo. En su mayora los

requerimientos eran explcitos, pero tambin haba algunos implcitos.

Los participantes en la investigacin iniciaron con un conjunto de reglas derivadas

de sus propias experiencias en sistemas, requerimientos de seguridad y de

ingeniera, por ejemplo el uso de "when" para el manejo de eventos, "while" para el

manejo de estados y "if-then" para el manejo de fallos.

El documento se analiz en dos fases, en la primera cada clusula del documento

se dividi en sus partes constituyentes. Los requerimientos obtenidos de las

clausulas se colocaron en una hoja para ayudar a su manipulacin. En la segunda

fase, cada requerimiento se volvi a escribir de una manera coherente provocando

una nueva redaccin de los requerimientos y la reclasificacin de algunas

declaraciones.

La segunda fase utiliz una regla denominada requerimientos genricos que

consista en adoptar una sintaxis genrica para los mismos, esta fue:

el deber

. La estructura separa las condiciones con las cuales el

requerimiento poda ser invocado (precondiciones), el evento que iniciaba el

requerimiento (trigger) y el comportamiento del sistema necesario (la respuesta del

sistema).

La sintaxis de requerimiento genrico, los dividi en cinco tipos:

Requerimiento ubicuo: no tiene condiciones previas o triggers. No se invoca

por un evento del sistema o en respuesta a un estado del sistema definido,

pero est siempre activo. Su forma es: El deber

.

Requerimiento manejado por eventos: se inicia slo cuando se detecta un

evento de activacin en el sistema. When representa la palabra clave de

este tipo de requerimiento. Su forma general es: WHEN el deber .

Comportamiento no deseado: cubre todas las situaciones que no son

deseables: fallos, perturbaciones, desviaciones de la conducta del usuario

deseado y cualquier comportamiento inesperado de los sistemas que

interactan. Son fuente importante de omisiones en los primeros

requerimientos, esto resulta ser costoso. If and Then representan las

palabras clave de este tipo de requerimiento. Su forma general es: If

, Then el

deber .

Requerimiento de manejo por estado: se encuentra activo alguno mientras el

sistema est en un estado definido. While representa la palabra clave de

este tipo de requerimiento. Su forma general es: WHILE el deber .

Caracterstica opcional: se aplica en sistemas que incluyen una caracterstica

particular. Where representa la palabra clave de este tipo de requerimiento.

La forma general de un requerimiento caracterstica opcional es: WHERE

el deber .

Existen tambin requerimientos complejos, que consisten en que en ocasiones

combinaciones de los tipos de requerimientos se pueden dar: When, While, If-Then

y Where produciendo expresiones ms complejas para especificar

comportamientos del sistema. El mismo evento puede activar diferentes

comportamientos del sistema dependiendo del estado del sistema cuando el evento

es detectado.

Los resultados obtenidos con la aplicacin de estos patrones fueron que la mayora

de los requerimientos pueden ser escritos en una de las plantillas con poca

dificultad, con los que no se pudo fueron manipulados para encajar el conjunto de

reglas o se desarroll el conjunto de reglas para incorporar los tipos de

requerimientos adicionales. Con los patrones se logr:

Una reestructuracin lgica para aumentar la claridad y comprensin.

Una reduccin de la palabrera para crear declaraciones simples.

La separacin de los triggers complejos resultando dos o ms requerimientos

atmicos.

Declaraciones y formatos reutilizables.

Los resultados muestran que la notacin modificada tiene un nmero de ventajas

sobre el uso sin restricciones del lenguaje natural. Con la implementacin de las

plantillas de requerimientos, los ocho tipos de problemas se redujeron. Se

solventaron los problemas de complejidad, duplicados, ejecucin e inestabilidad. Es

importante que los problemas de omisiones sean tratados con cuidado, ya que

aunque se apliquen los patrones antes vistos, no se puede asegurar que algn

requerimiento no haga falta. Por otro lado los problemas de ambigedad, vaguedad

y palabrera se redujeron.

En sntesis:

Cul es la problemtica?

La dificultad de obtener requerimientos de calidad derivndolos de lo expresado en

lenguaje natural por las partes y la complejidad de expresar los requerimientos en

algn lenguaje formal.

Cul es la solucin?

Se concluy que los requerimientos se podan agrupar en 5 tipos, para cada tipo se

desarroll una sintaxis y por medio de la misma se redact cada requerimiento, esto

permiti desarrollar requerimientos que aumentaron su calidad y disminuyeron

notoriamente los problemas que presentaban.