UNIDAD 4
 

  ANALISIS DE LOS
  REQUERIMIENTOS
 

 
Objetivo: Aplicará los requerimientos
 
correspondientes a su proyecto,
 
diseñará las interfaces de usuario y
 
los casos de uso del proyecto.
 

 
 
 UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS. 
 

4.1 REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

Un requerimiento es:

¨Una condición o necesidad de un usuario para resolver un problema o alcanzar un

objetivo¨.

Una condición o capacidad que debe estar presente en un sistema o

componentes de sistema para satisfacer un contrato, estándar, especificación u otro
documento formal.

Los requerimientos puedes dividirse: 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 características 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, estándares, etc.

4.2 CASOS DE USO

Un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo

sistema o una actualización de software.

Cada caso de uso proporciona uno o más escenarios que indican cómo debería
interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo
específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas,
prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza
a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.

En otras palabras, un caso de uso es una secuencia de interacciones que se

desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor
principal sobre el propio sistema.

Los diagramas de casos de uso sirven para especificar la comunicación y el

comportamiento de un sistema mediante su interacción con los usuarios y/u otros
sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los
casos de uso en un sistema.

65 
 
 UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS. 
 

Una relación es una conexión entre los elementos del modelo, por ejemplo la
especialización y la generalización son relaciones. Los diagramas de casos de uso se
utilizan para ilustrar los requerimientos del sistema al mostrar como reacciona una
respuesta a eventos que se producen en el mismo.

Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea
de negocio. Desde una perspectiva tradicional de la ingeniería de software, un caso del
uso describe una característica del sistema. Para la mayoría de proyectos de software,
esto significa que quizás a veces es necesario especificar diez o centenares de casos de
uso para definir completamente el nuevo sistema. El grado de la formalidad de un
proyecto particular del software y de la etapa del proyecto influenciará el nivel del detalle
requerido en cada caso de uso.

Los casos de uso pretenden ser herramientas simples para describir el

comportamiento del software o de los sistemas. Un caso del uso contiene una
descripción textual de todas las maneras que los actores previstos podrían trabajar con
el software o el sistema. Los casos del uso no describen ninguna funcionalidad interna
(oculta al exterior) del sistema, ni explican cómo se implementará. Simplemente
muestran los pasos que actor sigue para realizar una tarea.

Un caso de uso debe:

• Describir una tarea del negocio que sirva a una meta de negocio tener un nivel
apropiado del detalle
• Ser bastante sencillo como que un desarrollador lo elabore en un único
lanzamiento

Situaciones que pueden darse:

• Un actor se comunica con un caso de uso (si se trata de un actor primario la
comunicación la iniciará el actor, en cambio si es secundario, el sistema será el
que inicie la comunicación).
• Un caso de uso extiende otro caso de uso.

66 
 
 UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS. 
 

VENTAJAS

La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la

intención que tiene el actor (su usuario) al hacer uso del sistema.

Como técnica de extracción de requerimiento permite que el analista se centre en las

necesidades del usuario, qué espera éste lograr al utilizar el sistema, evitando que la
gente especializada en computación dirija la funcionalidad del nuevo sistema basándose
solamente en criterios tecnológicos.A su vez, durante la extracción (elicitation en inglés),
el analista se concentra en las tareas centrales del usuario describiendo por lo tanto los
casos de uso que mayor valor aportan al negocio. Esto facilita luego la priorización del
requerimiento.

LIMITACIONES 

Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero
no establecen completamente los requisitos funcionales ni permiten determinar los
requisitos no funcionales. Los casos de uso deben complementarse con información
adicional como reglas de negocio, requisitos no funcionales, diccionario de datos que
complementen los requerimientos del sistema. Sin embargo la ingeniería del
funcionamiento especifica que cada caso crítico del uso debe tener un requisito no
funcional centrado en el funcionamiento asociado.

Diagrama de Casos de Uso

Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso
del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su
interacción externa.

En el diagrama de casos de uso se representa también el sistema como una caja

rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja
del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que
participa mediante una línea.

67 
 
 UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS. 
 

En la siguiente figura, se muestra un ejemplo de Diagrama de Casos de Uso para un

cajero automático.

A) Elementos

Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores,
casos de uso y relaciones entre casos de uso.

B) Actores

Un actor es algo con comportamiento, como una persona (identificada por un rol), un
sistema informatizado u organización, y que realiza algún tipo de interacción con el
sistema. Se representa mediante una figura humana dibujada con palotes. Esta
representación sirve tanto para actores que son personas como para otro tipo de
actores.

