Interacción Persona -...

Tema: Análisis de requisitos

Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo

Interacción Persona - Ordenador

Análisis de Requisitos (II)


Análisis de Requisitos

• Adquisición o recogida de datos Observación y recolección de datos. Toma informal de notas

– Análisis etnográfico: Observación del entorno y procedimiento de trabajo

– Estudio de la audiencia: Usuarios y sus necesidades – Análisis de la competencia: Métodos anteriores, versiones previas

o aplicaciones similares

• Análisis e interpretación de la información Sistematización en formularios, siguiendo normas o estándares

– Objetivos de la aplicación: Descripción de tareas (requisitos, casos de uso)

– Objetivos de usabilidad y accesibilidad – Plataforma hardware y software necesaria. Dispositivos de

interacción.


Análisis de la información

¿Qué tenemos en este momento? • Entrevistas,

– p. ej con 5 clientes, un directivo y tres trabajadores.

• Cuestionarios, – p. ej. 50 encuestas recogidas de un formulario en internet

• Anotaciones de la observación, – p.ej. notas de dos visitas al centro de trabajo: procesos

administrativos, organización, posibles incidencias, etc…


Análisis de la información Siguiente paso: Análisis e interpretación de la información

recogida. Los datos obtenidos serán: • Cuantitativos:

– Obtención de valores numéricos: porcentajes, promedios, medias, desviaciones estándar, etc.

• Cualitativos: – Identificar patrones y/o temas recurrentes, categorización y

segmentación de datos y usuarios, análisis de los incidentes críticos.

Nota: Hay que tener cuidado con el modo de interpretar la información


Análisis de la información • Se efectúa mediante sistematización en

formularios. La información recogida de manera informal se estructura y se

presenta en plantillas siguiendo metodologías estandarizadas, en lo posible:

– Estándares de facto: empresas, fabricantes • Guías de estilo (Windows, iOS,

Android, Apple…)

– Estándares de iure: • Normas ISO, UNE • Metodologías de IS


Análisis: Objetivos de la aplicación

Además de los requisitos del sistema que veremos no hay que perder de vista los objetivos generales:

• Objetivos de negocio (de la empresa) – ¿Cuáles son las razones de empresa? – ¿Cómo determinará la empresa que la aplicación es un éxito?

• Objetivos de los usuarios – ¿Por qué los usuarios van a utilizar esta aplicación y no otra? – Si no puedes dar razones para que la usen probablemente fracasará – Hay que considerar cómo podemos mejorar nuestro servicio



La información recogida es útil para definir los objetivos de la aplicación. Se definen entonces los requisitos del sistema, es decir, las características que se deben incluir en el sistema. Existen dos tipos de requisitos: • Funcionales (RF):

– Establecen la funcionalidad del sistema …¿qué hace el sistema? – Describen las interacciones entre el sistema y el entorno – Son independientes de la implementación

• No funcionales (RNF): – Criterios para juzgar cómo opera el sistema – Atributos de calidad – Restricciones de implementación



Algunos ejemplos de requisitos no funcionales típicos son los siguientes:

– rendimiento – disponibilidad – seguridad – accesibilidad – usabilidad – estabilidad – portabilidad

– costo – operatividad – interoperabilidad – escalabilidad – concurrencia – mantenibilidad – interfaz



Es necesario elaborar un catálogo de requisitos que el software deberá satisfacer. Existen diferentes formas de representación de los requisitos:

- tablas de requisitos - árboles de decisión - tablas de decisión - casos de uso - ...



Representación de Requisitos mediante una tabla: – Técnica sencilla de enumeración en una tabla – Un requisito se representa con un código y un texto que lo describe – La estructura del código es fijada por la organización



• Ejemplo: Representación de Requisitos Volere shell (Preece, Rogers & Sharp)



• Ejemplo: Representación de requisitos http://www.volere.co.uk/



Representación de Requisitos Funcionales mediante casos de uso:


Análisis: Objetivos de la aplicación Casos de uso • Un caso de uso especifica el comportamiento de un

sistema o de una parte del mismo. Pero no especifica cómo se implementa dicho comportamiento.

• Describe el funcionamiento del sistema desde el punto de vista del usuario. Se usa fundamentalmente en la fase de análisis de requisitos.

• Un caso de uso describe la secuencia de interacciones que se producen entre un actor y el sistema.

