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.

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? …

La gestión de requerimientos, entendida como el conjunto de actividades que abarcan la recopilación, control, análisis, filtrado y documentación de los requisitos del sistema, consiste en tres actividades fundamentales:

Generación de requerimientos

Es la habilidad de entender las necesidades de los interesados, y recopilarlos en un repositorio para futuros análisis. Las necesidades pueden ser expresadas de forma abstracta y en términos de problemas (Quiero reducir mis ratios de error en un 35%) o bien concretos y en términos de una solución (Debe haber un botón rojo de paro en la consola).
En ambos casos las necesidades son conocidas como características.

Evaluación de requerimientos

Es la habilidad de discernir qué características son apropiadas para incluir en el producto, dado que raramente es posible satisfacer todas las características demandadas por cada uno de los interesados. La evaluación tiene en consideración todas las realidades del mercado y toma la decisión acerca de qué características se implementarán, cuales lo serán en la próxima versión, y cuales se aplazarán hasta más tarde.

Especificación de requerimientos

Es la habilidad de detallar el comportamiento de un sistema. En cada estadio del proceso de desarrollo, variaran la forma y el nivel de detalle en la especificación de los requerimientos. Para ilustrarlo, considérese un proceso estándar de desarrollo en 5 fases: Investigación, Viabilidad, diseño, construcción y test, lanzamiento. …

Según el origen y características, los requisitos pueden dividirse en diferentes tipos. que pueden representarse en forma de pirámide, en cuyo nivel superior se sitúan las necesidades de los interesados. En los niveles más bajos están características, casos de uso y requisitos complementarios, tal como se muestra en la figura:

• Necesidad: Un interesado demanda un requerimiento.

• Característica: Un servicio proporcionado por el sistema, por lo general formulado por un analista de negocios.

• Caso de uso: Una descripción del comportamiento del sistema descrito como una secuencias de acciones

• Requisito complementario: Otro requisito (generalmente no funcional) que no puede ser contemplado en los casos de uso

• Caso de prueba: Una especificación de las entradas necesarias para una prueba, las condiciones de ejecución y resultados esperados. Tiene el papel de comprobar si los casos de uso derivados de los casos de prueba y los requisitos complementarios se aplican correctamente

• Escenario: Una secuencia específica de acciones o una ruta de acceso específica a través de un caso de uso. Ayudan a derivar en casos de uso a partir de los casos de prueba y facilitan el diseño e implementación a través de los casos de uso.

Con bastante frecuencia, a diferentes niveles de los requisitos, se especifican diferentes niveles de detalle. Cuanto menor sea el nivel, más detallado es el requisito. Sin embargo, corresponde a los analistas de negocio decidir el nivel de detalle en cada nivel, aunque no sería incorrecto establecer requisitos muy detallados en el nivel de necesidades.