Los Requisitos según Metodología Métrica V3

Ø  Proceso EVS (Estudio de Viabilidad del Sistema): La actividad EVS 3 (Definición de Requisitos del Sistema) incluye la determinación de los requisitos generales mediante una serie de sesiones de trabajo con los usuarios participantes que hay que planificar y realizar. Una vez finalizadas, se analiza la información obtenida definiendo los requisitos y sus prioridades y se incorporan al catálogo de requisitos que servirá para el estudio y valoración de las distintas alternativas de solución que se propongan.

§  Tarea EVS 3.1: Identificación de las directrices técnicas y de gestión

§  Tarea EVS 3.2: Identificación de requisitos

§  Tarea EVS 3.3: Catalogación de requisitos

Ø  Proceso ASI (Análisis del Sistema de Información): En la actividad ASI 2 (Establecimiento de Requisitos) se lleva a cabo la definición, análisis y validación de los requisitos a partir de la información facilitada por el usuario, completándose el catálogo de requisitos obtenido en la definición del sistema. El objetivo de esta actividad es obtener un catálogo detallado de los requisitos a partir del cual se pueda comprobar que los productos generados en las actividades de modelización se ajustan a los requisitos de usuario.

§  Tarea ASI 2.1: Obtención de requisitos

§  Tarea ASI 2.2: Especificación de casos de uso

§  Tarea ASI 2.3: Análisis de requisitos

§  Tarea ASI 2.4: Validación de requisitos

OBTENCIÓN DE REQUISITOS

Se recoge información de los requisitos que debe cumplir el software, teniendo en cuenta las posibles restricciones del entorno, tanto hardware como software, que puedan afectar al sistema de información. Asimismo, también se definen las prioridades que hay que asignar a los requisitos, considerando los criterios de los usuarios acerca de las funcionalidades a cubrir.

ESPECIFICACIÓN DE CASOS DE USO

Es preciso especificar información relativa a la descripción del escenario, es decir, cómo un actor interactúa con el sistema y cuál es la respuesta obtenida; a las precondiciones y poscondiciones; a la identificación de interfaces de usuario y a las condiciones de fallo que afectan al escenario, así como la respuesta del sistema.

ANÁLISIS DE REQUISITOS

Detectar inconsistencias, ambigüedades, duplicidad o escasez de información. También se analizan las prioridades establecidas por el usuario y se asocian los requisitos relacionados entre sí.

VALIDACIÓN DE REQUISITOS

Mediante esta tarea los usuarios confirman que los requisitos especificados en el catálogo de requisitos, así como los casos de uso, son válidos, consistentes y completos.

Ø  Actividad ASI 9 (Análisis de consistencia y especificación de requisitos): tiene por objeto garantizar la calidad de los distintos modelos generados en el Análisis y asegurar que los usuarios y los analistas tienen el mismo concepto del sistema. Se verifica la calidad técnica de cada modelo, se asegura la coherencia entre los distintos modelos y se valida el cumplimiento de los requisitos. En esta actividad también se elabora el documento ERS, como producto para la aprobación formal, por parte del usuario, de las especificaciones del sistema.

§  Tarea ASI 9.1: Verificación de los modelos

§  Tarea ASI 9.2: Análisis de la consistencia entre modelos

§  Tarea ASI 9.3: Validación de los modelos

§  Tarea ASI 9.4: Elaboración del ERS (Especificación de Requisitos Software)

OTROS ESTÁNDARES

El estándar IEEE 1362-1998 utiliza el formato DRU (Documento de Requisitos de Usuario) y el estándar IEEE 830-1998 utiliza el formato ERS (Especificación de Requisitos de Software).

Ø  Mientras el DRU se concentra en exponer el problema por el usuario o personas sin conocimiento del software, el ERS se concentra en la solución a dichos problemas y está escrito por profesionales, pero con un lenguaje entendible por todos.