Resumen del cápitulo 7 Identifying needs and establishing requirements del Libro Interaction Design - Jenny Preece

Identificación de necesidades y establecimiento de requisitos

Cuando se realiza un proyecto de diseño de interacción se requiere una comprensión de, entre otras cosas, los usuarios y sus capacidades, sus tareas y metas actuales, las condiciones bajo las cuales el producto será utilizado y las restricciones en el rendimiento del producto.

Las actividades de requisitos, diseño y evaluación estan entrelazadas, dando como resultado la realización de requisitos y de diseño en paralelo, al mismo tiempo que el diseño se realiza de forma iterativa haciendo un ciclo de evaluación-rediseño.  Apesar de esto cada una de estas fases se tienen sus propias tecnicas. 

¿Qué, cómo y por qué?

¿Qué estamos tratando de lograr en esta actividad de diseño?

1.- Entender lo más posible sobre los usuarios, su trabajo y el contexto de ese trabajo, para que el sistema en desarrollo pueda apoyarlos en el logro de sus metas; Esto lo llamamos "identificar necesidades". 

2.- Producir, a partir de las necesidades identificadas, un conjunto de requisitos estables que formen una base sólida para avanzar en la reflexión sobre el diseño. 

¿Cómo podemos lograrlo?

A lo largo de este resumen se explicará cómo realizar los requisitos. Las tres fases generales son: recopilación de datos, análisis y captura de los datos, a lo que se le puede llamar requisitos. Es importante utilizar un conjunto complementario de técnicas de recopilación de datos y técnicas de interpretación de datos, y revisar y refinar constantemente los requisitos.

¿Por qué molestarse? La importancia de hacerlo bien

Como se mencionaba en el libro de Don Norman, se tiene que encontrar el problema correcto para encontrar la solución correcta, y para ello se tiene que involucrar los usuarios en el desarrollo del sistema. Y la forma de involucrarlos es tomando sus necesidades correctas para poder obtener sus requisitos correctos. 

¿Por qué establecer requerimientos?

El término "análisis de requisitos" se utiliza normalmente para describir la actividad de investigar y analizar un conjunto inicial de requisitos que se han reunido, obtenido o capturado. La ingeniería de requisitos reconoce que el desarrollo de un conjunto de requisitos es un proceso iterativo de evolución y negociación, y que necesita ser cuidadosamente administrado y controlado.

¿Qué son los requerimientos?

Un requisito es una declaración sobre un producto que especifica qué debe hacer o cómo debe realizarse. Uno de los objetivos de la actividad de requisitos es hacer los requisitos tan específicos, inequívocos y claros como sea posible. 

Diferentes tipos de requerimientos

Durante toda la carrera de Ingeniería de software nos han especificado que existen dos tipos de requerimientos, los funcionales y los no funcionales.Los requisitos funcionales, dicen lo que el sistema debe hacer, y los no funcionales, dicen qué limitaciones debe haber en el sistema. 

El libro decide refinar la dicion de los tipos de requisitos en las siguientes categorias:

• Requisitos funcionales: lo que el producto debe de hacer.
• Requisitos de datos: recogen el tipo, la volatilidad, la magnitud, la persistencia, la precisión y el valor de las cantidades de los datos requeridos.
• Requerimientos ambientales: se refieren a las circunstancias en las que se espera que el producto interactivo funcione. Se deben considerar cuatro aspectos en este tipop de requisitos: físico,  social, organizacional, y técnico.
• Requerimientos de usuario: captura las caracteristicas del grupo de usuarios. Los tipos de usuarios se clasifican en: novatos, expertos, casuales y frecuentes.
• Requerimientos de usabilidad: capturan los objetivos de usabilidad y las medidas asociadas para un producto en particular.

Recolección de datos

El propósito de la recopilación de datos es reunir datos suficientes, pertinentes y apropiados para que pueda producirse un conjunto de requisitos estables. Tenemos que averiguar sobre las tareas que los usuarios realizan actualmente y sus objetivos asociados, el contexto en el que se realizan las tareas y la razón de por qué las cosas son como son.

Tecnicas de recolección de datos

Cuestionarios

Entrevistas

Grupos de enfoques y talleres

Observacióon naturalista

Estudio de documentación

Elección entre tecnicas

Para escoger el tipo de herramienta a utilizar para la recolección de datos se tiene que tomar encuenta ciertos aspectos, cómo por ejemplo, el tipo de dato a recolectar, la dispersión de las partes interesadas, los recursos disponibles, etc. 