• Un caso de uso describe un requisito funcional del sistema.

• Dos niveles de descripción: diagrama y detallado



Diagrama de caso 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.

• Los elementos que pueden aparecer en un diagrama de Caso de Uso son: Actores, Casos de uso y Relaciones.


Elementos de un diagrama de casos de uso

Casos de uso • Un caso de uso tiene un nombre y se representa

mediante una elipse. • El nombre del caso de uso debe reflejar la tarea

específica que el actor desea llevar a cabo usando el sistema.

• Cada caso de uso puede estar definido por: – Texto que lo describe – Secuencia de pasos ejecutados dentro del escenario – Condiciones pre-post para que el escenario comience o termine – Mezcla de las anteriores



Actores • Un actor es una entidad externa al sistema que realiza

algún tipo de interacción con el mismo. • Esta representación sirve tanto para actores que son

personas como para otro tipo de actores (otros sistemas, sensores, etc.).

• Los actores no forman parte del sistema, aunque aparecen en los modelos.



Relaciones • UML define cuatro tipos de relación en los Casos de

Uso:

• De Comunicación:



Relaciones • De Generalización:

• El caso de uso hijo hereda la especificación del caso de uso padre.

• El hijo puede añadir o redefinir el comportamiento del padre. • El hijo puede ser colocado en cualquier lugar donde aparezca el

padre.



Relaciones • De Inclusión: un caso de uso base incorpora

explícitamente el comportamiento de otro caso de uso (proveedor) en el lugar especificado en el caso base.

• Representa un comportamiento común del caso de uso. • Representa un comportamiento que es reusado (un caso de

uso utiliza a otro).

Relación de dependencia con estereotipo <<include>> (o <<uses>>)



Relaciones • De Extensión: un caso de uso base incorpora

implícitamente el comportamiento de otro caso de uso (proveedor) en el lugar especificado indirectamente por el caso proveedor.

• Se utiliza para modelar la parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema.

• Separa el comportamiento opcional del obligatorio. • También se usa para modelar un subflujo que se ejecuta bajo

ciertas condiciones.


Ejemplos Diagrama de casos de uso

• Biblioteca

• Cajero automático

Hay herramientas como Microsoft Visio para generarlos.


Construcción del diagrama de casos de uso

• Para construir el modelo de Casos de Uso en la fase de Análisis se siguen los siguientes pasos:

1. Descripción de uno o varios escenarios • El propósito del sistema a desarrollar. • El modelo de negocio: determinar los procesos claves del

sistema. • Los diagramas de actividades para cada proceso.

2. En paralelo se identifican los posibles usuarios del sistema



1. Descripción de escenarios

• Una técnica muy útil para descubrir el funcionamiento de un sistema desde el punto de vista de los usuarios es la de los escenarios.

• Un escenario es una descripción textual del funcionamiento típico de un sistema o tarea desde la perspectiva de un usuario concreto.

• Describe el comportamiento de usuarios representativos. • Al menos un escenario por tipo de usuario o actor



Ejemplo: Caso de uso: Comprar entradas

• Ange Schmidt es una clienta de DeustcheSparKasse con un saldo medio de más de 10.000€. Utiliza el cajero para la mayor parte de sus transacciones.

• A última hora de la tarde de los viernes entra a un cajero de la entidad, se registra, selecciona la operación Comprar entradas, revisa las ofertas para ese fin de semana y selecciona un espectáculo. Si quedan entradas, selecciona dos localidades y las paga. Recoge las entradas y su tarjeta y sale del cajero.


Construcción del diagrama de casos de uso 2. Identificación de los posibles usuarios del sistema

• Se identifican los actores del sistema. • En una tabla se especifican todos los casos de uso en el

formato de alto nivel. • Se dibuja el Diagrama general de Caso de Uso. • Se relacionan los casos de uso y se ilustran las

relaciones en el Diagrama de Casos de Uso (<<extend>> y <<include>>).

3. Ordenar y describir • Ordenar según prioridad los casos de uso para

implementar primero los que sean críticos. • Documentarlo brevemente.


• En el esquema la descripción es muy general y se documenta con una descripción breve. Es útil para comprender el ámbito y el grado de complejidad del sistema.

Ejemplo: El siguiente Caso de Uso describe el proceso de sacar dinero cuando se está usando un cajero automático.

