Gestión de requisitos

En la fase de investigación, se recopilan los tres primeros tipos de requisitos de los usuarios, del área de negocio y del equipo de desarrollo. En cada área, se formulan preguntas similares: ¿cuáles son los objetivos?, ¿cuáles son las limitaciones?, ¿qué herramientas o procesos se utilizan actualmente?, etc. Solo cuando estos requisitos se comprenden bien se pueden desarrollar los requisitos funcionales .

Por lo general, los requisitos no pueden definirse completamente al inicio del proyecto. Algunos requisitos cambiarán, ya sea porque simplemente no se extrajeron o porque factores internos o externos influyen en el proyecto a mitad de su ciclo.

El resultado de la fase de investigación es un documento de requisitos aprobado por todos los miembros del equipo. Posteriormente, durante el desarrollo, este documento será fundamental para evitar desviaciones del alcance o cambios innecesarios. A medida que el sistema se desarrolla, cada nueva funcionalidad abre un mundo de posibilidades, por lo que la especificación de requisitos mantiene al equipo fiel a la visión original y permite un análisis controlado de los cambios de alcance.

Si bien muchas organizaciones aún utilizan únicamente documentos para gestionar los requisitos, otras gestionan sus bases de datos de requisitos mediante herramientas de software. Estas herramientas permiten gestionar los requisitos en una base de datos y, por lo general, incluyen funciones para automatizar la trazabilidad (por ejemplo, permitiendo la creación de enlaces electrónicos entre requisitos principales y secundarios, o entre casos de prueba y requisitos), la creación de bases de datos electrónicas, el control de versiones y la gestión de cambios. Normalmente, estas herramientas contienen una función de exportación que permite crear un documento de especificaciones exportando los datos de los requisitos a una aplicación de documentos estándar.

En la fase de viabilidad, se determinan los costos de los requisitos. Para los requisitos de usuario, se compara el costo actual del trabajo con los costos futuros proyectados una vez que el nuevo sistema esté en funcionamiento. Se plantean preguntas como: "¿Cuánto nos cuestan actualmente los errores de entrada de datos?" o "¿Cuál es el costo de los desperdicios debido a errores del operador con la interfaz actual?". De hecho, la necesidad de la nueva herramienta suele reconocerse cuando estas preguntas llegan a conocimiento del personal financiero de la organización.

Los costos empresariales incluirían: "¿Qué departamento tiene el presupuesto para esto?" "¿Cuál es la tasa de retorno esperada del nuevo producto en el mercado?" "¿Cuál es la tasa interna de retorno en la reducción de los costos de capacitación y soporte si creamos un sistema nuevo y más fácil de usar?"

Los costos técnicos están relacionados con los costos de desarrollo de software y los costos de hardware. "¿Contamos con el personal adecuado para crear la herramienta?" "¿Necesitamos nuevos equipos para dar soporte a las funciones ampliadas del software?" Esta última pregunta es crucial. El equipo debe analizar si las nuevas herramientas automatizadas aportarán la potencia de procesamiento suficiente para transferir parte de la carga del usuario al sistema y así ahorrar tiempo.

La pregunta también pone de relieve un punto fundamental sobre la gestión de requisitos. Un ser humano y una herramienta forman un sistema, y ​​esta comprensión es especialmente importante si la herramienta es un ordenador o una nueva aplicación. La mente humana destaca en el procesamiento paralelo y la interpretación de tendencias con datos insuficientes. La CPU destaca en el procesamiento en serie y el cálculo matemático preciso. Por lo tanto, el objetivo principal de la gestión de requisitos para un proyecto de software sería asegurar que el trabajo que se automatiza se asigne al procesador adecuado. Por ejemplo: «No obligue al usuario a recordar dónde se encuentra en la interfaz. Haga que la interfaz informe de la ubicación del usuario en el sistema en todo momento». O bien: «No obligue al usuario a introducir los mismos datos en dos pantallas. Haga que el sistema almacene los datos y complete la segunda pantalla según sea necesario».

El resultado de la fase de viabilidad es el presupuesto y el cronograma del proyecto.

