Ingeniería de Software.

Dr. Pedro Mejia Alvarez.

Septiembre 2009.
Introducción a los Requerimientos de Software

El éxito de un sistema de software se mide de acuerdo al grado con que este y su proyecto de
desarrollo cumplen con el objetivo para el cual fueron requeridos. La Ingeniería de
Requerimientos es la parte inicial del proceso de desarrollo la cual permite descubrir este objetivo
mediante la obtención, análisis y documentación de todos los requerimientos del cliente. El
problema fundamental del desarrollo de los sistemas de software es que los requerimientos son
inherentemente dinámicos. Estos cambian constantemente con el tiempo y los cambios se deben a
múltiples factores entre los que se encuentran, cambios por mejoras, cambios por errores
descubiertos, cambios por adopción de nuevas tecnologías ó cambios por mejoras en la
comprensión del sistema, entre otros. Debido a su naturaleza dinámica, el proceso de Ingeniería
de Requerimientos debe ser preciso y flexible a la vez. Preciso por que debe incluir todos los
requerimientos del cliente y del ambiente donde este estará operando. Así mismo debe ser
flexible, ya que los requerimientos están sujetos a constantes cambios.

Las malas o ineficientes prácticas de la Ingeniería de Requerimientos llevan invariablemente al

fracaso del desarrollo del software, y pueden ser más costosas, dependiendo de que tan tarde estas
son descubiertas en el proceso de desarrollo. Por esta razón, es necesaria una disciplina en el
desarrollo de software y en particular en el proceso de Ingeniería de Requerimientos a fin de
evitar que el desarrollo de software falle o que sufra de costos excesivos.
2.1 El Proceso de Ingeniería de Requerimientos
La primera etapa del proceso de desarrollo de Software es la Ingeniería de Requerimientos. En
esta fase se definen y especifican los requerimientos de los clientes y usuarios. Las actividades
involucradas en la Ingeniería de Requerimientos son: la obtención, el análisis, la especificación,
la validación y la administración de los requerimientos de software.

Los requerimientos de software se definen como las necesidades de los clientes, los servicios que
el usuario desea que proporcione el sistema y las restricciones sobre las que el software debe
operar. El resultado del proceso de requerimientos es la base para el diseño, la implementación y
la evaluación del software.

A pesar de los avances recientes en la Ingeniería de Software, en la actualidad existe una gran
cantidad de desarrolladores que no hacen uso de los procedimientos y actividades que
proporciona la Ingeniería de Software en el desarrollo de sistemas. Esto afecta particularmente a
la Ingeniería de Requerimientos ya que si no se descubren y especifican todos los requerimientos
del sistema en desarrollo, podría conducir a la entrega de un producto de software incompleto
(sin satisfacer completamente las necesidades de los clientes), con defectos y poco funcional.
Esto podría provocar también el abandono de los proyectos de software en pleno proceso de
desarrollo o que estos sean entregados con retrasos y a costos mayores a los estimados.

La Ingeniería de Requerimientos es una etapa de la Ingeniería de Software en donde muchos

proyectos no siguen un proceso bien definido. A pesar de que existen en la literatura un gran
número de procesos, métodos y herramientas para esta etapa, en la mayoría de los proyectos
actuales, se le da poca importancia a la definición, análisis y validación de los requerimientos y a
su consecuente documentación. Además, los proyectos resultantes no tienen una clara definición
y distinción entre los requerimientos y el diseño. Es decir, no distinguen claramente entre lo que
se quiere construir y la forma en como se debe construir el software.

En muchos de los casos, los problemas que se encuentran en el desarrollo de un proyecto o

producto de software provienen de la Ingeniería de Requerimientos. Por esta razón, es importante
definir de forma clara cual es el proceso y los métodos que definen a esta fase de la Ingeniería de
Software. En esta sección definiremos el proceso de Ingeniería de Requerimientos y sus
actividades asociadas.

2
La Ingeniería de Requerimientos en una fase clave en el proceso de Ingeniería de Software ya
que es la etapa en la cual se decide que es lo que se quiere construir. La fase de requerimientos es
la etapa del proceso que más afecta al producto resultante, si no se lleva a cabo adecuadamente.
Ninguna otra fase del proceso es más costosa de reparar. Muchos errores en los requerimientos
pasan sin detectarse hasta varias fases adelante en el ciclo de vida, y la corrección de estos es más
costosa, entre más fases se hayan terminado.

En la Figura 2.1 se muestra la interacción que existe entre las diferentes actividades del proceso
de Ingeniería de Requerimientos utilizando el paradigma de cascada, en donde cada actividad
tiene un retorno a la actividad anterior. Se parte del hecho de que existe una definición general
del problema y un análisis de factibilidad, el cual permite descubrir los problemas que involucra
el desarrollo del software. Siempre que se resuelvan los problemas descubiertos en el análisis de
factibilidad, el proceso de Ingeniería de Requerimientos inicia con la actividad de la obtención de
los requerimientos.

Los requerimientos inicialmente obtenidos con el cliente (conocidos como requerimientos

iniciales) y posteriormente analizados se escriben en el documento de descripción de
requerimientos (DDR). La especificación y validación son actividades que pueden ser repetidas
cuantas veces sean necesarias hasta lograr el nivel de refinamiento que se desee. Finalmente, cada
cambio en los requerimientos es llevado a cabo en distintas versiones del Documento de
Especificación de Requerimientos (DER). En este documento se incluyen todos los
requerimientos reales del sistema.

Las actividades que se definen en el proceso de la Ingeniería de Requerimientos son las

siguientes:

1. Análisis de factibilidad. Este análisis permitirá verificar si el software es factible de

desarrollarse, con el personal disponible, con las herramientas técnicas a su alcance, en el
costo contratado y en el tiempo que el cliente requiere. Si el analista observa que existen
muchos riesgos que no pueden ser resueltos para el desarrollo del software, podría ser
necesario cancelar o retrasar el proyecto.

2. Obtención de requerimientos. Los requerimientos de un sistema de software no se

encuentran en algún documento esperando que estos sean descubiertos. El analista de
requerimientos debe verificar con el cliente, y con los involucrados en el proyecto, cuales son
las necesidades de la organización y las demandas específicas del cliente. Esta tarea no es

3
 fácil, por lo cual en los próximos capítulos expondremos algunas de las técnicas mas
utilizadas para la obtención de requerimientos.

3. Análisis de los requerimientos. En ésta actividad, cada uno de los requerimientos se

verifican para analizar si son éstos una consecuencia lógica de sus necesidades. Los
requerimientos son analizados a fin de decidir cuales de estos deben aceptarse. Este análisis
es necesario ya que podrán existir conflictos en los requerimientos que provengan de distintas
fuentes, información incompleta o requerimientos podrían no ser factibles de implementar de
acuerdo con el presupuesto del proyecto. Derivado del análisis, se definen prioridades para
cada requerimiento. En esta actividad debe haber negociaciones entre clientes, usuarios y
desarrolladores a fin de que todos estén de acuerdo con cada uno de los requerimientos.
Como producto de esta negociación se deben eliminar vaguedades, inconsistencias ó
discrepancias con otros requerimientos, ó aspectos que puedan producir conflictos.

4. Especificación de Requerimientos. En esta actividad, los requerimientos derivados del

análisis son documentados con detalle, utilizando lenguaje natural y diagramas. En esta
actividad se distinguen cuales requerimientos son funcionales y cuales son no-funcionales
(aquellos aspectos que definen la calidad o las restricciones del software). De esta actividad
se genera el documento de especificación de requerimientos (DER).

5. Validación de los requerimientos. En esta actividad, se verifica que lo escrito sea realmente
lo que requiere el cliente. En algunos casos, en esta actividad se desarrollan prototipos de
software para visualizar los requerimientos de software, a fin de validar su funcionalidad.

En cada una de las actividades del proceso de la Ingeniera de Requerimientos se llevan a cabo
tareas específicas utilizando técnicas y herramientas de la Ingeniería de Requerimientos. El
objetivo de la Ingeniería de Requerimientos es obtener un documento formal (DER) en donde se
especifiquen las características y restricciones que debe cumplir el sistema que se va a
desarrollar. Este documento debe cumplir con ciertas características de calidad, como son las
siguientes: entendible, necesario, consistente, no ambiguo, completo, verificable, correcto,
realista, rastreable y modificable.

4
 Figura 2.1. El proceso de Ingeniería de Requerimientos en el modelo de cascada.

Dentro de las actividades del proceso de Ingeniería de Requerimientos se encuentran también las
siguientes tareas:

1. Administración de requerimientos. Durante la administración de requerimientos se verifica

que el proceso de requerimientos se siga de acuerdo a los estándares y procesos elegidos. La
administración de requerimientos implica el establecimiento y mantenimiento de un acuerdo
con el cliente para el proyecto de software. A este acuerdo se le denomina contrato. Este
acuerdo debe detallarse en el documento de especificación de requerimientos (DER). La
aceptación de los requerimientos debe darse por parte del cliente y también por parte de los
desarrolladores. Los desarrolladores deben aceptar éstas especificaciones y deben estar de
acuerdo en que éstas son factibles de implementarse.

En general las actividades de la administración de requerimientos son las siguientes:

• Documentación de cada uno de los requerimientos y la información relevante que indique,

el origen, el autor y la fecha de origen de cada requerimiento.

• Mantenimiento de los planes del proyecto a fin de cumplir con los tiempos de desarrollo.

• Negociación con el cliente de extensiones al tiempo o presupuesto del proyecto.

• Rastreo de los requerimientos a sus correspondientes diseños, códigos fuente y casos de

prueba.
5
 • Mantenimiento de los requerimientos y de sus cambios dentro de todas las fases de
desarrollo.

2. Producción del plan de los requerimientos y del documento de especificación de

requerimientos. El plan de requerimientos describe las actividades que se llevarán a cabo
para obtener los requerimientos, mientras que el documento de requerimientos (DER)
contiene la especificación del sistema de acuerdo con los requerimientos del cliente.

3. Control de cambios y mantenimiento de los requerimientos. Los cambios en los

requerimientos es una actividad que se presenta frecuentemente en cualquier proyecto de
desarrollo de software. Es necesario llevar a cabo un historial de todos los cambios hechos a
los requerimientos a fin de verificar su impacto en las demás etapas del desarrollo de
software.

Una vez que los requerimientos son completamente especificados, otros procesos del desarrollo
deben llevarse a cabo: diseño, implementación, pruebas y mantenimiento.

