Ø
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.
Se obtiene mediante el Diagrama de Flujo de
Datos (DFD), el Diccionario de Datos (DD) y la Especificación de Procesos à DeMarco (finales años
70).
