4.

3 Modelado de los requisitos

1. Una condicin o necesidad de un usuario para resolver un problema o
alcanzar un objetivo.
2. Una condicin o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estndar,
especificacin u otro documento formal.
3. Qu son Requerimientos?

Normalmente, un tema de la Ingeniera de Software tiene diferentes

significados. De las muchas definiciones que existen para requerimiento, ha
continuacin se presenta la definicin que aparece en el glosario de la
IEEE.

(1) Una condicin o necesidad de un usuario para resolver un problema o

alcanzar un objetivo. (2) Una condicin o capacidad que debe estar
presente en un sistema o componentes de sistema para satisfacer un
contrato, estndar, especificacin u otro documento formal. (3) Una
representacin documentada de una condicin o capacidad como en (1) o
(2).

Los requerimientos puedes dividirse en requerimientos funcionales y

requerimientos no funcionales. Los requerimientos funcionales definen las
funciones que el sistema ser capaz de realizar. Describen las
transformaciones que el sistema realiza sobre las entradas para producir
salidas.
Los requerimientos no funcionales tienen que ver con caractersticas que de
una u otra forma puedan limitar el sistema, como por ejemplo, el
rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad
(robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad,
portabilidad, estndares, etc.

Caractersticas de los requerimientos

Las caractersticas de un requerimiento son sus propiedades principales.
Un conjunto de requerimientos en estado de madurez, deben presentar una
serie de caractersticas tanto individualmente como en grupo. A
continuacin se presentan las ms importantes:

Necesario: Un requerimiento es necesario si su omisin provoca una

deficiencia en el sistema a construir, y adems su capacidad,
caractersticas fsicas o factor de calidad no pueden ser reemplazados por
otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su
redaccin debe ser simple y clara para aquellos que vayan a consultarlo en
un futuro.
Completo: Un requerimiento est completo si no necesita ampliar detalles
 en su redaccin, es decir, si se proporciona la informacin suficiente para
su comprensin.
Consistente: Un requerimiento es consistente si no es contradictorio con
otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretacin.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado
de manera que permita hacer uso de los siguientes mtodos de verificacin:
inspeccin, anlisis, demostracin o pruebas.

Una vez establecido el contexto del sistema:

_ Considerar el comportamiento del sistema que cada actor espera o requiere
Que ste proporcione:
_ Cules son las principales tareas de cada actor?
_ Tendr el actor que leer/escribir/cambiar informacin del sistema?
_ Tendr el actor que notificar al sistema de los cambios externos que se
produzcan?
_ Desea el actor ser informado de cambios no esperados?
_ Cada comportamiento distinto e identificable del sistema es un caso de uso.
_ Factorizar el comportamiento comn y el comportamiento variante.
_ Introducir esos casos de uso y relaciones en el diagrama de casos de uso.
_ Adornar esos casos de uso con notas que enuncien los requisitos no
Funcionales.
_ Especificar el comportamiento de cada caso de uso identificado.
Ejemplo:
El proceso de reunin de requisitos se intensifica y se centra especialmente en el
software. Dentro del proceso de anlisis es fundamental que a travs de una
coleccin de requerimientos funcionales y no funcionales, el desarrollador o
desarrolladores del software comprendan completamente la naturaleza de los
programas que deben construirse para desarrollar la aplicacin, la funcin
requerida, comportamiento, rendimiento e interconexin [PRR98]. En el caso de
este proyecto, el proceso de anlisis y de obtencin de requerimientos se lleva a
cabo a travs de trabajar conjuntamente con la psicloga Norma Rodrguez, quien
proporciona los parmetros bajo la aplicacin debe desarrollarse para poder de
esta manera cumplir con los objetivos.

Requisitos del Sistema

Establecer el contexto del sistema, identificando los actores.

Considerar el comportamiento del sistema que cada actor espera o
requiere que ste proporcione.
Nombrar los comportamientos comunes como casos de uso.
Factorizar el comportamiento comn y el comportamiento variante.
El comn en nuevos casos de uso que puedan ser utilizados por otros.
El variante en nuevos casos de uso que extiendan los flujos principales
Modelar esos casos de uso, actores y relaciones en un diagrama de
casos de uso.
Adornar esos casos de uso con notas que enuncien los requisitos no
funcionales.
Dificultades para definir los requerimientos

Los requerimientos no son obvios y vienen de muchas fuentes.

Son difciles de expresar en palabras (el lenguaje es ambiguo).
Existen muchos tipos de requerimientos y diferentes niveles de detalle.
La cantidad de requerimientos en un proyecto puede ser difcil de manejar.
Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o
ms estables que otros.
Los requerimientos estn relacionados unos con otros, y a su vez se relacionan
con otras partes del proceso.
Cada requerimiento tiene propiedades nicas y abarcan reas funcionales
especficas.
Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular
para cada proyecto.

Los requerimientos deben ser:

Especificados por escrito. Como todo contrato o acuerdo entre dos partes
Posibles de probar o verificar. Si un requerimiento no se puede comprobar,
entonces cmo sabemos si cumplimos con l o no?
Descritos como una caracterstica del sistema a entregar. Esto es: que es lo que el
sistema debe de hacer (y no como debe de hacerlo)
Lo ms abstracto y conciso posible. Para evitar malas interpretaciones.

Actividades de la Ingeniera de Requerimientos

En el proceso de IR son esenciales diversas actividades. En este documento

sern presentadas, sin embargo, en un proceso de ingeniera de requerimientos
efectivo, estas actividades son aplicadas de manera continua y en orden variado.
Dependiendo del tamao del proyecto y del modelo de proceso de software
utilizado para el ciclo de desarrollo, las actividades de la IR varan tanto en nmero
como en nombres.
La tabla #1 muestra algunos ejemplos de las actividades identificadas para cada
proceso.
A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el
conjunto de actividades mostradas en la tabla anterior, podemos identificar y
extraer cinco actividades principales que son:
 Anlisis del Problema
Evaluacin y Negociacin
Especificacin
Validacin
Evolucin

Principios de Especificacin

La especificacin, independientemente del modo en que se realice, puede ser

vista como un proceso de representacin. Los requerimientos se representan de
forma que conduzcan finalmente a una correcta implementacin del software.
Baltzer y Goldman proponen ocho principios para una buena especificacin:

PRINCIPIO #1. Separar funcionalidad de implementacin.

Primero, por definicin, una especificacin es una descripcin de lo que se desea,
en vez de cmo se realiza (implementa). Las especificaciones pueden adoptar dos
formas muy diferentes. La primera forma es la de funciones matemticas: dado
algn 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 cmo). En parte, esto es debido a que el resultado es una funcin
matemtica de la entrada (la operacin tiene puntos de comienzo y parada bien
definidos) y no est afectado por el entorno que le rodea.
PRINCIPIO #2. Se necesita un lenguaje de especificacin de sistemas orientado al
proceso.
Considerar una situacin en la que el entorno sea dinmico y sus cambios afecten
al comportamiento de alguna entidad que interacte con dicho entorno. Su
comportamiento no puede ser expresado como una funcin matemtica de su
entrada. En vez de ello, debe emplearse una descripcin orientada al proceso, en
la cual la especificacin del que se consigue mediante la especificacin de un
modelo del comportamiento deseado en trminos de respuestas funcionales, a
distintos estmulos del entorno.
PRINCIPIO #3. Una especificacin debe abarcar el sistema del cual el software es
una componente.
Un sistema est compuesto de componentes que interactan. Solo dentro del
contexto del sistema completo y de la interaccin entre sus partes puede ser
definido el comportamiento de una componente especfica. En general, un sistema
puede ser modelado como una coleccin de objetos pasivos y activos. Estos
objetos estn interrelacionados y dichas relaciones entre los objetos cambian con
el tiempo. Estas relaciones dinmicas suministran los estmulos a los cuales los
objetos activos, llamados agentes, responden. Las respuestas pueden causar
posteriormente cambios y, por tanto, estmulos adicionales a los cuales los
agentes deben responder.
PRINCIPIO #4. Una especificacin debe abarcar el entorno en el que el sistema
opera.
Similarmente, el entorno en el que opera el sistema y con el que interacta debe
ser especificado.
Afortunadamente, esto tan solo necesita reconocer que el propio entorno es un
sistema compuesto de objetos que interactan, pasivos y activos, de los cuales el
sistema especificado es una agente, Los otros agentes, los cuales son por
definicin inalterables debido a que son parte del entorno, limitan el mbito del
diseo subsecuente y de la implementacin. De hecho, la nica diferencia entre el
sistema y su entorno es que el esfuerzo de diseo e implementacin subsecuente
opera exclusivamente sobre la especificacin del sistema. La especificacin 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 especificacin de sistema debe ser un modelo cognitivo.
La especificacin de un sistema debe ser un modelo cognitivo, en vez de un
modelo de diseo o implementacin. 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. Adems, debe ser
posible incorporar en la especificacin 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 elaboracin para prevenir que surjan estos estados.
PRINCIPIO #6. Una especificacin debe ser operacional.
La especificacin debe ser completa y lo bastante formal para que pueda usarse
para determinar si una implementacin propuesta satisface la especificacin de
pruebas elegidas arbitrariamente. Esto es, dado el resultado de una
implementacin sobre algn conjunto arbitrario de datos elegibles, debe ser
posible usar la especificacin para validar estos resultados. Esto implica que la
especificacin, aunque no sea una especificacin completa del como, pueda
actuar como un generador de posibles comportamientos, entre los que debe estar
la implementacin propuesta. Por tanto, en un sentido extenso, la especificacin
debe ser operacional.
PRINCIPIO #7. La especificacin del sistema debe ser tolerante con la
incompletitud y aumentable.
Ninguna especificacin puede ser siempre totalmente completa. El entorno en el
que existe es demasiado complejo para ello. Una especificacin es siempre un
modelo, una abstraccin, de alguna situacin real (o imaginada). Por tanto, ser
incompleta. Adems, al ser formulad existirn muchos niveles de detalle. La
operacionalidad requerida anteriormente no necesita ser completa. Las
herramientas de anlisis empleadas para ayudar a los especificadores y para
probar las especificaciones, deben ser capaces de tratar con la incompletitud.
Naturalmente esto debilita el anlisis, el cual puede ser ejecutado ampliando el
rango de comportamiento aceptables, los cuales satisfacen la especificacin, pero
tal degradacin debe reflejar los restantes niveles de incertidumbre.
PRINCIPIO #8. Una especificacin debe ser localizada y dbilmente acoplada.