Guía 03 - Universidad del Cauca

GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
0. INTRODUCCIÓN. La Recolección de Requerimientos cumple un papel primordial en el proceso de desarrollo de
software: 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.
¿A qué se denomina determinacion de requerimientos?

Es el estudio de un sistema para conocer cómo trabaja y dónde es necesario efectuar mejoras.

Un requerimiento es una característica que debe incluirse en un nuevo sistema.

Vincula el estudio de un sistema existente con la recopilación de detalles relacionados con él.
1. TIPOS DE REQUERIMIENTOS.
Requerimientos Funcionales (refieren a las tareas que el sistema debe realizar) :

Definen el comportamiento del sistema.

Describen las tareas que el sistema debe realizar.

Al definir un requisito funcional es importante mantener el equilibrio entre la excesiva generalidad, insuficiencia de
detalle o ambigüedad, y el exceso de detalle con precisiones o descripciones innecesarias o redundantes.
Requerimientos NO Funcionales. Definen aspectos, que sin ser funcionalidades, resultan deseables desde el punto de
vista del usuario. Generalmente comprenden atributos de calidad:
(*) Tiempos de respuesta.
Requerimientos de Interface:
(*) Características de usabilidad.
(*) Facilidad de mantenimiento.
Definen las interacciones del sistema con su entorno.
Universidad del Cauca – Programa de Ingeniería de Sistemas
1
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
También están las RESTRICCIONES:
Los requisitos, en su definición purista definen el QUÉ, y no el CÓMO; pero en el conjunto de necesidades que debe cubrir
un sistema, no sólo hay que tener en cuenta QUÉ cosas hay que hacer, sino también en ocasiones CÓMO deben hacerse.
La clasificación entre requisitos puros (QUÉ) y restricciones (CÓMO) la debe considerar el analista para que el equipo de
trabajo sepa hasta qué punto determinados aspectos limitan sus opciones de trabajo, y poder mantener así la
trazabilidad con su origen (necesidad apuntada por el usuario, normativa legal, limitación técnica, etc.)
Con carácter general las restricciones imponen limitaciones:

En la libertad de los analistas al realizar el diseño del sistema.

En los procesos o formas de trabajar que se emplearán en el desarrollo del sistema.

El analista del sistema elige entre todas las opciones tecnológicamente posibles aquellas que según su criterio
profesional y las circunstancias del sistema, aportan mejor solución para la implementación de los requisitos
funcionales y no funcionales.
También tienen origen en la indicación por parte del cliente de instrucciones como:

Debe emplearse base de datos Oracle.

Los procesos de desarrollo deben ser conformes a la metodología Extreme Programming.

El sistema final debe ejecutarse sobre Linux Ubuntu.

