Pasos de la Gestión de Requerimientos

Por Joaquín Ibáñez Marimón, PMP® [ Acerca del autor]

Una descripción simplificada de la gestión de requerimientos contiene los siguientes pasos principales:

Establecer un plan de gestión de requisitos
Una de las primeras tareas en el proyecto es desarrollar un Plan de gestión de requerimientos (RMP son sus siglas en ingles). El RMP describe el enfoque general para gestionar los requerimientos del proyecto. El documento detalla cómo se generan, organizan, modifican y trazan los requerimientos en el ciclo de vida del proyecto. También describe todos los tipos de requerimientos y los atributos utilizados en el proyecto. Algunas cuestiones que debe clarificar el RPM son:

• ¿Cómo deben usarse las herramientas de gestión de requerimientos?
• ¿Qué tipos de requerimientos serán trazados en el proyecto?
• ¿Cuáles son los atributos de estos requerimientos?
• ¿Dónde se crearan los requerimientos-en una base de datos o solo en documentos?
• ¿Entre cuales requerimientos necesitamos implementar trazabilidad?
• ¿Qué documentos se requieren?
• ¿Qué requerimientos y documentos serán utilizados como contrato con un proveedor? ¿Qué metodología será utilizada?
• ¿El cliente necesita algún documento específico para cumplir con su proceso de desarrollo?
• ¿Cómo se implementará la gestión de cambios?
• ¿Qué proceso garantizará que todos los requerimientos serán implementados y comprobados?
• Qué requerimientos u opiniones necesitamos para generar informes?

Técnicas para la recopilación de requerimientos
La recopilación de requerimientos es un paso muy importante. Un error o mala interpretación de un requisito en esta etapa propagará el problema a través del ciclo de vida de desarrollo.

En muchos proyectos es más fácil agrupar todas las entradas de los interesados en un mismo tipo de requerimiento,. En otros proyectos, puede haber la necesidad de distinguir entre "necesidades de los interesados", que describen los requisitos iniciales, y "solicitudes de los interesados ", que pueden incluir las solicitudes de cambio posterior.

Entrevistas: Son utilizadas para recopilar información de los interesados. Sin embargo, la predisposición y experiencias de la persona entrevistada influirán en la obtención de resultados. Es conveniente la utilización de preguntas abiertas que no sugieran una determinada respuesta.

Análisis de Documentos: Todo establecimiento de requisitos implica un cierto estudio de los documentos que definen la razón de ser del proyecto, tales como planes de negocio, estudios de mercado, contratos, etc.…

Tormenta de ideas: Es una técnica eficaz porque las ideas más creativas y efectivas, son a menudo, el resultado de la combinación de ideas aparentemente inconexas. Además, esta técnica alienta el pensamiento de ideas inusuales.

Talleres de Requisitos: Pueden estar diseñados para alcanzar la unificación de criterios en cuanto a los requisitos de una capacidad en concreto. Conviene que sean dirigidos y coordinados por un experto, y son normalmente cortos (uno o varios días). Otras ventajas que a menudo consiguen es alentar el compromiso de los participantes con el proyecto, fomentando el espíritu de grupo

Creación de prototipos: Consiste en la creación de una versión rápida y poco depurara de un sistema o partes del mismo. Con dicho prototipo, los usuarios y diseñadores tendrán una idea clara de las capacidades del sistema., aunque podría tener la percepción de que los desarrolladores están en un estadio del diseño más avanzado de lo que realmente están, sugiriendo una impresión de los plazos de finalización demasiado optimista.

Casos de uso: Es una representación gráfica de las acciones que debe realizar un sistema. Deben complementarse siempre con atributos de calidad y otras informaciones tales como características de la interfaz.

Los casos de uso por sí sola no proporcionan suficiente información que permita actividades de desarrollo.

Guiones gráficos: Son un conjunto de dibujos que representan un conjunto de actividades de usuario que describen las que se producen en un sistema o capacidad existente o prevista. Los guiones gráficos son una especie de prototipos de papel. Los clientes, usuarios o desarrolladores dibujan pantallas, cuadros de diálogo, barras de herramientas y otros elementos que creen que deberá proporcionar el software. Los guiones gráficos son baratos y permiten eliminar los riesgos y costos más elevados de creación de prototipos.