Casos de Uso

Un caso de uso es una descripción de la secuencia de interacciones que se producen

entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea
específica. Expresa una unidad coherente de funcionalidad, y se representa en el
Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su
interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea
llevar a cabo usando el sistema.

Relaciones entre Casos de Uso

Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo
para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción
con un alcance menor como caso de uso.

68 
 
 UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS. 
 

La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la
comunicación en el equipo de desarrollo, el manejo de la documentación de casos de
uso.

Para el caso de que queramos utilizar estos casos de uso más pequeños, las
relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres
tipos: • Incluye (<>): Un caso de uso base incorpora explícitamente a otro caso de uso en
un lugar especificado en dicho caso base. Se suele utilizar para encapsular un
comportamiento parcial común a varios casos de uso. En la siguiente figura se muestra
cómo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso
Autorización.

4.3 DISEÑO DE INTERFAZ DE USUARIO

El propósito de la interfaz es muy simple: recoger de los usuarios la información del
sistema y ponerla a disposición de otros usuarios. La información recogida se llama
entrada del sistema y se almacena en la base de datos para ponerla a disposición de los
demás usuarios. La información suministrada se llama salida del sistema. Es decir, el
diseño de interfaces cubre tanto las entradas como las salidas.

Las entradas y salidas pueden ser interactivas o por lotes. En una interfaz
interactiva, el usuario se comunica directamente con el ordenador y la salida se obtiene
muy poco tiempo después de la entrada. En el caso de entradas o salidas no
interactivas, es decir, por lotes, las transacciones se reúnen en formularios en el punto
de recepción y después se introducen en el ordenador al mismo tiempo.

Estas transacciones se procesan y un tiempo después se producen las salidas,

las cuales se pasan al usuario. Así, el tiempo transcurrido desde la introducción de los
datos hasta que se obtiene una respuesta puede ser considerable.

El diseño de interfaz interactivo provoca un diálogo hombre-máquina que permite

un intercambio rápido de información entre los ordenadores y sus usuarios humanos,
mientras que la interfaz no interactiva utiliza un soporte de papel para contener la
información en el que las entradas normalmente se realizan en formularios
especialmente diseñados y las salidas se producen en un listado impreso.

Será necesario definir los formatos individuales de las pantallas utilizadas. En el

caso de utilizar un paquete estándar, habrá que evaluar la posibilidad de adoptar el tipo
de formato del producto.

69 
 
 UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS. 
 

Entre los aspectos a considerar en los formatos de pantalla se destacan:

encabezamiento, cuerpo principal, pie, teclas de función, teclas de ayuda y líneas de
visualización de los mensajes de ayuda.

También hay que describir, de forma detallada, los diálogos entre pantallas y su
encadenamiento. Para ello, es útil representarlas jerárquicamente, de forma que en los
niveles superiores se representen los menús, y en los niveles inferiores las pantallas de
diálogos, representativas de funciones o procesos concretos del sistema. En esta
representación jerárquica nos interesa identificar los menús o diálogos concretos en
función de los grupos de usuarios que los utilicen.

Será también necesario determinar los diálogos que se consideran críticos para un
funcionamiento correcto del nuevo sistema. Los diálogos críticos se determinan en
función de factores como: tipo de proyecto, grado de cambio con respecto al sistema
actual, complejidad de los trabajos del sistema.

Para ello, es útil tener en cuenta los siguientes criterios: frecuencia de uso de estos
diálogos, acceso a gran número de entidades de datos del sistema, gran número de
elementos de datos asociados con el diálogo, cambio en el modo habitual de trabajo en
el sistema actual, diálogos comunes a diferentes grupos de usuarios, diálogos que
contienen opciones complejas de navegación, etc.

Por último, habrá que realizar un prototipo dinámico que permita la simulación
(introducción y validación de datos por pantalla) para los diálogos considerados como
críticos.

Como recomendaciones para realizar este prototipo se tendrá en cuenta: la

determinación del punto de entrada a cada pantalla y sus posibilidades de navegación a
otras, la especificación de los datos asociados a cada pantalla (longitud, reglas de
validación, mensajes de ayuda, etc.), la evaluación de la consistencia del diseño,
asegurando que toda la información necesaria para el usuario está contemplada en las
pantallas, y la confirmación con el usuario de la validez de los diseños de pantalla
realizados

Entre las consideraciones a tener cuenta a la hora de diseñar pantallas se

encuentran las siguientes:

