GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

0. INTRODUCCIN. La Recoleccin de Requerimientos cumple un papel primordial en el proceso de desarrollo de

software: la definicin de lo que se desea producir. Su principal tarea consiste en la generacin de especificaciones
correctas que describan con claridad, sin ambigedades, 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 cmo trabaja y dnde es necesario efectuar mejoras.

Un requerimiento es una caracterstica que debe incluirse en un nuevo sistema.

Vincula el estudio de un sistema existente con la recopilacin 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 ambigedad, 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:

(*) Caractersticas de usabilidad.

(*) Facilidad de mantenimiento.

Definen las interacciones del sistema con su entorno.

Universidad del Cauca Programa de Ingeniera de Sistemas

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

Tambin estn las RESTRICCIONES:

Los requisitos, en su definicin purista definen el QU, y no el CMO; pero en el conjunto de necesidades que debe cubrir
un sistema, no slo hay que tener en cuenta QU cosas hay que hacer, sino tambin en ocasiones CMO deben hacerse.
La clasificacin entre requisitos puros (QU) y restricciones (CMO) 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, limitacin tcnica, etc.)
Con carcter general las restricciones imponen limitaciones:

En la libertad de los analistas al realizar el diseo del sistema.

En los procesos o formas de trabajar que se emplearn en el desarrollo del sistema.

El analista del sistema elige entre todas las opciones tecnolgicamente posibles aquellas que segn su criterio
profesional y las circunstancias del sistema, aportan mejor solucin para la implementacin de los requisitos
funcionales y no funcionales.

Tambin tienen origen en la indicacin por parte del cliente de instrucciones como:

Debe emplearse base de datos Oracle.

Los procesos de desarrollo deben ser conformes a la metodologa Extreme Programming.

El sistema final debe ejecutarse sobre Linux Ubuntu.

Debe desarrollarse empleando Java.

Universidad del Cauca Programa de Ingeniera de Sistemas

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

2. LA INGENIERA DE REQUERIMIENTOS (I.R.). De las definiciones que existen para requerimiento, a continuacin
se presenta la definicin que aparece en el glosario de la IEEE.
(1) Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo.
(2) Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para
satisfacer un contrato, estndar, especificacin u otro documento formal.
(3) Una representacin documentada de una condicin o capacidad como en (1) o (2).
2.1. Caractersticas de los requerimientos. Las caractersticas de un requerimiento son sus propiedades principales.
Un conjunto de requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente
como en grupo. A continuacin se presentan las ms importantes:

Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems
su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del
producto o del proceso.

Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin 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 redaccin, es decir, si se proporciona
la informacin suficiente para su comprensin.

Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su
definicin, no debe causar confusiones al lector.

Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los
siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas.
Universidad del Cauca Programa de Ingeniera de Sistemas

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

2.2. Dificultades para definir los requerimientos.

Los requerimientos no son obvios y vienen de muchas fuentes.

Son difciles 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 difcil de manejar.

Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros.

Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.

Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas.

Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

2.3. Importancia (y beneficios) de la Ingeniera 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 estimacin 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, desempeo, etc.).

Mejora la comunicacin entre equipos: La especificacin 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 Ingeniera de Sistemas

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

2.4. Los defectos comunes en los requisitos y sus consecuencias.

Defecto

Consecuencia

Implicacin insuficiente del cliente

Problemas en la validacin del producto obtenido

Requisitos crecientes y cambiantes

Degradacin de la estructura y arquitectura del producto

Requisitos ambiguos

Prdida de tiempo en re-codificacin

Requisitos innecesarios

Trabajo innecesario

Requisitos insuficientes

Problemas en la validacin del producto obtenido

Error en la estimacin y planificacin

Omisin de las necesidades de grupos de usuarios

Usuarios insatisfechos

2.5. Personal involucrado en la Ingeniera de Requerimientos.

Usuario final: Estn relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; estn familiarizados
con los procesos especficos que debe realizar el software, dentro de los parmetros de su ambiente laboral. Sern
quienes utilicen las interfaces y los manuales de usuario.

Usuario Lder: Son los que comprenden el ambiente del sistema o el dominio del problema en donde ser empleado
el software desarrollado. Proporcionan al equipo tcnico 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 administracin de cambios, de la implementacin y resolucin de anomalas. Su trabajo consiste en
revisar y mejorar los procesos del producto ya finalizado.

