El documento describe los 5 pasos del proceso de requisitos de software según la métrica V3. Estos incluyen la identificación de requisitos funcionales y no funcionales a través de sesiones con usuarios, la definición y el establecimiento detallado de requisitos, el análisis de consistencia entre los modelos, y el establecimiento de requisitos de implantación. El objetivo general es desarrollar un catálogo completo y validado de requisitos del software a través de la participación de múltiples partes interesadas

1. Requisitos del Software (Según Métrica V3)
1. Identificación de requisitos en PSI4. En esta actividad se elabora el primer Catálogo de
requisitos (información de la organización) a través de sesiones de trabajo (JRP) entre
los Consultores y Usuarios expertos analizando cada proceso, tal y como debería ser, y
NO según la situación actual.
2. Definición de requisitos en EVS3. Igualmente se utilizan sesiones de trabajo (JAD), esta
vez entre los Usuarios Expertos, Jefe de Proyecto y Analistas. Los resultados se
añaden al Catálogo de requisitos (funcionales y no funcionales) y se obtiene la
Identificación de requisitos y el Catálogo de normas.
3. Establecimiento de requisitos en ASI2. Continuarán las sesiones de trabajo para
completar el Catálogo de requisitos pasando a ser el Catálogo detallado de requisitos
(funcionales, de rendimiento, de seguridad, implantación y disponibilidad). Además en
esta actividad en la que sólo participan los Usuarios expertos y los Analistas (se
descuelga el Jefe de Proyecto) se especifican los Casos de uso, técnica obligatoria en OO
y, opcional en Estructurado.
Finalmente se analizan los requisitos mediante prioridades y relaciones entre ellos y se
validan por los usuarios confirmando que son válidos, completos y consistentes.
4. Análisis de consistencia y especificación de requisitos en ASI9. El objetivo aquí es
garantizar la calidad de los requisitos mediante las siguientes tareas:
◦ Verificación de la calidad técnica de los modelos.
◦ Aseguramiento la coherencia de los modelos.
Los análisis de consistencia propuestos en Estructurado son:
- Modelo Lógico de Datos Normalizado / Modelo de Procesos: Almacenes de datos
con las entidades o atributos de una entidad. Uso de caminos de acceso lógicos y
cálculos de acceso.
- Modelo Lógico de Datos Normalizado / Interfaz de Usuario: Diálogos de la interfaz
de usuario con el modelo lógico de datos.
- Modelo de Procesos / Interfaz de Usuario:Todo proceso en línea tiene asociado al
menos un diálogo.
Los análisis de consistencia propuestos en OO son:
- Modelo de Clases / Diagramas Dinámicos:
Mensajes entre objetos con el diagrama de interacción. Diagramas de transición de
estados se corresponden con operaciones de la clase.
- Modelo de clases / Interfaz de usuario: Clases de interfaz de usuario con el
modelo de clases.
- Análisis de la Realización de los Casos de Uso / Interfaz de Usuario: Navegación
entre pantallas con el diagrama de interacción de objetos.
◦ Validación del cumplimiento de los requisitos a través de los modelos.
Además, como producto final se elabora el documento de Especificación de
Requisitos del Software con el siguiente índice (diferente del IEEE 830-1993):
- Introducción.
- Ámbito y alcance.
- Participantes.
- Requisitos del sistema de información.
- Visión general del sistema de información.
- Referencia de los productos a entregar.
- Plan de acción.
5. El establecimiento de requisitos de implantación en DSI11 completa el Catálogo de
requisitos con los correspondientes a la implantación, documentación y control de
versiones. Vuelven las sesiones de trabajo con el Jefe de Proyecto, Analistas,
Usuarios expertos, Directivos y Responsables de operación y sistemas.