• Características deseadas: simplicidad, claridad y fácil de comprender. Será

necesario tener claridad visual, de forma que los elementos estén agrupados de
forma comprensible y con significado en vez de al azar y de forma confusa.

70 
 
 UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS. 
 

• Saber dónde situar la información en la pantalla. Será necesario indicar un

punto de partida obvio en la esquina superior izquierda de la pantalla, reservar
áreas específicas de pantalla para diferentes tipos de información (como, por
ejemplo, mandatos, mensajes de error, títulos y campos de datos, de forma que
esta consistencia se mantenga en todas las pantallas) y proporcionar una
composición que guste visualmente (es decir, que esté balanceada, sea
simétrica, sea predecible, secuencial, simple, con agrupamientos, etc.).

• Saber qué información situar en la pantalla. Para ello, hay que poner sólo la
información que es esencial para la toma de una decisión o para la ejecución de
una acción (¡No inundar al usuario con información!) y poner todos los datos
relacionados con una tarea en una única pantalla (así el usuario no tiene que
recordar datos de una pantalla a otra).

• Saber cómo situar la información en la pantalla. Así, en cuanto a las fuentes

de letras, se recomienda utilizar minúsculas para el texto con la letra inicial de la
frase en mayúsculas; para las etiquetas, encabezamientos o subtítulos utilizar
mayúsculas. En cuanto a las palabras, se recomienda no usar jerga, sino utilizar
palabras cortas, familiares, etc.
• La interfaz de entrada debe recoger todos los datos necesarios, sin
introducir errores, para el sistema. De esta forma, la interfaz contiene una
protección contra errores de entrada. Así mismo, también debe recoger los datos
minimizando el número de teclas pulsadas por el usuario. Las entradas deben
estar bien estructuradas y ser fáciles de comprender y utilizar. Se deben usar
nombres precisos y permitir abreviaturas cuando se necesiten introducciones
rápidas de datos.
• Se deben evitar las entradas repetitivas. Igualmente, el diseño de la salida
asegura que se extraen todos los datos suministrados por el sistema y que esas
salidas están estructuradas de forma que sean fáciles de leer.

• El color añade una nueva dimensión a la facilidad de uso de la pantalla, ya

que atrae la atención del usuario. Si se utiliza de forma adecuada, puede
resaltar la organización lógica de una pantalla, facilitar la separación de
componentes y acentuar las diferencias. Por el contrario, si se usa
inadecuadamente, puede distraer y fatigar la visión debilitando la facilidad de uso
del sistema. Por ejemplo, en las pantallas gráficas se recomienda no utilizar más
de seis colores a la vez, evitar colores extremos (rojo y azul, amarillo y púrpura),
evitar colores que no tengan contraste (blanco y amarillo, rojos, azules).

71 
 
 UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS. 
 

Existen tres enfoques principales para el diseño de casos:

1. El enfoque estructural o de caja blanca. Consiste en centrarse en la

estructura interna (implementación) del programa para elegir los casos
de prueba. En este caso, la prueba ideal (exhaustiva) del software
consistiría en probar todos los posibles caminos de ejecución, a través
de las instrucciones del código, que puedan trazarse.
2. El enfoque funcional o de caja negra. Consiste en estudiar la
especificación de las funciones, la entrada y la salida para derivar los
casos. Aquí, la prueba ideal del software consistiría en probar todas las
posibles entradas y salidas del programa.
3. El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones
estadísticos) que representen las posibles entradas al programa para
crear a partir de ellos los casos de prueba. La prueba exhaustiva
consistiría en probar todas las posibles entradas al programa.

Estos enfoques no son excluyentes entre sí, ya que se pueden combinar para
conseguir una detección de defectos más eficaz. Veremos a continuación una
presentación de cada uno de ellos.

4.3.1 REGLAS EN EL DISEÑO DE INTERFAZ DE USUARIO

PRINCIPIOS A SEGUIR EN EL DESARROLLO DE INTERFACES DE USUARIO:

A) Dar control al usuario

B) Reducir la carga de memoria del usuario

C) Consistencia

Dar control al usuario

ƒ Permitir a los usuarios utilizar teclado o ratón.

ƒ Permitir al usuario interrumpir su tarea y continuarla más tarde.
ƒ Utilizar mensajes y textos descriptivos.
ƒ Permitir deshacer las acciones, e informar de sus resultados.
ƒ Permitir una cómoda navegación dentro del producto y una fácil salida del
mismo.

72 
 
 UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS. 
 