Analistas y programadores: responsables del desarrollo del producto en s; interactan 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, diseadores de base de datos, entre otros.
Universidad del Cauca Programa de Ingeniera de Sistemas

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

3. Actividades de la Ingeniera de Requerimientos.

3.1. Anlisis 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 definicin clara del trmino "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 comunicacin entre desarrolladores y clientes; de esta
comunicacin con el cliente depende que entendamos sus necesidades. A travs de la definicin de problema, podemos
ver entonces que la actividad de "Anlisis del Problema" tiene por objetivo que se comprendan los problemas del negocio,
se evalen las necesidades iniciales de todos los involucrados en el proyecto y que se proponga una solucin de alto nivel
para resolverlo. Durante el anlisis 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 quin 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 transaccin bancaria".
Perspectiva del cliente = Prdida de tiempo
Perspectiva del banco = Posibles prdidas de clientes
Posibles soluciones pueden ser, determinar por qu demoran los cajeros, colocar una nueva caja (implica
contratacin de nuevos cajeros), abrir una nueva sucursal (involucra personal nuevo y estudio de mercado),
realizar transacciones por otros medios (telfono, Internet, mediante cajeros automticos, autobancos, etc.).
Mltiples soluciones aplican para el mismo problema, sin embargo, slo una de ellas ser la ms factible. Las
soluciones iniciales, deben ser definidas tomando en cuanta tanto la perspectiva tcnica como la del negocio.

Universidad del Cauca Programa de Ingeniera de Sistemas

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

B. Construir un vocabulario comn: Debe confeccionarse un glosario en dnde se definan todos los
trminos que tengan significados comunes (sinnimos) y que sern utilizados durante el proyecto. Por
ejemplo, las palabras pignoracin, retencin, valor en suspenso, custodia, garanta, entre otras, son utilizadas
para referirse a la accin de dejar una prenda (puede ser cualquier forma de ahorros) como garanta de una
deuda adquirida.
La creacin de un glosario es sumamente beneficiosa ya que reduce los trminos ambiguos desde el principio,
ahorra tiempo, asegura que todos los participantes de una reunin estn en la misma pgina, adems 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 ingeniera de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la
informacin necesaria para especificar un sistema adecuado.
Para saber quines son las personas, departamentos, organizaciones internas o externas que se vern
afectadas por el sistema, debemos realizar algunas preguntas.
Quin
Quin
Quin
Quin
Quin
Quin
Quin
Quin

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 inversin del sistema?

Como vemos, debe conocerse la opinin de todo aqul que de una u otra forma est involucrado con el
sistema, ya sea directa o indirectamente.

D. Definir los lmites 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 restriccin ambiental, presupuestaria, de tiempo, tcnica y de
factibilidad que limite el sistema que se va a construir.
Universidad del Cauca Programa de Ingeniera de Sistemas

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

3.2. Evaluacin y negociacin de los requerimientos. La diversa gama de fuentes de las cuales provienen los
requerimientos, hacen necesaria una evaluacin de los mismos antes de definir si son adecuados para el cliente. El
trmino "adecuado" significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades
tcnicas y econmicas, a la vez que se buscan resultados completos, correctos y sin ambigedades. En esta etapa se
pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstraccin y
descomposicin 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 trminos de
implementacin. A esta caracterstica se le conoce como prioridad y debe ser usada para establecer la secuencia en que
ocurrirn las actividades de diseo 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 operacin crtica del negocio.
Deseable: Si existe algn 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 categorizacin, la estrategia general es: incluir los obligatorios, discutir los deseables y descartar los
innecesarios. Antes de decidir la inclusin de un requerimiento, tambin debe analizarse su costo y complejidad.
C. Evaluar factibilidades y riesgos: Involucra la evaluacin de factibilidades tcnicas (pueden implementarse los
requerimientos con la tecnologa actual?); factibilidades operacionales (puede ser el sistema utilizado sin alterar el
organigrama actual?); factibilidades econmicas (ha sido aprobado por los clientes el presupuesto?).

En la actividad de evaluacin y negociacin, se incrementa la comunicacin 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 Ingeniera de Sistemas

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

3.3. Anlisis y documentacin de los mbitos de los Requerimientos.

mbitos

Documento relacionado (norma)

Sistema

Descripcin del Sistema (ConOps). Norma IEEE 1362.

Software