• Caso de Uso: Reintegrar efectivo • Actores: Cliente • Descripción Breve: Un Cliente llega al cajero automático, introduce

la tarjeta, se registra y solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el dinero solicitado tras comprobar que la operación puede realizarse. El cliente coge el dinero, la tarjeta (y el comprobante, si lo desea) y se va.

Documentación del diagrama de casos de uso


Construcción del modelo detallado (o expandido)

Los casos de uso que se consideran más importantes se describen a un nivel más detallado.

• La principal diferencia con un caso de uso de alto nivel está en que incluye un apartado de curso típico de eventos.


Caso de Uso: Realizar Reintegro Nro. de CU: 5 Actores: Cliente (iniciador) Propósito: Realizar una operación de reintegro de una cuenta del banco.

Descripción Breve: Un cliente llega al cajero automático, introduce la tarjeta, se identifica y solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el dinero solicitado tras comprobar que la operación puede realizarse. El cliente toma el dinero y la tarjeta y se va.

Referencias: CU1, CU2 Curso (Flujo) típico de eventos :

Acción del actor Respuesta del sistema 1. En este caso de uso empieza cuando un

Cliente introduce una tarjeta en el cajero. 3. Introduce la clave. 5. Selecciona la operación de Reintegro. 7. Introduce la cantidad requerida. 10. Recoge la tarjeta. 11. Recoge el recibo. 12. Recoge el dinero y abandona el cajero.

2.Pide la clave de identificación 4. Presenta las opciones de operaciones disponibles. 6. Pide la cantidad a retirar. 8. Procesa la petición y eventualmente, da el dinero solicitado. 9. Devuelve la tarjeta y genera un recibo.

Cursos (Flujos) Alternativos: • Línea 4: La clave es incorrecta. Se indica el error y se cancela la operación • Línea 8: La cantidad solicitada supera el saldo. Se indica el error y se cancela la operación.

• Ejemplo:

Construcción del modelo detallado (o expandido)


Análisis: Objetivos de usabilidad

Desde el punto de vista de la empresa: • Establecer medidas (cuantitativas) de éxito:

– Órdenes de compra – Acceso a un documento – Visitas – Descargas

Necesitamos un marco formal: Normativa ISO/EN/UNE



Desde el punto de vista del usuario: • ¿Cómo aseguramos la eficiencia, eficacia y

satisfacción del usuario? – Es necesario identificar objetivos cuantificables que

permitan medir y valorar si la aplicación es usable • ¿Cuánto tiempo pueden invertir los usuarios aprendiendo? • ¿Cuántos errores podrían cometer?



Definición: • La medida en la que un producto se puede usar por

determinados usuarios para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso especificado (ISO 9241-11).

• Un sistema es usable si es fácil de aprender y fácil de utilizar.

• Para poder hacer sistemas usables hace falta: – Comprender los factores psicológicos, ergonómicos,

organizativos y sociales. – Desarrollar herramientas y técnicas. – Conseguir una interacción eficiente, efectiva y satisfactoria.



Definiciones (ISO 9241-11):

• Efectividad: Precisión y grado de consecución con que los usuarios logran objetivos establecidos.

• Eficiencia: Relación entre los recursos empleados y la precisión y el grado de consecución con que los usuarios logran objetivos establecidos.

• Satisfacción: Ausencia de incomodidad y existencia de actitudes positivas hacia la utilización del producto.


Usabilidad: Objetivos

• Efectividad – ¿Cómo de bueno es el sistema a la hora de hacer lo que se

supone debe hacer?

• Eficiencia

– Una vez aprendido el manejo ¿se tarda poco en llevar a cabo las tareas?

• Satisfacción – ¿Está el usuario conforme con el sistema? ¿Tiene quejas?


Análisis: Otros objetivos de usabilidad

• Seguridad – ¿El sistema protege al usuario de situaciones no deseadas? – ¿Permite al usuario recuperarse fácilmente en caso de error?

• Utilidad – ¿El sistema permite hacer todas las tareas que el usuario debe

hacer?

• Facilidad de aprendizaje – ¿Puede el usuario aprender por exploración? – ¿Cuánto le costaría aprender todas las funcionalidades de esa

forma?

• Facilidad de recuerdo de uso – ¿Qué tipo de soporte se le da al usuario para que recuerde cómo