Debe desarrollarse empleando Java.
Universidad del Cauca – Programa de Ingeniería de Sistemas
2
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
2. LA INGENIERÍA DE REQUERIMIENTOS (I.R.). De las definiciones que existen para requerimiento, a continuación
se presenta la definición que aparece en el glosario de la IEEE.
(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.
(2) 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.
(3) Una representación documentada de una condición o capacidad como en (1) o (2).
2.1. 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.

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. El lenguaje usado en su
definición, no debe causar confusiones al lector.

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.
Universidad del Cauca – Programa de Ingeniería de Sistemas
3
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
2.2. 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.
2.3. Importancia (y beneficios) de la Ingeniería de Requerimientos.

Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la I.R. consiste de una serie
de pasos organizados y bien definidos.

Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La I.R. proporciona un punto de
partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y
recursos necesarios.

Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal
desarrollo no descubierto a tiempo, es sumamente caro.

Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos
(funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).

Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre
clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.

Evita rechazos de usuarios finales: La I.R. obliga al cliente a considerar sus requerimientos cuidadosamente y
revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.
Universidad del Cauca – Programa de Ingeniería de Sistemas
4
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
2.4. Los defectos comunes en los requisitos y sus consecuencias.
Defecto
Consecuencia
Implicación insuficiente del cliente
Problemas en la validación del producto obtenido
Requisitos crecientes y cambiantes
Degradación de la estructura y arquitectura del producto
Requisitos ambiguos
Pérdida de tiempo en re-codificación
Requisitos innecesarios
Trabajo innecesario
Requisitos insuficientes
Problemas en la validación del producto obtenido
Error en la estimación y planificación
Omisión de las necesidades de grupos de usuarios
Usuarios insatisfechos
2.5. Personal involucrado en la Ingeniería de Requerimientos.

Usuario final: 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 que comprenden el ambiente del sistema o el dominio del problema en donde será empleado
el software desarrollado. 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: responsables del desarrollo del producto en sí; interactúan directamente con el cliente.

Personal de pruebas: Encargados de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones
presentadas por el sistema son las adecuadas. Validan 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.
Universidad del Cauca – Programa de Ingeniería de Sistemas
5
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
3. Actividades de la Ingeniería de Requerimientos.
3.1. Análisis del Problema: El objetivo de esta actividad es entender las verdaderas necesidades del negocio. Antes de
describir qué pasos deben cumplirse en esta actividad, debemos tener una definición clara del término "Problema".
"Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se desean". Aquí
vemos nuevamente la importancia que tiene una buena comunicación entre desarrolladores y clientes; de esta
comunicación con el cliente depende que entendamos sus necesidades. A través de la definición de problema, podemos
ver entonces que la actividad de "Análisis del Problema" tiene por objetivo que se comprendan los problemas del negocio,
se evalúen las necesidades iniciales de todos los involucrados en el proyecto y que se proponga una solución de alto nivel
para resolverlo. Durante el análisis del problema, se realizan una serie de pasos para garantizar un acuerdo entre los
involucrados, basados en los problemas reales del negocio.
Estos pasos son los siguientes:
A. Comprender el problema que se está resolviendo: Es importante determinar quién tiene el problema
realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde
diferentes puntos de vista. Veamos la siguiente necesidad: "El cliente se queja mucho por la enorme fila que
debe formar para realizar una transacción bancaria".
Perspectiva del cliente = Pérdida de tiempo
Perspectiva del banco = Posibles pérdidas de clientes
Posibles soluciones pueden ser, determinar por qué demoran los cajeros, colocar una nueva caja (implica
contratación de nuevos cajeros), abrir una nueva sucursal (involucra personal nuevo y estudio de mercado),
realizar transacciones por otros medios (teléfono, Internet, mediante cajeros automáticos, autobancos, etc.).
Múltiples soluciones aplican para el mismo problema, sin embargo, sólo una de ellas será la más factible. Las
soluciones iniciales, deben ser definidas tomando en cuanta tanto la perspectiva técnica como la del negocio.
Universidad del Cauca – Programa de Ingeniería de Sistemas
6
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
B. Construir un vocabulario común: Debe confeccionarse un glosario en dónde se definan todos los
términos que tengan significados comunes (sinónimos) y que serán utilizados durante el proyecto. Por
ejemplo, las palabras pignoración, retención, valor en suspenso, custodia, garantía, entre otras, son utilizadas
para referirse a la acción de dejar una prenda (puede ser cualquier forma de ahorros) como garantía de una
deuda adquirida.
La creación de un glosario es sumamente beneficiosa ya que reduce los términos ambiguos desde el principio,
ahorra tiempo, asegura que todos los participantes de una reunión están en la misma página, además de ser
reutilizable en otros proyectos.
C. Identificar a los afectados por el sistema: Identificar a todos los afectados evita que existan sorpresas
a medida que avanza el proyecto. Las necesidades de cada afectado, son discutidas y sometidas a debate
durante de ingeniería de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la
información necesaria para especificar un sistema adecuado.
Para saber quiénes son las personas, departamentos, organizaciones internas o externas que se verán
afectadas por el sistema, debemos realizar algunas preguntas.
¿Quién
¿Quién
¿Quién
¿Quién
¿Quién
¿Quién
¿Quién
¿Quién
usará el sistema que se va a construir?
desarrollará el sistema?
probará el sistema?
documentará el sistema?
dará soporte al sistema?
dará mantenimiento al sistema?
mercadeará, venderá, y/o distribuirá el sistema?
se beneficiará por el retorno de inversión del sistema?
Como vemos, debe conocerse la opinión de todo aquél que de una u otra forma está involucrado con el
sistema, ya sea directa o indirectamente.
D. Definir los límites y restricciones del sistema: Este punto es importante pues debemos saber lo que se
está construyendo, y lo que no se está construyendo, para así entender la estrategia del producto a corto y
largo plazo. Debe determinarse cualquier restricción ambiental, presupuestaria, de tiempo, técnica y de
factibilidad que limite el sistema que se va a construir.
Universidad del Cauca – Programa de Ingeniería de Sistemas
7
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
3.2. Evaluación y negociación de los requerimientos. La diversa gama de fuentes de las cuales provienen los
requerimientos, hacen necesaria una evaluación de los mismos antes de definir si son adecuados para el cliente. El
término "adecuado" significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades
técnicas y económicas, a la vez que se buscan resultados completos, correctos y sin ambigüedades. En esta etapa se
pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstracción y
descomposición de cada problema presentado. Los principales pasos de esta actividad son:
A. Descubrir problemas potenciales: se identifican aquellos requerimientos ambiguos, incompletos, inconsistentes, etc.
B. Clasificar los requerimientos: se busca identificar la importancia que tiene un requerimiento en términos de
implementación. A esta característica se le conoce como prioridad y debe ser usada para establecer la secuencia en que
ocurrirán las actividades de diseño y prueba de cada requisito. La prioridad de cada requerimiento dependerá de las
necesidades que tenga el negocio. Con base en la prioridad, cada requerimiento puede ser clasificado como:
Obligatorio: si afecta una operación crítica del negocio.
Deseable: Si existe algún proceso que se quiera incluir para mejorar los procesos actuales.
Innecesario: si se trata de un requerimiento informativo o que puede esperar para fases posteriores.
Una vez hecha esta categorización, la estrategia general es: incluir los obligatorios, discutir los deseables y descartar los
innecesarios. Antes de decidir la inclusión de un requerimiento, también debe analizarse su costo y complejidad.
C. Evaluar factibilidades y riesgos: Involucra la evaluación de factibilidades técnicas (¿pueden implementarse los
requerimientos con la tecnología actual?); factibilidades operacionales (¿puede ser el sistema utilizado sin alterar el
organigrama actual?); factibilidades económicas (¿ha sido aprobado por los clientes el presupuesto?).
En la actividad de evaluación y negociación, se incrementa la comunicación entre el equipo de desarrollo y los afectados.
Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben
tenerse en cuenta; entre las principales tenemos:
 Documentar todos los requerimientos al nivel de detalle que sea requerido.
 Mostrar todos los requerimientos a los involucrados en el sistema.
 Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos.
 Establecer las relaciones entre requerimientos que indiquen dependencias.
 Negociar con flexibilidad para que exista un beneficio mutuo.
 Enfocarse en intereses y no en posiciones.
Universidad del Cauca – Programa de Ingeniería de Sistemas
8
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
3.3. Análisis y documentación de los ámbitos de los Requerimientos.
Ámbitos
Documento relacionado (norma)
Sistema
Descripción del Sistema (ConOps). Norma IEEE 1362.
Software
Especificación de Requerimientos de Software (SRS). Norma IEEE 830.
3.3.1. Descripción del Sistema (ConOps). Documento dirigido a los usuarios, que describe las características de un
sistema propuesto, desde el punto de vista del usuario. La Descripción del Sistema es el medio de comunicación que
recoge la visión general, cualitativa y cuantitativa de las características del sistema; compartido por la parte cliente y
desarrolladora. La Descripción del sistema proporciona:

La descripción de las necesidades operacionales del usuario sin entrar en detalles técnicos.

La documentación de las características del sistema y las necesidades operacionales del usuario, de forma que puedan
ser verificadas sin requerir conocimientos técnicos.

El documento que recoge los deseos del usuario, sin requerir una cuantificación medible. Por ejemplo, el usuario
puede indicar que desea que los tiempos de respuesta de las consultas sean rápidos, y las razones de su deseo, sin
necesidad de cuantificar esos términos. Más adelante, el desarrollo y análisis de los requisitos del sistema, el analista
concretará y cuantificará esos deseos.

El documento en el que, comprador y suministrador, reflejan las posibles estrategias de solución, y las restricciones
que deben respetarse.
Universidad del Cauca – Programa de Ingeniería de Sistemas
9
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
3.3.2. Especificación de Requerimientos de Software (SRS).
Un documento SRS es la especificación de las funciones que realiza un determinado producto de software, programa o
conjunto de programas en un determinado entorno. Los aspectos básicos que debe incluir son:

Funcionalidad. Descripción de lo que el software debe hacer.

Interfaces externos. Cómo debe interactuar el software con las personas, el sistema de hardware, o con otros
sistemas (software y hardware).

Rendimiento. Indicación de la velocidad, disponibilidad, tiempos de respuesta, tiempos de recuperación, tiempos de
determinadas funciones.

Atributos. Consideraciones de portabilidad, corrección, mantenibilidad, seguridad, etc.

Restricciones de diseño en la implementación. Indicación de las restricciones que puedan afectar por la
necesidad de sometimiento a estándares, lenguajes, políticas de integridad de bases de datos, límites de recursos
disponibles para el desarrollo, sistema operativo, etc.
IMPORTANTE: Las especificaciones de requisitos de software deben EVITAR requisitos de diseño o de proyecto.
Un documento SRS debe especificar el QUÉ, no el CÓMO.
La especificación de requisitos de software se centra en el producto,
no en el proceso de desarrollo del producto.
En un SRS no deben incluirse requisitos de PROYECTO
porque representan los términos contractuales entre el cliente y el proveedor,
y normalmente incluyen información relativa a los procesos de adquisición o de suministro
Universidad del Cauca – Programa de Ingeniería de Sistemas
10
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
Una descripción de requisitos del sistema limita las alternativas de diseño posibles, pero esto no significa que deba decidir
cuál debe ser la solución de diseño del sistema.
La especificación de requisitos de software determina qué funcionalidades deben realizarse, qué datos deben generarse
en cada resultado, en qué lugar y quién los debe producir. La SRS debe centrarse en los servicios que se realizarán, pero,
en general, NO DEBE ESPECIFICAR ELEMENTOS DE DISEÑO COMO LOS SIGUIENTES:

División del software en módulos.

Distribución de funciones en los módulos.

Descripción del flujo de información entre los módulos.

Elección de las estructuras de datos.
Deben centrarse únicamente en el punto de vista externo del sistema,
y no en el funcionamiento interno
Es importante destacar que la especificación de requisitos es el resultado final de las actividades de análisis y evaluación
de requerimientos; este documento resultante será utilizado como fuente básica de comunicación entre los clientes,
usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementación del sistema.
Los clientes y usuarios utilizan la SRS para comparar si lo que se está proponiendo, coincide con las necesidades de la
empresa. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. El personal de
pruebas elaborará las pruebas funcionales y de sistemas en base a este documento. Para el administrador del proyecto
sirve como referencia y control de la evolución del sistema.
Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propia plantilla.
Universidad del Cauca – Programa de Ingeniería de Sistemas
11
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
3.4. Validación de Requerimientos. La validación es la actividad de la IR que permite demostrar que los
requerimientos definidos en el sistema son los que realmente quiere el cliente; además revisa que no se haya omitido
ninguno, que no sean ambiguos, inconsistentes o redundantes. En este punto es necesario recordar que la SRS debe
estar libre de errores, por lo tanto, la validación garantiza que todos los requerimientos presentes en el documento de
especificación sigan los estándares de calidad. No debe confundirse la actividad de evaluación de requerimientos con la
validación de requerimientos. La evaluación verifica las propiedades de cada requerimiento, mientras que la validación
revisa el cumplimiento de las características de la especificación de requisitos.
Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se desean
revisar. A continuación se presentan varios ejemplos:

¿Están incluidas todas las funciones requeridas por el cliente? (completa).

¿Existen conflictos en los requerimientos? (consistencia).

¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua).

