Identififying needs and establishing requirements

Sea cual sea la sitación inicial, y sea cual sea el objetivo del proyecto, las necesidades del usuario, requirimientos, aspiraciones y expetaciones tienen que ser discutidos, refinados, clarificados, y probablemente cambiar su alcance. Esto requiere un entendimiento de, entre otras cosas, las condiciones bajo las cuales el producto será usado, y las restricciones (constraints) en el desempeño del producto.

Tal como Don Norman decía en su capitulo Design Thinking y el proceso del diseño, entender la forma en el que las personas usarían el producto, a partir de un design research.

La actividad del diseño va orientado hacia dos objetivos:

1. Ententeder, tanto como sea posible, de los usuarios.
2. Producir a partir de las necesidades indentificadas. 

Los dos puntos anteriores, al tener como objetivo, producir un conjunto de requerimientos, también le es conocido como actividad de requerimientos.  Con esta actividad, se trata de hacer al los requisitos tan específicos, inequívocos y claros como sea posible.

Un requerimiento es una declaración sobre un producto que especifica qué debe hacer o cómo debe realizarse. 

La recopilación de datos resulta ser una actividad muy importante, ya que de ellos se desprenderán los requisistos, pero para desprenderlos, hay que saber recopilarlos, analizarlos e interpretarlos, por lo que debe realizarse con base a un marco, teoría o hipótesis, y debe llevarse a cabo con buenas técnicas. Así como en ingeniería de software, donde tenemos entrevistas, cuestionarios, juntas, etc.

Cuando los requerimientos son erróneos, el producto puede llegar a ser completamente ignorado, o incluso despreciado por los usuarios, creando conflictos de productividad para quienes deben usarlo. Así que adoptar un enfoque centrado en el usuario, escuchando sus necesidades, y tomarlas en cuenta, puede conllevar a un resultado que satisfagan las necesidades y expectativas de los usuarios.

Un diseño interactivo requiere que entendamos la funcionalidad requerida y las resrticciones bajo las cuales el producto debe operar, o ser desarrollado.

Hay dos tipos de requisitos:

1. Funcionales — Dicen lo que el sistema debe hacer. Estos requesitos son muy importantes para productos interactivos.
2. No Funcionales — Dicen qué limitaciones hay en el sistema y su desarrollo. 

El autor del libro, aborda una categorización sobre otros tipos de requisitos que pueden ser tomados en cuenta al momento de recopilarlos:

• Requisitos de Datos (Data requirement) — Recogen el tipo, la volatilidad, la magintud, la persistencia, la precisión y el valor de las cantidades de los datos requeridos. Todos los dispositivos interactivos tienen que manejar cantidades mayores o menores de datos. 
• Requisitos de entorno o contexto (Enviromental requirements or context) — Se refieren a las circuntancias en las que se espera que el producto interactivo funcione. Aspectos a ser considerados en este tipo de requesitos:
• Entorno físico
• Entorno Social
• Entorno Organizacional
• Entorno Técnico  

• Requisitos de usuario (User requirements) — Captan las características del grupo de usuarios deseados: sus habilidades y destrezas. 
• Requisitos de usabilidad (Usability requirements) — Captan los objetivos de usabilidad y medidas asociadas para un producto en particular: eficacia, eficiencia, seguridad, utilidad, capacidad de aprendizaje y memorización. Estos requisitos conllevan una estrecha relación hacia los usuarios para quienes está orientado el producto. 

Aún exisitiendo un conjunto inicial de requisitos, es necesario la recopilación de datos para ampliar, aclarar y confirmarlos. 

Entre las técnicas de repilación de datos tenemos:

• Cuestionarios — brindan datos específicos.
• Entrevistas — hacen que la gente explore las cuestiones.
• Grupos de enfoque y talleres — permiten lograr una opinión de conseso y/o destacar áreas de conficto y desacuerdo.
• Observación naturalista — ayuda a comprender la naturaleza de las tareas y el contexto en el que se realizan.
• Estudiar la documentación — es bueno para entender la legislación y obtener antecedentes del trabajo. 