2.1.1 El Modelo de Espiral del Proceso de Ingeniería de Requerimientos

Otra manera de llevar a cabo el proceso de Ingeniería de Requerimientos es mediante el
paradigma de espiral (referencia), en donde las actividades se repiten hasta obtener un documento
de requerimientos aceptable, como se muestra en la Figura 2.2. Siempre que existan problemas en
una versión previa del documento de requerimientos (borrador), se regresa a las etapas anteriores
del espiral. El proceso finaliza cuando se produce un documento aceptable (el cual cumple con
los requerimientos de calidad de la organización). Así mismo, el proceso puede terminar por
factores externos como la presión del cliente ó la falta de recursos. Después de que el documento
es producido satisfactoriamente, cualquier cambio futuro en los requerimientos será parte de la
administración de los requerimientos.

Los modelos descritos en las figuras 2.1 y 2.2 son adecuados para lograr el Documento de
Especificación de los Requerimientos del sistema. Los dos modelos poseen cuatro actividades
enlazadas que permiten avanzar o retroceder en el proceso en cualquier momento del desarrollo.
Esto permite lograr un documento de requerimientos completo y consistente.

6
 Figura 2.2. El modelo espiral del proceso de Ingeniería de Requerimientos.

2.1.2 Entradas y salidas al proceso de Ingeniería de Requerimientos

Después de haber definido el proceso de Ingeniería de Requerimientos y con el fin de que el
proceso realice sus funciones en forma adecuada, es necesario definir con precisión sus entradas
y salidas. Distintos autores han sugerido varias entradas y salidas al proceso, sin embargo solo
mencionaremos las propuestas por Sommerville (referencia).

Las entradas propuestas son las siguientes:

1. Documentos del proyecto. Los documentos del proyecto que proporcionaran información
importante al proceso de la Ingeniería de Requerimientos son el documento de administración
del proyecto y el documento de factibilidad. El documento de administración del proyecto
incluye las actividades de todo el proyecto, el personal asignado y los tiempos de cada
actividad. El documento de factibilidad ayuda a entender la capacidad técnica y
organizacional con que cuentan los desarrolladores para llevar a cabo el proyecto e identifica
si es capaz de llevarlo a cabo dentro de los tiempos y costos estimados.

2. Información existente del sistema. Describe la información sobre el medio ambiente y el

dominio en el que operará el sistema así como la funcionalidad requerida. No es posible

7
 desarrollar el sistema si no se conoce el ambiente sobre el cual operará y cuales son los
usuarios del futuro sistema.

3. Necesidades de los clientes y usuarios. Define que el lo que el cliente y los usuario
requieren del sistema para poder llevar a cabo su labor.

4. Estándares organizacionales. Son estándares utilizados por la organización respecto a la

práctica de desarrollo de sistemas y administración de la calidad.

5. Regulaciones. Se refiere a regulaciones externas que afectarán al sistema en cuanto a su

seguridad, confiabilidad, y otros factores que pudieran afectar a la salud con la operación del
sistema.

Por otro lado las salidas del proceso son las siguientes.

1. Requerimientos. Es una descripción de los requerimientos que fueron obtenidos y analizados

por el cliente y el analista de requerimientos.

2. Especificación del sistema. Es un documento detallado en el cual se especificara la

funcionalidad del sistema y sus restricciones.

3. Modelos del Sistema. Son una serie de modelos gráficos que pueden consistir en diagramas
de flujo de datos, diagramas de entidad-relación, diagramas de objetos, entre otros, que
permiten describir la funcionalidad del sistema. Estos modelos pueden estar contenidos en los
documentos DDR o DER.

4. Prototipo. Es una versión del sistema de software, el cual no incluye toda su funcionalidad.
En muchas ocasiones un prototipo permite descubrir, modificar o validar algunos de los
requerimientos del sistema.

Como puede observarse la salida más importante del proceso es el documento de especificación.
Este documento es conocido también como Documento de Especificación de Requerimientos de
Software (DER).

8
2.2 ¿Que son los requerimientos y por que son tan importantes?
Un requerimiento de software permite definir las funciones, capacidades o atributos de cualquier
sistema de software. También, los requerimientos pueden representar factores de calidad del
sistema que permitirán evaluar su utilidad a un cliente o usuario. Los requerimientos son los
datos de entrada al proceso de desarrollo de software y representan lo que se requiere
implementar. Los requerimientos también representan una descripción de cómo el sistema deberá
comportarse, describe información del dominio de la aplicación, describe restricciones de la
operación del sistema y especifica atributos ó propiedades del sistema.

En la definición de los requerimientos no se deben incluir aspectos de diseño, que especifiquen

como deben implementarse tales requerimientos, ni detalles de planeación del proyecto o de las
pruebas. Es importante separar lo que se requiere (que se detalla con los requerimientos) de
como se requiere que el sistema sea diseñado (que se detalla en la etapa del diseño). Sin embargo,
el que hacer y el como hacerlo, en ocasiones se especifica de la misma forma. Esta confusión,
proviene generalmente de los analistas de requerimientos, quienes por lo general, piensan antes
en como hacer el sistema, antes de lo que debe hacer el sistema. Los clientes/usuarios por lo
general saben que debe hacer el sistema, pero no siempre saben como debe construirse ni las
consecuencias (económicas o técnicas) de la implementación de tales requerimientos.

De cualquier forma, los requerimientos definen un problema por resolver. Este problema puede
constituir el desarrollo de un sistema de software nuevo ó la mejora de un software actualmente
en operación. El desarrollo de un software nuevo demanda mayores retos en cuanto a su
especificación. Por otro lado, la especificación de un software existente que demanda mejoras
debería ser más fácil, ya que tanto los clientes como los desarrolladores cuentan con cierta
experiencia que les permite conocer los requerimientos por mejorar.

Es claro que todo software tiene requerimientos que lo definen y quizás la parte más difícil de la
construcción del software es la decisión de que es lo que se debe construir. Ninguna otra parte del
desarrollo del software es más difícil que la definición precisa de los requerimientos del software.
No hay otra parte del proceso de desarrollo que pudiera perjudicar más al software resultante que
los requerimientos, si estos no son definidos correctamente. Corregir los requerimientos es más
difícil que corregir cualquier otra parte del proceso de desarrollo.

Toda aplicación de software tiene usuarios los cuales confían en esta para mejorar su
productividad o para mejorar algún atributo de sus sistemas anteriores. El tiempo dedicado para
9
entender las necesidades del usuario debe verse como una inversión a largo plazo para el éxito
del proyecto. Si los desarrolladores no cuentan con un documento de requerimientos, con el que
los clientes estén completamente de acuerdo, entonces será difícil llevar a buen final el desarrollo
del software o proporcionar un adecuado mantenimiento. Aun cuando se trate de un software
comercial, no definido por ningún cliente, dicho documento debe estar correctamente definido, y
en consecuencia claramente entendible.

En ocasiones es difícil especificar completamente todos los requerimientos antes del diseño o de
su construcción. En ocasiones, el tipo de software a desarrollar o su medio ambiente de operación
no se conocen completamente desde el principio. En estos casos, existen procesos iterativos e
incrementales (como los descritos en los capítulos 1.3.2 y 1.3.3) que permiten especificar y
construir el software en etapas o mediante prototipos. Sin embargo, aunque en este caso sea más
difícil escribir el documento de requerimientos, éste nunca debe faltar.

La obtención de requerimientos es un proceso difícil debido a que el cliente puede pedir algo que
no es factible de llevar a la práctica. Así mismo, puede ocurrir que los desarrolladores entiendan
distintas cosas de las que el cliente está requiriendo. Por estas razones el proceso de obtención de
requerimientos demanda especial atención.

Frecuentemente, existe una tendencia a comenzar el desarrollo de software sin haber dedicado
suficiente tiempo a comprender, analizar, administrar y documentar los requerimientos de una
forma adecuada. Muchos desarrolladores y clientes tienden a creer que el éxito del proyecto
depende de que tan rápido se comience a codificar. Sin embargo, de acuerdo a la experiencia
industrial, la mayoría de los proyectos que fracasan llevan a cabo una pobre recolección y análisis
de requerimientos.

Los requerimientos son inicialmente especificados por el cliente o usuario del sistema. El
analista de requerimientos (el cual forma parte del equipo de desarrollo) recolecta los
requerimientos y los transforma, de la especificación del cliente (requerimientos establecidos) a
su implementación real (requerimientos reales). Los requerimientos establecidos deben escribirse
en el documento DDR, mientras que los requerimientos reales deben estar en el documento DER.

Existe una diferencia significativa entre los requerimientos establecidos y los reales. Los
requerimientos establecidos son aquellos que el cliente provee, sin ningún cambio por parte de
los desarrolladores. Estos requerimientos pueden ser el resultado de una propuesta de desarrollo o
de entrevistas con el cliente. Este tipo de requerimientos se documentan mediante anotaciones en

10
lenguaje natural a veces acompañadas de dibujos o diagramas que describen al sistema tal y como
el cliente lo requiere. Los requerimientos reales, son aquellos que resultan del análisis exhaustivo
de lo que el cliente requiere. No solo incluye anotaciones de lo que el cliente requiere sino que
además es el resultado de un análisis que permite evaluar la factibilidad, la completitud y la
eficiencia de los requerimientos. Los requerimientos a menudo pueden ser confusos o vagos,
contradictorios entre si ó poco realistas. Los requerimientos reales tienden a evitar tener estas
características.

El documento de requerimientos, mostrado en la Figura 2.3, está dirigido a los usuarios y clientes
quienes verifican que realmente estén definidos todos los servicios y restricciones. Así mismo, el
documento de especificación de requerimiento sirve al equipo de desarrolladores como una base
para las siguientes fases del proceso de desarrollo, es decir, para iniciar el diseño y la
implementación del sistema.

Algunos de los requisitos que debe satisfacer un documento de requerimientos de software son
los siguientes:

1. Especificará únicamente el comportamiento externo del sistema. La parte interna será

detallada en el Diseño.

Figura 2.3. El DER está orientado a clientes, usuarios y desarrolladores.

11
2. Especificará las restricciones de la implementación.

3. Será fácil de cambiar.

4. Servirá como herramienta de referencia para los mantenedores del sistema.

5. Describirá las respuestas para los eventos no deseados.

La identificación de los requerimientos reales demanda de un proceso interactivo e iterativo,

