11. Especificación

No hay duda de que la forma de especificar tiene mucho que ver con la calidad de la solución. Los
ingenieros de software que se han esforzado en trabajar con especificaciones incompletas,
inconsistentes o mal establecidas han experimentado la frustración y confusión que invariablemente se
produce. Las consecuencias se padecen en la calidad, oportunidad y completitud del software
resultante.
Hemos visto que los requerimientos de software pueden ser analizados de varias formas diferentes. Las
técnicas de análisis pueden conducir a una especificación en papel que contenga las descripciones
graficas y el lenguaje natural de los requerimientos del software. La construcción de prototipos conduce
a una especificación ejecutable, esto es, el prototipo sirve como una representación de los
requerimientos. Los lenguajes de especificación formal conducen a representaciones formales de los
requerimientos que pueden ser verificados o analizados.

12. Principios de Especificación

La especificación, independientemente del modo en que se realice, puede ser vista como un proceso de
representación. Los requerimientos se representan de forma que conduzcan finalmente a una correcta
implementación del software.
Baltzer y Goldman proponen ocho principios para una buena especificación:

PRINCIPIO #1. Separar funcionalidad de implementación.
Primero, por definición, una especificación es una descripción de lo que se desea, en vez de cómo se
realiza (implementa). Las especificaciones pueden adoptar dos formas muy diferentes. La primera forma es la de funciones matemáticas: dado algún conjunto de entrada, producir un conjunto particular de
salida. La forma general de tales especificaciones es encontrar [un/el/todos] resultado tal que P
(entrada), donde P representa un predicado arbitrario. En tales especificaciones, el resultado a ser
obtenido ha sido expresado enteramente en una forma sobre el que (en vez de cómo). En parte, esto es
debido a que el resultado es una función matemática de la entrada (la operación tiene puntos de
comienzo y parada bien definidos) y no esta afectado por el entorno que le rodea.

PRINCIPIO #2. Se necesita un lenguaje de especificación de sistemas orientado al proceso.
Considerar una situación en la que el entorno sea dinámico y sus cambios afecten al comportamiento de
alguna entidad que interactúe con dicho entorno. Su comportamiento no puede ser expresado como una
función matemática de su entrada. En vez de ello, debe emplearse una descripción orientada al proceso,
en la cual la especificación del que se consigue mediante la especificación de un modelo del
comportamiento deseado en términos de respuestas funcionales, a distintos estímulos del entorno.

PRINCIPIO #3. Una especificación debe abarcar el sistema del cual el software es una componente.
Un sistema esta compuesto de componentes que interactúan. Solo dentro del contexto del sistema
completo y de la interacción entre sus partes puede ser definido el comportamiento de una componente
especifica. En general, un sistema puede ser modelado como una colección de objetos pasivos y
activos. Estos objetos están interrelacionados y dichas relaciones entre los objetos cambian con el
tiempo. Estas relaciones dinámicas suministran los estímulos a los cuales los objetos activos, llamados
agentes, responden. Las respuestas pueden causar posteriormente cambios y, por tanto, estímulos
adicionales a los cuales los agentes deben responder.

PRINCIPIO #4. Una especificación debe abarcar el entorno en el que el sistema opera.
Similarmente, el entorno en el que opera el sistema y con el que interactúa debe ser especificado.
Afortunadamente, esto tan solo necesita reconocer que el propio entorno es un sistema compuesto de
objetos que interactúan, pasivos y activos, de los cuales el sistema especificado es una agente, Los
otros agentes, los cuales son por definición inalterables debido a que son parte del entorno, limitan el
ámbito del diseño subsecuente y de la implementación. De hecho, la única diferencia entre el sistema y
su entorno es que el esfuerzo de diseño e implementación subsecuente opera exclusivamente sobre la
especificación del sistema. La especificación del entorno facilita que se especifique la interfaz del
sistema de la misma forma que el propio sistema, en vez de introducir otro formalismo.

PRINCIPIO #5. Una especificación de sistema debe ser un modelo cognitivo.
La especificación de un sistema debe ser un modelo cognitivo, en vez de un modelo de diseño o
implementación. Debe describir un sistema tal como es percibido por su comunidad de usuario. Los
objetivos que manipula deben corresponderse con objetos reales de dicho dominio; los agentes deben
modelar los individuos, organizaciones y equipo de ese dominio; y las acciones que ejecutan deben
modelar lo que realmente ocurre en el dominio. Además, debe ser posible incorporar en la
especificación las reglas o leyes que gobiernan los objetos del dominio. Algunas de estas leyes
proscriben ciertos estados del sistema (tal como “dos objetos no pueden estar en el mismo lugar al
mismo tiempo”), y por tanto limitan el comportamiento de los agentes o indican la necesidad de una
posterior elaboración para prevenir que surjan estos estados.

