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:
<precondiciones opcionales> <trigger opcional> el <nombre del sistema> deber
<respuesta del sistema>. 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 <nombre del sistema> deber
<respuesta del sistema>.
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 <precondiciones
opcionales> <trigger> el <nombre del sistema> deber <respuesta del
sistema>.
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
<precondiciones opcionales> <trigger>, Then el <nombre del sistema>
deber <respuesta del sistema>.
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 <est en un estado
especfico> el <nombre del sistema> deber <respuesta del sistema>.
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
<caracterstica es incluida> el <nombre del sistema> deber <respuesta del
sistema>.

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.