¿Cómo llevamos a cabo el análisis de requisitos?

¿Cómo es el proceso de planificación?

El análisis de requisitos se incluye en el proceso de planificación, que, a su vez, debe ser el siguiente:

1. A proyecto visión que describe la producto a crear.
2. Un plan de acción o idea general que establece lo que hay que hacer para alcanzar nuestros objetivos.
3. Lista de tareas básicas que determinan las fases de trabajo en el proyecto.
4. Planificación temporal, en la que definimos qué y cuándo debe entregarse.
5. Planificación detallada de las tareas individuales creadas durante la tercera fase.

El análisis de requisitos abarca los tres primeros puntos del proceso de planificación.

Visión del proyecto

Llegados a este punto, deberíamos plantearnos algunas preguntas básicas:

1. ¿Qué queremos hacer?

Seguramente, a estas alturas, ya somos conscientes de lo que pretendemos, y la idea del proyecto hace tiempo que está presentada y pensada, pero merece la pena profundizar en ella. Quizá descubramos nuevas cuestiones que merezca la pena explicar. Las siguientes cuestiones pueden ser útiles en este sentido:

• ¿Qué problema debe resolver este proyecto?
• ¿Quién será su usuario final?
• ¿Estamos creando una interfaz para los usuarios? ¿Está prevista su creación en el futuro? ¿Se ha determinado el tipo de interfaz que creamos (de escritorio o móvil)? ¿Nos importa el RWD?
• ¿Existen aplicaciones similares? ¿Cuáles son sus ventajas e inconvenientes?
• ¿Se ha creado ya algún diseño inicial o maqueta sobre el proyecto?
• ¿Dependerá el proyecto de alguna aplicación externa? ¿Tienen o conocemos sus limitaciones?
• ¿Sabemos algo sobre el rendimiento esperado y el nivel de seguridad?

2. ¿Cuáles son los requisitos?

Ha llegado el momento de establecer una lista de requisitos fijados para el proyecto. Además de los requisitos funcionales, especificamos los que no están relacionados con las funcionalidades: usabilidad, capacidad de respuesta, velocidad, rendimiento y seguridad.

Comprobemos si cada uno de los requisitos cumple los siguientes criterios:

• es completa: tenemos su imagen completa,
• es correcta, veraz y esperada,
• es factible - factible y otros requisitos no lo niegan,
• es necesario: es necesario para que el sistema funcione o lo exige el cliente,
• sea inequívoca, legible e imposible de malinterpretar,
• es verificable: después de la aplicación, mediante la observación y las pruebas, es posible determinar si este requisito se ha cumplido o no.

3. ¿Cuál es el objetivo final?

Aquí merece la pena crear una visualización sencilla del funcionamiento del proyecto. Nada ayuda más a comprender la idea del proyecto que dibujar un flujo básico o simplemente escribir en la pizarra en puntos lo que va a suceder a continuación. En el caso de una aplicación con interfaz de usuario, lo ideal es disponer incluso de las maquetas más sencillas.

4. ¿Cuáles son las prioridades?

Al igual que cuando se construye una casa, los proyectos informáticos deben partir de cero al principio y luego centrarse en lo que más se necesita. Por lo tanto, al principio, a partir de la lista de requisitos, es necesario especificar una lista de todas las posibles funciones que desempeñará un proyecto determinado y, a continuación, acordar cuáles de ellas tienen la máxima prioridad y deben llevarse a cabo lo antes posible y cuáles son del tipo "nice-to-have".

El resultado de toda la fase de visualización del proyecto debe ser una imagen general de cómo debe funcionar el proyecto, ya sea a través de maquetas o del flujo de actividades dibujado. También deberíamos recibir una lista de todas las posibles funciones que debe cumplir un determinado proyecto y saber también qué prioridad tiene cada una de ellas.

La visualización del proyecto es un momento clave durante el análisis de los requisitos. Ayuda a comprender a fondo la esencia del problema, y cuanto mejor sea el material que lo ilustre, más eficaces serán las siguientes fases de planificación.

Plan de acción

En esta fase, ya determinamos cómo imaginamos el funcionamiento del proyecto en su conjunto. Es bueno tener unas cuantas ideas de aplicación, pensar y discutir cada una de ellas, y destacar sus puntos débiles y fuertes. También merece la pena dibujar aquí en detalle una idea elegida, si no todas.

Esta fase también es el momento de considerar cuestiones puramente tecnológicas, no sólo en qué lenguaje o marco se escribirá el proyecto, sino también qué herramientas adicionales necesitaremos, por ejemplo, ¿decidimos utilizar el AWS stack o quizá algo más. Si estamos dudando entre algunas tecnologías o no tenemos ni idea de qué utilizar, merece la pena desplazar esa decisión en el tiempo y delegarla en una tarea de investigación. Por supuesto, sólo podremos hacerlo si la planificación posterior no se ve bloqueada por dicha investigación. De lo contrario, podemos asignarlas con seguridad a las tareas de la sprint.

Tareas principales

Una vez establecido el plan del proyecto, procedemos a definir las tareas principales, que luego serán discutidas en detalle y desglosadas en tareas más pequeñas por el desarrollo equipo al planificar un nuevo sprint. Es importante describir cada tarea con la mayor precisión posible.

Resumen

Como ya se ha mencionado, el proceso de análisis de requisitos variará en función de la complejidad del proyecto. Hay problemas más fáciles y más difíciles, y también los hay que ya han sido resueltos por alguien y otros completamente nuevos en los que hay que detenerse más tiempo. En cualquier caso, hay algunos consejos importantes que conviene tener en cuenta:

• Comunicación. Es el componente más importante de todo ciclo de vida de un proyecto; todo debe estar claramente definido y explicado.
• Comprender rápidamente el problema. Está muy bien tener escrita la documentación del proyecto, pero recordemos que debe ser lo más concisa posible y no ocupar mil páginas. Cada miembro del equipo de desarrollo debe tener acceso a ella y debe poder comprender rápidamente la visión del proyecto.
• Simplicidad ante todo. Intentemos que lo que planifiquemos sea lo más sencillo posible, elijamos soluciones más simples que puedan desarrollarse fácilmente en el futuro, o renunciemos a ellas cuando surja la necesidad.
• No lo vas a necesitar. Teniendo en cuenta que en programación nos guiamos por el principio YAGNI, aquí, lo tenemos en la nuca y no aceleramos demasiado.
• Los cambios. No les tengamos miedo; tarde o temprano todo proyecto los necesita. Además, no nos engañemos pensando que lo que planifiquemos hoy funcionará siempre. Al mismo tiempo, no debemos tratar los cambios como algo malo e indeseable. Los cambios deben ser sinónimo de mejora, y eso es lo que queremos: que el proyecto sea el mejor.
• El tiempo. No dejemos que la planificación se alargue demasiado y se eternice. Si tenemos un problema que nos bloquea, busquemos soluciones fuera o elijamos la opción más fácil.

Siempre vale la pena recordar los aspectos anteriores al analizar los requisitos, y entonces todo irá sobre ruedas y será la base de un proyecto bien planificado.

Más información:

• ¿Cuál es el mejor enfoque de gestión de proyectos para el desarrollo de software?
• Buenas prácticas de Codest para la creación de software. Nuestro enfoque del recorrido del cliente
• Una guía rápida para crear y desarrollar su propio mercado. ¿Qué merece la pena saber?