ETAPAS DE LA INGENIERIA DE REQUERIMEINTOS

a) Estudio de Factibilidad del Sistema

b) Obtención y Análisis de Requerimientos
c) Especificación de Requerimientos y documentación
d) Validación de los requerimientos documentados

ESTUDIO DE FACTIBILIDAD
Consiste en la recolección y evaluación de la información, para esto debe recurrir a
las fuentes de información, quienes son las personas que utilizaran el sistema
(ingenieros, expertos en tecnología, usuarios finales, etc) todo esto con el único
propósito de responder 3 preguntas fundamentales: ¿El sistema contribuye a los
objetivos de la organización? ¿El sistema se puede implementar con tecnología
actual y con restricciones de costo y tiempo? ¿El sistema puede integrarse a otros
existentes en la organización?

CREACION DEL INFORME DE FACTIBILIDAD: Consiste en estipular el

presupuesto, calendarización del sistema y/u requerimientos adicionales del
sistema.

OBTENCION Y ANALISIS DE REQUERIMIENTOS

Es la segunda etapa que consiste en determinar:
- El dominio de la Aplicación
- Desempeño del Sistema
- Restricciones del Sistema
- Otros

En esta etapa toman gran importancia los stakeholders, los cuales pueden ser
usuarios finales, ingenieros, desarrolladores.
1. Los stakeholders no conocen realmente lo que desean obtener del sistema.

2. Los stakeholders representan sus demandas en términos de su propio lenguaje

(dominio), con lo cual los ingenieros de requerimientos deben adecuarse al
lenguaje de ellos.

3. Los stakeholders poseen requerimientos distintos lo que conlleva a que en

muchas ocasiones los requerimientos de ellos entren en conflicto.

4. Los requerimientos son dinámicos debido a que estos van cambiando durante el
proceso de análisis ya que pueden surgir nuevos stakeholders que eventualmente
pueden tener requerimientos distintos a los que ya existían estipulados.

Modelo del proceso de obtención y análisis

1. Comprensión del dominio. El analista debe desarrollar su propia comprensión

del dominio de la aplicación.
2. Recolección de requerimientos. El analista debe interactuar con los
stakeholders, para determinar las necesidades que poseen y de esta manera
solucionarlas.
3. Clasificación. Esta etapa permite organizar y agrupar los requerimientos.
4. Resolución de conflictos. Esta tarea permite resolver los conflictos que surgen
de la intervención de los distintos stakeholders.
5. Priorización. Esta tarea permite dar prioridad a los distintos requerimientos
coherentes encontrados.
6. Verificación de requerimientos. Esta tarea permite verificar que los
requerimientos sean completos, consistentes y tengan relación a las necesidades
planteadas por los stakeholders.
 Existen distintas técnicas que se pueden aplicar para la obtención de los
requisitos:

1. Introspección. Esta técnica consiste en que el ingeniero (en esta etapa también
llamado analista) se pone en el lugar del cliente y le da recomendaciones de la
funcionalidad imaginando el sistema que se desea construir.

2. Entrevistas. Técnica que consiste en obtener mediante algún tipo de entrevista

con los stakeholders los requerimientos que desean. Tipos de entrevistas:

 Open Ended Interview: consiste en que el cliente narra su problemática y

que el ingeniero lo guíe a través de la charla, de forma que pueda
especificar los requerimientos.
 Entrevistas en Grupos de Desarrollo: consiste en generar grupos con el
personal del cliente de modo que tengan entre ellos una especialidad en
común. La idea es reclutar a los expertos de las distintas áreas de la
empresa para generar los requerimientos de una manera global.
 Las Discusiones: consisten en que el ingeniero establezca una discusión
con el cliente acerca de la problemática a tratar de modo que se genere un
conjunto de requerimientos del sistema.

3. Casos de Uso. Esta técnica consiste en identificar los escenarios para obtener
los requerimientos. Un escenario indica como debe interactuar el sistema con el
usuario para obtener un objetivo específico; dicho de otra manera, un caso de uso
es una secuencia de interacciones entre el sistema y los stakeholders en
respuesta a un evento que desea realizar un stakeholder con el sistema.

