análisis de requisitos -...

25/02/2013

Universidad de Zaragoza 1

Análisis de Requisitos

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

Análisis etnográfico: Observación del entorno y procedimiento de– 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ónSistematización en formularios, siguiendo normas o estándares

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

Tema: Análisis de requisitos

j p p ( q ,de uso)

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

interacción.

Análisis de la información

El análisis y la interpretación de la información recogida puede ser:

• Cuantitativo: – Obtención de valores numéricos: porcentajes,

promedios, medias, desviaciones estándar, etc.

• Cualitativo: – Identificar patrones y/o temas recurrentes,


categorización de los datos, análisis de los incidentes críticos.

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

25/02/2013


Análisis de la información

• Sistematización en formulariosLa información recogida de manera informal se estructura y se

t i i d t d l í t d i d l iblpresenta 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

• Objetivos de negocio (de la empresa)– ¿Cuáles son las razones de empresa?

Có d t i á l l li ió é it ?– ¿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


25/02/2013



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ísticasrequisitos 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


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

- ...

25/02/2013



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)


25/02/2013



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



Representación de Requisitos Funcionales mediante casos de uso:


25/02/2013



Casos de uso

• Un caso de uso especifica el comportamiento de unUn 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


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.


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.


25/02/2013


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


q

– 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.


p

25/02/2013



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

Uso:

• De Comunicación:


Actorcaso de uso


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.


25/02/2013



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 dependenciacon estereotipo <<include>> (o <<uses>>)


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

implícitamente el comportamiento de otro caso de usoimplí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


ciertas condiciones.

25/02/2013


Diagrama de casos de uso

Ejemplo: Cajero automático


Notas: - Generado con Microsoft Visio- Tened en cuenta el cambio de notación

Construcción del modelo 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

25/02/2013



1. Descripción de escenarios

• Una técnica muy útil para descubrir el funcionamiento de• 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.


p p

• 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 deDeustcheSparKasse 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.

25/02/2013



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>>)


(<<extend>> y <<include>>).

• Ordenar según prioridad los casos de uso para implementar primero los que sean críticos.

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

25/02/2013



Desde el punto de vista del usuario:

• ¿Cómo aseguramos la eficiencia, eficacia y ¿ g , ysatisfacció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:


p– Comprender los factores psicológicos, ergonómicos,

organizativos y sociales.

– Desarrollar herramientas y técnicas.

– Conseguir una interacción eficiente, efectiva y satisfactoria.

25/02/2013



Definiciones (ISO 9241-11):

• Efectividad: Precisión y grado de consecución con queEfectividad: 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


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

d b h ?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?

25/02/2013


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?


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?


Utilizar parámetros de medida de ISO 9241-11

• Tiempo aprendizaje/tiempo tarea• 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


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

una página– No cometer errores fatales irrecuperables

25/02/2013



Utilizar parámetros de medida de ISO 9241-11

• Impresión subjetiva• 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


llegue al final


• Normativa: UNE-EN ISO 9241-11


Componentes de la usabilidad

25/02/2013



• Normativa: UNE-EN ISO 9241-11–Eficacia: Las medidas de eficacia comparan los

objetivos del usuario con la precisión y el grado deobjetivos del usuario con la precisión y el grado deconsecución con que pueden lograrse dichos objetivos.

–Eficiencia: Las medidas de eficiencia comparar el nivelde eficacia alcanzado con los recursos empleadospara ello. Los recursos a considerar podrían incluir:esfuerzo físico o mental, tiempo, costes materiales ofinanciero, etc.


–Satisfacción: Mide hasta qué punto los usuarios estánlibres de incomodidad, así como su actitud respecto ala utilización del producto.


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

usabilidad de un sistema.


25/02/2013


UN

E-E

Análisis: Objetivos de usabilidadE

N IS

O 9241-11


UN

E-E


EN

ISO

9241-11


25/02/2013



• 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: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: Dif t i t f i di id l d t ( ó il


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 )


dificultad de personalización,…)

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

25/02/2013



• 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

M h d t di id d tá t


• 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

25/02/2013


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)


p )

– Objetivos de la aplicación

– Objetivos de usabilidad

– Objetivos de accesibilidad

25/02/2013


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”

f


– Evaluaciones a partir de descripciones formales de escenarios de casos de uso

– Tests de usabilidad

– …

25/02/2013


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


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.

análisis de requisitos -...

Documents