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]

...