Especificacin de Requerimientos de Software (SRS). Norma IEEE 830.

3.3.1. Descripcin del Sistema (ConOps). Documento dirigido a los usuarios, que describe las caractersticas de un
sistema propuesto, desde el punto de vista del usuario. La Descripcin del Sistema es el medio de comunicacin que
recoge la visin general, cualitativa y cuantitativa de las caractersticas del sistema; compartido por la parte cliente y
desarrolladora. La Descripcin del sistema proporciona:

La descripcin de las necesidades operacionales del usuario sin entrar en detalles tcnicos.

La documentacin de las caractersticas del sistema y las necesidades operacionales del usuario, de forma que puedan
ser verificadas sin requerir conocimientos tcnicos.

El documento que recoge los deseos del usuario, sin requerir una cuantificacin medible. Por ejemplo, el usuario
puede indicar que desea que los tiempos de respuesta de las consultas sean rpidos, y las razones de su deseo, sin
necesidad de cuantificar esos trminos. Ms adelante, el desarrollo y anlisis 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 solucin, y las restricciones
que deben respetarse.

Universidad del Cauca Programa de Ingeniera de Sistemas

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

3.3.2. Especificacin de Requerimientos de Software (SRS).

Un documento SRS es la especificacin de las funciones que realiza un determinado producto de software, programa o
conjunto de programas en un determinado entorno. Los aspectos bsicos que debe incluir son:

Funcionalidad. Descripcin de lo que el software debe hacer.

Interfaces externos. Cmo debe interactuar el software con las personas, el sistema de hardware, o con otros
sistemas (software y hardware).

Rendimiento. Indicacin de la velocidad, disponibilidad, tiempos de respuesta, tiempos de recuperacin, tiempos de

determinadas funciones.

Atributos. Consideraciones de portabilidad, correccin, mantenibilidad, seguridad, etc.

Restricciones de diseo en la implementacin. Indicacin de las restricciones que puedan afectar por la
necesidad de sometimiento a estndares, lenguajes, polticas de integridad de bases de datos, lmites de recursos
disponibles para el desarrollo, sistema operativo, etc.

IMPORTANTE: Las especificaciones de requisitos de software deben EVITAR requisitos de diseo o de proyecto.
Un documento SRS debe especificar el QU, no el CMO.
La especificacin 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 trminos contractuales entre el cliente y el proveedor,
y normalmente incluyen informacin relativa a los procesos de adquisicin o de suministro

Universidad del Cauca Programa de Ingeniera de Sistemas

10

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

Una descripcin de requisitos del sistema limita las alternativas de diseo posibles, pero esto no significa que deba decidir
cul debe ser la solucin de diseo del sistema.
La especificacin de requisitos de software determina qu funcionalidades deben realizarse, qu datos deben generarse
en cada resultado, en qu lugar y quin los debe producir. La SRS debe centrarse en los servicios que se realizarn, pero,
en general, NO DEBE ESPECIFICAR ELEMENTOS DE DISEO COMO LOS SIGUIENTES:

Divisin del software en mdulos.

Distribucin de funciones en los mdulos.

Descripcin del flujo de informacin entre los mdulos.

Eleccin 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 especificacin de requisitos es el resultado final de las actividades de anlisis y evaluacin
de requerimientos; este documento resultante ser utilizado como fuente bsica de comunicacin entre los clientes,
usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementacin 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 evolucin 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 Ingeniera de Sistemas

11

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

3.4. Validacin de Requerimientos. La validacin es la actividad de la IR que permite demostrar que los
requerimientos definidos en el sistema son los que realmente quiere el cliente; adems 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 validacin garantiza que todos los requerimientos presentes en el documento de
especificacin sigan los estndares de calidad. No debe confundirse la actividad de evaluacin de requerimientos con la
validacin de requerimientos. La evaluacin verifica las propiedades de cada requerimiento, mientras que la validacin
revisa el cumplimiento de las caractersticas de la especificacin de requisitos.
Durante la actividad de validacin pueden hacerse preguntas en base a cada una de las caractersticas que se desean
revisar. A continuacin se presentan varios ejemplos:

Estn incluidas todas las funciones requeridas por el cliente? (completa).

Existen conflictos en los requerimientos? (consistencia).

Tiene alguno de los requerimientos ms de una interpretacin? (no ambigua).

Est cada requerimiento claramente representado? (entendible).