soportado por prácticas eficientes, por procesos claramente definidos y por herramientas que
permitan definir, analizar y administrar los requerimientos eficientemente. Es un proceso
interactivo, en el cual los clientes/usuarios deben estar en constante comunicación con los
desarrolladores (en este caso, con los analistas de requerimientos). A partir de esta constante
comunicación, es como los requerimientos pueden aclararse y evitar ser confusos o vagos. Sin
una adecuada comunicación, no es posible hacer una buena identificación de los requerimientos
reales del sistema. Además, es un proceso iterativo, debido a que, solo mediante varias
iteraciones será posible mejorar la funcionalidad requerida del sistema e identificar a los
requerimientos reales.

Existen un gran número de consecuencias que se presentan cuando los requerimientos son
incorrectos o incompletos.

1. El sistema podría terminarse tarde o los costos podrían excederse más de lo esperado.

2. El cliente y los usuarios finales no estarán satisfechos con el sistema final. Podrían usar solo
parte de la funcionalidad del sistema o decidirse a abandonar el sistema al poco tiempo
después de empezar a utilizarlo.

3. El sistema podría no ser confiable, con errores frecuentes y caídas que podrían interrumpir la
operación normal del sistema.

4. Si el sistema continúa en uso, los costos de mantenimiento podrían ser muy altos.

5. El sistema en ejecución podría resultar difícil de operar.

6. El sistema podría no tener la calidad o la funcionalidad requerida por el usuario.

El costo de reparar omisiones o errores en la etapa de requerimientos, suele ser mucho menor que
la reparación de errores en etapas posteriores del desarrollo. Consecuentemente, el costo de no
reparar los errores durante la etapa de requerimientos es muy alto.

12
2.3 El Rol del Analista de Requerimientos
Todo proyecto de software necesita un analista de requerimientos, ya que este estará a cargo de
todas las actividades del proceso de Ingeniería de Requerimientos.

El analista de requerimientos tiene un rol central en la recolección y diseminación de información

del sistema o producto a desarrollar. El analista sirve de interfase entre el cliente y los usuarios de
la organización y con los diseñadores y el director del proyecto. La Figura 2.4 describe la
relación que existe entre el analista y los grupos de clientes/usuarios y desarrolladores.

En general, el analista de requerimientos es quien mas interactúa con el cliente. Su propósito es

recabar toda la información posible del cliente a fin de especificar sus requerimientos y permitir
realizar eficientemente las actividades de las demás etapas del desarrollo. El analista juega un rol
central en la recolección y diseminación de información del sistema de software a desarrollar,
mientras que el administrador o jefe del proyecto coordina todas las actividades del proyecto. Por
lo tanto, el analista debe transmitir la información del cliente y de su organización de la forma
más precisa y correcta posible al jefe del proyecto para que esta se envíe a la etapa del diseño.

Patrocinador del Proyecto Administrador del Proyecto

requerimientos Factibilidad,
del negocio Tiempos y costos

requerimientos
requerimientos funcionales
del cliente/usuario
y no-funcionales

Cliente y Desarrolladores
Usuarios

Analista de Requerimientos
restricciones y requerimientos funcionales
requerimientos y no-funcionales

Otros interesados Pruebas

en el sistema

Figura 2.4. Analista de Requerimientos.

13
Además de llevar a cabo todas las actividades incluidas en el proceso de Ingeniería de
Requerimientos el analista debe realizar las siguientes actividades:

1. Definir los objetivos del proyecto y los beneficios al negocio. El trabajo del analista
comienza cuando este ayuda al cliente a definir para que se quiere llevar a cabo el proyecto y
cuales serán los beneficios que traerá el desarrollo del sistema de software. En esta actividad
deben definirse las oportunidades de negocio y los beneficios que traerá el sistema de
software al implementarse. Así mismo, en esta actividad se definirá el contexto, medio
ambiente de operación del sistema, las necesidades actuales del cliente y del mercado, y los
riesgos del negocio. Algunas de estas actividades obtienen su información del documento de
factibilidad. Como resultado del anterior análisis, en esta actividad se planteará una propuesta
general de la solución que se propone para el nuevo producto, la cual ayudará a cumplir con
los objetivos.

2. Identificar el problema a resolver y obtener los requerimientos. Una vez definidos los
objetivos del proyecto, es necesario que el analista junto con el cliente definan el problema
que se quiere resolver y de esta forma poder obtener los requerimientos.

3. Identificar a los involucrados en el desarrollo del proyecto así como a las clases de
clientes y usuarios. En esta actividad se identifican a las personas involucradas en el
proyecto, por parte del cliente y por parte del grupo de desarrollo. Así mismo se definen
responsabilidades y las actividades que realizarán.

4. Identificar el ambiente del dominio a desarrollar y estar preparado para desarrollar el

sistema requerido. Esta actividad del analista involucra estudiar el ambiente o dominio del
sistema a desarrollar. Para que esta actividad se pueda llevar a cabo es necesario estudiar el
medio ambiente y las características del la organización en donde operará el sistema. Por otro
lado, en esta actividad el analista y el jefe del proyecto verificarán que el equipo de desarrollo
está compuesto por personal capacitado para llevar a cabo el sistema requerido. En muchos
proyectos el personal aprende sus actividades cuando el sistema está en desarrollo y esto lleva
frecuentemente a retrasos en la entrega. Esto debe evitarse. Si no se cuenta con personal
suficiente y capacitado para llevar a cabo el desarrollo que se requiere es preferible no
participar en el proyecto. El analista debe conocer las nuevas tecnologías y asesorar al jefe del
proyecto sobre la capacitación del personal. La tecnología de software y de computación
evolucionan continuamente, y un grupo de desarrollo con conocimientos obsoletos no será

14
 capaz de proporcionar a los clientes con sistemas modernos y eficientes. Un sistema eficiente
es aquel que utiliza los recursos de forma eficiente, con el menor costo y en el menor tiempo
posible. Por otro lado, existen herramientas y metodologías de desarrollo de requerimientos
que el analista debe conocer para llevar a cabo su tarea eficientemente.

5. Administrar los requerimientos utilizando un proceso y un plan de requerimientos.

Todo proyecto de software requiere de un proceso que defina actividades a seguir. En este
caso, la administración de requerimientos permitirá al analista de requerimientos trazar una
planificación de actividades a realizar en esta fase del desarrollo del proyecto y seguirla de
acuerdo al proceso de requerimientos establecido. La administración le ayudará al analista a
definir cada una de las actividades a seguir en los requerimientos, los tiempos máximos
establecidos y las personas involucradas para cada actividad. Así mismo, la administración le
permitirá al analista llevar a cabo todas las actividades definidas en el plan de los
requerimientos (el cual define las actividades a llevar a cabo dentro del proceso de Ingeniería
de Requerimientos). La administración de requerimientos está involucrada en todo el ciclo de
desarrollo del software y ayuda a dar seguimiento a los requerimientos a lo largo de su
definición, implementación y prueba. Cada requerimiento funcional, se convierte en un
conjunto de funciones definidas en el diseño, por lo cual después de definir cada
requerimiento, es necesario darle seguimiento y rastrearlo dentro del diseño, pruebas y
producto terminado. El rastreo de los requerimientos hacia cada una de las funciones
definidas en el diseño, se lleva a cabo por el analista con la ayuda de los diseñadores,
programadores y probadores. La forma de regresar de un diseño o de una implementación
hacia la etapa de los requerimientos es mediante el rastreo de las funciones hacia sus
correspondientes requerimientos. Este rastreo permitirá realizar cambios debido a errores,
realizar mejoras o dar mantenimiento al sistema de software. Los requerimientos no-
funcionales son mas difíciles de rastrear que los funcionales ya que no implican a una función
especifica o a una parte de la arquitectura del diseño. En muchos casos el rastreo de los
requerimientos no-funcionales puede llevarse a cabo hasta que el producto es terminado. Los
requerimientos no-funcionales son aquellos que imponen restricciones sobre el producto a
desarrollar o sobre el proceso, y especifican restricciones externas que el software debe
cumplir. Algunos de estos requerimientos no-funcionales incluyen, seguridad, usabilidad,
confiabilidad o desempeño. Cada uno de estos requerimientos no están definidos como una
función explicita, algunos dependen de las técnicas de diseño empleadas y otros dependen de

15
 la programación. Por ejemplo, para hacer que un sistema sea rápido, no deben utilizarse
técnicas de programación o sistemas operativos que incluyan un alto overhead. La usabilidad
depende de la habilidad de los diseñadores de plantear una arquitectura del sistema que lleve
a una implementación que los usuarios puedan entender y que su uso sea fácil. El desempeño
tampoco es una función explicita, y su implementación implica que los diseñadores y los
programadores sean capaces de utilizar de la forma mas eficiente posible los recursos
computacionales disponibles. La seguridad puede ser una parte del sistema e incluir distintas
funciones. Por ejemplo, si se trata de un sistema basado en Web (referencia), el cual se quiere
proteger contra intrusos externos, la seguridad podría incluir un “firewall”(referencia), el cual
consiste de un conjunto de funciones que evitan que usuarios externos entren al sistema y lo
accedan sin autorización.

6. Modelar los requerimientos. El analista debe determinar los casos en los cuales es necesario
representar los requerimientos de forma grafica o mediante métodos visuales distintos a texto.
En estos casos se podrían incluir, por ejemplo, distintos tipos de gráficos para representar
arquitecturas, diagramas de flujos de información, diagramas de transición de estados,
diagramas de clases, diagramas de entidad-relación, diagramas de comportamiento, tablas, o
interfaces hombre-maquina.

7. Realizar control de cambios en los requerimientos. Esta actividad forma parte de la

administración de requerimientos, y permite a los clientes y desarrolladores administrar los
requerimientos actuales y los anteriores a fin de que el proyecto pueda estar bajo control. Los
clientes tienden a hacer frecuentes cambios en los requerimientos por lo que una eficiente
comunicación permitirá descubrir los efectos que producirán estos cambios y anticiparse a
futuros errores. En esta actividad, el analista debe explicar la importancia y consecuencias de
los cambios en los requerimientos a los clientes, usuarios y desarrolladores. Es importante
reservar suficiente tiempo y presupuesto para los cambios en el software. Los cambios en el
software cuestan tiempo y dinero, y esto es algo que los clientes no siempre están dispuestos a
pagar. Debido a que en cualquier proyecto de software existirán siempre cambios frecuentes a
los requerimientos, es importante tener siempre control sobre estos cambios. Los cambios en
los requerimientos pueden deberse varios factores. Pueden deberse a mejoras o cambios
requeridos en la funcionalidad o a la necesidad de requerimientos nuevos. Algunas veces
también, los requerimientos no se definen desde un principio por que estos no se comprenden.
Esto ocurre especialmente, en dominios de aplicación no conocidos por los desarrolladores.
16
 En este caso, los requerimientos son definidos conforme avanza el proyecto y a medida que
