Capitulo 7 - Identifying Needs and Establishing Requirements del libro Interaction Design beyond human-computer interaction de John Wiley & Sons, Inc.
¿Qué estamos tratando de lograr en esta actividad de diseño?
Un objetivo es comprender tanto como sea posible acerca de los usuarios, su trabajo y el contexto de ese trabajo, para que el sistema en desarrollo pueda ayudarlos a alcanzar sus objetivos; A esto lo llamamos "identificar necesidades". Partiendo de esto, nuestro segundo objetivo es producir, a partir de las necesidades identificadas, un conjunto de requisitos estables que forman una base sólida para avanzar hacia la reflexión sobre el diseño.
En términos generales, las actividades de requisitos progresan de manera secuencial:
- primero recopilan algunos datos,
- luego los interpretan,
- luego extraen algunos requisitos, pero se vuelven mucho más desordenados que esto,
- y las actividades influyen mutuamente a medida que el proceso se repite.
Identificar necesidades y establecer requisitos es en sí misma una actividad iterativa en la que las subactividades se informan y refinan entre sí. No dura un número determinado de semanas o meses y luego termina. En la práctica, los requisitos evolucionan y se desarrollan a medida que las partes interesadas interactúan con los diseños y ven lo que es posible y cómo ciertas instalaciones pueden ayudarlos.
La importancia de hacerlo bien
Adoptar un enfoque de desarrollo centrado en el usuario es una forma de evitar que surjan problemas de claridad y falta de detalle en los requisitos que produzcan que el proyecto fracase. 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 necesidades y expectativas de los usuarios.
¿Porqué establecer requisitos?
La actividad de comprender lo que debe hacer un producto ha recibido varias etiquetas, por ejemplo:
- recopilación de requisitos,
- captura de requisitos,
- obtención o elicitación de requisitos,
- análisis de requisitos,
- ingeniería de requerimientos
"Elicitación" implica que "otros" (presumiblemente los clientes o usuarios) conocen los requisitos y tenemos que hacer que nos lo comuniquen. Sin embargo, los requisitos no son tan fáciles de identificar. Podría argumentar que, en algunos casos, los clientes deben saber cuáles son los requisitos porque conocen las tareas que deben realizarse y pueden haber pedido que se cree un sistema en primer lugar.
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, y uno que necesita ser cuidadosamente administrado y controlado.
Establecer requisitos se refiere 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.
¿Qué son los requisitos?
Un requisito es una declaración sobre un producto previsto que especifica qué debe hacer o cómo debe funcionar. Uno de los objetivos de la actividad de requisitos es hacer que los requisitos sean tan específicos, inequívocos y lo más claros posible
Diferente tipos de requerimientos:
- requisitos funcionales, que dicen lo que debe hacer el sistema. Capturan lo que el producto debe hacer.
- requisitos no funcionales, que dicen qué restricciones existen sobre el sistema y su desarrollo.Un requisito no funcional para un procesador de texto podría ser que debe ser capaz de ejecutarse en una variedad de plataformas, como PC, Mac y máquinas Unix. Otra podría ser que debe poder funcionar en una computadora con 64 MB de RAM.
Los requisitos de datos capturan el tipo, la volatilidad, el tamaño, la persistencia, la precisión y el valor de las cantidades de datos requeridos.
Los requisitos ambientales o el contexto de uso se refieren a las circunstancias en las cuales se espera que el producto interactivo opere. Deben tenerse en cuenta cuatro aspectos del medio ambiente al establecer los requisitos.
Primero está el entorno físico, como la cantidad de iluminación, ruido y polvo que se espera en el entorno operativo.
El segundo aspecto del entorno es el entorno social. Las cuestiones planteadas con respecto a los aspectos sociales del diseño de interacción, como la colaboración y la coordinación, deben explorarse en el contexto del desarrollo actual.
El tercer aspecto es el entorno organizacional, por ejemplo, qué tan bueno es el soporte para el usuario, qué tan fácil se puede obtener.
Finalmente, será necesario establecer el entorno técnico: por ejemplo, ¿con qué tecnologías se ejecutará el producto o con qué será compatible, y qué limitaciones tecnológicas podrían ser relevantes?
Los requisitos del usuario capturan las características del grupo de usuarios previsto, sus habilidades y destrezas. Pero además de estos, un usuario puede ser un novato, un experto, un usuario casual o frecuente.
Los requisitos de usabilidad capturan los objetivos de usabilidad y las medidas asociadas para un producto en particular. Los requisitos de usabilidad están relacionados con otros tipos de requisitos que debemos establecer, como los tipos de usuarios que se espera que interactúen con el producto.
Recolección de datos
El propósito de la recopilación de datos es recopilar datos suficientes, relevantes y apropiados para que se pueda generar un conjunto de requisitos estables. Incluso 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 de recolección de datos que pueden ser combinadas:
Cuestionarios: Son una serie de preguntas diseñadas para obtener información específica de nosotros. Los cuestionarios bien diseñados son buenos para obtener respuestas a preguntas específicas de un gran grupo de personas, y especialmente si ese grupo de personas se extiende por un área geográfica amplia, por lo que no es factible visitarlos a todos.
Entrevistas: Las entrevistas implican hacerle a alguien un conjunto de preguntas. Las entrevistas se pueden clasificar en términos generales como estructuradas, no estructuradas o semiestructuradas, dependiendo de cuán rigurosamente el entrevistador se apegue a un conjunto de preguntas preparado. Es importante que los miembros del equipo de desarrollo se reúnan con los interesados y que los usuarios se sientan involucrados. Las entrevistas consumen mucho tiempo y quizá no sea posible visitar a todas las personas pensadas.
Grupos focales y talleres: Como alternativa o como corroboración, puede ser muy revelador reunir a un grupo de partes interesadas para discutir temas y requisitos. Estas sesiones pueden estar muy estructuradas con temas establecidos para el debate, o pueden ser no estructuradas. En este último caso, se requiere un facilitador que pueda mantener el debate en la pista y pueda proporcionar el enfoque o la redirección necesarios cuando sea apropiado.
Son buenos para obtener una visión de consenso y / o destacar áreas de conflicto y desacuerdo.
Observación naturalista. Puede ser muy difícil para los humanos explicar lo que hacen o incluso describir con precisión cómo logran una tarea. La observación 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 un interesado, toma notas, hace preguntas (pero no demasiadas) y observa lo que se está haciendo en el contexto natural de la actividad.
Estudiar documentación. Los procedimientos y las reglas a menudo están escritos en manuales y estos son una buena fuente de datos sobre los pasos involucrados en una actividad y cualquier regulación que rija una tarea. Estudiar documentación es bueno para comprender la legislación y obtener información básica sobre el trabajo. Tampoco implica el tiempo de las partes interesadas, lo cual es un factor limitante en las otras técnicas.
Olson y Moran (1996) sugieren que elegir entre técnicas de recopilación de datos se basa en dos cuestiones: la naturaleza de la técnica de recopilación de datos en sí y la tarea a estudiar.
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.
Interpretación y análisis de datos
El objetivo de la interpretación es comenzar a estructurar y registrar descripciones de requisitos.
Un análisis más centrado de los datos seguirá a la interpretación inicial. 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 se han analizado y documentado tradicionalmente mediante diagramas de flujo de datos, diagramas de estado, diagramas de flujo de trabajo, etc. Los requisitos de datos se pueden expresar mediante diagramas de entidad relación, por ejemplo. Si el desarrollo es adoptar un enfoque orientado a objetos, los requisitos funcionales y de datos se combinan en diagramas de clase, y el comportamiento se expresa en gráficos de estado y diagramas de secuencia, entre otros.
Descripción de Tareas
Cada uno de estos puede usarse para describir tareas existentes o tareas previstas con un nuevo mecanismo.
Escenarios: Un escenario es una "descripción narrativa informal" (Carroll, 2000). Describe las actividades o tareas humanas en una historia que permite la exploración y discusión de contextos, necesidades y requisitos.
Casos de Uso: Los casos de uso también se centran en los objetivos del usuario, pero el énfasis aquí está en una interacción entre el usuario y el sistema, más que en la tarea del usuario. Un caso de uso está asociado con un actor, y el objetivo del actor en el uso del sistema que el caso de uso quiere capturar.
Casos de uso esenciales:
Los casos de uso esenciales representan abstracciones de los escenarios, es decir, representan un caso más general de lo que representa un escenario, y tratan de evitar los supuestos de un caso de uso tradicional. 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.
Análisis de Tareas
El 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: ¿qué están tratando de lograr, por qué están tratando de lograrlo y cómo lo están haciendo? La información obtenida del análisis de tareas establece una base de prácticas existentes sobre las cuales construir nuevos requisitos o diseñar nuevas tareas.
El análisis jerárquico de tareas (HTA) implica dividir una tarea en subtareas y luego en subtareas, etc. Luego se agrupan como planes que especifican cómo se pueden realizar las tareas en una situación real.
El punto de partida es un objetivo del usuario. Esto se examina y se identifican las principales tareas asociadas con el logro de ese objetivo. En su caso, estas tareas se subdividen en subtareas.
Conclusiones
La identificación de las necesidades y la generación es importante, y es más importante tomarse el tiempo de hacer estas actividades de manera adecuada dentro del diseño centrado en el humano, ya que es en lo que parte esta metodología, en saber lo que los usuarios necesitan, sus deseos y para esto hay que interactuar con ellos aplicando distintas técnicas de recolección de datos como entrevistas, encuestas, etnografía, porque lo principal de la metodología es el humano y diseñar un producto correcto y agradable al usuario. Los requerimientos de usabilidad son muy importantes en esta metodología, ya que permiten conocer el nivel de experiencia que los usuarios finales tendrán; además de que establecen si el sistema contendrá elementos que harán que a los usuarios se les facilite la interacción en él.
En la Ingeniería en Software, el no tener bien establecidos los requisitos, ocasiona muchas veces que el proyecto falle, o que no resulte como el cliente esperaba. Además de que los costos se van incrementando cuando se va avanzando cada vez en el proyecto y en los requisitos no se han resuelto lo problemas. Usar la metodología de HCD es importante en un proyecto y muchas veces hay que tomarle prioridad y combinar esta metodología con otras que usemos para tener las posibilidad de generar un producto con requerimientos bien establecidos y un diseño agradable y funcional.
La identificación de las necesidades y la generación es importante, y es más importante tomarse el tiempo de hacer estas actividades de manera adecuada dentro del diseño centrado en el humano, ya que es en lo que parte esta metodología, en saber lo que los usuarios necesitan, sus deseos y para esto hay que interactuar con ellos aplicando distintas técnicas de recolección de datos como entrevistas, encuestas, etnografía, porque lo principal de la metodología es el humano y diseñar un producto correcto y agradable al usuario. Los requerimientos de usabilidad son muy importantes en esta metodología, ya que permiten conocer el nivel de experiencia que los usuarios finales tendrán; además de que establecen si el sistema contendrá elementos que harán que a los usuarios se les facilite la interacción en él.
En la Ingeniería en Software, el no tener bien establecidos los requisitos, ocasiona muchas veces que el proyecto falle, o que no resulte como el cliente esperaba. Además de que los costos se van incrementando cuando se va avanzando cada vez en el proyecto y en los requisitos no se han resuelto lo problemas. Usar la metodología de HCD es importante en un proyecto y muchas veces hay que tomarle prioridad y combinar esta metodología con otras que usemos para tener las posibilidad de generar un producto con requerimientos bien establecidos y un diseño agradable y funcional.
Comentarios
Publicar un comentario