12 Nov Los requerimientos funcionales en desarrollo de software
Uno de los aspectos esenciales en el desarrollo de software es definir claramente el alcance del mismo, y dentro del ciclo de vida del desarrollo las actividades más importantes desde nuestro concepto, son la definición de los requerimientos, funcionales y no funcionales, esto es el pilar de la construcción de la solución. Comencemos hablando de requerimientos funcionales y su definición.
“Los requerimientos funcionales son las descripciones explicitas del comportamiento que debe tener una solución de software y que información debe manejar.”
Por lo tanto, los requerimientos funcionales:
- Expresan las capacidades o cualidades que debe tener la solución para satisfacer los requerimientos de los interesados de proyecto.
- Se expresan en términos de cuál debe ser el comportamiento de la solución y que información debe manejar.
- Deben proporcionar una descripción lo suficientemente detallada para permitir el desarrollo e implementación de la solución.
- Son los que más influyen en si la solución será aceptada o no por los usuarios.
La identificación, análisis y gestión de los requerimientos funcionales es una actividad crítica en el desarrollo de software. La gestión de los requerimientos funcionales deficiente, es citada como una de las causas más frecuentes en el fracaso de los proyectos, es por ello que es importante entender que son los requerimientos funcionales, bajo qué metodologías deben identificarse y gestionarse para asegurar el logro de los objetivos.
Importancia de definir los requerimientos
Los problemas y errores en la gestión de requerimientos funcionales son citados como una de las causas más frecuentes que ocasionan insatisfacción de las expectativas de los interesados en proyectos de software.
Profundizando en las causas de estos problemas, las situaciones observadas con mayor frecuencia son:
- Requerimientos funcionales con descripciones muy ambiguas, produciendo interpretaciones inadecuadas por parte del equipo de desarrollo.
- El requerimiento funcional no fue entendido adecuadamente cuando fue levantado con el interesado, pasando información incorrecta al equipo de desarrollo.
- En su forma original, el requerimiento funcional no era factible técnicamente y el equipo de desarrollo realizó modificaciones que no fueron aprobadas por los interesados.
Es fundamental la aplicación de metodologías probadas de gestión de requerimientos funcionales que eviten que estos problemas sucedan, algunas de las prácticas más recomendadas son:
- Ante la presencia de ambigüedades, solicitar información adicional, mesas de trabajo o reuniones con los interesados. Es menos costoso esperar a obtener una descripción que aclare las dudas antes que asumir y avanzar en el desarrollo.
- Validar las descripciones escritas de los requerimientos funcionales antes de comenzar su desarrollo.
- Cualquier duda que presente el equipo de desarrollo buscar comunicación con los interesados para su resolución.
- Si durante el desarrollo se presentará la necesidad de modificar algún requerimiento funcional debido a razones técnicas, solicitar mesas de trabajo o reunir, no proceder con un desarrollo e implementación que no ha sido validado por los interesados.
Siguiendo estas prácticas podemos asegurar una mejor aceptación de los requerimientos funcionales cuando llegue el momento de la implementación.
Los requerimientos funcionales en un enfoque
Bajo un enfoque de proyecto predictivo, esto es, un proyecto de software ejecutado con la metodología de ciclo de vida de desarrollo de sistema (Cascada), esto es, el desarrollo del sistema se realiza el fases claramente delimitadas, el análisis, diseño, desarrollo, pruebas e implementación de la solución.
En la metodología cascada, el desarrollo de un nuevo sistema o requerimiento funcional individual siempre comienza con una fase de levantamiento y análisis, caracterizada por los siguientes aspectos:
- Especialistas conocidos como Analistas de negocio (Business Analyst) realizan reuniones con los interesados (Por ejemplo los usuarios de la nueva solución) para levantar cuáles son sus requerimientos.
- Se utilizan distintas técnicas de levantamiento de requerimientos funcionales, como pueden ser las entrevistas, mesas de trabajo o lluvia de ideas.
- De todo este proceso surge un documento de requerimientos de software que describe la funcionalidad que se espera de la nueva solución.
- Para que el enfoque sea exitoso, el documento debe ser lo más detallado posible. Sin embargo, un problema es que al tener que ser detallado, los revisores pueden verse abrumados, ocasionado que ciertos errores no sean identificados.
- Una vez aprobado, el documento de requerimientos de software se convierte en un contrato, cualquier aspecto que el equipo de desarrollo no implemente se convierte en una causa de no aceptación. Por otro lado, cualquier aspecto adicional o cambio solicitado por los interesados debe llevar un proceso de cambio de alcance.
¿Bajo este enfoque que es un requerimiento funcional? Pues es un comportamiento o funcionalidad que debe ser cumplida con rigurosidad y exactitud por la solución implementada.
Como se sabe, el surgimiento de las metodologías ágiles ha devenido en muchas críticas al enfoque predictivo, sin embargo, es necesario que entendamos que existen situaciones en las que de hecho el enfoque predictivo es el más recomendable, de igual forma, ya no hay verdades absolutas, esto se demuestra en la versión 7 del PMBook – La biblia del desarrollo de proyectos con enfoque predictivo, ha incorporado el agilismo e incluso se mencionan procesos híbridos.
En situaciones donde tenemos una solución conocida, los estándares para implementar nuevos requerimientos funcionales están definidos y existe claridad en las reglas por todas las partes, el enfoque predictivo es el que da los mejores resultados.
Los requerimientos funcionales en las metodologías
Las metodologías ágiles establecen un enfoque más flexible sobre lo que es un requerimiento funcional, los proyectos son ejecutados en iteraciones cortas se fomenta una mayor constante interacción entre usuario y desarrolladores abrazando el cambio en lugar de rechazarlo.
Por ejemplo en el marco de trabajo Scrum:
- El dueño de producto (Product Owner) es el que tiene la responsabilidad de la gestión de los requerimientos funcionales.
- Sostiene reuniones con los interesados e identifica los requerimientos funcionales los cuales luego lleva al equipo de desarrollo de software.
- Para las reuniones con los interesados también pueden aplicarse técnicas de levantamiento de requerimientos, como por ejemplo las entrevistas, mesas de trabajo, entre otras.
- Una de las formas de documentar los requerimientos funcionales en metodologías agiles es la historia de usuario.
- La intención es que las historias de los usuarios sean el inicio y no el final de las conversaciones entre usuarios e interesados sobre la funcionalidad que debe tener el software.
- El enfoque ágil fomenta la constante comunicación entre interesados y usuarios, los requerimientos funcionales se van elaborando progresivamente, priorizando para el desarrollo los que estén definidos sin ambigüedades.
¿Bajo este enfoque que es un requerimiento funcional? Pues es un comportamiento o funcionalidad que debe ser cumplida con rigurosidad y exactitud por la solución implementada.
Como se sabe, el surgimiento de las metodologías ágiles ha devenido en muchas críticas al enfoque predictivo, sin embargo, es necesario que entendamos que existen situaciones en las que de hecho el enfoque predictivo es el más recomendable, de igual forma, ya no hay verdades absolutas, esto se demuestra en la versión 7 del PMBook – La biblia del desarrollo de proyectos con enfoque predictivo, ha incorporado el agilismo e incluso se mencionan procesos híbridos.
En situaciones donde tenemos una solución conocida, los estándares para implementar nuevos requerimientos funcionales están definidos y existe claridad en las reglas por todas las partes, el enfoque predictivo es el que da los mejores resultados.
¿Bajo este enfoque Qué es un requerimiento funcional? Pues es un elemento que se documenta como una historia de usuario que puede ser elaborado progresivamente y modificado en función de las necesidades del negocio.