PROCESOS DE LA INGENIERIA DE REQUERIMIENTOS.

PROCESOS DE LA INGENIERIA DE REQUERIMIENTOS.

INTRODUCCIÓN

CONCEPTOS BASICOS

¿Qué es un requerimiento?

 Requerimiento (Requirement).

 Requisito. Circunstancia, condición (Larousse).

 Requerimiento. Necesitar, tener precisión de algo

 (Larousse).

 Básicamente un requerimiento es una característica

 que se debe exhibir un software para solucionar un

 cierto problema del mundo real.

DIMENSIONES DE LOS REQUERIMIENTOS

Ámbito: esta dimensión indica en qué ámbito se debe entender el requerimiento. Un ámbito de sistema indica que el requerimiento debe cumplirse a nivel de sistema, entendiendo por sistema un conjunto de hardware y software.

Característica: esta dimensión clasifica los requerimientos en función de la naturaleza de la característica del sistema deseada que se especifica. La clasificación más habitual suele ser la de requerimientos funcionales (qué funciones debe realizar el sistema) y no funcionales (otras características del sistema).

Los requerimientos funcionales se refieren a la funcionalidad que tendrá el software.

Ejemplo: Permitirá el cálculo de la nómina cada quincena

Los requerimientos no funcionales son cualidades o restricción que debe tener el software.

Ejemplo: Debe correr bajo Windows 95.

Audiencia: Esta dimensión fundamental, indica la audiencia a la que está dirigido el requerimiento, es decir, las personas que deben ser capaces de entenderlo.

En general, se pueden distinguir dos tipos de audiencia, los clientes y usuarios, que no tienen porqué tener formación en ingeniería del software, y los desarrolladores de software.

DEFINICIÓN DE INGENIERÍA DE REQUERIMIENTOS

La IR es el proceso sistemático para desarrollar requerimientos a través de un proceso cooperativo e iterativo de análisis del problema, documentación de las observaciones resultantes en varios formatos de representación y verificación de la precisión del entendimiento ganado

OBJETIVO DE INGENIERÍA DE REQUERIMIENTOS

Especificar los requerimientos con claridad y detalle para:

1. Construir un sistema que satisfaga los requerimientos del cliente.

2. Se pueda verificar objetivamente que el sistema cumple esos requerimientos.

3. La ingeniería de requerimientos es un proceso iterativo.

4. Las iteraciones se repiten de común acuerdo entre el equipo de desarrollo y el cliente.

11.1.- ANALISIS DE REQUISITOS.

El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software.

El análisis de requisitos permite al ingeniero de sistemas especificar la función y el rendimiento del software, indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

El análisis de requisitos permite al ingeniero del software ( a menudo llamado analista en esta función) refinar la definición del software y construir los modelos de los dominios de datos, funcional y de comportamiento que van a ser tratados por el software.

El análisis de requisitos proporciona modelos al diseñador del software que pueden traducirse en el diseño de datos, arquitectónico, de interfaz y procedimental.

El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: (1) reconocimiento del problema, (2) evaluación y síntesis, (3) modelado, (4) especificación y (5) revisión.

La meta del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el usuario o el cliente.

11.2.- TÉCNICAS DE COMUNICACION.

El análisis de requisitos del software siempre empieza con la comunicación entre dos o más partes. Un cliente tiene un problema que pretende sea resuelto con una solución basada en computadora.

Un desarrollador responde a la solicitud de ayuda del cliente. La comunicación ha empezado. Pero como ya hemos señalado, el camino de la comunicación al entendimiento está a menudo lleno de baches.

11.2.1.-Inicio del Proceso.

La técnica de análisis más usada para cubrir el hueco de comunicación entre el cliente y el desarrollador y para empezar el proceso de comunicación es llevar a cabo una reunión o entrevista preliminar.