Pueden los requerimientos ser implementados con la tecnologa 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 validacin de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento
para el software desarrollado.

Universidad del Cauca Programa de Ingeniera de Sistemas

12

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

3.5. Evolucin de los requerimientos (Seguimiento). Los requerimientos son una manera de comprender mejor el
desarrollo de las necesidades de los usuarios y cmo los objetivos de la organizacin pueden cambiar, por lo tanto, es
esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de
evolucin es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto.
Los requerimientos cambian por diferentes razones. Las ms 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 caracterstica en particular,
modificacin que a la vez puede tener impacto en otros requerimientos. Por esto, la administracin de cambios involucra
actividades como establecer polticas, guardar histricos 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 cdigo, ya que evita tener
requerimientos parchados en un proyecto.
Entre algunos de los beneficios que proporciona el control de versiones estn:

Prevenir cambios no autorizados.

Guardar revisiones de los documentos de requerimientos.

Recuperar versiones previas de los documentos.

Prevenir la modificacin simultnea 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 Ingeniera de Sistemas

13

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

4. TCNICAS DE INGENIERA DE REQUERIMIENTOS.

Tcnica

Ventajas

Desventajas

Se obtiene una gran cantidad de informacin

correcta a travs del usuario.

Entrevistas y
Cuestionarios

La informacin obtenida al principio puede

ser redundante o incompleta.

Pueden ser usadas para obtener un pantallazo del

Si el volumen de informacin manejado es

dominio del problema.

alto, requiere mucha organizacin de parte

Son flexibles.

del analista, as como la habilidad para

Permiten combinarse con otras tcnicas.

tratar y comprender el comportamiento de

todos los involucrados.

Permiten expresar la intencin 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

informacin

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 informtica dirijan la

funcionalidad

del

nuevo

sistema

basndose

solamente en criterios tecnolgicos.

Lluvia de Ideas

Los diferentes puntos de vista y las confusiones en

cuanto a terminologa, son aclaradas por expertos.

Es necesaria una buena compenetracin del

grupo participante.

Ayuda a desarrollar ideas unificadas basadas en el

conocimiento de un experto.

Prototipos

Ayudan

validar

desarrollar

nuevos

El cliente puede llegar a pensar que el

requerimientos.

prototipo es una versin del software que

Permite comprender aquellos requerimientos que

ser desarrollado.

no estn muy claros y que son de alta volatilidad.

menudo,

compromisos
objetivo

de

el
de

desarrollador
implementacin

acelerar

la

hace
con

puesta

el
en

funcionamiento del prototipo.

Universidad del Cauca Programa de Ingeniera de Sistemas

14

GUIA 3. Conceptos sobre Ingeniera de Requerimientos.

5. CONCLUSIONES Y RECOMENDACIONES.
A pesar de la importancia que tiene la Ingeniera de Requerimientos, ha costado mucho que se le preste la atencin
adecuada a esta actividad. An quedan muchos desafos que deben ser mejorados, tales como la integracin de
requerimientos funcionales y no funcionales, la formalizacin de la SRS, entre otras.
Cada actividad y tcnica 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 razn, se considera que no
existe un modelo de proceso ideal para la I.R.; encontrar el mtodo o la tcnica perfecta es una ilusin, pues cada
mtodo y tcnica ofrece diferentes soluciones ante un problema. Cabe recordar que la Ingeniera 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 cmo se percibe el problema, sino tambin, del nivel de
experiencia que tengan los involucrados.
Tomando en cuenta la magnitud de comunicacin y el trabajo en equipo que debe existir en la I.R., se considera
necesario enfatizar ms en cerrar las brechas que todava existen, incluyendo los siguientes elementos:
Factores sociales: involucrar al grupo para compartir sus experiencias.
Factores de problemas especficos: el dominio de la estructura y estndares disponibles.
Factores organizacionales: tiempo y costo presupuestados.
Factores de diseo: 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,
tambin ayuda a establecer una buena relacin de trabajo y comunicacin entre el equipo de desarrollo y los clientes. Es
realmente necesario que los clientes y usuarios participen en la definicin de sus requerimientos, pues ellos son los que
deciden nuestro destino en el proyecto, deciden si les gusta o no y adems financian el proyecto.
-------------------------- FIN DEL DOCUMENTO

Universidad del Cauca Programa de Ingeniera de Sistemas

15