Análisis de interfaces: El diseño incorrecto de las interfaces es a menudo una de las principales causas de sobrecoste y fracaso del producto. La identificación temprana de las características de las interfaces externas clarifica el ámbito de aplicación de producto, ayuda en el proceso de evaluación del riesgo, reduce los costos de desarrollo del producto, y mejora la satisfacción del cliente.

Modelado: Es una representación de la realidad que pretende facilitar la comprensión. El uso de prototipos y modelos ayuda a eliminar ambigüedades y contradicciones, contribuyendo de forma notable al éxito del proyecto.

Desarrollo el documento de visión
Es un documento de visión es un documento que describe la 'visión', o plan general, para un determinado proceso de software. Pretende ser un documento de alto nivel más breve y general que un documento de requisitos de producto, y en él se describe lo que se espera llevar a cabo y las características que no están en el alcance, pero que se prevé agregarán al producto en posteriores etapas del desarrollo de éste

El propósito del documento es recopilar y analizar las ideas que han surgido para el futuro del producto, y asegurarse de que los interesados clave tienen una visión clara y compartida de los objetivos y alcance del proyecto. Identifica alternativas y los riesgos asociados con el proyecto. Por último, presenta un presupuesto para la fase de planificación.

Durante el desarrollo del documento de visión, uno de los logros principales del análisis de negocio es que se deriven características para las necesidades de los interesados. Las características deben tener todos los atributos de un buen requerimiento: Verificable, no redundante, claro….

El documento de visión debe contener la información esencial acerca del sistema que está siendo desarrollado. Además de listar todas sus características, debe contener:

• Una descripción general del producto.
• Un sumario con las capacidades del sistema.
• Toda la información que pueda ser requerida para comprender el propósito del sistema.

También pueden listarse todas las necesidades de los interesados que no fueron recogidas en otros documentos

Crear casos de uso
Los requerimientos funcionales se describen mejor en forma de casos de uso, que se derivan de las características. Un caso de uso es una descripción de un sistema en términos de una secuencia de acciones. Debe ser un resultado observable o un valor para el actor (un actor es alguien o algo que interactúa con el sistema).

Los casos de uso:

• Son iniciados por un actor
• Modelan la interacción entre el interesado y el sistema
• Describen una secuencia de acciones
• Capturan los requerimientos funcionales
• Proporcionan algún valor para un actor
• Representan un completo y significativo flujo de eventos.

Especificación suplementaria
Las especificaciones suplementarias recogen aquellos requerimientos no funcionales (usabilidad, fiabilidad, rendimiento,..) y algunos requerimientos funcionales internos del sistema que, por tanto, son difíciles de contemplar en los casos de uso.

Creación de casos de prueba a partir de casos de uso
Tan pronto como se recopilan todos los requisitos, deberíamos diseñar una forma de comprobar si se implementan correctamente en el producto final. Los casos de prueba mostrarán a los evaluadores qué pasos deben realizarse para probar todos los requisitos. En este paso nos concentraremos en la creación de casos de prueba a partir de casos de uso.

Creación de casos de prueba a partir de especificaciones complementarias
El enfoque utilizado en el paso anterior no se aplica a las pruebas de los requisitos complementarios. Dado que estos requisitos no se expresan como una secuencia de acciones, el concepto de escenarios no se les aplica, y debe desarrollarse un enfoque individual a cada uno de los requisitos complementarios.

En este paso, también se diseñarán pruebas de infraestructura y cuestiones relacionadas con la plataforma.

Diseño del sistema
Los requisitos son la base para el diseño del sistema, que a menudo se ve facilitada por el uso del lenguaje unificado de modelado (UML)

Bibliografía:

Young, Ralph R, “Recommended Requirements Gathering Practices”,STSC, Abril 2002.
Gottesdiener, Ellen, “Good Practices for Developing User Requirements” , STSC, Marzo 2008.
Zielczynski, Peter . “Requirements Management Using IBM® Rational® RequisitePro®”, IBM Press., 2008.