República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II

Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis

“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

UNIDAD N° 1 REQUERIMIENTOS DEL SOFTWARE.

TEMA N° 1 QUE SON LOS REQUERIMIENTOS O REQUISITOS DEL SOFTWARE.
1.1.- Introducción.
En la actualidad, son muchos los procesos de desarrollo de software que existen. Con el pasar de los años, la
Ingeniería de Software ha introducido y popularizado una serie de estándares para medir y certificar la calidad,
tanto del sistema a desarrollar, como del proceso de desarrollo en sí. Se han publicado muchos libros y
artículos relacionados con este tema, con el modelado de procesos del negocio y la reingeniería. Un número
creciente de herramientas automatizadas han surgido para ayudar a definir y aplicar un proceso de desarrollo
de software efectivo. Hoy en día la economía global depende más de sistemas automatizados que en épocas
pasadas; esto ha llevado a los equipos de desarrollo a enfrentarse con una nueva década de procesos y
estándares de calidad.
Sin embargo, ¿cómo explicamos la alta incidencia de fallos en los proyectos de software? ¿Por qué existen
tantos proyectos de software víctimas de retrasos, presupuestos sobregirados y con problemas de calidad?
¿Cómo podemos tener una producción o una economía de calidad, cuando nuestras actividades diarias
dependen de la calidad del sistema?
Tal vez suene ilógico pero, a pesar de los avances que ha dado la tecnología, aún existen procesos de
producción informales, parciales y en algunos casos no confiables.
La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que
enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la
generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente
y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas
relacionados al desarrollo de sistemas.
Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones
que existen para requerimiento, a continuación se presenta la definición que aparece en el glosario del
Instituto de Ingeniería Eléctrica y Electrónica (IEEE), de los E.U.A.
I. Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.
II. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para
satisfacer un contrato, estándar, especificación u otro documento formal.
III. Una representación documentada de una condición o capacidad como en (I) o (II).
Los requerimientos pueden dividirse en requerimientos funcionales y requerimientos no funcionales.
 Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen
las transformaciones que el sistema realiza sobre las entradas para producir salidas.
 Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan
limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario,
fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad,
estándares, etc.

1.2.- Características de los requerimientos.

Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en
estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A
continuación se presentan las más importantes.
 Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a
construir, y además su capacidad, características físicas o factor de calidad no pueden ser
reemplazados por otras capacidades del producto o del proceso.

1
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

 Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y
clara para aquellos que vayan a consultarlo en un futuro.
 Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si
se proporciona la información suficiente para su comprensión.
 Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
 No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación.
 Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita
hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.

1.3.- Dificultades para definir los requerimientos.

 Los requerimientos no son obvios y vienen de muchas fuentes.
 Son difíciles de expresar en palabras (el lenguaje es ambiguo).
 Existen muchos tipos de requerimientos y diferentes niveles de detalle.
 La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
 Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que
otros.
 Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del
proceso.
 Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.
 Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
 Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.
1.4.- Fundamentos del Análisis de Requerimientos.
Definición: Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios
para definir un proyecto de software.
Es la etapa más crucial del desarrollo de un proyecto de software.
La IEEE los divide en funcionales y no funcionales:
 Funcionales: Condición o capacidad de un sistema requerida por el usuario para resolver un problema
o alcanzar un objetivo.
 No Funcionales: Condición o capacidad que debe poseer un sistema para satisfacer un contrato, un
estándar, una especificación u otro documento formalmente impuesto.
Para realizar bien el desarrollo de software es esencial realizar una especificación completa de los
requerimientos de los mismos. Independientemente de lo bien diseñado o codificado que esté, un programa
pobremente especificado decepcionará al usuario y hará fracasar el desarrollo.
La tarea de análisis de los requerimientos es un proceso de descubrimiento y refinamiento, El ámbito del
programa, establecido inicialmente durante la ingeniería del sistema, es refinado en detalle. Se analizan y
asignan a los distintos elementos de los programas las soluciones alternativas.
Tanto el que desarrolla el software como el cliente tienen un papel activo en la especificación de
requerimientos. El cliente intenta reformular su concepto, algo nebuloso, de la función y comportamiento de los
programas en detalles concretos, El que desarrolla el software actúa como interrogador, consultor y el que
resuelve los problemas.

2
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

El análisis y especificación de requerimientos puede parecer una tarea relativamente sencilla, pero las
apariencias engañan. Puesto que el contenido de comunicación es muy alto, abundan los cambios por mala
interpretación o falta de información. El dilema con el que se enfrenta un ingeniero de software puede ser
comprendido repitiendo la sentencia de un cliente anónimo:
"Sé que crees que comprendes lo que piensas que he dicho, pero no estoy seguro de que lo que
creíste oír sea lo que yo quise decir".
Los requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y detallados, y
además contienen múltiples relaciones entre sí. Lo que nos da a concluir, que el conjunto de requerimientos de
un sistema computacional es complejo.
Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones simples y
concisas para el sistema. Esto se logra al clasificar, estructurar y organizar todo lo que el sistema debe de
hacer. En otras palabras al analizar sus requerimientos.
El análisis de requerimientos es la tarea que plantea la asignación de software a nivel de sistema y el diseño
de programas. El análisis de requerimientos facilita al ingeniero de sistemas especificar la función y
comportamiento de los programas, indicar la interfaz con otros elementos del sistema y establecer las
ligaduras de diseño que debe cumplir el programa. El análisis de requerimientos permite al ingeniero refinar la
asignación de software y representar el dominio de la información que será tratada por el programa. El análisis
de requerimientos da al diseñador la representación de la información y las funciones que pueden ser
traducidas en datos, arquitectura y diseño procedimental. Finalmente, la especificación de requerimientos
suministra al técnico y al cliente, los medios para valorar la calidad de los programas, una vez que se haya
construido.