El primer conjunto de cuestiones de contexto libre se enfoca sobre el cliente, los objetivos generales y los beneficios esperados. Por ejemplo, el analista podría preguntar:

 ¿Quién está detrás de la solicitud de este trabajo?

 ¿Quién utilizará la solución?

 ¿Cuál será el beneficio económico del éxito de una solución?

 ¿Hay alguna otra alternativa para la solución que necesita?

El siguiente conjunto de preguntas permite al analista obtener un mejor entendimiento del problema y al cliente comentar sus opiniones sobre la solución:

 ¿Cómo caracterizaría una <<buena<< salida (resultado) generada para una solución?

 ¿A qué tipo de problema(s) va dirigida esta solución?

 ¿Puede mostrarme (o describirme) el entorno en que se utilizará la solución.

 ¿Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de enfocar la solución?

El último conjunto de preguntas se concentra en la eficacia de la reunión. Gauge y Weinberg [GAU89] las denominan <<meta-preguntas>> y proponen la siguiente lista (abreviada)

 ¿Es usted la persona adecuada para responder estas preguntas? ¿Sus respuestas son <<oficiales>>?

 ¿Son adecuadas mis preguntas para el problema que tiene Usted?

 ¿Estoy preguntando demasiado?

 ¿Hay alguien más que pueda proporcionar información adicional?

 ¿Hay algo más que debería preguntarle?

Estas preguntas y (otras) ayudarán a <<romper el hielo>> e iniciar la comunicación tan esencial para el éxito del análisis.

11.2.2.- Técnicas para facilitar las especificaciones de la aplicación. (TFEA)

Este enfoque es partidario de la creación de un conjunto de clientes y desarrolladores que trabajan juntos para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución [ZAH90]

Cada sub-equipo presenta entonces sus mini-especificaciones, a todos los asistentes TFEA para estudiarlas.

Una vez que se han completado las mini-especificaciones, cada asistente de la TFEA hace una lista de criterios de validación del producto / sistema y presenta su lista al equipo. Se crea así una lista de consenso de criterios de validación. Finalmente, uno o más participantes (o algún tercero) es asignado para escribir el borrador entero de especificación con todo lo expuesto en la reunión TFEA.

Directrices TFEA:

• La reunión se celebra en un lugar neutral a la que acuden tanto los clientes como el equipo de ingenieros analistas.

• Se establecen normas de preparación y de participación.

• Se sugiere una agenda suficientemente formal para cubrir todos los puntos importantes, pero a su vez lo suficientemente informal para animar el flujo de ideas.

• Se establece un coordinador que controle la reunión. Puede ser un cliente, o del equipo.

• Se establece un mecanismo de definición: tipos de gráficos, estilo de hojas, proyectores, pizarras, etc.

• El objetivo es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de los requisitos.

11.2.3.- Despliegue de la función de calidad.

El despliegue de la función de calidad (DFC) es una técnica de gestión de calidad que traduce las necesidades del cliente en requisitos técnicos del software.

DFC identifica tres tipos de requisitos [ZUL92]

1. Requisitos Normales: Se declaran objetivos y metas para un producto o sistema durante las reuniones con el cliente. Si estos requisitos están presentes, el cliente quedará satisfecho.

2. Requisitos esperados: Estos requisitos son implícitos al producto o sistema y pueden ser tan fundamentales que el cliente no los declara explícitamente. Su ausencia sería motivo de una insatisfacción significativa.

3. Requisitos innovadores: Estas características van más allá de las expectativas del cliente y suelen ser muy satisfactorias.

En realidad el DFC se extiende a todo el proceso de ingeniería [AKA90].

En las reuniones con el cliente el despliegue de función se emplea para determinar el valor de cada función requerida para el sistema. El despliegue de información identifica tanto los objetos de datos como los acontecimientos que el sistema debe producir y consumir. Estos están unidos a las funciones. Finalmente, la exposición de tareas examina el comportamiento del sistema o producto dentro del contexto de su entorno. El análisis de valor es llevado a cabo para determinar la prioridad relativa de requisitos determinada durante cada uno de los tres despliegues mencionados anteriormente.

NIVELES DE EXPRESION

...