---AR.gif "Modelo de Proceso")
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 system85" [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.
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.
