La comunicación con los usuarios es un aspecto prioritario para las empresas que desarrollan sistemas software; aun así confían más en la experiencia acumulada que no en la aplicación de métodos pensados para capturar la experiencia de los usuarios y sus verdaderas necesidades. Sin embargo, cuando se analizan las razones por las cuales no se alcanzan correctamente dichas necesidades de los usuarios las compañías suelen otorgar la culpabilidad a los propios usuarios, argumentando “que no describieron correctamente sus necesidades, que cambian de pensamiento fácilmente, que tienen diferentes puntos de vista o simplemente que éstos no saben cómo diseñar un producto interactivo”. Lo que nunca piensan es que si hubieran aplicado correctamente las técnicas del análisis de requisitos centradas en los usuarios se habrían ahorrado estos problemas —y los usuarios estarían satisfechos— [LIU03].
Como vemos, el concepto que en última instancia establece la calidad de un sistema software viene determinado a partir de la concordancia entre los requisitos fijados y la consecución de los mismos.
Los requisitos de un sistema interactivo hasta hace poco únicamente hacían referencia a la componente funcional dejando otras connotaciones fuera del alcance del sistema. Afortunadamente, hoy en día los aspectos relacionados con los usuarios y con el uso que éstos realizan de los sistemas acaparan mayor grado de interés.
Esta fase del modelo de proceso se fundamenta en la Ingeniería de los Requisitos especificada en el Capítulo 2 y en el modelo de calidad definido en el estándar ISO/IEC 9126-1 [ISO01], que describe la calidad de los requisitos del sistema en las etapas iniciales del ciclo de vida refiriéndose principalmente a la vista externa y a la vista del usuario más que en referencia a la calidad interna o funcional, que es a la que únicamente hacen referencia los desarrolladores.
Este modelo de calidad hace especial énfasis en la consecución de la necesaria y suficiente calidad para ser capaces de encontrar las verdaderas necesidades de los usuarios como objetivo prioritario. Tarea que no resulta nada fácil puesto que las necesidades que los usuarios exteriorizan habitualmente difieren de sus necesidades reales. Los usuarios, por ejemplo, no son siempre conscientes de sus verdaderas necesidades las cuales, además, evolucionan con el uso del sistema.
Análisis
El punto de vista que de la fase del Análisis de Requisitos realiza la Ingeniería del Software (IS) «clásica» establece los servicios que el sistema debe proporcionar y las restricciones bajo las cuales debe operar. Se especifican las condiciones que determinan qué debe hacer el sistema y cómo debe hacerlo, o sea requisitos:
- Funcionales, que describen una funcionalidad o un servicio del sistema.
- No funcionales, que suelen ser restricciones al sistema (p. e., tiempo de respuesta) o para su proceso de desarrollo (utilizar un determinado lenguaje).
Por otra parte, los modelos de Ingeniería de los Requisitos añaden nuevos factores a tener en cuenta que, de realizarse, garantizarán el desarrollo de un sistema con un grado mucho tanto desde el punto de vista funcional como de su usabilidad y de su accesibilidad.
Aun así, las aproximaciones al desarrollo de software «centradas en el usuario» reconocen que es imposible especificar todos los requisitos por adelantado [BRO95].
Los clientes no pueden apreciar sus necesidades reales hasta que no pueden ver e interactuar con las opciones de que disponen (muchos requisitos son descubiertos una vez los usuarios interactúan con el «runnig prototype» [BRO95]); o incluso más, no aprecian las nuevas tecnologías hasta que no las prueban, simplemente porque las desconocen. No se sabe lo que se ha desarrollado hasta que no se ha realizado el primer «wrong system» [ROS02a].
De las afirmaciones anteriores se deduce que será imposible determinar todos estos objetivos en una primera fase o visita con el cliente. Deberá ser el propio Equipo de Desarrollo quien, haciendo uso de las técnicas de prototipaje y evaluación referenciadas por el modelo de proceso junto con las actividades de protección de la Gestión de la Configuración, GC, (explicada en el apartado 2.2.4.1), sea capaz de definir toda esta información lo más detallada y efectivamente posible.
¡Aun así, los cambios son inevitables!, por lo que tenemos la obligación de reducir su número y disminuir al máximo el impacto de los mismos.
El modelo de proceso, MPIu+a, utiliza parte de la GC de la IS a la que le aplica un cambio decisivo para conseguir el deseado diseño centrado en el Usuario: En la IS el Diseño de las Interfaces se aborda después de haber especificado el diseño de los datos, el arquitectónico y el de los módulos, mientras que en el MP el Diseño de las Interfaces pasa a primer término y el resto viene condicionado, si procede, a la Interfaz.
El enfoque del diseño de la interfaces de usuarios desde el punto de vista de la Ingeniería del Software y de la Ingeniería de la Usabilidad es parecido pero distinto
Este cambio, aunque parece menor e insignificante, es altamente determinante, pues ello conlleva a una total reorientación en la forma de trabajar con muchas connotaciones colaterales. Vincular el diseño de la estructura interna del sistema al diseño de su interfaz introduce, por ejemplo, cambios en la estructura de las Bases de Datos debidos a una especificación impuesta por un requisito de la interfaz.
Vídeo + Transparencias + contenido adicional
Ampliación del contenido del DCU como concepto en el módulo 4.- Análisis de Requisitos que forma parte del Curso Interacción Persona-Ordenador.