Hay que ser cuidadoso al elegir entre las técnias, ya que no tener expereciencia respecto a una, puede resultar en desperdiciar tiempo y dinero, así que hay que considerar los recursos con los que se cuenta.

Algunas pautas básicas a tener en cuenta para una buena recopilación de datos son:

• Organizar una primera sesión de recolección de datos.
• Identificar las necesidades de los interesados.
• Involucrar tanta gente como sea posible, mientras más opiniones, mejor.
• Combinar diversas técnicas de recopilación de datos. 
• Usar apoyos, como prototipos, durante las sesiones de recolección de datos.
• Relizar un piloto de la recolección de datos, para comprobar si puede ser efectivo.

Después de la primera reunión, es buena idea comenzar la interpretación de y análisis de los datos, ya que hay una experiencia fresca, recién salida del horno, en la mente, así también es buena idea discutir los hallazgos con otros, para obtenre distitnas perspectivas de la información.

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

Algunas formas de anilizar y documentar requisitos funcionales han sido a través de diagramas de flujo, diagramas de estado y diagramas de flujo de trabajo.

Por otra parte, cuatro técnicas que tiene un enfoque centrado en el usuario,  y se utilizan pra comprender las metas y tareas de los usuarios:

1. Escenarios
2. Casos de uso
3. Casos de uso esenciales
4. Análisis de tareas

Con todo esto, la actividad de requisistos se itera varias veces antes de que evolucione a un conjunto de requisitos estables. Además, tales técnicas no son mutuamente excluyentes, y normalmente se usan en combinación, para capturar diferentes perspectivas o para documentar etapas durante el ciclo de vidal desarrollo.

Escenarios — Descripción narrativa informal. Describe actividades o tareas humanas en forma de historia, y permite explorar y discutir contextos, necesidades y requerimientos. Sin embargo, no describe explícitamente el uso de software u otro soporte tecnológico para lograr una tarea.

Casos de uso — Hace enfásis en la interacción usuario-sistema en lugar de la propia tarea del usuario. El caso de uso principal describe el conjunto de acciones que el analista cree que se realizan más comúnmente por un actor (usuario).

Casos de uso esencial — Es una combinación mejorada de los escenarios y los casos de uso. En sí, es una narración estructurada que consta de tres partes:

1. Nombre : expresa la intención general del usuario
2. Descripcion escalonada : de las acciones del usuario
3. Descripción escalonada : dde la responsabilidad del sistema. 

 El análisis de tareas es una actividad que se realiza para analizar la razón subyacente y el propósito de lo que la gente está haciendo. La información que se obtiene establece una base de prácticas existentes sobre las cuales se pueden construir nuevos requisitos. Es muy parecido a lo que se raliza en el design research, del que hablaba Don Norma, en donde se realiza una investagación observando a las personas, y tratan de entendér porqué hacen lo que hacen.

Una técnica de análisis de tareas es el Análisis de tareas jerárquicas (HTA), el cual fue diseñado para identificar las necesidades de capacitación. Se trata de romper una tarea en subtareas y luego más subtareas, y de esta manera sucesivamente. Después se agrupan como planes que especifican cómo se pueden realizar tales tareas en una situación real.

Este capitulo es lo mismo que en el curso de análisis de requerimiento en ingeniería de software, no trata mucho de psicología  como hablaba Don Norman. Aunque una parte que se le parace mucho al proceso del diseño, es el hecho de tener que entender a los usuarios que utilizarían un producto, hay que entender lo que hacen, porqué lo hacen, y con ello sentar las bases del diseño del producto, el cual hay que prototipar y probar duante un proceso que también es iterativo, y en cada iteración, hay un retreoalimentación por parte de los usuarios y desarrolladores con el fin de acercarse más a las expectativas de los usuarios y tener un sistema que cumpla con los conceptos del buen diseño: undestability y usability.