Empezaré con una afirmación tajante: si quieres que tu aplicación web se resuelva con éxito cierra correcta y completamente el análisis de requerimientos. De no ser así el resultado será insatisfactorio siempre. Lo siento para todos aquellos que quieren desembarazarse de previos al desarrollo. Esto es así. No he visto en todos los proyectos en los que he participado nada que desmienta esta afirmación. Y más importante todavía no conozco a través de nadie o de la literatura ejemplos o afirmaciones contrarias.
La toma de requerimientos y su análisis es la pieza clave del desarrollo de aplicaciones web. Me remitiré a lo comentado al respecto por Paul Grünbacher en libro Web Engineering, The Discipline of Systematic Development of Web Applications: ".. los requerimientos a menudo no son descritos de forma apropiada o puede estar especificados de manera ambigura, vaga o incorrecta. Las típicas consecuencias de requerimientos pobres son la baja aceptación del usuario o cliente, fallos de planificación o arquitecturas de software inadecuadas".
Si somos sensibles a lo comentado entiendo que nos preocuparemos en tener un documento vivo de requerimientos y procedimentada su gestión. Sin embargo esto no es suficiente si estamos hablando de aplicaciones web. Las aplicaciones web son multidisciplinares porque requieren la participación de expertos en diferentes campos: multimedia, SEO, contenidos, arquitectos de software, especialistas en bases de datos, .. También es un hecho de que una parte de los participantes de la definición de los requerimientos no están disponibles, como pueden ser un colectivos de usuarios de una plataforma de la que se quiere soporte. Y cuando están disponibles participan del lema IKIWISI (I know It When I See It), que quiere decir que no saben con certeza que quieren hasta que lo vean ejecutandose. Y es posible además que lo quieran ver sobre contenidos que ellos mismos gestionan. En sí, los propios requerimientos, son muy volátiles y las restricciones sobre entornos aparecen y desaparecen con más frecuencia de la que podemos gestionar. Y como la web incluyen nuevas técnicas cada día es dificil tener un equipo cualificado y con experiencia un mes tras otro.
Hay que cumplir unos principios básicos en la definición y análisis de requerimientos, y para los que vienen del desarrollo clásico y estructurado algún sacrificio:
- Entender el contexto de proyecto. Una solución web muy extrañamente se desarrollará como solución aislada a un problema o demanda sino que formará parte de un conjunto ya funcionando. Es importante que el equipo de desarrolladores lo entiendan.
- Implicar a todos los participantes. El desarrollo de aplicaciones web implica a muchos actores. Como ya hemos mostrado antes hay personal que dota de contenidos, personal de posicionamiento, consultores de negocio, el mismo equipo de desarrollo, miembros del equipo de sistemas, usuarios finales, .. Que complicado es hacer que todas estas partes representadas tomen conciencia de que son parte del éxito o fracaso del proyecto y que deben participar de forma coordinada y activa de la definición y análisis de requerimientos.
- Definir de forma iterativa los requerimientos. La definición de requerimientos en un proyecto web puedo decir que no se cierra ni cuando sube el nuevo desarrollo a producción. Está en continuo cambio. Que se echen las manos a la cabeza los clásicos gestores de desarrollo de software pero en el mundo web a cada momento se puede encontrar una personalización, una actualización, una ampliación al conjunto de usuarios, .. un afinamiento a la definición original. Pero no se tiene que pensar en una caos o anarquia total del "quiero que tenga...". La definición de requerimientos clave (entendidos como los que definen la arquitectura del sistema, diferentes escenarios o planning de proyecto) tiene que tener una fecha límite y consenso de todas las partes. Más allá de esto, el resto de requrimientos participan de la propia flexibilidad de la web y de la comprensión en ello de la dirección.
- Enfocar la arquitectura del sistema. Como hemos indicado en el punto anterior encontrar la arquitectura del sistema y construir alrededor de ella el resto de requerimientos es el camino adecuado para desarrollar aplicaciones flexibles y escalables.
