Las tres actividades que componen el modelo de procesos de ingeniería de requerimientos son:
- Elicitación de Requerimientos.
- Análisis de Requerimientos.
- Validación de Requerimientos.
La elicitación de requerimientos en la más importante de la ingeniería de requerimientos. Es en esta actividad en la que se mantiene la interacción entre clientes, usuarios y los ingenieros de requerimientos.
- Objetivos de la elicitación de requerimientos.
- Conocer el dominio del problema: es fundamental que los ingenieros de requerimientos conozcan el dominio del problema, de forma que puedan entenderse con los clientes y usuarios y que sean capaces de transmitir dicho conocimiento al resto del equipo de desarrollo [Kovitz 1998].
- Descubrir las necesidades reales de clientes y usuarios: además de aquellas necesidades explícitamente manifestadas por los clientes y usuarios, es muy importante llegar a descubrir el conocimiento tácito, es decir, aquellas necesidades que la mayor parte de las veces se asumen y toman por implícitas [Goguen y Linde 1993, Kovitz 1998].
- Consensuar los requerimientos entre los propios clientes y usuarios: puede que distintos grupos de clientes y usuarios presenten distintas necesidades que sean contradictorias entre sí. Durante la elicitación, normalmente después de la primera iteración, es necesario negociar entre los distintos participantes hasta obtener una visión común de los requerimientos [Boehm et al. 1994, Parets-Llorca y Grünbacher 1999].
- Entradas y salidas de la elicitación de requerimientos.
- Entradas: en la primera iteración, la entrada principal de esta actividad es la información proveniente de clientes y usuarios. En itereaciones posteriores también se toman como entradas los requerimientos-C, los requerimientos-D, el prototipo y los conflictos aparecidos en la iteración anterior.
- Salidas: la salida de esta actividad es una nueva versión (o la primera si se trata de la primera iteración) de los requerimientos-C, que serán analizados en la siguiente actividad.
- Objetivos del análisis de requerimientos.
- Detectar conflictos en los requerimientos-C: los requerimientos-C suelen ser información proveniente de distintas fuentes y normalmente presentan contradicciones o ambigüedades debido a su naturaleza informal. Durante el análisis de los requerimientos-C, normalmente mediante la construcción de un modelo, es habitual que al incrementar la precisión con la que es necesario expresar los requerimientos aparezcan dichas contradicciones o ambigüedades que deberán resolverse en nuevas reuniones de elicitación mediante algún mecanismo de negociación.
- Profundizar en el conocimiento del dominio del problema: por mucho que el ingeniero de requerimientos aprenda sobre el dominio del problema, siempre quedarán aspectos desconocidos. Construir un modelo suele conllevar un incremento en el grado de conocimiento del problema que puede facilitar el proceso de construir un producto útil para clientes y usuarios con los conocimientos apropiados.
- Establecer las bases para el diseño: normalmente, los modelos obtenidos durante la realización del análisis de los requerimientos-C suelen construir las bases para las actividades de diseño. En el caso de que se utilicen notaciones similares en análisis y diseño (por ejemplo, orientadas a objetos), se consigue lo que se suele denominar proceso sin costuras (seamless process en inglés), es decir, una evolución graudal de los modelos abstractos de análisis hacia los modelos más cercanos a la implementación.
- Entradas y salidas del análisis de requerimientos.
- Entradas: son los requerimientos-C elicitados en la actividad anterior, los requerimientos-D y el prototipo de la iteración previa e información proveniente de clientes y usuarios en el caso de que tengan conocimientos de las técnicas de análisis apropiadas.
- Salidas: es una nueva versión (o la primera si se trata de la primera iteración) de los requerimientos-D y del prototipo, que en el caso de que se utilicen especificaciones formales ejecutables para expresar los requerimientos-D puede generarse automáticamente, así como posibles conflictos encontrados en los requerimientos-C, lo que provocaría que se repitiese el ciclo elicitación-análisis.
- Objetivos de la validación de requerimientos.
- Asegurarse de que los requerimientos describen el producto deseado: aunque las actividades de elicitación y análisis se hayan realizado correctamente, siempre es necesario confirmar que los requerimientos obtenidos se corresponden realmente con los que los clientes y usuarios desean, de forma que se evite la situación en la que el producto final, que puede ser técnicamente correcto, no es satisfactorio. Las actividades de validación conllevan generalmente a la elicitación de nuevos requerimientos debido a que, a medida que el nuevo sistema se va perfilando, suelen ir apareciendo nuevas necesidades que hasta entonces estaban ocultas, sobre todo mediante la utilización de prototipos [Davis 1995].
- Entradas y salidas de la validación de requerimientos.
- Entradas: son los requerimientos-C, los requerimientos-D, en el caso de que los clientes y usuarios tengan conocimientos suficientes para comprender las notaciones utilizadas, el prototipo y la información de validación proveniente de clientes y usuarios.
- Salidas: son las versiones validadas, total o parcialmente, de los requerimientos-C, requerimientos-D, en el caso de que los clientes y usuarios tengan conocimientos suficientes para comprender las notaciones utilizadas, y del prototipo. En el caso de que se detecten conflictos o se eliciten nuevos requerimientos se repite el ciclo completo de actividades.
No hay comentarios:
Publicar un comentario