UNIDAD 4
ANALISIS DE LOS
REQUERIMIENTOS
Objetivo: Aplicará los requerimientos
correspondientes a su proyecto,
diseñará las interfaces de usuario y
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.
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.
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 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
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.
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:
• 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
Existen tres enfoques principales para el diseño de casos:
1.
El enfoque estructural o de caja blanca. Consiste en centrarse en laestructura 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 laespecificació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 ocasionesestadí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
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
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, ...)
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
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 ¾ Despliegazonas en el plano de la casa
¾ Despliegaubicaciones 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.