Otro aspecto importante para poder escoger de manera correcta la herramienta de recolección de datos, es tomar encuenta las habilidades del recolector y la naturaleza de la herramienta.

Algunas pautas de recolección de datos

• Centrarse en identificar las necesidades de las partes interesadas. 
• Involucrar a todos los grupos interesados.
• Involucrar más de un representante de cada grupo.
• Utilice una combinación de técnicas de recopilación de datos.
• Apoyar las sesiones de recolección de datos con accesorios apropiados, tales como descripciones de tareas y prototipos si están disponibles. 
• Ejecute una sesión piloto si es posible para asegurarse de que su sesión de recopilación de datos probablemente vaya según lo planeado. 
• La forma de registrar datos.

Interpretación y análisis de datos

El objetivo de la interpretación es comenzar a estructurar y registrar descripciones de requisitos.

Existen diferentes técnicas y anotaciones para investigar diferentes aspectos del sistema que a su vez darán lugar a los diferentes requisitos. Por ejemplo, los requisitos funcionales han sido tradicionalmente analizados y documentados usando diagramas de flujo de datos, diagramas de estado, diagramas de flujo de trabajo, etc. Los requisitos de datos se pueden expresar usando diagramas entidad-relación. Si el desarrollo es tomar un enfoque orientado a objetos, los requisitos funcionales y de datos se combinan en los diagramas de clases, con el comportamiento expresado en diagramas de estados y diagramas de secuencia, entre otros. 

A medida que se apliquen más técnicas de interpretación y análisis, surgirá una comprensión más profunda de los requisitos y se ampliarán y aclararán las descripciones de los requisitos.

Descripción de tareas

Hay diferentes descripciones de las tareas, tres de ellas son: escenarios, casos de uso y casos de uso esenciales. Cada uno de estos puede ser utilizado para describir tareas ya existentes o tareas previstas con un nuevo dispositivo. No son mutuamente excluyentes y se usan a menudo en combinación para capturar diferentes perspectivas o para documentar diferentes etapas durante el ciclo de vida del desarrollo.

Escenarios

Escribe actividades o tareas humanas en una historia que permite explorar y discutir contextos, necesidades y requerimientos. No describe explícitamente el uso de software u otro soporte tecnológico para lograr una tarea. El uso del vocabulario y el fraseado de los usuarios significa que los escenarios pueden ser comprendidos por las partes interesadas y pueden participar plenamente en el proceso de desarrollo.

Casos de uso

Los casos de uso también se centran en las metas de los usuarios, pero el énfasis aquí está en una interacción usuario-sistema en lugar de la propia tarea del usuario. Para desarrollar un caso de uso, primero identifique a los actores, es decir, a las personas u otros sistemas que estarán interactuando con el sistema en desarrollo. Luego examine a estos actores e identifique su meta o metas en el uso del sistema. 

Uso de casos esenciales

Un caso de uso esencial es una narración estructurada que consta de tres partes: un nombre que expresa la intención general del usuario, una descripción escalonada de las acciones del usuario y una descripción escalonada de la responsabilidad del sistema. En lugar de los actores, los casos de uso esencial se asocian con las funciones de los usuarios.

Análisis de tareas

El análisis de tareas es un término general que abarca técnicas para investigar procesos cognitivos y acciones físicas, en un alto nivel de abstracción y en minuciosos detalles.

Análisis de tareas jerárquicas

El análisis jerárquico de tareas (HTA) fue diseñado originalmente para identificar las necesidades de capacitación (Annett y Duncan, 1967). Se trata de romper una tarea en subtareas y luego en sub-subtareas y así sucesivamente. 

Conclusión

Este capítulo se menciona el proceso de requerimientos de software, pero solo se define la obtención y el análisis. 

De las cosas nuevas que aprendí en este libro es sobre los escenarios y el HTA. En realidad sabía de los escenarios, pero no sabía que tuviera un nombre, pero del HTA lo desconocia totalmente. Creo que es una buena forma de encontrar todos los caminos posibles que ṕuede llevar una tarea, aasí mismo de poder desglosarla  lo más que se pueda para hacer más facíl la identificación de requerimientos.

Los tipos de requerimientos que se mencionan ya los habiamos visto en Fundamentos de Ingeniería de software. Ahora las tecnicas de recolección de datos son una lista menor de lo que se presenta en este capítulo que las que vimos en la materia de requisitos de software.