1.5.- Personal Involucrado en la Ingeniería de Requerimientos

Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es
importante saber que cada una de esas personas tienen diversos intereses y juegan roles específicos dentro
de la planificación del proyecto; el conocimiento de cada papel desempeñado, asegura que se involucren a las
personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR.
No conocer estos intereses puede ocasionar una comunicación poco efectiva entre clientes y desarrolladores,
que a la vez traería impactos negativos tanto en tiempo como en presupuesto. Los roles más importantes
pueden clasificarse como sigue:
 Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están relacionados con la
usabilidad, la disponibilidad y la fiabilidad del sistema; están familiarizados con los procesos
específicos que debe realizar el software, dentro de los parámetros de su ambiente laboral. Serán
quienes utilicen las interfaces y los manuales de usuario.
 Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema
en donde será empleado el software desarrollado. Ellos proporcionan al equipo técnico los detalles y
requerimientos de las interfaces del sistema.
 Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, estas personas
son las responsables de la administración de cambios, de la implementación y resolución de
anomalías. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado.
 Analistas y programadores: Son los responsables del desarrollo del producto en sí; ellos interactúan
directamente con el cliente.
 Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las
condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los
requerimientos satisfacen las necesidades del cliente.
Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser:
administradores de proyecto, documentadores, diseñadores de base de datos, entre otros.
Puntos a considerar durante la Ingeniería de Requerimientos

3
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

Aunque la lista no está completa, se enumeran los puntos más importantes.

1.5.1.- Objetivos del negocio y ambiente de trabajo

Aunque los objetivos del negocio están definidos frecuentemente en términos generales, son usados para
descomponer el trabajo en tareas específicas. En ciertas situaciones IR se enfoca en la descripción de las
tareas y en el análisis de sistemas similares. Esta información proporciona la base para especificar el sistema
que será construido; aunque frecuentemente se añadan al sistema tareas que no encajan con el ambiente de
trabajo planificado.
El nuevo sistema cambiará el ambiente de trabajo, sin embargo, es muy difícil anticipar los efectos actuales
sobre la organización. Los cambios no ocurren solamente cuando un nuevo software es implementado y
puesto en producción; también ocurren cuando cambia el ambiente que lo rodea (nuevas soluciones a
problemas, nuevo equipo para instalar, etc.). La necesidad de cambio es sustentada por el enorme costo de
mantenimiento; aunque existen diversas razones que dificultan el mantenimiento del software, la falta de
atención a la IR es la principal.
Frecuentemente la especificación inicial es también la especificación final, lo que obstaculiza la comunicación
y el proceso de aprendizaje de las personas involucradas; esta es una de las razones por las cuales existen
sistemas inadecuados.

1.5.2.- Punto de vista de los clientes

Muchos sistemas tienen diferentes tipos de clientes. Cada grupo de clientes tiene necesidades diferentes y,
diferentes requerimientos tienen diferentes grados de importancia para ellos. Por otro lado, escasas veces
tenemos que los clientes son los mismos usuarios; trayendo como consecuencia que los clientes soliciten
procesos que causan conflictos con los solicitados por el usuario.
Diferentes puntos de vistas también pueden tener consecuencias negativas, tales como datos redundantes,
inconsistentes y ambiguos.
El tamaño y complejidad de los requerimientos ocasiona desentendimiento, dificultad para enfocarse en un
solo aspecto a la vez y dificultad para visualizar relaciones existentes entre requerimientos.
I. Barreras de comunicación
La ingeniería de requerimientos depende de una intensa comunicación entre clientes y analistas de
requerimientos; sin embargo, existen problemas que no pueden ser resueltos mediante la comunicación.
Para remediar esto, se deben abordar nuevas técnicas operacionales que ayuden a superar estas
barreras y así ganar experiencia dentro del marco del sistema propuesto.
II. Evolución e integración del sistema
Pocos sistemas son construidos desde cero. En la práctica, los proyectos se derivan de sistemas ya
existentes. Por lo tanto, los analistas de requerimientos deben comprender esos sistemas, que por lo
general son una integración de componentes de varios proveedores.
Para encontrar una solución a problemas de este tipo, es muy importante hacer planeamientos entre los
requerimientos y la fase de diseño; esto minimizará la cantidad de fallas directas en el código.
III. Documentación de requerimientos
Los documentos de ingeniería de requerimientos son largos. La mayoría están compuestos de cientos o
miles de páginas; cada página contiene muchos detalles que pueden tener efectos profundos en el resto
del sistema.
Normalmente, las personas se encuentran con dificultades para comprender documentos de este
tamaño, sobre todo si lo leen cuidadosamente. Es casi imposible leer un documento de especificación
de gran tamaño, pues difícilmente una persona puede memorizar los detalles del documento. Esto
causa problemas y errores que no son detectados hasta después de haberse construido el sistema.

4
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

TEMA N° 2 LA INGENIERIA DE REQUISITOS.

2.1.- Definición.
En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos comprende todas las
tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un
software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar
en conflicto entre ellos.
Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traducción del inglés.
La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés
como request.
El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de
alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin
ambigüedades o contradicciones, etc.

 Ingeniería de Requerimientos ayuda a los ingenieros de software a entender mejor el problema en

cuya solución trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el
impacto del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuarán los
usuarios finales con el software.

 La ingeniería de requerimientos es el proceso de desarrollar una especificación de software. Las

especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del
sistema.

 La Ingeniería de Requerimientos se define, como un conjunto de actividades en las cuales, utilizando

técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución
(a veces más de una

2.1.1.- Fases de implementación.

Desde un punto de vista conceptual, las actividades son de cinco clases.

 Obtener requisitos: a través de entrevistas o comunicación con clientes o usuarios, para saber
cuáles son sus deseos.

 Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos
obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados por el diseño.

 Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente
documentados.

 Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la

aplicación.

 Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que
inicialmente se pretendía.

2.2.- Ingeniería de Requerimientos vs. Administración de Requerimientos.

El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería
de Requerimientos. (IR). La meta de la ingeniería de requerimientos (IR) es entregar una especificación de
requisitos de software correcta y completa.
Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software, es ellos se basan
muchos participantes del proyecto para:

5
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

 Planear el proyecto y los recursos que se usarán en él. Los líderes de proyecto usan los
requerimientos como una base para la estimación del esfuerzo necesario en un proyecto.
 Especificar el tipo de verificaciones que se habrán de realizar al sistema. Por ejemplo: cuando se está
tratando de alinearse a cierta norma oficial o estándar.
 Planear la estrategia de prueba a la que habrá de ser sometido el sistema. Los requerimientos son la
base sobre la cual se decide si un caso de prueba fue ejecutado exitosamente por el sistema o no.
Son el fundamento del ciclo de vida del proyecto. Los requerimientos documentados son la base para crear la
documentación del sistema
De ahí su importancia y la importancia de que deban de ser definidos y manejados de la forma más adecuada
posible.

2.3.- ¿ Porqué los Proyectos de Software son Exitosos ?.

 Involucra a Usuarios 15.9%
 Soporte Administración 13.9%
 Clara definición de Requerimientos 13.0%
 Apropiado Planeamiento 9.6%
 Expectativas Realistas 8.2%
 Hitos no Extensos 7.7%
 Staff Competente de profesionales 7.2%
 Propietario 5.3%

2.4.- ¿ Porqué los Proyectos de Software Fallan ?

 Requerimientos Incompletos 13.1%
 Falta de Requerimientos 12.4%
 Falta de Recursos 10.6%
 Expectativas no Realistas 9.9%
 Cambio Requerimientos/Especificaciones 8.7%
 Falta de Planeamiento 8.1%
 No se especifico el tiempo adecuado 7.5%
» Fuente: QualitySystems & Software – 1997

6
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

TEMA N° 3.- LEVENTAMIENTO Y RECOLECCION DE REQUERIMIENTOS.

3.1.- Introducción.
Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo de software, este
entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente.
Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lógico que para
recabarlos haya que obtener la información de primera mano. Esto es, mediante entrevistas con el cliente o
recabando documentación que describa la manera que el cliente desea que funcione el sistema de software.
Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y cada cambio involucra un costo.
Por eso es necesario tener archivada una copia de la documentación original del cliente, así como cada
revisión o cambio que se haga a esta documentación. Como cada necesidad del cliente es tratada de diferente
forma, es necesario clasificar estas necesidades para saber cuáles de ellas serán satisfechas por el software y
cuales por algún otro producto del sistema.

3.2...- Principios de Especificación.

La especificación, independientemente del modo en que se realice, puede ser vista como un proceso de
representación. Los requerimientos se representan de forma que conduzcan finalmente a una correcta
implementación del software. Estos se dividen de la siguiente manera:

3.2.1.- Requerimientos funcionales.

Estos son los que describen lo que el sistema debe de hacer. Es importante que se describa él ¿Qué? Y no él
¿Cómo?. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos,
la lógica y gran parte del código del sistema.

3.2.2.- Requerimientos de desempeño.

Estos requerimientos nos informan las características de desempeño que deben de tener el sistema. ¿Que tan
rápido?, ¿Que tan seguido?, ¿Cuantos recursos?, ¿Cuantas transacciones?
Este tipo de requerimientos es de especial importancia en los sistemas de tiempo real en donde el desempeño
de un sistema es tan crítico como su funcionamiento.

3.2.3.- Disponibilidad (en un determinado periodo de tiempo).

Este tipo de requerimientos se refiere a la durabilidad, degradación, potabilidad, flexibilidad, contabilidad y
capacidad de actualización. Este tipo de requerimientos es también muy importante en sistemas de tiempo real
puesto que estos sistemas manejan aplicaciones críticas que no deben de estar fuera de servicio por periodos
prolongados de tiempo.

3.2.4.- Entrenamiento.
Este tipo de requerimientos se enfoca a las personas que van usar el sistema. ¿Que tipo de usuarios son?,
¿Que tipo de operadores?, ¿Que manuales se entregarán y en que idioma?
Este tipo de requerimientos, aunque muchas veces no termina en un pedazo de código dentro del sistema, son
muy importantes en el proceso de diseño ya que facilitan la introducción y aceptación del sistema en donde
será implementado.

3.2.5.- Restricciones de diseño.

Muchas veces las soluciones de un sistema de software son normadas por leyes o estándares, este tipo de
normas caen como "restricciones de diseño".

3.2.6.- Materiales.

7
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

Aquí se especifica en que medio se entregara el sistema y como esta empaquetado. Es importante para definir
los costos de industrialización del sistema.

3.3.- Manejo de Requerimientos.

De acuerdo con el "Capability Maturity Model" (CMM), el manejo de requerimientos involucra:
"Establecer y mantener un acuerdo con el cliente sobre los requerimientos del proyecto de software. Este
acuerdo son los requerimientos del sistema alojados al software." … ". Este acuerdo cubre requerimientos
técnicos y no técnicos (como fechas de entrega). El acuerdo forma las bases para estimar, planear, ejecutar y
monitorear el proyecto de desarrollo de software a través de todo su ciclo de vida." … "Bajo las restricciones
del proyecto, el grupo de manejo de requerimientos toma las medidas necesarias para que los requerimientos
que están bajo su responsabilidad estén documentados y controlados"
¿De que manera podemos controlar los requerimientos de software si estos siempre evolucionan con el
tiempo?. El CMM nos proporciona las guías para lograrlo.
"Para lograr el control de los requerimientos, el grupo de requerimientos revisa los requerimientos antes de
que estos sean incorporados al proyecto de software y cada vez que los requerimientos cambian los planes,
productos, y actividades son ajustadas para quedar en línea con los nuevos requerimientos de software".
En otras palabras, para obtener el nivel que requiere el CMM en manejo de requerimientos débenos de tomar
en cuenta dos cosas.
 Que los requerimientos deben de ser revisados (y aprobados) por el grupo de requerimientos, y no son
impuestos por en su totalidad por presiones externas ajenas al proyecto. El requerimiento técnico podrá
ser impuesto por el mercado o presiones de la competencia, pero entonces los requerimientos no
técnicos (Calidad, Costo y Tiempo de entrega) deberán estar especificados de común acuerdo con el
grupo de requerimientos del proyecto de software.
 Los requerimientos técnicos y no técnicos forman un conjunto entre sí, si cambia uno forzosamente
deberán cambiar los demás. Esto es: más contenido técnico implica o más costo, o menos calidad o
más tiempo estimado de entrega. De modo que los cambios técnicos deberán ser aprobados por el
grupo de requerimientos y este grupo estimará los impactos en tiempo, costo, calidad. El resultado de la
estimación es la entrada a los líderes del proyecto para decidir si el cambio se acepta o no.

3.4.- Técnicas Usadas en el Levantamiento de Requerimientos.

3.4.1.- Introducción..
Cuanto más tarde en el ciclo de vida se detecta un error, más cuesta repararlo. Muchos errores permanecen
latentes y no son detectados hasta bastante después de la etapa en que se cometieron. Muchos podrían
detectarse tempranamente. Se cometen muchos errores de requisitos Impacto de los errores en la etapa de
requisitos
El software resultante puede no satisfacer a los usuarios. Las interpretaciones múltiples de los requisitos
pueden causar desacuerdos entre clientes y desarrolladores. Es imposible que a través del testeo el software
satisfaga sus requisitos. Puede gastarse tiempo y dinero construyendo el sistema erróneo.
Existen varias técnicas para la IR, sin embargo, en este tema se van a estudiar sólo algunas de ellas. Cada
técnica puede aplicarse en una o más actividades de la IR; en la práctica, la técnica más apropiada para cada
actividad dependerá del proyecto que esté desarrollándose, estas son:
 Entrevistas y cuestionarios.
 Lluvia o Tormenta de Ideas (Brainstorm).
 Prototipos.
 Técnica JAD (Joint Aplication Designer).

8
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

3.5.- Entrevistas y Cuestionarios.

Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o de grupos.
Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de
preguntas relacionadas con varios aspectos de un sistema.
Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema
propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o
que serán afectados por él.
Las preguntas que deben realizarse en esta técnica, deben ser preguntas de alto nivel y abstractas que
pueden realizarse al inicio del proyecto para obtener información sobre aspectos globales del problema del
usuario y soluciones potenciales.
Con frecuencia, se utilizan preguntas abiertas para descubrir sentimientos, opiniones y experiencias
generales, o para explorar un proceso o problema. Este tipo de preguntas son siempre apropiadas, además
que ayudan a entender la perspectiva del afectado y no están influenciadas por el conocimiento de la solución.
Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios, procesos, etc. El
siguiente ejemplo muestra algunos tipos de preguntas abiertas.
Del Usuario
 ¿Quién es el cliente?
 ¿Quién es el usuario?
 ¿Son sus necesidades diferentes?
 ¿Cuáles son sus habilidades, capacidades, ambiente?
Del Proceso
 ¿Cuál es la razón por la que se quiere resolver este problema?
 ¿Cuál es el valor de una solución exitosa?
 ¿Cómo usted resuelve el problema actualmente?
 ¿Qué retrasos ocurren o pueden ocurrir?
Del Producto
 ¿Qué problemas podría causar este producto en el negocio?
 ¿En qué ambiente se usará el producto?
 ¿Cuáles son sus expectativas para los conceptos fácil de usar, confiable, rendimiento?
 ¿Qué obstáculos afectan la eficiencia del sistema?
El éxito de esta técnica combinada, depende de la habilidad del entrevistador y de su preparación para la
misma. Los analistas necesitan ser sensibles las dificultades que algunos entrevistados crean durante la
entrevista y saber cómo tratar con problemas potenciales. Asimismo, necesitan considerar no sólo la
información que adquieren a través del cuestionario y la entrevista, sino también, su significancia.

3.6.- Lluvia o Tormenta de Ideas (Brainstorm).

Este método comenzó en el ámbito de las empresas, aplicándose a temas tan variados como la productividad,
la necesidad de encontrar nuevas ideas y soluciones para los productos del mercado, encontrar nuevos
métodos que desarrollen el pensamiento creativo a todos los niveles, etc. Pero pronto se extendió a otros

9
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

ámbitos, incluyendo el mundo de desarrollo de sistemas; básicamente se busca que los involucrados en un
proyecto desarrollen su creatividad, promoviendo la introducción de los principios creativos.
A esta técnica se le conoce también como torbellino de ideas, tormenta de ideas, desencadenamiento de
ideas, movilización verbal, bombardeo de ideas, sacudidas de cerebros, promoción de ideas, tormenta
cerebral, avalancha de ideas, tempestad en el cerebro y tempestad de ideas, entre otras.

3.6.1.- Principios de la lluvia de ideas.

 Aplazar el juicio y no realizar críticas, hasta que no agoten las ideas, ya que actuaría como un
inhibidor. Se ha de crear una atmósfera de trabajo en la que nadie se sienta amenazado.
 Cuantas más ideas se sugieren, mejores resultados se conseguirán: "la cantidad produce la calidad".
Las mejores ideas aparecen tarde en el periodo de producción de ideas, será más fácil que
encontremos las soluciones y tendremos más variedad sobre la que elegir.
 La producción de ideas en grupos puede ser más efectiva que la individual.
 Tampoco debemos olvidar que durante las sesiones, las ideas de una persona, serán asociadas de
manera distinta por cada miembro, y hará que aparezcan otras por contacto.
El equipo en una lluvia de ideas debe estar formado por:
El Director: es la figura principal y el encargado de dirigir la sesión. Debe ser un experto en pensamiento
creador. Su función es formular claramente el problema y que todos se familiaricen con él. Cuando lo haga,
debe estimular ideas y hacer que se rompa el hielo en el grupo. Es el encargado de que se cumplan las
normas, no permitiendo las críticas. Debe permanecer callado e intervenir cuando se corte la afluencia de
ideas, por lo que le será útil llevar ya un listado de ideas. Debe hacer que todos participen y den ideas.
Además, es la persona que da concede la palabra y da por finalizada la sesión. Posteriormente, clasificará las
ideas de la lista que le proporciona el secretario.
El secretario: registra por escrito las ideas según van surgiendo. Las enumera, las reproduce fielmente, las
redacta y se asegura que todos están de acuerdo con lo escrito. Por último realizará una lista de ideas.
Los participantes: pueden ser habituales o invitados; cualquier involucrado en el proyecto entra en esta
categoría. Su función es producir ideas. Conviene que entre ellos no haya diferencias jerárquicas.
Las personas que componen el grupo deben estar motivadas para solucionar el problema, y con un ambiente
que propicie la participación de todos. Todos pueden sentirse confiados y con la sensación de que pueden
hablar sin que se produzcan críticas. Todas las ideas en principio deben tener el mismo valor, pues cualquiera
de ellas puede ser la clave para la solución. Es necesario prestar mucha atención a las frases que pueden
coartar la producción de ideas. Además durante la celebración no deben asistir espectadores.
Debemos evitar todos los bloqueos que paralizan la ideación: como son nuestros hábitos o ideas
preconcebidas, el desánimo o falta de confianza en sí mismo, el temor y la timidez.

3.6.2.- Las fases de aplicación en el Brainstorm.

I. Descubrir hechos.
Al menos con un día de antelación, el director comunica por escrito a los miembros del grupo sobre los temas
a tratar. El director explica los principios de la Tormenta de ideas e insiste en la importancia de tenerlos en
cuenta. La sesión comienza con una ambientación de unos 10 minutos, tratando un tema sencillo y no
comprometido. Es una fase especialmente importante para los miembros sin experiencia.
Se determina el problema, delimitándolo, precisándolo y clarificándolo. A continuación se plantea el problema,
recogiendo las experiencias que se poseen o consultando documentación. Cuando es complejo, conviene
dividirlo en partes. Aquí es importante la utilización del análisis, desmenuzando el problema en pequeñas
partes para conectar lo nuevo y lo desconocido.
II. Producir ideas (es la fase de tormenta de ideas propiamente dicha).

10
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

Se van aplicando alternativas. Se busca producir una gran cantidad de ideas, aplicando los principios que
hemos visto. Además, es útil cuando se ha trabajado mucho, alejarse del problema, pues es un buen
momento para que se produzcan asociaciones. Muchas de las nuevas ideas serán ideas antiguas, mejoradas
o combinadas con varias ya conocidas.
Al final de la reunión, el director da las gracias a los asistentes y les ruega que no abandonen el problema, ya
que al día siguiente se le pedirá una lista de ideas que les puedan haber surgido. Se incorporan las ideas
surgidas después de la reunión.
III. Descubrir soluciones
Se elabora una lista definitiva de ideas, para seleccionar las más interesantes. La selección se realiza
desechando las ideas que no tienen valor y se estudia si son válidas las que se consideran interesantes. Lo
mejor es establecer una lista de criterios de conveniencia para cada idea. Se seleccionan las ideas más útiles
y si es necesario se ponderarán. Pueden realizarlo los mismos miembros del grupo o crear otros para esta
tarea; la clasificación debe hacerse por categorías (tarea que corresponde al director). Se presentan las ideas
de forma atractiva, haciendo uso de soportes visuales.

3.7.- Prototipos.
Los prototipos permiten al desarrollador crear un modelo del software que debe ser construido.
Al igual que todos los enfoques al proceso de desarrollo del software, el prototipado comienza con la captura
de requerimientos. Desarrolladores y clientes se reúnen y definen los objetivos globales del software,
identifican todos los requerimientos que son conocidos, y señalan áreas en las que será necesaria la
profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El diseño rápido se centra en
una representación de aquellos aspectos del software que serán visibles al usuario (por ejemplo, entradas y
formatos de las salidas). El diseño rápido lleva a la construcción de un prototipo. El prototipo es evaluado por
el cliente y el usuario y utilizado para refinar los requerimientos del software a ser desarrollado. Un proceso de
iteración tiene lugar a medida que el prototipo es “puesto a punto” para satisfacer las necesidades del cliente y
permitiendo al mismo tiempo una mejor comprensión del problema por parte del desarrollador.

3.7.1.- Existen principalmente dos tipos de prototipos.

I. Prototipo rápido (o concept prototipe): El prototipado rápido es un mecanismo para lograr la
validación pre-compromiso. Se utiliza para validar requerimientos en una etapa previa al diseño
específico. En este sentido, el prototipo puede ser visto como una aceptación tácita de que los
requerimientos no son totalmente conocidos o entendidos antes del diseño y la implementación. El
prototipo rápido puede ser usado como un medio para explorar nuevos requerimientos y así ayudar a
“controlar” su constante evolución.
II. Prototipo evolutivo: Desde una perspectiva diferente, todo el ciclo de vida de un producto puede ser
visto como una serie incremental de detallados prototipos acumulativos. Tradicionalmente, el ciclo de
vida está dividido en dos fases distintas: desarrollo y mantenimiento. La experiencia ha demostrado
que esta distinción es arbitraria y va en contra de la realidad ya que la mayor parte del costo del
software ocurre después de que el producto se ha entregado. El punto de vista evolutivo del ciclo de
vida del software considera a la primera entrega como un prototipo inicial en el campo. Modificaciones
y mejoras subsecuentes resultan en nuevas entregas de prototipos más maduros. Este proceso
continúa hasta que se haya desarrollado el producto final. La adopción de esta óptica elimina la
distinción arbitraria entre desarrollo y mantenimiento, resultando en un importante cambio de
mentalidad que afecta las estrategias para la estimación de costos, enfoques de desarrollo y
adquisición de productos.

3.8. - Técnica JAD (Joint Application Design)

No importa cuán experto llegue a ser como entrevistador, inevitablemente experimentará situaciones en las
cuales las entrevistas uno a uno no parecerán tan útiles como usted quisiera. Las entrevistas personales
requieren mucho tiempo y están sujetas a error, y sus datos están propensos a una mala interpretación. IBM
desarrolló un método alternativo para entrevistar a los usuarios uno a uno, conocido como diseño conjunto de

11
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

aplicaciones [Joint Application Design, JAD]. Las razones para usar JAD son reducir el tiempo (y el costo)
requerido por las entrevistas personales, mejorar la calidad de los resultados de la evaluación de los
requerimientos de información y generar una mayor identificación del usuario con los nuevos sistemas de
información como resultado de los procesos participativos.
Aunque JAD se puede sustituir por las entrevistas personales en cualquier momento apropiado del ciclo de
vida del desarrollo de sistemas, normalmente ha sido utilizado como una técnica que le permite, como analista
de sistemas, realizar el análisis de los requerimientos y diseñar la interfaz de usuario en conjunto con los
usuarios. Todas las complejidades de esta técnica sólo se pueden aprender en un seminario donde se
expliquen los métodos patentados por IBM. Sin embargo, aquí podemos transmitirle suficiente información
sobre JAD para que se entere de algunas de sus ventajas y desventajas en comparación con las entrevistas
uno a uno.

3.8.1.- Condiciones que Apoyan el Uso de JAD.

La siguiente lista de condiciones le ayudará a decidir cuándo puede ser provechoso el uso de JAD. Considere
el uso del diseño conjunto de aplicaciones cuando:
I. Los grupos de usuarios están intranquilos y quieren algo nuevo, no una solución común a un problema
típico.
II. La cultura organizacional apoya los métodos conjuntos de resolución de problemas entre diversos
niveles de empleados.
III. Los analistas prevén que la cantidad de ideas generadas por medio de las entrevistas uno a uno no
será tan abundante como la cantidad de ideas que se podrían obtener de un ejercicio en grupo.
IV. El flujo de trabajo de la organización permite la ausencia de personal importante durante un periodo de
dos a cuatro días.

3.8.2.- Quien está Involucrado.

Las sesiones de diseño conjunto de aplicaciones incluyen una variedad de participantes: analistas, usuarios,
ejecutivos, etc.—, que aportarán su experiencia y habilidades, en diferente medida, a las sesiones. Aquí su
principal interés es que todos los miembros del equipo que participarán en el proyecto se comprometan e
involucren con el enfoque JAD. Escoja un patrocinador ejecutivo, una persona de experiencia que presentará y
concluirá la sesión de JAD. De preferencia, seleccione a un ejecutivo del grupo de usuarios que tenga algún
tipo de autoridad sobre las personas del área de sistemas de información que trabajen en el proyecto. Esta
persona será un símbolo visible e importante del compromiso de la organización con el proyecto de sistemas.
Por lo menos un analista del área de sistemas de información debe estar presente, pero a menudo el analista
toma un rol pasivo, a diferencia de lo que ocurre en la entrevista tradicional en la cual el analista controla la
interacción. Como analista del proyecto, usted debe estar presente en la sesión de JAD para escuchar lo que
dicen los usuarios y lo que necesitan.
Además, usted tendrá que dar una opinión especializada en caso que en la sesión de JAD se proponga alguna
solución de un costo desproporcionado. Sin este tipo de retroalimentación inmediata, las soluciones poco
realistas con costos excesivos podrían colarse en la propuesta y ser difíciles de eliminar más tarde.
Es conveniente seleccionar de ocho a 12 usuarios de cualquier nivel para participar, en las sesiones de JAD.
Procure seleccionar a usuarios por encima del nivel operativo, que tengan capacidad para explicar qué
información requieren para realizar sus trabajos, así como las características que les agradarían en un sistema
de cómputo nuevo o mejorado.
El líder de la sesión no debe ser un experto en el análisis y diseño de sistemas sino alguien que cuente con
habilidades de comunicación excelentes para facilitar las interacciones apropiadas. Tome nota que no es
conveniente designar a un líder de sesión que le reporte a una persona del grupo. Para evitar esta posibilidad,
una organización podría contratar a un consultor externo que funja como líder de sesión. El punto es contar
con una persona que atraiga la atención del grupo para tratar las cuestiones importantes de los sistemas,

12
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

negociar satisfactoriamente y resolver los conflictos, y ayudar a los miembros del grupo a alcanzar un acuerdo
general. :
Su sesión de JAD también debe incluir a uno o dos observadores que sean analistas o expertos técnicos de
otras áreas funcionales para ofrecer explicaciones y consejos técnicos al grupo durante las sesiones. Además,
un miembro del departamento de sistemas de información debe asistir a las sesiones de JAD para redactar
formalmente todo lo que se haga.

3.8.3.- Donde Celebrar las Reuniones de JAD.

De ser posible, recomendamos que las sesiones de dos a cuatro días se realicen fuera de las oficinas de la
organización, en ambientes cómodos. Algunos grupos usan los centros ejecutivos o incluso las instalaciones
de apoyo a la toma de decisiones en grupo que están disponibles en las principales universidades. La idea es
minimizar las distracciones y responsabilidades cotidianas inherentes al trabajo regular de los participantes. La
propia sala debe albergar cómodamente a la cantidad de personas invitadas. El equipo de apoyo a
presentaciones, como mínimo incluye dos proyectores de transparencias, un pizarrón, un rotafolio y acceso a
una copiadora. Las salas destinadas al apoyo a la toma de decisiones en grupo también proporcionan PCs
conectadas a una red, un sistema de proyección y software escrito para facilitar la interacción de grupos y
minimizar el comportamiento improductivo de los mismos.
Programe su sesión de JAD cuando todos los participantes puedan comprometerse a asistir. No realice las
sesiones a menos que todos aquellos que haya invitado realmente asistan. Esta regla es importante para el
éxito de las sesiones. Asegúrese de que todos los participantes reciban una agenda antes de la reunión, y
considere la idea de realizar una reunión informativa, de alrededor de medio día de duración, una semana más
o menos antes del taller para que los involucrados sepan lo que se espera de ellos. Una reunión previa de este
tipo le permite moverse rápidamente y desenvolverse con confianza una vez que se haya iniciado la reunión
definitiva.

3.8.4.- Realización de un Análisis Estructurado de las Actividades del Proyecto.

IBM recomienda que las sesiones de JAD examinen los siguientes puntos en el proyecto de sistemas
propuesto: planeación, recepción, procesamiento/seguimiento de recibos, supervisión y asignación,
procesamiento, registro, envío y evaluación. Se deben plantear y responder en cada tema las preguntas quién,
qué, cómo, dónde y por qué. Es evidente que los sistemas interactivos ad hoc como los sistemas de apoyo a
la toma de decisiones y otros tipos de sistemas que dependen del estilo del encargado de tomar las decisiones
(incluso los sistemas de prototipos) no se analizan con tanta facilidad como con el enfoque estructurado de
JAD.
En su calidad de analista en las sesiones de JAD, usted debe recibir las notas del redactor y debe preparar un
documento de especificaciones técnicas con base en lo que haya ocurrido en la reunión. Presente
sistemáticamente los objetivos de los directivos así como el alcance y los límites del proyecto. También debe
incluir las partes específicas del sistema, como detalles sobre los diseños de pantallas e informes.

3.9.- Análisis Comparativo de las Técnicas Anteriores.

Técnica Ventajas Desventajas

• Mediante ellas se obtiene una gran cantidad • La información obtenida al principio puede ser
de información correcta a través del usuario. redundante o incompleta.
Entrevistas y • Pueden ser usadas para obtener un pantallazo • Si el volumen de información manejado es alto,
Cuestionarios del dominio del problema. requiere mucha organización de parte del
analista, así como la habilidad para tratar y
• Son flexibles.
comprender el comportamiento de todos los
• Permiten combinarse con otras técnicas. involucrados.

Lluvia de Ideas • Los diferentes puntos de vista y las • Es necesaria una buena compenetración del
confusiones en cuento a terminología, son grupo participante.

13
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

aclaradas por expertos.

• Ayuda a desarrollar ideas unificadas basadas
en la experiencia de un experto.

• Ayudan a validar y desarrollar nuevos • El cliente puede llegar a pensar que el prototipo
requerimientos. es una versión del software que será
desarrollado.
Prototipos • Permite comprender aquellos requerimientos
que no están muy claros y que son de alta • A menudo, el desarrollador hace compromisos
volatilidad. de implementación con el objetivo de acelerar
la puesta en funcionamiento del prototipo

• Ahorro de tiempo sobre las entrevistas • JAD requiere que todos los participantes
tradicionales uno a uno. Algunas dediquen una gran cantidad de tiempo. Dado
organizaciones han estimado en 15 por ciento que JAD requiere un compromiso de dos a
menos tiempo que el enfoque tradicional. cuatro días.
• Posibilidad de un desarrollo rápido a través de • Si la preparación para las sesiones de JAD es
JAD. Dado que las entrevistas de usuarios no inadecuada en cualquier aspecto o si el informe
se realizan consecutivamente estas se de seguimiento y la documentación de
realizan en un periodo de semanas o meses. especificaciones están incompletos. En estos
casos los diseños resultantes podrían ser poco
• Posibilidad de mejorar el concepto de
satisfactorios. Es necesario que muchas
propiedad del sistema de información. Como
variables se conjuguen correctamente para que
analistas, nos esforzamos por involucrar a los
JAD tenga éxito.
usuarios en formas significativas y los
animamos a que sientan como suyos los • Las habilidades y cultura que requiere la
sistemas que estemos diseñando. organización no se hayan desarrollado lo
Técnica JAD suficiente para permitir el esfuerzo concertado
• Debido a su naturaleza interactiva y a su alta
indispensable para ser productivo en un
visibilidad, JAD ayuda a los usuarios a
escenario JAD.
involucrarse en las etapas tempranas de los
proyectos de sistemas y le da seriedad a la
retroalimentación que proporcionan.
• Un beneficio final de participar en las sesiones
de JAD es el desarrollo de diseños creativos.
El carácter interactivo de JAD tiene mucho en
común con las técnicas de la lluvia de ideas
que generan nuevas ideas y nuevas
combinaciones de ideas gracias a un entorno
dinámico y estimulante. Los diseños pueden
evolucionar a través de interacciones
simplificadas, en lugar de en un aislamiento
relativo.

El siguiente cuadro muestra las técnicas que pueden ser utilizadas en las diferentes actividades de la IR.

Análisis del Evaluación y Especificación

Validación Evolución
Problema Negociación de Requisitos

Entrevistas y
X X
Cuestionarios

Lluvia de
X X
Ideas

Prototipos X

Técnica JAD X X X

14
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

3.10.- Conclusiones y Recomendaciones.

A pesar de la importancia que tiene la Ingeniería de Requerimientos, ha costado mucho que se le preste la
atención adecuada a esta actividad. Aún quedan muchos desafíos que deben ser mejorados, tales como la
integración de requerimientos funcionales y no funcionales, la evaluación de especificaciones alternativas, la
formalización de la SRS, entre otras.
Cada actividad y técnica de la IR utilizada individualmente, dará diferentes soluciones para diferentes
proyectos, incluyendo aquellos casos en los que el dominio y el área del problema son el mismo. Por esta
razón, considero que no existe un modelo de proceso ideal para la IR; encontrar el método o la técnica
perfecta es una ilusión, pues cada método y técnica ofrece diferentes soluciones ante un problema.
En esta investigación se presentaron una serie de actividades y técnicas, que no pertenecen a un modelo de
proceso en sí, sino, que son una alternativa al material publicado por diferentes autores y que, desde mi punto
de vista, son las más importantes.
Debemos recordar que la Ingeniería de Requerimientos es una actividad que involucra a clientes, usuarios,
equipo de desarrollo, administradores de proyectos, etc.; por lo tanto, el proceso de IR no depende solamente
de la forma en cómo se percibe el problema, sino también, del nivel de experiencia que tengan los
involucrados.
Tomando en cuenta la magnitud de comunicación y el trabajo en equipo que debe existir en la IR, considero
necesario enfatizar más en cerrar las brechas que todavía existen, incluyendo los siguientes elementos:
 Factores sociales: involucrar al grupo para compartir sus experiencias.
 Factores de problemas específicos: el dominio de la estructura y estándares disponibles.
 Factores organizacionales: tiempo y costo presupuestados.
 Factores de diseño: por ejemplo, interfases de usuario
Es importante tomarse el tiempo necesario para conocer a nuestros clientes y usuarios, así como su ambiente
de trabajo. Esto, también ayuda a establecer una buena relación de trabajo y comunicación entre el equipo de
desarrollo y los clientes. Es realmente necesario que los clientes y usuarios participen en la definición de sus
requerimientos, pues ellos son los que deciden nuestro destino en el proyecto, deciden si les gustamos o no y
además financian el proyecto.
En cuanto a la investigación realizada de la técnica de Casos de Uso para la Ingeniería de Requerimientos,
puede decirse que los casos de uso son independientes del método de diseño que se utilice, y por lo tanto, del
método de programación. Luego de documentar los requerimientos de un sistema con casos de uso, se
puede diseñar un sistema “estructurado” (manteniendo una separación entre datos y funciones), o un sistema
Orientado a Objetos, sin que la técnica sea de mayor o menor utilidad en alguno de los dos casos. Esto da
más flexibilidad al método, y probablemente contribuya a su éxito.
Otro punto a considerar, es la inclusión del término “Administración de Requerimientos” en la década de los
90. Con esta nueva visión, se busca encontrar una descripción más apropiada de las actividades
involucradas, a la vez de enfatizar la importancia de mantener una buena relación entre los afectados y el
equipo del proyecto.
Entregar software de calidad, a tiempo y dentro del presupuesto, hará que nuestros clientes confíen y
asegurará el crecimiento y madurez de la relación de negocio.

15
 República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE II
Universidad Politécnica del Oeste Modulo: Fundamentos de Ingeniería de Requisitos y Análisis
“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas

4.- BIBLIOGRAFIA:
I. http://requerimientos.galeon.com/
II. Senn, James A. "Análisis y Diseño de Sistemas de Información". Segunda Edición. McGraw Hill. 1992.
III. JAMES A SENN, Análisis y Diseño de Sistema de Información, Mc Graw Hill, Enero 1990
IV. JAMES A. SENN, Análisis y Diseño de Sistemas de Información, Segunda Edición, Mc Graw Hill, Abril
2000.
V. IEEE Task Force on Requirements Engineering. Software Engineering Resources by Roger S.
Pressman & Associates
VI. Edward - Yourdon (1993) - Análisis Estructurado Moderno, Prentice Hall Hispanoamericana, S. A., pp.
136-147, 500-511.
VII. Roger - S. P. (1993) - Ingeniería del Software, Mc. Graw-Hill, pp. 217-218, 247.

VIII. Kendall & Kendall – Análisis y Diseño de Sistemas; Prentice Hall – 6 Edición.

IX. Pressman, R.S., "Ingeniería del Software. Un enfoque práctico.", McGraw-Hill.

X. Larman, C. "UML y patrones: Introducción al análisis y diseño orientado a objetos". Prentice halll.

XI. www.monografias.com: Ingeniería De Requerimientos, Ingeniería De Software.

XII. www.eici.ucm.cl/.../ygomez/.../Ingenieria-De-Requerimientos.doc

XIII. http://www.galeon.com/zuloaga/Doc/AnalisisRequer.pdf

XIV.

16