ƒ Permitir distintos niveles de uso del producto para usuarios con distintos niveles
de experiencia.
ƒ Hacer transparente la interfaz del usuario (este debe creer que trabaja
directamente con los objetos).
ƒ Permitir al usuario personalizar la interfaz.
ƒ Permitir al usuario manipular directamente los objetos de la interfaz.
ƒ El usuario debe sentir que tiene el control del sistema.

Reducir la carga de memoria del usuario

9 Aliviar carga memoria corto plazo (deshacer, copiar y pegar, mantener los
últimos datos introducidos).
9 Reconocimiento antes que recuerdo (elegir de listas mejor que teclear).
9 Dar indicaciones visuales de donde está el usuario, que está haciendo y que
puede hacer a continuación
9 Proporcionar funciones de deshacer, rehacer y acciones por defecto..
9 Proporcionar atajos de teclado (iniciales en menús, teclas rápidas).
9 Asociar acciones a los objetos (menú contextual).
9 Utilizar metáforas del mundo real (sistema telefónico, agenda).

Iconos de Lotus Organizer

Ejemplo de mala metáfora

Metáfora de la agenda

73 
 
 UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS. 
 

9 Presentar al usuario solo la información que necesita.

9 Hacer la presentación visual clara (colocación/agrupación de objetos, excesiva
información, ...).

Ejemplo de mal (izquierda) y buen diseño (derecha)

Consistencia
¾ Permite al usuario utilizar conocimiento adquirido en otros programas
consistentes (P.e. Mostrar siempre el mismo mensaje ante un mismo tipo de
situación aunque se produzca en distintos lugares).
¾ Consistencia en la realización de tareas: proporcionar al usuario indicaciones
sobre el proceso que esta siguiendo.
¾ Consistencia dentro de un producto y de un producto a otro.
•Presentación
•Comportamiento
•Interacción
¾ Ejemplo consistencia en la mejora de la interfaz: Botones de las ventanas de
Windows (3.11 y 95/98).
¾ Consistencia en los resultados de las acciones: misma respuesta ante misma
acción.
¾ Consistencia en la apariencia estética (iconos, fuentes, colores, distribución de
pantallas, ...)
¾ Fomentar la libre exploración de la interfaz, sin miedo a consecuencias
negativas.

74 
 
 UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS. 
 

4.3.2 INTEGRACION DE LA INTERFAZ AL CASO DE USO

Aunque se han propuesto modelos diferentes para el diseño de la interfaz de usuario
(Por ejemplo, NOR86, NIE00), todos sugieren alguna combinación de los siguientes
pasos:

1.- Con base en la información desarrollada durante el análisis de la información, definir

los objetos y las acciones de la interfaz (operaciones).
2.- Definir eventos (acciones del usuario) que cambiarán el estado de la interfaz Modelar
este comportamiento.
3.- Representar cada estado de la interfaz tal como lo vera el usuario final.
4.- Indicar como interpreta el usuario el estado del sistema a partir de la interfaz
proporcionada mediante la interfaz.

En algunos casos, el diseñador de la interfaz puede empezar con borradores de cada

estado de la interfaz (es decir, el aspecto de la interfaz en distintas circunstancias) y
luego trabajar hacia atrás para definir objetos, acciones y otra información importante
para el diseño. Independientemente de la secuencia de las tareas del diseño, éste debe:

A) Seguir siempre las reglas de oro analizadas.

B) Modelar la manera en que se implementará la interfaz
C) Tomar en cuenta el entorno (por ejemplo, la tecnología de despliegue, el
sistema operativo, las herramientas de desarrollo) en que habrá de
usarse.

APLICACIÓN DE LOS PASOS DEL DISEÑO DE LA INTERFAZ

Un paso importante en el diseño de la interfaz es la definición de los objetos que esta
tendrá y las acciones que se les aplicarán. Para realizarlo se analizan los casos de uso.
Es decir, se escribe una descripción de un caso de uso. Luego se aíslan los nombres
(objetos) y los verbos (acciones) para crear una lista de objetos y acciones.
Una vez definidos los objetos y las acciones, que se han elaborado de manera iterativa,
se organizan por tipo. Se identifican objetos de destino, origen y aplicación. Un objeto
origen (como el icono de un informe) se arrastra y coloca en un objeto de destino (por
ejemplo, un icono de impresora). La implicación de esta acción es crear un informe
impreso. Un objeto de aplicación representa datos específicos de la aplicación que n ose
manipulan directamente como parte de la interacción con la pantalla. Por ejemplo, en
una lista de correo se almacenan nombres para un envío de correspondencia.