los desarrolladores conocen el dominio de la aplicación por desarrollar. De acuerdo a la
experiencia industrial, se conoce que un 20% de cambios en los requerimientos lleva a
duplicar el costo del desarrollo (referencia). Por esta razón es importante que existan en el
proyecto acciones que permitan controlar los cambios en los requerimientos, antes que estos
produzcan excesos en costos y tiempos de desarrollo.

Adicionalmente, un analista eficiente debe combinar habilidades de comunicación con un amplio

conocimiento del dominio de la aplicación. De esta forma, el analista de requerimientos debe
poseer las siguientes habilidades para tener éxito en sus labores.

1. Capacidad de comunicación. Un analista deberá ser capaz de escuchar y comunicarse con el

cliente y con los desarrolladores. Será capaz de negociar los requerimientos y su evolución y
de trasmitir correctamente las necesidades del usuario. Deberá ser capaz de conducir
entrevistas y realizar cuestionarios entre los clientes y los usuarios.

2. Capacidad de análisis y observación. El analista debe ser capaz de evaluar críticamente la

información recolectada de múltiples fuentes, y reconciliar conflictos y prioridades que surjan
entre los requerimientos. Debe ser capaz de distinguir entre los requerimientos funcionales y
los no-funcionales (características específicas del sistema). Así mismo debe ser capaz de
distinguir entre lo que el cliente desea de lo que realmente requiere, o de los que es factible de
implementar. Debe ser capaz de observar el rendimiento de los desarrolladores y de los
usuarios quienes finalmente operarán el software. A partir de su capacidad de análisis y
observación el analista podrá documentar los requerimientos del usuario.

3. Capacidad de organización. El analista debe ser capaz de organizar todas las actividades
que surjan alrededor de su ambiente. Así mismo debe ser capaz de coordinar al personal con
quien debe interactuar de forma tal que su labor sea eficiente. El proceso de Ingeniería de
requerimientos puede continuar durante todo el desarrollo del proyecto, ya que los
requerimientos pueden cambiar o evolucionar, y también nuevos requerimientos pueden
surgir con el desarrollo del sistema. Por estas razones, el analista no terminará su labor al
terminarse esta etapa, sino que continuará realizando su labor hasta que el sistema sea
finalmente puesto en operación.

4. Analizar los riesgos del desarrollo del software. Los riesgos son eventos que llevan a que el
proyecto falle, se retrase o introduzca problemas en el desarrollo. En muchas ocasiones los

17
 proyectos de software parten de requerimientos en los cuales se desconoce la forma en que
estos serán implementados. Es necesario que el analista sea capaz de recolectar y analizar los
requerimientos. Así mismo, debe ser capaz de anticipar la forma en como estos
requerimientos deben ser implementados. Algunos requerimientos llevan a implementaciones
poco factibles, con grandes tiempos de implementación o muy costosos de llevar a la practica.
Cada requerimiento implica un riesgo cuando este se lleva a la implementación, por lo cual el
analista debe analizar cuales requerimientos son factibles, cuales no son factibles y los
correspondientes costos y tiempos de su implementación. El manejo de riesgos se discutió
con detalle en el capitulo anterior.

2.4 Los roles del cliente y del usuario

El éxito en el desarrollo del software esta ligado a los beneficios que obtengan los clientes y los
desarrolladores. A menudo la relación desarrollador-cliente tiende a ser tensa, problemática, de
poca comunicación o de adversarios y parte de estos problemas surgen debido a que no se
entiende claramente lo que son los requerimientos y las responsabilidades de clientes y
desarrolladores.

El cliente es cualquier persona que requiere ó que de alguna forma se beneficia de un producto de
software. Esta persona puede ser aquella que ordena la construcción del proyecto, quien lo
selecciona ó lo especifica, quien utiliza el producto de software ó también aquellos que de alguna
forma reciben los beneficios del producto de software. Los clientes proveen la idea y financian el
proyecto de software además de proveer el concepto del producto (sistema) de software que se
requiere y justifican su adquisición. Esta justificación debe estar descrita en términos del valor
que aportará el producto de software a los usuarios y a la organización que recibirá el producto de
software. El cliente es quien primero visualiza la necesidad de contratar el proyecto o el producto
de software de acuerdo a las necesidades de la organización, y también quien planea su posible
implantación dentro del negocio y los costos que ello implica. De esta forma el cliente, con la
ayuda del jefe del proyecto y del analista, planean el posible costo y el tiempo en que demanda
sea desarrollado el proyecto (o producto) de software.

En ocasiones, el cliente y los desarrolladores definen en conjunto los objetivos del producto de
software. Si el usuario conoce poco sobre el ambiente de operación o las funciones del producto a
desarrollar, entonces el analista de requerimientos podrá ayudar al cliente en la definición del

18
producto. De cualquier forma, en la mayoría de los casos, será útil que los desarrolladores ayuden
al cliente en la definición del producto.

Hay una clara diferencia entre el cliente y el usuario, aunque en ocasiones son la misma persona.
El cliente es quien solicita el proyecto, pero el usuario es quien finalmente operará dicho
software, después de que este sea implementado. De esta forma, el usuario es parte del personal
que trabaja para el cliente.

Es claro que el cliente no debe solicitar un software que los usuarios no puedan operar, y aquí es
donde potencialmente pueden surgir varios conflictos en los requerimientos. Sin embargo, es
difícil saber si un usuario podrá o no operar un software que aun no ha sido construido. Estos
conflictos suelen resolverse involucrando al usuario en la etapa de requerimientos y durante las
demás etapas del desarrollo. Al usuario hay que tomarlo en cuenta ya que es necesario identificar
su nivel de habilidades y conocimientos en el uso del producto de software. Además, los usuarios
pueden describir las actividades que ellos realizan cotidianamente y la calidad y funcionalidad
que esperan del producto. De hecho, el analista de requerimientos debe obtener de los usuarios
parte de los requerimientos.

A menudo los clientes proveen las necesidades generales del proyecto, pero los detalles
específicos los proveen los Ingenieros de la organización. Estos deben de trabajar conjuntamente
con el analista de requerimientos para entender y describir al mayor detalle posible las
necesidades del proyecto.

Algunos de las responsabilidades que se esperan del cliente son las siguientes:

• Educar al analista de requerimientos acerca del negocio y sus objetivos.

• Ser claro y preciso acerca del problema que se quiere resolver.

• Colaborar con el analista en la definición de los requerimientos.

• Revisar los documentos de requerimientos y el avance del proyecto.

• Comunicar a los analistas sobre cambios en los requerimientos.

• Plantear costos y tiempos esperados de desarrollo y estar abierto a discutir cambios en los
costos y tiempos de entrega.

• Estar siempre dispuesto a reunirse con los desarrolladores para discutir distintos aspectos del
proyecto.

19
• Respetar los procesos que implementarán los desarrolladores para implementar el producto.

Los usuarios de sistema de software pueden clasificarse de acuerdo a los siguientes aspectos:

• La frecuencia con la que usan el sistema.

• Las funciones que usan del sistema y su frecuencia.

• La experiencia en el dominio de la aplicación y su experiencia con otros sistemas similares.

• El tipo de uso que le dan al sistema (operación, administración, mantenimiento, supervisión).

• Las tareas que desempeñan en soporte de los procesos de la organización.

• Sus privilegios de acceso o niveles de seguridad (tales como usuario invitado, administrador o
usuario de nivel interno).

• Tipo de usuarios necesarios para operar el sistema (persona, grupo de personas, robot, u otra
computadora).

La clasificación de usuarios del sistema ayuda a la obtención de requerimientos por que define a
detalle las características de los usuarios y de su actividad. Es importante distinguir a los usuarios
que utilizan el sistema con frecuencia para sus labores en la organización de aquellos que lo
utilizan esporádicamente. Esto no solo permitirá definir su rol en la organización sino también su
nivel de experiencia. Algunos usuarios por su inexperiencia, solo utilizan cierta funcionalidad del
sistema que les es de mayor utilizad ó la cual conocen mejor. Otra parte de la funcionalidad del
sistema no la utilizan, por que la desconocen ó por que no la encuentran útil. Obtener esta
información permite definir con mayor precisión los requerimientos y diseñar interfaces de
usuario más útiles y fáciles de usar.

Algunos usuarios del sistema no llegan a utilizarlo, sin embargo se ven indirectamente
influenciados por su operación. Este personal pueden ser los encargados de su mantenimiento,
los administradores del sistema o el personal de supervisión. Este personal es importante por que
permite verificar que las labores de los usuarios se lleven a cabo de forma eficiente y sin errores.
Algunos otros usuarios solo reciben los beneficios o los productos que entrega el sistema y
forman parte de la organización. Este tipo de personas pueden ser integradores o ingenieros de
producto que se encargan de usar y dar salida a los productos que produce el sistema de software.

Algunos usuarios pueden tener mayor nivel de autorización para el acceso a ciertas funciones o
niveles de operación del sistema de software. Por ejemplo, en un sistema de software de control

20
de tarjetas de crédito de un banco, deberán existir personas que cuenten un mayor nivel en la
organización o con mayor nivel de autorización para realizar operaciones de modificación de las
cuentas de las tarjetas de crédito.

Por otro lado, los usuarios no necesariamente tienen que ser personas. Algunos sistemas se
operan de forma automática, mediante otros sistemas de computo, mediante robots o de forma
híbrida computadora-humano. Muchos sistemas de software industriales operan en ambiente con
un alto nivel de ruido, contaminación o de calor, por lo cual se requiere de un sistema
automatizado para operar el sistema.

En general, en la Ingeniería de Requerimientos es importante identificar a todos los involucrados

en el proceso a fin de obtener y validar el proceso. El no llevar a cabo esta identificación, puede
llevar a diseñar el sistema sin contar con toda la información o sin contar con la valiosa opinión
de alguno de los actores que participan en el proceso

2.5 El Plan de los Requerimientos