4. Vord. Este método se basa en la obtención de los requerimientos mediante

distintos puntos de vista. Este método esta formado por distintas etapas las cuales
son:
4.1 Identificación de puntos de vista, lo que permite definir tanto los distintos
puntos de vista como los servicios específicos que se entregan a cada punto
de vista.
4.2 Estructuración de puntos de vista, permite agrupar y jerarquizar los distintos
servicios. En la jerarquía se posicionan en la parte superior aquellos servicios
comunes y se heredan los puntos de vista de bajo nivel.
4.3 Documentación de puntos de vista, esto comprende refinar los puntos de vista
y los servicios identificados.
4.4 Trazado del punto de vista del sistema, comprende identificar los objetos en un
diseño orientado a objetos utilizando la información obtenido en los puntos de
vista.

Aunque existen distintos métodos para recoger los requerimientos del sistema,
todos al final cumplen lo siguiente:

1. Se debe poder representar y entender el dominio de la información de un

problema planteado por el cliente.
2. Se debe definir la funcionalidad que debe cumplir el sistema.
3. Se debe representar el comportamiento del sistema.
4. Se deben describir los modelos que representan tanto la información como
la función y el comportamiento del sistema de una manera jerárquica.
 5. El proceso de análisis de requerimientos debe estar en todo el desarrollo el
sistema, es decir desde la información esencial hasta la implementación.

Especificación de requerimientos

En esta etapa se establece lo que el sistema va a realizar, es una etapa muy

compleja debido a su naturaleza.

Principios para representar los requisitos de Software:

1. Separa la funcionalidad de la implementación.

2. Desarrollar un modelo de comportamiento de un sistema que comprenda
los datos y las respuestas funcionales de un sistema a varios estímulos del
entorno.
3. Establecer los componentes del sistema que interactúan con el.
4. Definir el entorno en que operara el sistema
5. Crear un modelo intuitivo
6. Considerar que una especificación es una abstracción de una situación real
por lo cual será incompleta y existirá a muchos niveles de detalle.
7. Definir un contenido y estructura que sea susceptible a cambios.

Es importante destacar que aunque los requerimientos pueden expresarse de

cualquier manera hay que considerar que los principios enunciados anteriormente
se deben llevar a la realidad, por ello es recomendable expresar los requerimientos
mediante algún dibujo en papel. Según [1] se presentan las siguientes directrices a
seguir:

1. El formato de la representación y el contenido deberían estar relacionados

con el problema. Esto quiere decir que se puede realizar una representación
general de la especificación de requerimientos del software independiente de las
distintas simbologías que dependen del área de aplicación en la cual se este
realizando la especificación de requerimientos.
2. La información contenida dentro de la especificación debería estar
escalonada. Las representaciones deberían permitir que el lector pueda manejar
la información en distintos niveles hasta llegar a los detalles de la especificación.
3. La numeración de párrafos y diagramas debería indicar el nivel de detalle
que se muestra. Esto permite que la información se pueda presentar con distintos
niveles de abstracción.
4. Los diagramas y otras formas de notación deberían restringirse en número
y ser consistentes en su empleo. Esto permite evitar notaciones que produzcan
confusión en la comprensión.
5. Las representaciones deben permitir revisiones. Esto permite que se pueda
cambiar el contenido de una especificación si varía el contenido de esta. Es
recomendable utilizar una herramienta CASE que permite actualizar dicha
información.
Finalmente existe un documento de requerimientos del software, también llamado
especificación de requerimientos del software el cual es la declaración oficial de lo
que requieren los desarrolladores del sistema. Según [1] las actividades son:
I. Introducción
A. Referencia del sistema
B. Descripción general.
C. Restricciones del proyecto de software.
II. Descripción de la información
A. Representación del contenido de la información
B. Representación del flujo de la información
1. Flujo de datos
2. Flujo de control
III. Descripción funcional
A. Partición funcional
B. Descripción funcional
1. Descripción del procesamiento
2. Restricciones/limitaciones
3. Requisitos de rendimiento
4. Restricciones de diseño
5. Diagramas de soporte
C. Descripción del control
1. Especificación de control
2. Restricciones de diseño
IV. Descripción del comportamiento
A. Estados del sistema
B. Eventos y acciones
V. Criterios de validación
A. Límites del rendimiento
B. Clases de prueba
C. Respuesta esperada del software
D. Consideraciones especiales
VI. Bibliografía
VII. Apéndice.