PRINCIPIO #6. Una especificación debe ser operacional.
La especificación debe ser completa y lo bastante formal para que pueda usarse para determinar si una
implementación propuesta satisface la especificación de pruebas elegidas arbitrariamente. Esto es, dado
el resultado de una implementación sobre algún conjunto arbitrario de datos elegibles, debe ser posible
usar la especificación para validar estos resultados. Esto implica que la especificación, aunque no sea
una especificación completa del como, pueda actuar como un generador de posibles comportamientos,
entre los que debe estar la implementación propuesta. Por tanto, en un sentido extenso, la
especificación debe ser operacional.

PRINCIPIO #7. La especificación del sistema debe ser tolerante con la incompletitud y aumentable.
Ninguna especificación puede ser siempre totalmente completa. El entorno en el que existe es
demasiado complejo para ello. Una especificación es siempre un modelo, una abstracción, de alguna
situación real (o imaginada). Por tanto, será incompleta. Además, al ser formulad existirán muchos
niveles de detalle. La operacionalidad requerida anteriormente no necesita ser completa. Las
herramientas de análisis empleadas para ayudar a los especificadores y para probar las
especificaciones, deben ser capaces de tratar con la incompletitud. Naturalmente esto debilita el
análisis, el cual puede ser ejecutado ampliando el rango de comportamiento aceptables, los cuales
satisfacen la especificación, pero tal degradación debe reflejar los restantes niveles de incertidumbre.

PRINCIPIO #8. Una especificación debe ser localizada y débilmente acoplada.
Los principios anteriores tratan con la especificación como una entidad estática. Esta surge de la
dinámica de la especificación. Debe ser reconocido que aunque el principal propósito de una
especificación sea servir como base para el diseño e implementación de algún sistema, no es un objeto
estático precompuesto, sino un objeto dinámico que sufre considerables modificaciones. Tales
modificaciones se presentan en tres actividades principales: formulación, cuando se está creando una
especificación inicial; desarrollo, cuando la especificación se esta elaborando durante el proceso
iterativo de diseño e implementación; y mantenimiento, cuando la especificación se cambia para reflejar
un entorno modificado y/o requerimientos funcionales adicionales.

13. Metodos de Análisis de Requerimientos

Las metodologías de análisis de requerimientos combinan procedimientos sistemáticos con una notación
única para analizar los dominios de información y funcional de un problema de software; suministra un
conjunto de heurísticas para subdividir el problema y define una forma de representación para las
visiones lógicas y físicas. En esencia, los métodos de análisis de requerimientos del software, facilitan al
ingeniero de software aplicar principios de análisis fundamentales, dentro del contexto de un método
bien definido.
La mayoría de los métodos de análisis de requerimientos son conducidos por la información. Estos es, el
método suministra un mecanismo para representar el dominio de la información. Desde esta
representación, se deriva la función y se desarrollan otras características de los programas.
El papel de los métodos de análisis de requerimientos, es asistir al analista en la construcción de “una
descripción precisa e independiente” del elemento software de un sistema basado en computadora.

14. Metodologías de Análisis de Requerimientos

Las metodologías de análisis de requerimientos facilitan al analista la aplicación de los principios
fundamentales del análisis de una manera sistemática.
Características Comunes
Aunque cada método introduce nueva notación y heurística de análisis, todos los métodos pueden ser
evaluados en el contexto de las siguientes características comunes:
1. Mecanismos para el análisis del dominio de la información
2. Método de representación funcional
3. Definición de interfaces
4. Mecanismos para subdividir el problema
5. Soporte de la abstracción
6. Representación de visiones físicas y lógicas
Aunque el análisis del dominio de la información se conduce de forma diferente en cada metodología,
pueden reconocerse algunas guías comunes. Todos los métodos se enfocan (directa o indirectamente)
al flujo de datos y al contenido o estructura de datos. En la mayoría de los casos el flujo se caracteriza
en el contexto de las transformaciones (funciones) que se aplican para cambiar la entrada en la salida.
El contenido de los datos puede representarse explícitamente usando un mecanismo de diccionario o,
implícitamente, enfocando primero la estructura jerárquica de los datos.
Las funciones se describen normalmente como transformaciones o procesos de la información. Cada
función puede ser representada usando una notación especifica. Una descripción de la función puede
desarrollarse usando el lenguaje natural, un leguaje procedimental con reglas sintácticas informales o un
lenguaje de especificación forma.