El propósito del plan de los requerimientos es determinar y documentar las actividades a seguir
durante el proceso de Ingeniería de requerimientos, dentro del ciclo de vida del software. Este
plan debe elaborarse por el analista de requerimientos durante la fase inicial del proceso. En el
plan aquí propuesto las dos primeras actividades del plan son obligatorias. Después de que la
factibilidad del producto o proyecto es aprobada, las siguientes actividades pueden llevarse a
cabo. La siguiente es una lista de los actividades a considerar en este plan:

1. Resumen del contrato/proyecto. Este resumen contiene un la problemática que se quiere

resolver y como esta problemática se resolverá el proyecto de desarrollo del sistema de
software. Así mismo en este resumen se describirán los antecedentes que llevaron a la
decisión de construir el software.

2. Determinar la factibilidad, los recursos necesarios, los costos y los tiempos estimados del
proyecto. En esta actividad debe definirse un documento de factibilidad que permita verificar
si el proyecto es factible de construirse.

3. Definición de objetivos del proyecto, beneficios al negocio y contexto operativo. En esta

actividad debe definirse un documento que describa los antecedentes del proyecto,

21
 oportunidades de negocio que se abren con la construcción del sistema, las necesidades
actuales del cliente y del mercado, las propuestas iniciales de solución y el contexto del
medio ambiente operativo.

4. Definición de los riesgos del proyecto. Un riesgo es un factor que altera de forma negativa el
desarrollo del software, que afecta su calidad, su costo o su fecha de terminación. El
documento de riesgos presenta los riesgos asociados con el desarrollo del sistema del
software. El documento de riesgos es necesario dentro del ciclo de desarrollo debido a que
permite anticipar los problemas, prever soluciones y registrar la experiencia en este tipo de
situaciones. Este documento es continuación al documento de factibilidad y contempla los
riesgos de todas las actividades del proceso de desarrollo, no solo de los riesgos de la
actividad de los requerimientos. Estimar las perdidas potenciales en caso de ocurrencia de
cada riesgo, la probabilidad de ocurrencia, y la posible habilidad de poder control tales
riesgos.

5. Documentos DDR y DER. Estos documentos son el resultado de las actividades del proceso
de Ingeniería de requerimientos sobre el proyecto del sistema de software a desarrollar.

6. Métodos, técnicas y herramientas a utilizar. Para cada una de las fases del proceso existen
distintos métodos, técnicas y herramientas bien documentadas que permiten hacer el proceso
más eficiente. Es necesario especificar cuales de estas serán utilizadas para cada fase del
proceso. En los próximos capitulo, se detallaran algunos de los métodos, las técnicas y las
herramientas mas conocidas para este proceso. Es necesario que el grupo de desarrolladores
se familiarice con ellas y que se justifiquen las razones por las cuales estas fueron elegidas.

7. Documentos de soporte. Deben existir un conjunto de documentos que ayuden a dar soporte
al proceso. Existen 2 tipos de documentos que serán utilizados con más frecuencia durante el
proceso de Ingeniería de Requerimientos. El primer tipo son todos aquellos documentos que
describen a la organización sus objetivos, funciones y flujos de trabajo, asi como su ambiente
operativo y el personal de la organización. El segundo documento mas importante es el
documento de administración de proyecto de desarrollo del software. Este documento permite
documentar todas las actividades del proceso, su planificación de actividades, tiempos y
asignación de personal. Otros documentos de soporte importantes son:

• documentos de procesos, técnicas y herramientas de desarrollo.

• documentos de estándares y políticas organizacionales.

22
 • documentos de legislación, normas y estándares,

2.6 Análisis de Factibilidad

En esta actividad se realiza un estudio que permite decidir si el desarrollo de software es factible.
Como se muestra en la Figura 2.1, en cualquier sistema a desarrollar, el proceso de Ingeniería de
Requerimientos debe comenzar con este análisis. La factibilidad indica si el desarrollo de
software es factible desde el punto de vista económico, técnico y organizacional. La factibilidad
económica indica si el software será realizado en el tiempo indicado y con los recursos
económicos disponibles. La factibilidad técnica indica si el software será posible de desarrollar
con el personal disponible, para lo cual éste personal debe contar con los conocimientos técnicos
en el dominio de la aplicación que se requiere. Así mismo, permite decidir si se cuenta con el
hardware y software necesarios para desarrollar el software. La factibilidad organizacional es un
aspecto que permite evaluar si la organización se verá beneficiada con el desarrollo de este
software. Desde el punto de vista organizacional, el desarrollo de software debería permitir a una
organización aprender, mejorar sus procesos y obtener una ganancia económica con el desarrollo
del software.

La factibilidad afecta al cliente y a los desarrolladores. Por un lado, el cliente demanda un

sistema que resuelva sus problemas y que presente nuevas soluciones a su ambiente
organizacional. Y por otro lado, el desarrollador pretende obtener con el desarrollo aprendizaje y
experiencia, ganancias económicas y prestigio en la construcción de sistemas de software.

La entrada al estudio de factibilidad es un conjunto de requerimientos del negocio, una

descripción del sistema y describe la forma de como se pretende que el sistema apoye en los
procesos del negocio del cliente. Los resultados de este análisis consisten en un reporte que
presentará recomendaciones acerca de si el sistema debe llevarse a cabo o no y sus restricciones.

Tanto para el cliente como para el desarrollador pueden escribirse distintos reportes de
factibilidad (o podría también escribirse un solo reporte para ambos).

En general, el análisis de factibilidad debe responder a varias preguntas:

1. El sistema contribuirá a los objetivos de negocio de la organización del cliente y también del
desarrollador ?.

23
2. Podrá el sistema ser desarrollado con la tecnología actual, el personal disponible, y con las
restricciones de presupuesto y de tiempo de desarrollo impuestas ?.

3. Podrá el sistema ser integrado con otros sistemas actualmente en operación ?.

4. Podrá el sistema ser operado eficientemente por los usuarios de la organización del cliente ?

Cada una de estas preguntas debe estar resuelta antes de comenzar el desarrollo del proyecto de
software. En el estudio de factibilidad es necesario consultar distintas fuentes de información
para decidir si el sistema debe ser construido o no. Este personal puede ser, administradores de
los departamentos de la organización del cliente, Ingenieros de Cómputo que tengan
conocimientos con el sistema requerido, expertos en técnicas relacionadas al proyecto y usuarios
finales del sistema. Así mismo, es recomendable también consultar a los desarrolladores, quienes
finalmente son quienes mas poseen mayores conocimientos técnicos en el dominio de la
aplicación requerida. Podrían existir distintas organizaciones que podrían llevar a cabo el
desarrollo, y algunas de estas podrían desarrollarlo factiblemente y otras no. Por esta razón,
también es importante que la organización del cliente estudie la experiencia en el dominio de la
aplicación de distintas organizaciones de desarrolladores, para poder decidir cual de estas
organizaciones es capaz de llevar a cabo el sistema requerido.

Finalmente, el resultado de este reporte debe indicar si el software es factible de desarrollarse o

no lo es, y debe estar debidamente justificado. Un proyecto que no esta claramente justificado,
podría no ser de mucha utilidad para la organización del cliente.

2.7 Definición de objetivos del proyecto y beneficios al negocio.

Los objetivos del proyecto ayudan a todos los involucrados (clientes y desarrolladores) a
visualizar una dirección común. Los objetivos permiten describir de lo que se trata el sistema de
software por desarrollar y en lo que este puede evolucionar. El sistema de software solo se puede
llevar a cabo dentro de un proyecto. Mediante el proyecto será posible identificar y administrar
todas las actividades que permitan desarrollar el sistema de software.

Un proyecto de software fracasará si este no cuenta con objetivos claros, o si algunos de los
involucrados en el proyecto no están de acuerdo en algunos objetivos. Dicho de otra forma, todos
los involucrados deben de estar de acuerdo en todos los objetivos del proyecto. En algunos

24
proyectos no hay una comunicación abierta, permanente y efectiva, o algunos de estos se
encuentran en distintos lugares geográficos, lo cual lleva a que algunos pudieran no trabar en
equipo o no conocer todos los objetivos del proyecto. El trabajo en equipo es esencial en
proyectos grandes y complejos en donde se requiere de personal no solo especializado en
software, sino también en otras múltiples disciplinas.

Si los objetivos del proyecto no están claramente definidos esto llevará a definir requerimientos
incompletos, erróneos o con frecuentes cambios. Por otro lado, los beneficios al negocio
describen la forma en que el sistema de software mejorará a la organización del cliente y a la vez
beneficiará a los desarrolladores.

La Tabla 2.1 describe la plantilla para el documento de objetivos del proyecto y beneficios al
negocio.

1. Objetivos del Negocio

1.1. Antecedentes

1.2. Oportunidades de Negocio

1.3. Criterios de Éxito

1.4. Necesidades del cliente y del mercado

2. Propuestas de solución.

2.1. Características principales del sistema.

2.2. Suposiciones y dependencias.

3. Alcance y limitaciones

4. Contexto del Negocio

4.1. Perfil de los participantes en el proyecto.

4.2. Ambiente Operativo.

Tabla 2.1. Plantilla para el documento de objetivos del proyecto y beneficios al negocio.

25
2.7.1 Objetivos del Negocio
Los proyectos comienzan cuando existe la idea de que el nuevo sistema mejorará de alguna forma
la operación o las ganancias de la organización. Los objetivos describen principalmente los
beneficios que el nuevo sistema traerá a los clientes y a los desarrolladores.

Los objetivos del negocio pueden describirse mediante los siguientes factores:
Antecedentes. Los antecedentes permiten describir las razones y el contexto en que fue
concebido el nuevo producto. Provee una descripción general de los motivos que llevaron a la
decisión de construir el sistema de software

Oportunidades de Negocio. Describe las oportunidades que existen en el mercado en el cual el

sistema de software estará compitiendo. Si se trata de un sistema de software para una empresa,
describe el problema del negocio que el sistema estará resolviendo o las mejoras que traerá a la
organización receptora, así como el ambiente en el que el sistema estará operando. Incluye una
evaluación comparativa de otros sistemas y soluciones potenciales existentes indicando las
ventajas del producto contra las demás soluciones. Permite describir también los problemas que
actualmente no pueden resolverse sin el sistema de software. Muestra como ayuda a competir con
las tendencias del mercado, con la evolución de la tecnología o las estrategias de la organización
receptora. Incluye además, otras tecnologías, procesos o recursos requeridos que permiten
proporcionar una solución completa.