llevar a cabo tareas infrecuentes?



• Normativa: UNE-EN ISO 9241-11

Componentes de la usabilidad



• Normativa: UNE-EN ISO 9241-11 – Esta normativa se utiliza para comprobar la usabilidad

de un sistema.



Se pueden utilizar los parámetros de medida de ISO 9241-11también para establecer objetivos de usabilidad:

• Impresión subjetiva

– Calificar el sitio como mínimo de 2,5 sobre 7 (elegante…)

• Tareas realizadas

– Un 75% de usuarios que intente comprar un artículo llegue al final



• Tiempo aprendizaje/tiempo tarea – Usar el sitio por primera vez sin entrenamiento < 10

minutos – Encontrar un tema por primera vez en menos de 2

minutos – Usuarios expertos (5 visitas) menos de 30 segundos

• Número de errores – No visitar más de tres páginas erróneas para visitar

una página – No cometer errores fatales irrecuperables


UN

E-E

N IS

O 9241-11




• Al analizar los objetivos de la aplicación hay que tener en cuenta el estudio de la audiencia y el análisis de la diversidad y optar por el diseño adecuado: – Diseño generalista: Una interfaz de propósito general para todo el mundo

– Diseño optimizado: Diseño simple para audiencia reducida y concreta

– Diseño alternativo: Diferentes interfaces individuales para cada grupo, entorno (móvil u

oficina), etc.

– Diseño multipropósito: Diseño único con partes diferentes para cada sector


Análisis: Objetivos de accesibilidad

• Accesibilidad: – Grado en el que un producto, dispositivo,

servicio o entorno está disponible para tantas personas como sea posible.

– Pensar en dotar de funcionalidad total para todos los tipos de discapacidades supone un reto difícilmente alcanzable (amplio abanico de discapacidades, dificultad de personalización,…)

– Hay que tener en cuenta la necesidad de incorporar dispositivos específicos.



• Para plantear los objetivos de accesibilidad hay que considerar las limitaciones que se van a abordar.

• Discapacidad – Una diferencia individual que supera un límite más o menos arbitrario

• Muchas de estas discapacidades están presentes en

grado diferente entre muchos sujetos considerados normales



• Para plantear los objetivos de accesibilidad hay que considerar las limitaciones que se van a abordar.

• Tipos de discapacidades: – Deficiencias visuales – Auditivas – Movimiento – Cognitivas


Análisis: Plataforma HW & SW

• Entorno informático de trabajo de los usuarios – Ordenadores y sistemas operativos – Monitores y otros periféricos – Considerar diferencias en el dispositivo (móviles,

oficina) – Considerar diferencias en navegador, en la red


Análisis: Plataforma HW & SW

• Definir la plataforma HW y el entorno SW más adecuado teniendo en cuenta: – Análisis etnográfico: considerar el modelo mental del

usuario, cómo realiza las tareas, etc. – Análisis de la audiencia: considerar el grupo o grupos

que utilizarán la aplicación, teniendo en cuenta todos los puntos de vista (edad objetivo, nivel adquisitivo, perfil, etc)

– Objetivos de la aplicación – Objetivos de usabilidad – Objetivos de accesibilidad


Prototipado de los requisitos

• Esbozos: – El documento de análisis de requisitos suele incluir

unos primeros bocetos (prototipo inicial).


Evaluación en Análisis de Requisitos

• Para verificar que los requisitos planteados son adecuados hay que realizar una evaluación

• Existen numerosas técnicas de evaluación, entre las que destacan: – Entrevistas, cuestionarios, grupos de discusión

(utilizadas también en la definición de los requisitos) – Evaluaciones de tipo “recorrido cognitivo” – Evaluaciones a partir de descripciones formales de

escenarios de casos de uso – Tests de usabilidad – …


Conclusiones

• Hacer un buen análisis de los requisitos del sistema a desarrollar es crucial.

• Debemos conocer quiénes serán nuestros usuarios. Hace falta definir para cada categoría sus necesidades y metas.

• Debe hacerse un prototipado completo: actores, tareas, relaciones...

• Se deben definir de forma clara los objetivos de la aplicación, de usabilidad y de accesibilidad para tenerlos en cuenta a la hora de realizar el diseño.

Interacción Persona -...

Documents

Transcript of Interacción Persona -...