Si los costos se determinan con precisión y los beneficios a obtener son suficientemente grandes, el proyecto puede pasar a la etapa de diseño. En esta etapa, la principal actividad de gestión de requisitos consiste en comparar los resultados del diseño con el documento de requisitos para asegurar que el trabajo se mantenga dentro del alcance previsto.

Una vez más, la flexibilidad es fundamental para el éxito. He aquí un ejemplo clásico de un cambio de alcance a mitad de camino que, de hecho, funcionó bien. A principios de los 80, los diseñadores de Ford esperaban que el precio de la gasolina alcanzara los 3,18 dólares por galón para finales de la década. A mitad del diseño del Ford Taurus, los precios se habían estabilizado en torno a los 1,50 dólares por galón. El equipo de diseño decidió que podrían construir un coche más grande, más cómodo y más potente si los precios de la gasolina se mantenían bajos, así que rediseñaron el vehículo. El lanzamiento del Taurus batió récords de ventas a nivel nacional, principalmente por su amplitud y comodidad de conducción.

En la mayoría de los casos, sin embargo, desviarse tanto de los requisitos originales no funciona. Por lo tanto, el documento de requisitos se convierte en una herramienta fundamental que ayuda al equipo a tomar decisiones sobre los cambios de diseño. ^{[ 7 ]}

En la fase de construcción y pruebas, la principal actividad de la gestión de requisitos consiste en asegurar que el trabajo y los costos se mantengan dentro del cronograma y el presupuesto, y que la herramienta resultante cumpla con los requisitos establecidos. Una herramienta fundamental en esta fase es la creación de prototipos y las pruebas iterativas. Para una aplicación de software, la interfaz de usuario se puede diseñar en papel y probar con usuarios potenciales mientras se desarrolla la estructura del software. Los resultados de estas pruebas se registran en una guía de diseño de interfaz de usuario y se entregan al equipo de diseño cuando estén listos para desarrollar la interfaz.

Un aspecto importante de esta etapa es la verificación. Este esfuerzo verifica que el requisito se haya implementado correctamente. Existen cuatro métodos de verificación: análisis, inspección, prueba y demostración. Los resultados numéricos de la ejecución del software o el rendimiento en una prueba de red, por ejemplo, proporcionan evidencia analítica de que se ha cumplido el requisito. La inspección de la documentación del proveedor o las hojas de especificaciones también verifica los requisitos. Probar o demostrar el software en un entorno de laboratorio también verifica los requisitos: se realizará una verificación de tipo prueba cuando se utilice equipo de prueba que normalmente no forma parte del laboratorio (o del sistema bajo prueba). Los procedimientos de prueba exhaustivos que describen los pasos y sus resultados esperados identifican claramente lo que se debe observar como resultado de realizar cada paso. Una vez completado el paso o conjunto de pasos, el resultado esperado del último paso indicará lo que se ha observado y luego identificará qué requisito o requisitos se han verificado (identificados por un número). El número, el título y la descripción del requisito se encuentran juntos en otra sección del documento de prueba.

Es prácticamente imposible que un proyecto de desarrollo de software se complete sin que se le soliciten algunos cambios. Estos cambios pueden deberse a modificaciones en el entorno en el que se prevé utilizar el producto final, cambios en el negocio, cambios en la normativa, errores en la definición original de los requisitos, limitaciones tecnológicas, cambios en el entorno de seguridad, etc. Las actividades de gestión de cambios de requisitos incluyen la recepción de las solicitudes de cambio de las partes interesadas, el registro de dichas solicitudes, el análisis y la determinación de la conveniencia y el proceso de implementación, la implementación de la solicitud de cambio , el aseguramiento de la calidad de la implementación y el cierre de la solicitud de cambio. Posteriormente, se recopilan y analizan los datos de las solicitudes de cambio, se derivan las métricas pertinentes y se integran en el repositorio de conocimiento de la organización. ^{[ 8 ]}

La gestión de requisitos no finaliza con el lanzamiento del producto. A partir de ese momento, se recopilan los datos sobre la aceptabilidad de la aplicación y se incorporan a la fase de investigación de la siguiente generación o versión. De este modo, el proceso vuelve a empezar.