Criterios de Éxito. Proporcionar los beneficios que el sistema traerá al negocio mediante
criterios cuantitativos y cualitativos. La Tabla 2.2 presenta algunos ejemplos de objetivos del
negocio, financieros y no-financieros. Determinar la forma en que los clientes y desarrolladores
medirán el éxito en este proyecto. Describir los factores que tendrán el mayor impacto para
conseguir el éxito del proyecto, incluyendo factores que estén dentro y fuera del control de la
organización. Especificar criterios de medición del éxito.

Necesidades del cliente y del mercado. Describe las necesidades de clientes típicos de mercado
que se quiere abarcar, con el sistema a desarrollar, incluyendo las necesidades que actuales no se
satisfacen con los sistemas o tecnologías actuales. Presenta los problemas que actualmente
enfrentan los usuarios del sistema a actual, y que no se presentaran con el sistema a desarrollar.
Define a un alto nivel, los requerimientos no-funcionales más importantes con que debe contar el
nuevo sistema, sin incluir detalles de diseño o implementación.

26
Financieros No Financieros

• Capturar una porción del X% del • Conseguir un índice de satisfacción del

mercado en los primeros Y meses.
• Llegar a un volumen de venta de X%
mayor al actual.
• Conseguir una ganancia neta del X% en
los primeros Y meses.
• Reducir costos de operación en X% con
respecto al sistema anterior.
cliente de al menos X después de Y meses de
instalación del sistema
• Incrementar la productividad del sistema en
X% y reducir los errores de captura de datos
en Y%.
• Desarrollar tecnología de punta que permita
conseguir estándares ISO.
• Ayudar a la organización a estar entre las 3
más competitivas del mercado.

Tabla 2.2. Ejemplos de objetivos financieros y no-financieros

2.7.2 Propuestas de solución.

Esta sección describe la visión estratégica que deberá seguirse para conseguir los objetivos
planteados. Esta visión provee el contexto para la toma de decisiones durante el desarrollo y la
vida del sistema a desarrollar. No debe contener requerimientos funcionales detallados o
información de administración del proyecto.

La propuesta de solución debe presentarse formalmente en un documento que incluya los

propósitos a largo plazo del sistema de software a desarrollar. Debe reflejar las visiones de todos
los participantes en el proyecto sobre las necesidades a solucionar.

La propuesta de solución debe identificar:

Cliente de destino. Identifica el cliente o la organización en donde se implantará el sistema.

Oportunidad de negocio o necesidad de la organización. Describe la necesidad actual de la

organización en donde se requiere el sistema.

Nombre del sistema o producto. Identifica el nombre del producto como se quiere dar a conocer
en el mercado.

27
Categoría del producto. Clasifica el producto de acuerdo al tipo de sistema de software. Por
ejemplo, sistema de información, sistema de manejo de bases de datos gerencial, sistema de
ventas de productos en Web.

Beneficio principal, razones para comprar el sistema o usarlo. Identifica los beneficios que el
sistema traerá a la organización y permite justificar su compra.

Sistema o procesos actuales, y otras alternativas competitivas. Identifica el sistema o los que
actualmente esta utilizando la organización describiendo las desventajas o problemas que se
tienen en su utilización.

Ventajas del desarrollo del nuevo sistema o producto. Describe las ventajas que traerá a la
organización el nuevo sistema de software.

Características principales del sistema. Describe las características principales del sistema, y si
es necesario las ordena por prioridad. Identifica cuales de estas características distinguen al
sistema del sistema actual, o de otros productos similares en el mercado. Cada una de estas
características podría convertirse en requerimientos funcionales, no-funcionales, o elementos del
sistema.

Suposiciones y dependencias. Describe las suposiciones que realizan los clientes-usuarios y los
desarrolladores al plantear los objetivos del proyecto. Con frecuencia las suposiciones que hacen
los clientes no son compartidas con los usuarios o con los desarrolladores, y viceversa. Si estas
suposiciones se plantear por escrito y son revisadas por cada integrante del proyecto, se pueden
discutir a fin de que todos estén de acuerdo en cada suposición y así presentar una visión común.
Las dependencias del proyecto describen todos los factores ligados al proyecto que están fuera de
su control. Estas podrían incluir, partes del proyecto que deben sub-contratarse, normas o
estándares a cumplir, regulaciones gubernamentales, y regulaciones o normas de la propia
empresa. Por otro lado, usualmente el sistema a implementar, estará operando dentro de una
empresa y formando parte de su sistema general de ventas, operación o administración, por lo
cual interactuará y dependerá de alguna forma de los sistemas o procesos de la organización,
cuando este se encuentre operando.

28
2.7.3 Alcance y limitaciones
El alcance describe las capacidades que el sistema de software este tendrá y también las que no
tendrá. En ocasiones el cliente requiere algunas funciones del sistema que son muy costosas, que
requieren de mucho tiempo de desarrollo o que están fuera del alcance o del contexto del
proyecto. Los requerimientos que se encuentren fuera del alcance deben rechazarse a menos de
que sea posible ampliar el alcance del proyecto para incluir estos requerimientos, con los
correspondientes cambios en presupuesto, administración del proyecto y personal. Es necesario
llevar un registro de los requerimientos rechazados y las razones de cada rechazo en caso de que
estos aparezcan de nuevo en el futuro. Las limitaciones definen los requerimientos que esta fuera
del alcance del proyecto y que no es posible implementarlos debido a situaciones de factibilidad.

En ocasiones el proyecto de software a desarrollar se planea llevarlo a cabo a lo largo de varios

años y mediante distintas versiones alcance del proyecto. La versión inicial define las primeras
funciones que se planea que se incluyan en el sistema y las subsecuentes versiones definen la
funcionalidad que se espera que se añadan después de concluir la primera versión. Se espera que
la primera versión proporcione la funcionalidad mínima que se espera del sistema y con la cual
sea posible que la organización opere eficientemente. Se pretende que las subsecuentes versiones
mejoren y añadan funcionalidad al sistema y también que permitan corregir o mejorar algunos
defectos encontrados en la primera versión. Cada una de las versiones deberá tener su propio
alcance y limitaciones.

2.7.4 Contexto del Negocio

Para poder trabajar en un proyecto de software es necesario conocer a todos sus participantes.
Cada participante en un proyecto de software cuenta con un rol y una responsabilidad que le
permite contribuir hacia el logro de los objetivos del proyecto. Si no se conoce a todos los
participantes del proyecto se crearan conflictos en el desarrollo del proyecto. Cada participante
contribuye en cierta parte del proyecto por lo cual la definición de sus responsabilidades permite
delimitar su área de especialidad, su participación dentro de su grupo de trabajo, y a que Jefe
debe responder sobre su trabajo. El ambiente operativo permite delimitar el medio ambiente
sobre el cual el sistema de software va a operar. Este ambiente incluye componentes de cómputo,
componentes eléctricos y mecánicos, sistemas externos, sistemas de información, y personal de
operación y mantenimiento.

29
Perfil de los participantes en el proyecto. Los participantes del proyecto son todos aquellos
individuos, grupos u organizaciones que participan activamente en el proyecto. El perfil de los
participantes describe y clasifica a los participantes de acuerdo al área en donde se encontraran
participando. Seleccionar personal para trabajar en el proyecto depende de la especialidad de
cada posible participante y de su experiencia. Es importante integrar a los participantes en áreas
del proyecto en las cuales tengan conocimientos y experiencia. Si algún participante se integra a
alguna área en la cual no tenga experiencia previa, deberá dedicarse tiempo a entrenarlo o
capacitarlo, lo cual podría extender el tiempo de desarrollo de esta parte del proyecto.

El perfil de cada participante en el proyecto deberá contener la siguiente información:

Desarrollador:

• Area de especialidad.

• Responsabilidades asignadas.

• Area del proyecto asignada.

• Habilidades y experiencia previa que le permiten contribuir significativamente a cumplir

con las responsabilidades asignadas.

Usuario u operador:

• Conocimientos sobre el sistema nuevo.

• Entrenamiento necesario para operar el sistema nuevo.

• Productividad actual.

Ambiente Operativo. Describe el ambiente en el cual el sistema estará operando y define

algunas características o requerimientos importantes del sistema como son: disponibilidad,
confiabilidad, desempeño, y usabilidad. Esta información contribuirá de forma importante en la
definición de la arquitectura del sistema, la cual es la primera parte del diseño. No se pretende
aquí definir completamente toda la arquitectura del sistema sino únicamente hacer un
planteamiento genérico que permita visualizar el contexto operativo del sistema. El contexto
permitirá identificar todas las partes que componen el sistema a desarrollar, al medio ambiente
externo que rodeara al sistema, y a las personas que estarán involucradas en su operación. Es
importante poner especial atención a la definición inicial de los requerimientos no-funcionales
definidos. En ocasiones es difícil conocer con precisión cada uno de estos requerimientos y saber

30
cuales son implicaciones de diseño. Además de que podría en ocasiones ser posible conocer el
logro de estos requerimientos solo hasta que el sistema, o una parte de este halla sido construido.
Para poder identificar el ambiente operativo, es necesario elaborar un diagrama de contexto del
sistema. El diagrama de contexto permite definir una arquitectura inicial del sistema, las
interconexiones entre sus componentes mas importantes y también permite establecer los limites
o fronteras del sistema. El diagrama de contexto es la abstracción de mas alto nivel que permite a
usuarios y desarrolladores ponerse de acuerdo sobre los componentes que integran al sistema, su
funcionalidad y restricciones. Ayuda a identificar algunos de los flujos de información mas
importantes y sus conexiones con el mundo exterior.

2.9 Tipos de Requerimientos

Los requerimientos de software son descripciones de los servicios y restricciones del sistema en
desarrollo. Existen diferentes maneras de clasificarlos, sin embargo, generalmente se agrupan de
acuerdo a la audiencia a quienes van dirigidos y a las características del sistema.

2.9.1 Tipos de Requerimientos de acuerdo a la audiencia

Existen diferentes niveles de descripción de requerimientos, que permiten orientar los
requerimientos a diversos usuarios. Es distinto explicar los alcances de un sistema nuevo a
clientes usuarios que no van a utilizar el sistema, pero que de alguna forma están involucrados en
el desarrollo del sistema, que explicárselos a los desarrolladores o arquitectos de software que se
encargarán de su implementación. Como se observa, se requiere de diferentes niveles de
descripción y tipos de descripción de requerimientos (referencia):

