Identifying needs and establishing requirements

Capitulo 7 del libro Interaction Desing: Beyond Human Computer Interaction. -Jennifer Preece, Yvonne Rogers, Helen Sharp

Un proyecto de diseño de interacción tiene como objetivo reemplazar o actualizar un sistema establecido, o puede tener como objetivo desarrollar un producto totalmente innovador sin precedentes evidentes. En este tipo de proyectos las necesidades, requisitos, aspiraciones y expectativas de los usuarios deben discutirse, refinarse, aclararse y volverse a analizar hasta que sea suficiente. Para esto, se requiere que los desarrolladores tengan comprensión de sus usuarios y sus capacidades, tareas y objetivos, entre otras cosas.  

Hay dos objetivos a lograr en esta actividad de diseño:

1. Comprender todo lo posible acerca de los usuarios, su trabajo y el contexto de ese trabajo, para que el sistema a desarrollar pueda ayudarles a lograr sus objetivos (identificar sus necesidades).
2. Producir, a partir de las necesidades identificadas, un conjunto de requisitos estables que formen una base sólida para avanzar hacia la reflexión sobre el diseño.

Estas actividades progresan de manera secuencial: primero se recopilan datos, luego se interpretan, después se extraen los requisitos, pero a medida que el proceso se repite se vuelve más complicado que esto. Una de las razones es que una vez que se comiencen a analizar los datos, es posible que se necesiten reunir más datos para aclarar o confirmar ideas que se tengan o que la forma en que se documentan los requisitos puede afectar al análisis.
Identificar necesidades y establecer requisitos es una actividad iterativa en la que las subactividades se informan y refinan entre sí. En la práctica, los requisitos evolucionan y se desarrollan a medida que los stakeholders interactúan con los diseños y ven lo que es posible.

La etapa de definición de requisitos es la que más fracasos causa en los proyectos de software. Por razones como objetivos y requisitos poco claros. Si los requisitos son incorrectos, el producto podría ser ignorado, despreciado por los usuarios o provocar desconfianza en el cliente, entre otras cosas.
Adoptar un enfoque de desarrollo centrado en el usuario seria lo ideal. Si las voces y las necesidades de los usuarios se escuchan claramente y se tienen en cuenta, entonces es más probable que el resultado final satisfaga las neceidaes y expectativas de los usuarios.

La actividad de comprender lo que debe de hacer un producto ha recibido varios nombres, por ejemplo, "recopilación de requisitos" y "captura de requisitos" ambos implican que existen requisitos y simplemente necesitamos recogerlos. La "obtención de requisitos" implica que "otros" conocen los requisitos y tenemos que hacer que nos lo comuniquen. El término "análisis de requisitos" se usa normalmente para describir la actividad de investigar y analizar un conjunto inicial de requisitos que se han recopilado, obtenido o capturado. La "ingeniería de requisitos" es un término mejor que los demás porque reconoce que el desarrollo de un conjunto de requisitos es un proceso iterativo de evolución y negociación que necesita ser cuidadosamente administrado y controlado.
El término "establecer requisitos" sirve para representar el hecho de que los requisitos surgen de las actividades de recopilación e interpretación de datos y se han establecido a partir de una comprensión sólida de las necesidades de los usuarios.

Cuando se habla de un requisito se refiere a una declaración sobre un producto previsto que especifica qué debe hacer o cómo debe funcionar.
Existen dos tipos diferentes de requisitos:

1. Funcionales: dicen lo que debe hacer el sistema. Por ejemplo, un requisito funcional para un procesador de texto puede ser que debe admitir una variedad de estilos de formato.
2. No funcionales: dicen qué restricciones hay sobre el sistema y su desarrollo. Por ejemplo, que un procesador de texto deba ser capaz de ejecutarse en una variedad de plataformas, como PC, Mac y máquinas Unix

Los requisitos de datos captura el tipo, la volatilidad, el tamaño, la persistencia, la precisión y el valor de las cantidades de datos requeridos.

Los requisitos de entorno o de contexto de uso se refieren a las circunstancias en las cuales se espera que el producto interactivo opere, existen 4 aspectos del entorno:

1. Entorno físico: se refiere a cosas como la cantidad de iluminación, ruido y polvo que se espera en el entorno operativo.
2. Entorno social: todo respecto a los aspectos sociales, como la colaboración y la coordinación que deben explorarse en el contexto del desarrollo actual
3. Entorno organizacional: un ejemplo es, qué tan bueno es el soporte de usuario y qué tan fácil se puede obtener.
4. Entorno técnico: con qué tecnologías se ejecutará el producto o con qué será compatible.