¿Está cada requerimiento claramente representado? (entendible).

¿Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible? (factible).

¿Está la SRS escrita en un lenguaje apropiado? (clara).

¿Existe facilidad para hacer cambios en los requerimientos? (modificable).

¿Está claramente definido el origen de cada requisito? (rastreable).

¿Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable).
La validación de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento
para el software desarrollado.
Universidad del Cauca – Programa de Ingeniería de Sistemas
12
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
3.5. Evolución de los requerimientos (Seguimiento). Los requerimientos son una manera de comprender mejor el
desarrollo de las necesidades de los usuarios y cómo los objetivos de la organización pueden cambiar, por lo tanto, es
esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de
evolución es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto.
Los requerimientos cambian por diferentes razones. Las más frecuentes son:

Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas.

Porque cambió el problema que se estaba resolviendo.

Porque los usuarios cambiaron su forma de pensar o sus percepciones.

Porque cambió el ambiente de negocios.

Porque cambió el mercado en el cual se desenvuelve el negocio.
Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una característica en particular,
modificación que a la vez puede tener impacto en otros requerimientos. Por esto, la administración de cambios involucra
actividades como establecer políticas, guardar históricos de cada requerimiento, identificar dependencias entre ellos y
mantener un control de versiones.
Tener versiones de los requerimientos es tan importante como tener versiones del código, ya que evita tener
requerimientos parchados en un proyecto.
Entre algunos de los beneficios que proporciona el control de versiones están:

Prevenir cambios no autorizados.

Guardar revisiones de los documentos de requerimientos.

Recuperar versiones previas de los documentos.

Prevenir la modificación simultánea a los requisitos.

En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un solo
proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos.
Universidad del Cauca – Programa de Ingeniería de Sistemas
13
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
4. TÉCNICAS DE INGENIERÍA DE REQUERIMIENTOS.
Técnica
Ventajas

Desventajas
Se obtiene una gran cantidad de información

correcta a través del usuario.
Entrevistas y
Cuestionarios

La información obtenida al principio puede
ser redundante o incompleta.
Pueden ser usadas para obtener un pantallazo del

Si el volumen de información manejado es
dominio del problema.
alto, requiere mucha organización de parte

Son flexibles.
del analista, así como la habilidad para

Permiten combinarse con otras técnicas.
tratar y comprender el comportamiento de
todos los involucrados.

Permiten expresar la intención que tiene el usuario.

Permiten extraer los requerimientos del usuario y
Escenarios
(Casos de Uso,
del sistema.

Tarjetas CRC,
Diagramas de
Flujo)
NO permiten establecer los requisitos no
funcionales.

Centran al analista en las tareas principales de
usuario.


Deben
complementarse
con
información
consignada en otros documentos.

Tienen en cuenta todos los usuarios evitando que
En sistemas grandes toman mucho tiempo
para definir todas los escenarios.
las personas especializadas en informática dirijan la
funcionalidad
del
nuevo
sistema
basándose
solamente en criterios tecnológicos.

Lluvia de Ideas
Los diferentes puntos de vista y las confusiones en

cuanto a terminología, son aclaradas por expertos.

Es necesaria una buena compenetración del
grupo participante.
Ayuda a desarrollar ideas unificadas basadas en el
conocimiento de un experto.


Prototipos
Ayudan
a
validar
y
desarrollar
nuevos

El cliente puede llegar a pensar que el
requerimientos.
prototipo es una versión del software que
Permite comprender aquellos requerimientos que
será desarrollado.
no están muy claros y que son de alta volatilidad.

A
menudo,
compromisos
objetivo
de
el
de
desarrollador
implementación
acelerar
la
hace
con
puesta
el
en
funcionamiento del prototipo.
Universidad del Cauca – Programa de Ingeniería de Sistemas
14
GUIA 3. Conceptos sobre Ingeniería de Requerimientos.
5. 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 formalización de la SRS, entre otras.
Cada actividad y técnica de la I.R. 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, se considera que no
existe un modelo de proceso ideal para la I.R.; 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. Cabe 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 I.R. 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 I.R., se considera
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 los 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 gusta o no y además financian el proyecto.
-------------------------- FIN DEL DOCUMENTO
Universidad del Cauca – Programa de Ingeniería de Sistemas
15