1. Los Requerimientos del Usuario. Son expresados en lenguaje natural utilizando diagramas
fáciles de comprender, y representan los servicios que se espera que el sistema provea y las
restricciones bajo las cuales el sistema debe funcionar. También son conocidos como
Requerimientos del Cliente.

2. Los Requerimientos del Sistema. En estos requerimientos se establecen con más detalle los
servicios y restricciones del sistema. También se les conoce como especificación funcional o
Requerimientos del Desarrollador.

31
3. Especificación del Diseño del software. Es una descripción abstracta del diseño del software
que se utiliza como una base para el diseño y la implementación.

Los distintos niveles de descripción de requerimientos son necesarios debido a que informan de
manera clara su contenido a diferentes tipos de usuarios. Por ejemplo, los requerimientos de
usuario, como están expresado en un lenguaje claro, fácil y sin detalles funcionales, están
dirigidos a clientes administradores, usuarios finales del sistema, clientes ingenieros, contratistas
administradores y arquitectos del sistema.

Por otro lado, los requerimientos del sistema son dirigidos para usuarios técnicos del sistema,
clientes ingenieros, arquitectos del sistema y desarrolladores de software. Debido a su
especificación funcional dentro del sistema, es necesario contar con un cierto grado de
conocimiento técnico ó especialización en el área. Y por último, la especificación del diseño de
software está dirigida a clientes ingenieros, arquitectos del sistema y desarrolladores de software.

2.9.2 Tipos de Requerimientos de acuerdo a su característica

Esta clasificación se realiza en función de la naturaleza de las características del sistema que se
desarrolla. Generalmente los requerimientos de sistemas de software se clasifican en funcionales
y no funcionales.

1. Requerimientos funcionales. Los requerimientos funcionales son declaraciones de los

servicios que proveerá el sistema y describen la interacción entre el sistema y su
ambiente, la reacción a entradas de datos y su comportamiento en condiciones específicas.
También declaran lo que el sistema no debe hacer.

2. Requerimientos no funcionales. Los requerimientos no funcionales, son las restricciones

de los servicios o funciones ofrecidas por el sistema, o restricciones sobre el sistema que
limitan la solución a un problema.

Los requerimientos no funcionales no se refieren directamente a las funciones específicas que

entrega el sistema, sino a sus propiedades emergentes. Existen muchas maneras de
clasificarlos. Sommerville [2] propone la clasificación descrita en la Figura 2.6.

• Requerimientos del producto, especifican el comportamiento del producto, por ejemplo

la rapidez de ejecución del sistema, espacio de memoria requerida, la fiabilidad ó tasa de
fallas para que el sistema sea aceptable, o su portabilidad y usabilidad.
32
• Requerimientos Organizacionales, se derivan de las políticas y procedimientos
existentes en la organización del cliente y desarrollador. Ejemplo de éstos son los
estándares que deben utilizarse en los procesos, en los lenguajes de programación, en la
implementación o métodos de diseño, y en los requerimientos que se especifican cuando
se entrega el producto y documentación.

• Requerimientos externos, se refieren a aquellos que se derivan de factores externos al

sistema y de su proceso de desarrollo. Por ejemplo, los requerimientos de
interoperabilidad que establecen la manera en que el sistema interactúa con otros sistemas
de la organización, requerimientos legales que aseguran que el sistema opere dentro de la
ley y los éticos que aseguran que el sistema será aceptado por el usuario y el público en
general.

Figura 2.6. Clasificación de requerimientos no funcionales.

33
2.9.3 Otros tipos de Requerimientos
Es muy difícil clasificar de los requerimientos, pero lo importante en todo proceso tal vez no sólo
sea la clasificación, sino también la obtención de todos los requerimientos del software a
desarrollar, así como su especificación y administración. Existen otras clasificaciones de los
requerimientos en la bibliografía de Ingeniería de Requerimientos y que permiten definir de
manera especifica las necesidades de los usuarios. Estos tipos de requerimiento son los siguientes
(referencias):

1. Requerimientos de dominio. Los requerimientos de dominio son requerimientos que

provienen del dominio de aplicación del sistema y reflejan las características de este dominio.

2. Requerimientos de Datos. Los requerimientos de datos definen las estructuras de datos

requeridas en el sistema.

3. Requerimiento de Interfaz. Definen las características y parámetros de la comunicación del

sistema a desarrollar con otros sistemas dentro de la empresa, o incluso de los subsistemas.

Los requerimientos evolucionan o tienden a cambiar de acuerdo a las necesidades del negocio o
el desarrollo del software puede llevar tiempo sobre todo si se trata de sistemas grandes. Desde
esta perspectiva los requerimientos se clasifican en:

1. Requerimientos duraderos. Estos tipos de requerimientos son relativamente estables debido

a que se derivan de la actividad principal de la organización y porque están relacionados
directamente con el dominio del sistema.

2. Requerimientos volátiles. Estos requerimientos sufrirán cambios probablemente durante el

desarrollo del sistema o después de que este se haya puesto en operación. Existe la siguiente
clasificación de los requerimientos volátiles:

• Requerimientos mutantes. Son requerimientos que cambian debido a los cambios del
ambiente en el que opera la organización.

• Requerimientos emergentes. Son requerimientos que surgen al incrementarse la

compresión del cliente en el desarrollo del sistema. El proceso de diseño puede producir
nuevos requerimientos emergentes.

34
 • Requerimientos consecutivos. Estos requerimientos, son el resultado de la introducción
del sistema. Esta introducción puede cambiar los procesos de la organización y abrir
nuevas formas de trabajar que generarán nuevos requerimientos.

• Requerimientos de compatibilidad. Son requerimientos que dependen de sistemas

particulares o procesos de negocios dentro de la organización.

3. Requerimientos negociables. Finalmente, pero no menos importante, esta la clasificación de

los requerimientos de acuerdo a su capacidad de negociación.

• Requerimientos negociables. Este tipo de requerimientos son aquellos los cuales son
sujetos a negociación con el cliente. En este tipo de requerimientos se pueden demandar
negociaciones para realizar cambios, mejoras, o pedir extensiones de tiempo de desarrollo
o presupuesto.

• Requerimientos no negociables. Este tipo de requerimientos es inflexible y no admite

cambios o mejoras. Se debe realizar tal y como fue definido.

2.10 Problemas asociados al proceso de Ingeniería de

Requerimientos
Los problemas que se encuentran mas frecuente en esta área pueden agruparse en las siguientes 3
categorías:

1. Problemas de alcance, en los cuales se describen el ámbito y los límites de operación del
software. En esta categoría algunos de los problemas podrían ser, que el ambiente del sistema
no esta bien delimitado, o que no exista información suficiente del flujo de información de la
organización.

2. Problemas de comprensión de lo que se quiere construir, con los clientes, usuarios y con los
grupos de desarrolladores. En esta categoría podrían aparecer distintos problemas:

• Los clientes y usuarios no entienden completamente todo lo que requieren o no cuentan

con toda la información que de soporte a sus necesidades.

• Los clientes y usuarios tienen poco conocimiento de las capacidades y limitaciones de los
sistemas de cómputo.
35
 • Los analistas de requerimientos tienen poco conocimiento del dominio de la aplicación.

• Los usuarios y los analistas hablan distintos lenguajes técnicos.

• Existen distintas perspectivas de cómo debe construirse el software, entre el cliente y los
desarrolladores.

3. Problemas de volatilidad debidos a los continuos cambios en los requerimientos. En esta

categoría se trata de resolver los problemas que existen cuando los requerimientos deben
cambiar razones tecnológicas, por errores, o por mejoras.

2.10.1 Problemas de alcance

En la Ingeniería de requerimientos, frecuentemente es difícil establecer el ámbito o los límites de
operación del software. Sin embargo siempre debe tenerse en cuenta que en los requerimientos
se describen distintas actividades a las del diseño. El diseño especifica la arquitectura del sistema
y las técnicas usadas en la construcción, sin embargo en los requerimientos no debemos
especificar la forma en como se desea construir el sistema, sino que se debe solo decidir que es lo
que se quiere construir. El no tener claro esta diferencia lleva a la construcción de requerimientos
conflictivos, ambiguos y poco verificables.

La obtención de requerimientos comienza con un análisis de la organización y del contexto de

operación que permita establecer los límites y objetivos del sistema a construir. Si no son
definidos claramente los límites y los objetivos del sistema, se corre el riesgo de producir
requerimientos incompletos, fuera de contexto, o potencialmente inútiles.

La obtención de requerimientos no debe considerar aspectos del diseño, ya que se deben

considerar las necesidades del cliente y no las necesidades de los desarrolladores. Sin embargo,
los clientes en ocasiones hacen peticiones muy ambiciosas o confusas, sin considerar las
implicaciones practicas. Por esta razón, es importante considerar la opinión de los desarrolladores
para verificar que las necesidades del cliente son factibles de implementar.

Existen al menos 3 contextos que afectan al proceso de Ingeniería de requerimientos para un

sistema propuesto.

1. Organización

2. Medio Ambiente

3. Proyecto.
36
En la obtención de requerimientos es necesario contar con una buen comprensión de la
organización para la cual se llevara a cabo la construcción del sistema, así como de los objetivos
que logrará el sistema para la organización. EL interés primordial de la organización no es el
sistema de software en si, sino los efectos positivos que se esperan con su introducción dentro del
medio ambiente de la organización. En muchas ocasiones, esto no se refleja en la práctica, ya que
muchos proyectos se concentran mas en el sistema a construir sin considerar los factores
organizacionales. Algunos de los factores organizacionales incluyen:

• Las personas que introducen entradas al sistema de software.

• Los usuarios o operadores del sistema de software

• Las formas en que el sistema cambiara los medios en los que la organización hace negocios.

Si durante la obtención de requerimientos no considera estos factores, se podrían producir los

siguientes problemas: malos entendidos entre el cliente, los usuarios del sistema y los
desarrolladores, resistencia de los usuarios a usar el sistema, desconfianza, o quizás ignorancia de
las capacidades del nuevo sistema.

Los factores medio ambientales también tienen una fuerte influencia en la obtención de
requerimientos. Algunos de los factores medio ambientales son los siguientes:

• Restricciones de hardware o software impuestas al sistema de software. El sistema a construir

podría ser un componente de un sistema mas grande ya existente dentro de la organización.