Figura 3.3: Proceso de obtención y análisis de requerimientos

1. La introducción permite establecer metas y objetivos que debe poseer el

software a desarrollar.
2. La descripción de la información establece una descripción detallada del
software a desarrollar. En esta etapa se documentan el contenido de la
información y sus relaciones.
3. En la descripción funcional se describen todas las funciones necesarias para
desarrollar la problemática en cuestión. Además se describe cada función,
estableciendo restricciones y sus debidas justificaciones. Además se establecen
características del rendimiento.
4. La descripción del comportamiento describe el operar del software que se ve
afectado por acontecimientos externos.
5. Los criterios de validación no se profundizan en esta etapa debido a que en la
próxima sección se describe, sin embargo se pude describir que la especificación
de los criterios de validación actúa como una revisión de todos los requerimientos.
Validación de requerimientos
En esta etapa se establecen los requerimientos finales ó completos que definirán
el sistema que el cliente desea. Según [3] para validar los requerimientos se deben
realizar las siguientes verificaciones:
1. Verificación de Validez. Esta verificación se refiere a que un usuario puede
pensar que se necesita un sistema para llevar a cabo ciertas funciones; sin
embargo, el razonamiento y el análisis identifican que se requieren funciones
adicionales y diferentes
2. Verificación de consistencia. Esta verificación se refiere a que los
requerimientos en el documento de requerimientos no deben de contradecirse;
es decir no deben existir contradicciones con respecto a cualquier funcionalidad
del sistema.
3. Verificación de integridad. Esta verificación hace alusión a que en el
documento de requerimientos deben de estar todas las funcionalidades y
restricciones propuestas por el usuario para el sistema
4. Verificación de realismo. Esta verificación hace referencia a que los
requerimientos definidos han de poder implementarse utilizando las tecnologías
existentes. Además estas tecnologías deben considerar el presupuesto, fechas
de entrega y desarrollo del sistema.
5. Verificabilidad. Consiste en establecer un conjunto de verificaciones que
permitan demostrar que el sistema cumple con los requerimientos definidos en el
documento de requerimientos.
Existen diversos tipos de enfoques que permiten realizar una verificación de los
requerimientos dentro de las cuales se puede destacar, según [3], las siguientes:
1. Revisiones de requerimientos. Esta es una técnica manual que consiste en
que los requerimientos son analizados nuevamente entre los clientes y los
desarrolladores. En caso de que existan omisión o error en algún requerimiento
se recomienda que el desarrollador negocie alguna solución con el cliente.
2. Construcción de prototipos. Esta técnica consiste en crear un modelo en base
a los requerimientos ya establecidos. Existen dos tipos de prototipos, tanto los
prototipos desechables como los prototipos evolutivos. Los prototipos
desechables consisten en definir un modelo para demostrar el cumplimiento de
los requerimientos definidos con lo cual se puede reducir los costos involucrados
en el ciclo de de vida del desarrollo. Una vez hecha esta evolución el prototipo se
desecha.
Los prototipos evolutivos consisten en desarrollar una implementación inicial,
exponerla a los stakeholders e irla refinando hasta llegar a un desarrollo de
sistema adecuado, este tipo de prototipo tiene como objetivo desarrollar un
prototipo rápida para que el cliente valore los resultados y recomiende cambios
de una manera oportuna.