Los requisitos del usuario capturar las características del grupo de usuarios previsto. Pero además de estos, un usuario puede ser un novato, un experto, un usuario casual o frecuente. Esto afecta las formas en que se diseña la interacción. La colección de atributos para un "usuario típico" se denomina perfil de usuario.

Requisitos de usabilidad. Estos requisitos son con respecto a la facilidad con que los usuarios pueden utilizar el producto a desarrollar. Ejemplos: “El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 4 horas”, “el sistema debe proporcionar mensajes de error que sean informativos y orientados a usuario final”

La recolección de datos consiste en recopilar datos suficientes, relevantes y apropiados para que se pueda generar un conjunto de requisitos estables. Si existe un conjunto de requisitos iniciales, se requerirá la recopilación de datos para ampliar, aclarar y confirmar  esos requisitos iniciales.

Existen diversas técnicas para la recolección de datos:

• Cuestionarios: serie de preguntas diseñadas para obtener información específica de las personas. Los buenos cuestionarios obtienen respuestas a preguntas específicas de un gran grupo de personas.
• Entrevistas: implican hacerle a alguien un conjunto de preguntas (por lo general cara a cara). Es importante que los miembros del equipo de desarrollo se reúnan con las partes interesadas y que los usuarios se sientan involucrados. Las entrevistas llevan mucho tiempo y puede que no sea factible visitar a todos los usuario.
• Grupos y talleres: consiste en reunir a un grupo de las partes interesadas para discutir temas y requisitos. Pueden estar muy estructuradas con temas establecidos para el debate, o pueden ser no estructuradas (en este caso se requiere un facilitador para mantener el debate enfocado). Los grupos y los talleres son buenos para obtener una visión de consenso y/o destacar áreas de conflicto y desacuerdo. 
• Observación naturalista: implica pasar un tiempo con las partes interesadas a medida que realizan sus tareas diarias, observando el trabajo tal como sucede, en su entorno natural. Un miembro del equipo de diseño sigue a una parte interesada, toma notas, hace preguntas (pero no demasiadas) y observa lo que se está haciendo en el contexto natural de la actividad.
• Estudio de documentación: estudiar documentación es bueno para comprender la legislación y obtener información básica sobre el trabajo. No implica el tiempo de los usuarios, lo cual es un factor que limita a las otras técnicas. Los procedimientos y las reglas a menudo se escriben en manuales y estos son una buena fuente de datos sobre los pasos involucrados en una actividad. 

Las técnicas de recopilación de datos difieren en dos aspectos principales

1.  La cantidad de tiempo que toman y el nivel de detalle y riesgo asociado con los hallazgos. Por ejemplo, afirman que una observación naturalista tomará dos días de esfuerzo y tres meses de entrenamiento, mientras que las entrevistas requieren un día de esfuerzo y un mes de entrenamiento.
2.  El conocimiento que el analista debe tener sobre los procesos cognitivos básicos.

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

• Escenarios. Un escenario es una "descripción narrativa informal". Describe las actividades o tareas humanas en una historia que permite la exploración y discusión de contextos, necesidades y requisitos. No describe explícitamente el uso de software u otro soporte tecnológico para lograr una tarea. El uso del vocabulario y la redacción de los usuarios significa que los interesados pueden comprender los escenarios y que pueden participar plenamente en el proceso de desarrollo. 
• Casos de uso. Se centran en los objetivos del usuario, pero el énfasis aquí está en una interacción entre el usuario y el sistema en lugar de la tarea del usuario en sí. Un caso de uso está asociado con un actor, y el objetivo del actor en el uso del sistema es lo que el caso de uso quiere capturar. En esta técnica, el caso de uso principal describe lo que se llama el "curso normal" a través del caso de uso, es decir, el conjunto de acciones que el analista cree que se realiza con mayor frecuencia. 
• Casos de uso esenciales. 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. Esta división entre las responsabilidades del usuario y del sistema puede ser muy útil durante el diseño conceptual al considerar la asignación de tareas y el alcance del sistema, es decir, de qué es responsable el usuario y qué debe hacer el sistema.

Análisis de tareas. Se utiliza principalmente para investigar una situación existente, no para visualizar nuevos sistemas o dispositivos. Se utiliza para analizar la razón subyacente y el propósito de lo que las personas están haciendo

Análisis jerárquico de tareas. Implica dividir una tarea en subtareas y luego en otras subtareas, etc. Luego se agrupan como planes que especifican cómo se pueden realizar las tareas en una situación real. AJT se enfoca en las acciones físicas y observables que se realizan, e incluye mirar acciones que no están relacionadas con el software o un dispositivo de interacción.