La gestión de requisitos es el proceso de documentar, analizar , rastrear , priorizar y acordar los requisitos y luego controlar los cambios y comunicarlos a las partes interesadas relevantes. Es un proceso continuo a lo largo de un proyecto. Un requisito es una capacidad a la que debe ajustarse el resultado de un proyecto (producto o servicio).
El propósito de la gestión de requisitos es garantizar que una organización documente, verifique y satisfaga las necesidades y expectativas de sus clientes y partes interesadas internas o externas. [1] La gestión de requisitos comienza con el análisis y obtención de los objetivos y limitaciones de la organización. La gestión de requisitos incluye además el apoyo a la planificación de los requisitos, la integración de los requisitos y la organización para trabajar con ellos (atributos de los requisitos), así como las relaciones con otra información que cumpla con los requisitos y los cambios para estos.
La trazabilidad así establecida se utiliza en la gestión de requisitos para informar el cumplimiento de los intereses de la empresa y las partes interesadas en términos de cumplimiento, integridad, cobertura y coherencia. Las trazabilidades también apoyan la gestión de cambios como parte de la gestión de requisitos al comprender los impactos de los cambios a través de requisitos u otros elementos relacionados (por ejemplo, impactos funcionales a través de relaciones con la arquitectura funcional) y facilitar la introducción de estos cambios. [2]
La gestión de requisitos implica la comunicación entre los miembros del equipo del proyecto y las partes interesadas, y el ajuste a los cambios de requisitos a lo largo del proyecto. [3] Para evitar que una clase de requisitos anule a otra, la comunicación constante entre los miembros del equipo de desarrollo es fundamental. Por ejemplo, en el desarrollo de software para aplicaciones internas, la empresa tiene necesidades tan fuertes que puede ignorar los requisitos del usuario o creer que al crear casos de uso , se están atendiendo los requisitos del usuario.
La trazabilidad de requisitos se ocupa de documentar la vida de un requisito. [4] Debería ser posible rastrear hasta el origen de cada requisito y, por lo tanto, cada cambio realizado en el requisito debería documentarse para lograr la trazabilidad. [5] Incluso el uso del requisito después de que se hayan implementado y utilizado las características implementadas debe ser rastreable. [5]
Los requisitos provienen de diferentes fuentes, como la persona de negocios que solicita el producto, el gerente de marketing y el usuario real. Todas estas personas tienen diferentes requisitos para el producto. Al utilizar la trazabilidad de requisitos, se puede rastrear una característica implementada hasta la persona o grupo que la deseaba durante la obtención de requisitos . Esto se puede utilizar, por ejemplo, durante el proceso de desarrollo para priorizar el requisito, [6] determinando qué tan valioso es el requisito para un usuario específico. También se puede utilizar después de la implementación, cuando los estudios de usuarios muestran que una función no se utiliza, para ver por qué era necesaria en primer lugar.
En cada etapa de un proceso de desarrollo , existen actividades y métodos clave de gestión de requisitos. A modo de ejemplo, considere un proceso de desarrollo estándar de cinco fases con las etapas de Investigación, Viabilidad, Diseño, Construcción y Prueba, y Lanzamiento.
En Investigación, las tres primeras clases de requisitos se obtienen de los usuarios, de la empresa y del equipo de desarrollo. En cada área se hacen preguntas similares; cuáles son los objetivos, cuáles son las limitaciones, cuáles son las herramientas o procesos actuales, etc. Sólo cuando estos requisitos se comprendan bien se podrán desarrollar requisitos funcionales .
En el caso común, los requisitos no se pueden definir completamente al comienzo del proyecto. Algunos requisitos cambiarán, ya sea porque simplemente no se extrajeron o porque fuerzas internas o externas en funcionamiento afectan el proyecto a mitad del ciclo.
El entregable de la etapa de Investigación es un documento de requisitos que ha sido aprobado por todos los miembros del equipo. Más adelante, en pleno desarrollo, este documento será fundamental para evitar cambios de alcance o cambios innecesarios. A medida que se desarrolla el sistema, cada nueva característica abre un mundo de nuevas posibilidades, por lo que la especificación de requisitos ancla al equipo a la visión original y permite una discusión controlada del cambio de alcance. [ cita necesaria ]
Si bien muchas organizaciones todavía utilizan únicamente documentos para gestionar los requisitos, otras gestionan sus líneas base de requisitos utilizando herramientas de software. Estas herramientas permiten gestionar los requisitos en una base de datos y, por lo general, tienen funciones para automatizar la trazabilidad (por ejemplo, al permitir la creación de enlaces electrónicos entre los requisitos principales y secundarios, o entre casos de prueba y requisitos), creación de líneas de base electrónicas, control de versiones y gestión del cambio. Por lo general, estas herramientas contienen una función de exportación que permite crear un documento de especificación exportando los datos de requisitos a una aplicación de documento estándar. [ cita necesaria ]
En la etapa de Factibilidad se determinan los costos de los requisitos. Para los requisitos del usuario, el costo actual del trabajo se compara con los costos futuros proyectados una vez que el nuevo sistema esté implementado. Se formulan preguntas como estas: “¿Cuánto nos cuestan ahora los errores de entrada de datos?” O "¿Cuál es el costo del desperdicio debido a un error del operador con la interfaz actual?" En realidad, a menudo se reconoce la necesidad de la nueva herramienta cuando estas preguntas llegan a la atención del personal financiero de la organización.
Los costos comerciales incluirían: "¿Qué departamento tiene el presupuesto para esto?" "¿Cuál es la tasa de rendimiento esperada del nuevo producto en el mercado?" "¿Cuál es la tasa interna de retorno al reducir 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. "¿Tenemos las personas adecuadas para crear la herramienta?" "¿Necesitamos nuevos equipos para soportar funciones de software ampliadas?" Esta última pregunta es de un tipo importante. El equipo debe investigar si las herramientas automatizadas más nuevas agregarán suficiente potencia de procesamiento para trasladar parte de la carga del usuario al sistema y ahorrar tiempo a las personas.
La pregunta también señala 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 una computadora o una nueva aplicación en una computadora. La mente humana sobresale en el procesamiento paralelo y la interpretación de tendencias con datos insuficientes. La CPU destaca en el procesamiento en serie y en el cálculo matemático preciso. Por lo tanto, el objetivo general del esfuerzo de gestión de requisitos para un proyecto de software sería garantizar que el trabajo que se automatiza se asigne al procesador adecuado. Por ejemplo, “No hagas que el humano recuerde dónde está en la interfaz. Haga que la interfaz informe la ubicación del humano en el sistema en todo momento”. O “No hagas que el humano ingrese los mismos datos en dos pantallas. Haga que el sistema almacene los datos y complete la segunda pantalla según sea necesario”.
El entregable de la etapa de Viabilidad es el presupuesto y el cronograma del proyecto.
Suponiendo que los costos se determinen con precisión y que los beneficios que se obtendrán sean suficientemente grandes, el proyecto puede pasar a la etapa de Diseño. En Diseño, la principal actividad de gestión de requisitos es comparar los resultados del diseño con el documento de requisitos para asegurarse de que el trabajo se mantenga dentro del alcance.
Una vez más, la flexibilidad es primordial para el éxito. Aquí hay una historia clásica de cambio de alcance a mitad de camino que realmente funcionó bien. Los diseñadores de automóviles Ford a principios de los años 80 esperaban que los precios de la gasolina alcanzaran 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 centrado en alrededor de 1,50 dólares el galón. El equipo de diseño decidió que podían construir un automóvil más grande, más cómodo y más potente si los precios de la gasolina se mantenían bajos, por lo que rediseñaron el automóvil. El lanzamiento del Taurus estableció récords de ventas a nivel nacional cuando salió el nuevo automóvil, principalmente porque era muy espacioso y cómodo de conducir.
Sin embargo, en la mayoría de los casos, apartarse hasta ese punto de los requisitos originales no funciona. Por tanto, el documento de requisitos se convierte en una herramienta fundamental que ayuda al equipo a tomar decisiones sobre cambios de diseño. [7]
En la etapa de construcción y prueba, la actividad principal de la gestión de requisitos es garantizar que el trabajo y los costos se mantengan dentro del cronograma y el presupuesto, y que la herramienta emergente realmente cumpla con los requisitos establecidos. Una herramienta principal utilizada en esta etapa es la construcción de prototipos y las pruebas iterativas. Para una aplicación de software, la interfaz de usuario se puede crear en papel y probar con usuarios potenciales, mientras se construye el marco 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. Hay 4 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 de 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 producirá un tipo de verificación de prueba cuando se utilice equipo de prueba que normalmente no forma parte del laboratorio (o sistema bajo prueba). Los procedimientos de prueba integrales que describen los pasos y los resultados esperados identifican claramente lo que se verá como resultado de realizar el paso. Después de completar el paso o conjunto de pasos, el resultado esperado del último paso indicará lo que se ha visto y luego identificará qué requisito o requisitos se han verificado (identificados por número). El número de requisito, el título y la palabrería están unidos en otra ubicación del documento de prueba.
Difícilmente se podría completar un proyecto de desarrollo de software sin que se le solicitaran algunos cambios. Los cambios pueden deberse a cambios en el entorno en el que se prevé utilizar el producto terminado, cambios comerciales, cambios regulatorios, errores en la definición original de requisitos, limitaciones en la tecnología, cambios en el entorno de seguridad, etc. Las actividades de gestión de cambios de requisitos incluyen recibir las solicitudes de cambio de las partes interesadas, registrar las solicitudes de cambio recibidas, analizar y determinar la conveniencia y el proceso de implementación, la implementación de la solicitud de cambio, el control de calidad para la implementación y el cierre de la solicitud de cambio. Luego, los datos de las solicitudes de cambio se compilan, analizan y se derivan las métricas apropiadas que se integran en el depósito de conocimientos de la organización. [8]
La gestión de requisitos no termina con el lanzamiento del producto. A partir de ese momento, los datos que llegan sobre la aceptabilidad de la aplicación se recopilan y se introducen en la fase de investigación de la próxima generación o versión. Así el proceso comienza de nuevo.
Adquirir una herramienta para respaldar la gestión de requisitos no es un asunto trivial y debe emprenderse como parte de una iniciativa más amplia de mejora de procesos. Durante mucho tiempo se ha percibido que una herramienta, una vez adquirida e instalada en un proyecto, puede abordar todas sus necesidades relacionadas con la gestión de requisitos. Sin embargo, la compra o el desarrollo de una herramienta para respaldar la gestión de requisitos puede ser una decisión costosa. Las organizaciones pueden verse agobiadas por costosos contratos de soporte, un esfuerzo desproporcionado puede desviarse hacia aprender a usar la herramienta y configurarla para abordar necesidades particulares, y un uso inadecuado que puede conducir a decisiones erróneas. Las organizaciones deben seguir un proceso incremental para tomar decisiones sobre herramientas que respalden sus necesidades particulares dentro del contexto más amplio de su proceso de desarrollo y herramientas. [9] Las herramientas se presentan en Trazabilidad de requisitos .
{{cite journal}}: Citar diario requiere |journal=( ayuda )