75 
 
 UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS. 
 

La propia lista podría ordenarse, combinarse o purgarse (acciones de menú), pero no

arrastrarse ni colocarse mediante interacción del usuario. Una vez que el diseñador
queda satisfecho con un objeto importante y que se han definido las acciones (para una
iteración de diseño) se realiza el formato de la pantalla. Como otras actividades de
diseño de la interfaz, el formato de la pantalla es un proceso interactivo; en el se elabora
el diseño gráfico y se colocan los iconos, la definición de texto descriptivo en pantalla, la
especificación y la asignación de nombres a las ventanas, además de la definición de los
elementos primarios y secundarios de los menús. Si un metáfora de la realidad es
apropiada para la aplicación, se especifica en este momento, y el diseño se organiza de
manera tal que satisfaga la metáfora. A continuación se presenta un caso de estudio
preliminar (escrito por el propietario) para la interfaz.

Caso de uso preliminar: Quiero tener acceso a mi sistema HogarSeguro desde

cualquier lugar remoto vía internet. Empleando software de navegador que opera en mi
notebook (mientras estoy trabajando o viajando) puedo determinar el estado del sistema
de alarmas, armar o desarmar el sistema, reconfigurar zonas de seguridad y ver
diferentes habitaciones de la casa con las cámaras de video preinstaladas.

Para tener acceso a HogarSeguro desde un lugar remoto proporciono una

identificación y una contraseña. Estos elementos definen los niveles de acceso (por
ejemplo, no todos los usuarios pueden reconfigurar el sistema ni proporcionar
seguridad). Una vez validado, puedo revisar el estatus del sistema y cambiarlo al armar o
desarmar HogarSeguro. Puedo reconfigurar el sistema al desplegar un plano de la casa,
ver cada uno de los sensores de seguridad, desplegar cada zona configurada
actualmente y modificar zonas de acuerdo con las necesidades. Puedo ver el interior de
la casa con las cámaras de video colocadas de manera estratégica. Puedo hacer
acercamientos y desplazamientos con las cámaras para proporcionar diferentes vistas
del interior.

Con base en este caso de uso se identifican las tareas del propietario, los
objetos y los elementos siguientes:
¾ Tiene acceso al sistema HogarSeguro
¾ Ingresa un ID y una contraseña para acceso remoto
¾ Revisa el estatus del sistema
¾ Arma o desarma el sistema HogarSeguro
¾ Despliega el plano de la casa y las ubicaciones de los sensores
¾ Despliega zonas en el plano de la casa
¾ Cambia zonas en el plano de la casa

76 
 
 UNIDAD IV / ANALISIS DE LOS REQUERIMIENTOS. 
 

¾ Despliega ubicaciones de las cámaras de video o el plano de la casa

¾ Selecciona visualmente una cámara de video
¾ Ve imágenes de video
¾ Desplaza o acerca las cámaras de video

Los objetos (en negritas) y las acciones (en cursivas) se extraen de la lista de
tareas del propietario. La mayor parte de los objetos indicados son objetos de la
aplicación. Sin embargo, ubicación de las cámaras de video (un objeto de origen)
se arrastra y coloca en cámara de video (un objeto de destino) para crear una
imagen de video (una ventana que contiene el desplegué de video).

Se crea un boceto preliminar del formato de la pantalla para el monitoreo de

video. La imagen de video se solicita seleccionando un icono de ubicación de las
cámaras de video, C, localizado en el plano de la casa desplegado en la ventana de
monitoreo. En este caso, se arrastra la ubicación de una cámara de video en la sala,
SA, y se coloca sobre el icono de cámara de video ubicado en la parte superior
izquierda de la pantalla. Aparecerá la ventana de imagen de video, desplegando
video de flujo continuo proveniente de la cámara ubicada en la sala (SA). Los
controles deslizables de acercamiento y desplazamiento se emplean para controlar
la ampliación y la dirección de la imagen del video. Para seleccionar una vista de
otra cámara, el usuario simplemente arrastra y coloca un icono de ubicación de
cámara diferente en el icono de la cámara emplazado en la esquina superior
izquierda de la pantalla.

El boceto del formato que se muestra tendría que complementarse con una
expansión de cada elemento de menú dentro de la barra de menús, indicando cuales
acciones están disponibles para el modo de monitoreo de video (estado). Durante la
etapa de diseño de la interfaz se crearía un conjunto completo de bocetos para cada
tarea de propietario anotada en el escenario del usuario.

77