• La madurez del dominio del sistema a construir.

• El rol del sistema como componente de un sistema mas grande dentro de la organización.

Las restricciones del medio ambiente se derivan del hecho de que el sistema por construir es no
siempre un sistema único, sino que frecuentemente forma parte de un sistema global de la
organización. Al formar parte de un sistema mas grande, es necesario conocer todos los
componentes que forman parte del medio ambiente global. El sistema a construir debe ser
compatible con los sistemas existentes no solo desde el punto de vista arquitectural, sino también
de usabilidad. Los usuarios futuros del sistema deben sentirse cómodos con la nueva
funcionalidad o con las nuevas funciones introducidas por el nuevo sistema. Desde el punto de
vista arquitectural el sistema a construir debe ser compatible con el sistema actual, dado que
probablemente será un componente de este, para lo cual se requerirán de interfaces de conexión o
enlace. El tipo de arquitectura de hardware y software debe ser compatible con el sistema actual.
37
Así mismo, es posible que ambos compartan Bases de Datos, protocolos y líneas de
comunicación, sistemas operativos e incluso interfaces hombre-maquina.

El contexto del proyecto también afecta a la obtención de los requerimientos. Algunos de los
factores que afectan al proyecto son:

• Estilo en la administración del proyecto.

• Jerarquía de administración y desarrollo.

• Procesos de desarrollo a seguir.

• Experiencia en el dominio.

• Experiencia en desarrollos previos.

• Restricciones impuestas por el cliente y los usuarios: tiempos de desarrollo, costos, calidad
deseada.

La forma en como el proyecto de desarrollo es administrado puede afectar de forma positiva o

negativa al sistema por construir. Típicamente, existe un director o jefe de proyecto como cabeza
del grupo de desarrolladores. El director de proyecto es quien maneja o administra el desarrollo
del proyecto, y administra el personal y los recursos asignados. Debe coordinar las actividades
del personal involucrado en el proyecto y debe proveer una jerarquía organizacional para el
personal a cargo del desarrollo. Así mismo, el director del proyecto debe administrar los tiempos
y recursos del proyecto y verificar que estos se cumplan. Muchos proyectos nunca terminan en
tiempo y costo y muchos requerimientos tienen que ser continuamente re-negociados. Por esta
razón, es necesario que establezca una comunicación efectiva con el cliente a fin de negociar
extensiones o cambios en el proyecto. Sin esta comunicación, será difícil que un proyecto llegue
a terminar satisfactoriamente.

Por otro lado, el proceso de desarrollo a seguir es también responsabilidad del director del
proyecto, quien junto con el grupo de diseñadores debe decidir sobre el tipo de proceso que se
debe seguir. En ocasiones, podría ser necesario un proceso de desarrollo incremental, en el cual la
construcción sea mediante prototipos, o por el contrario, podría ser necesario un proceso simple
en cascada.

38
2.10.2 Problemas de entendimiento
En recientes estudios (referencia) se encontró que el 56% de los errores en sistemas en operación
se debían a que existió un comunicación muy pobre entre el cliente y el analista en la definición
de los requerimientos, y que este tipo de errores fueron los mas difíciles de corregir (utilizando
mas de 82% por ciento del tiempo del personal dedicado a corregir los errores). Los problemas
de entendimiento durante el proceso de obtención de requerimientos puede llevar a la definición
de requerimientos ambiguos, incompletos, inconsistentes o incluso incorrectos, debido a que no
resolvieron las necesidades reales de los clientes y de los usuarios.

Los problemas de entendimiento puede separarse en tres aspectos principales:

• Los grupos involucrados en la obtención de requerimientos (por parte del cliente y por parte
de los desarrolladores) tienen distinta preparación técnica, distintos estudios o distinto nivel
de experiencia, de forma que el conocimiento de un grupo puede ser distinto (mayor o menor)
que el de otro grupo. Esto hace difícil el análisis de los requerimientos, ya la información se
obtuvo de estas distintas fuentes de información.

• El lenguaje utilizado para expresar los requerimientos por los distintos grupos puede ser
demasiado formal o demasiado informal, como para que sea comprendido por todos y que
cumpla con las necesidades de cliente.

• La dificultad de organizar de forma coherente y comprensible la gran cantidad de información

obtenida durante el proceso de obtención de requerimientos.

En general, los requerimientos deben ser expresados de forma que:

• Promuevan la comunicación y entendimiento entre los clientes y los desarrolladores.

• Permitan al desarrollador determinar si lo requerimientos son factibles de implementar.

• Permitan verificar los requerimientos de calidad.

Los distintos grupos involucrados en la definición y desarrollo del software pueden estar
organizados de forma jerárquica. La organización del cliente puede tener su organización en
varios niveles, en donde cada grupo tenga distintas responsabilidades y funciones. Por otro lado,
los desarrolladores pueden provenir de una empresa de desarrollo con su propia estructura
jerárquica.

39
La información recolectada de los requerimientos puede provenir de distintos grupos de la
organización de cliente y por lo tanto puede tener distintos enfoques y puntos de vista. Esto puede
hacer difícil la obtención de los requerimientos.

Cada grupo de personas en la organización del cliente puede tener sus propias prioridades del
manejo del proyecto, sus propias opiniones sobre los objetivos y distintas responsabilidades en la
implementación del sistema. Por lo tanto, los requerimientos y el problema a resolver puede
provenir de muy distintas fuentes con distintos puestos y distintas responsabilidades, con lo cual
el sistema les puede afectar a su labor de muy distintas formas. Aun cuando la información del
problema a resolver provenga de personas con distintas opiniones, se debe hacer un esfuerzo de
entendimiento y comunicación entre todos los involucrados para definir el problema real a
solucionar, los detalles de los requerimientos y el impacto que tendrá su implementación. Los
desarrolladores del sistema de software y los analistas de requerimientos pueden tener un
conocimiento limitado del dominio de la aplicación, mientras que los clientes y usuarios pueden
no conocer mucho de los métodos de diseño necesarios para desarrollar el sistema. El cliente
puede no conocer lo que se necesita para resolver su problema, o puede no conocer las
dificultades de los desarrolladores para entender el problema o para implementar el sistema. Por
otro lado, los analistas de requerimientos o muchos de los desarrolladores pueden tener
dificultades para comprender el problema del cliente, sus metas y sus necesidades.

Muchos de los problemas antes descritos, pueden solucionarse poniendo especial atención al
logro de una comunicación fluida entre el cliente y los desarrolladores.

La obtención de requerimientos comienza con descripciones informales del problema ó del

sistema a desarrollar que a menudo involucran a personas con pocos conocimientos de sistemas
de software ó sistemas de cómputo en general. Por lo tanto, la obtención de requerimientos está
sujeta a problemas de verificación de información, debido a los malos entendidos entre los
clientes y los desarrolladores. Para evitar estos malentendidos, es necesario desarrollar distintos
tipos de documentos enfocados a distintos grupos. Todos estos documentos pueden estar
descritos en distintos lenguajes o a distinto nivel de especificación técnica, pero todos ellos deben
definir un objetivo común. Estos distintos documentos deben estar escritos principalmente en
lenguaje de texto, pero pueden incluir distintos diagramas, para definir flujo de información o
para representar el problema a resolver. En estos documentos debe haber un diccionario de
términos que permita a los clientes y desarrolladores contar con un lenguaje y términos comunes.

40
Dado que los requerimientos pueden provenir de distintos grupos de personas, la información
recolectada puede presentar problemas de redundancia, ambigüedad o información contradictoria,
o simplemente puede expresar la opinión muy particular de los distintos grupos.

Los requerimientos pueden presentar problemas de entendimiento debido a la complejidad el

sistema. Los requerimientos pueden ser malentendidos debido a su alta complejidad y a que
pocas personas comprenden el problema global.

Existen distintas herramientas y métodos para obtención de requerimientos, sin embargo estas
son muchas veces poco utilizadas debido a que son difíciles de usar o por que la información que
recolectan puede no ser muy útil. En los próximos capítulos describiremos algunos de estos
métodos y herramientas para obtener requerimientos. La mayoría de métodos y herramientas
permiten describir y recolectar requerimientos de manera informal y por lo pueden estar sujetos a
distintas interpretaciones. Por otro lado, los métodos formales de obtención y definición de
requerimientos frecuentemente son difíciles de comprender y poca gente es capaz de utilizarlos
en toda su capacidad.

2.10.3 Problemas de volatilidad

Los requerimientos tienden a cambiar por distintas razones. Durante el desarrollo del sistema los
requerimientos pueden madurar debido a mejores conocimientos sobre el sistema y sus objetivos,
o pueden cambiar debido a nuevas necesidades impuestas por el cliente o por la organización. Si
estos cambios no son realizados, el sistema estará incompleto y potencialmente se puede correr el
riesgo de que el sistema llegue a ser poco útil. Mientras exista entre el cliente y los
desarrolladores un buen entendimiento de las consecuencias de estos cambios, en tiempos de
desarrollo y costos no habrá problema. Sin embargo, los cambios excesivos, pueden llevar a:

• Realizar un desarrollo con tiempo de terminación muy largo.

• Provocar problemas con la documentación de sistema.

• Provocar problemas con el control de versiones del sistema.

• Provocar problemas de cambios de objetivos.

En muchos proyectos de desarrollo, los requerimientos son recolectados mientras el sistema esta
en desarrollo. En este caso, los sistemas que no son comprendidos en toda su extensión y en todas

41
sus funciones, tendrán que ser desarrollados de forma incremental. En esta forma de desarrollar
sistemas, los requerimientos del sistema se van añadiendo mientras se desarrolla el sistema.

Otra causa de la volatilidad en los requerimientos se debe a que los requerimientos fueron
obtenidos por distintos grupos de personas y cada grupo a menudo tiene distintos objetivos y
visualiza los requerimientos de distinta forma que los demás grupos. La fase de análisis, descrita
en los próximos capítulos, permitirá estudiar cada requerimiento a fin de darle consistencia,
prioridad, y coherencia.

Independientemente de la naturaleza de cada requerimiento se debe buscar que estos lleguen a ser
estables lo más pronto posible. Se deben buscar que todos los involucrados comprendan que cada
cambio es un factor de riesgo que necesariamente llevara a extender la terminación de proyecto, y
en el peor de los casos puede llevar aun sistema con tantos cambios que será imposible terminar,
o que terminara con múltiples defectos.

42