Documentos de Académico
Documentos de Profesional
Documentos de Cultura
En esta actividad se determina el dominio de la aplicación, se especifican los servicios que debe
proveer el sistema, la funcionalidad requerida del sistema, y las restricciones de hardware y
software. Es indispensable la participación de los usuarios y clientes para la identificación de los
requerimientos del sistema.
Como resultado de esta actividad se debe obtener un documento inicial de definición de los
requerimientos (DDR), en donde se definen las necesidades iniciales del sistema, o lo que se
conoce como requerimientos iniciales. Estos requerimientos pudieran no ser los definitivos, ni
tampoco todos los requerimientos. Nuevos requerimientos pueden ser agregados al documento
conforme se vayan descubriendo o incluso los requerimientos ya definidos pueden modificarse o
eliminarse.
3. Definir los límites y restricciones del sistema para determinar con precisión que es lo que el
sistema va a hacer y también especificar lo que no va a hacer.
4. Identificar a las personas o usuarios interesados en el sistema, ya que ellos conocen el
medio ambiente en que operará el sistema y pueden ayudar describiendo sus necesidades.
Los detalles específicos del problema del cliente deben ser bien comprendidos. La descripción
del problema proviene de cliente, sin embargo, en ocasiones el problema es difícil de
documentar. Este problema ocurre por las siguientes razones:
• El analista y los desarrolladores entienden el problema pero no saben como llevarlo a cabo.
Aunque el problema se comprenda, no será posible llevarlo a cabo si este no es factible. Por lo
tanto, después de comprender el problema y antes de comenzar el desarrollo, tanto el cliente
como los desarrolladores deben estar de acuerdo en su factibilidad. El problema de la factibilidad
se trata en el capítulo anterior.
71
operador de la tienda, cobrar e introducir datos sobre los productos vendidos. El objetivo de este
sistema de cómputo sería la automatización del proceso de venta de productos de la tienda
departamental.
• Ambiente operacional. Permite definir el ambiente sobre el cual el sistema estará operando y
todos sus componentes. Este medio ambiente podría ser, un sistema distribuido, un sistema en
red de área local, un sistema robotizado, un sistema de manufactura computarizado o una
aplicación de comercio electrónico.
• Sistemas de hardware. Estos sistemas comprenden, los sistemas de cómputo, las redes
utilizadas y sus protocolos, así como cualquier otros sistemas eléctricos y mecánicos.
• Sistemas de Software. Estos sistemas comprenden los sistemas operativos, bases de datos,
lenguajes, sistemas de manejo de archivos, software de aplicación, sistemas de seguridad,
entre otros.
• Interfaces Hombre-Maquina. Estos sistemas son aquellos con los que los usuarios tendrán
contacto directo para llevar a cabo sus labores.
• Conexiones externas. Estos sistemas son aquellos que provienen del exterior del sistema y
que reciben datos del sistema o a quienes el sistema envía datos.
• Capacidad del Sistema Actual. Este aspecto permite identificar cual es la capacidad de
procesamiento y de almacenamiento requeridos por el sistema.
Un gran número de sistemas no solo están compuestos por una computadora y un software
interno. Las industrias, las empresas bancarias, las empresas de telecomunicaciones o las
72
empresas de comercio electrónico, por mencionar solo algunas, tienen medios de operación muy
complejos que comprenden sistemas de cómputo, sistemas electro-mecánicos, robots, complejos
sistemas de tele-comunicaciones y sofisticadas interfaces de usuario. El desarrollo de sistemas de
software sobre éste tipo de ambientes, implica que especialistas de distintas disciplinas de la
Ingeniería se involucren en su especificación y diseño.
Podemos mencionar por ejemplo, el sistema de software que opera sobre los cajeros automáticos
de los bancos. Mediante este cajeros, es posible realizar diversas transacciones bancarias como
sacar dinero, hacer transferencias bancarias, consultar saldos o cambiar claves. Estos cajeros
contienen un sistema de cómputo el cual controla los dispositivos electro-mecánicos que
permiten almacenar y dar dinero a las personas con cuenta en el banco. Además, estos cajeros,
cuentan con sistema de comunicaciones, que les permiten enlazarse con los sistemas de cómputo
del banco. Cuando un cliente del banco introduce su tarjeta de crédito, para obtener dinero del
cajero, el sistema se comunica con el sistema de cómputo del banco para validar la tarjeta y para
obtener el estado de la cuenta del cliente.
Es necesario que los desarrolladores de este sistema cuenten con los conocimientos necesarios
sobre el dominio de la aplicación a desarrollar. Sin estos conocimientos el software sería difícil
de desarrollar o tendría fuertes implicaciones en el tiempo y costo de desarrollo. Esta parte debe
identificarse durante la fase de factibilidad, anteriormente descrita.
Las siguientes actividades ayudan a comprender las necesidades del cliente y los usuarios:
73
• Identificar las tareas o funciones que describen las necesidades del cliente (identificar los
casos de uso).
1. Antecedentes. En los antecedentes se resumen las razones y el contexto del nuevo producto.
Proveen una descripción general de la historia o la situación que llevó a la decisión de
construir el producto o sistema.
3. Visión del producto. Es una descripción general de lo que se persigue con la construcción
del software y de los beneficios que se esperan. Resume de forma cuantitativa y cualitativa
los beneficios que el producto o el sistema aportará a la organización. En este aspecto es
importante que los clientes, usuarios y los directores de proyecto definan la forma en como se
medirá el éxito o el fracaso del desarrollo y los factores que afectarán o que tendrán mayor
impacto en el éxito del proyecto, incluyendo factores dentro o fuera de la organización.
74
4. Riesgos del negocio. En este aspecto, los riesgos definen los problemas que se contemplan
dentro del desarrollo del proyecto; una vez que el comienzo de éste ha sido ha sido aprobado.
Los tipos de riesgos que se pueden presentar son:
5. Alcances del proyecto a través de los requerimientos del negocio. Los alcances del
proyecto permiten al cliente y a los desarrolladores, identificar las implicaciones del
desarrollo como son, el tiempo de construcción, los costos y las personas involucradas en
desarrollo (por parte del cliente y por parte de los desarrolladores). En ocasiones, es difícil
para los desarrolladores estimar tiempos y costos de desarrollo, sin embargo, en la mayoría de
los proyectos, el cliente tiene un tiempo máximo permitido y un costo que no puede exceder
su presupuesto. Los conflictos que surjan por los tiempos y costos deben resolverse cuando la
etapa de factibilidad y de especificación de requerimientos estén terminadas. Hasta entonces,
se tendrá la información suficiente para llevar a cabo decisiones de contratación, o rechazo
del proyecto.
1. La estructura organizacional.
75
3.2. Búsqueda y Recolección de Información
Para comprender el problema a solucionar, es importante contar con diversa información que
permita conocer la organización del cliente, sus necesidades y en general el dominio de la
aplicación. Esta información debe recolectarse de distintos manuales de la organización,
estándares y políticas, y manuales técnicos que describan las distintas partes del dominio de la
aplicación y los procesos y normas de la organización. La información recolectada sobre el
problema a resolver, debe organizarse coherentemente a fin de que pueda ser utilizada no solo
durante el proceso de Ingeniería de Requerimientos, sino también durante todo el ciclo de
desarrollo.
Algunos ejemplos de información que debe ser recolectada son los siguientes:
1. Información sobre el sistema actual. Esta información provee detalles sobre el sistema que
se quiere remplazar y que actualmente está en funcionamiento. Si se trata de un producto a
desarrollar de uso genérico, ésta información deberá ser aquella que describe los productos
similares actualmente en el mercado, contra quienes el producto tendrá que competir. Es
importante en este caso, recolectar información sobre la funcionalidad y restricciones del
producto competidor, su precio, el soporte que se ofrece y sus limites geográficos de
distribución.
76
3.3. Definición de Límites y Restricciones
Los limites definen el contexto de operación del sistema y definen su medio de operación. Las
restricciones definen las limitantes organizaciones, técnicas, económicas o de tiempos de
desarrollo impuestas para el proyecto o producto de software a desarrollar. Dentro de las
restricciones deben definirse las condiciones de confiabilidad, disponibilidad, desempeño,
seguridad e integridad, y en general los requerimientos no-funcionales que se le exigirán al
sistema. Esta información influirá significativamente en la definición de la arquitectura del
sistema (por definir en la etapa de diseño).
El diagrama de contexto (referencia) se utiliza para definir los límites y las conexiones entre el
sistema y el medio ambiente que lo rodea. Además, identifica interfaces que permiten comunicar
al sistema con su medio externo. En la información que sale o entra al sistema a través de las
interfaces se utilizan flujos de control, de datos y de materiales. El diagrama de contexto puede
utilizarse como el diagrama que se encuentra en lo mas alto de la jerarquía arquitectónica del
sistema. La Figura 3.2 muestra el diagrama de contexto de un sistema de inscripciones a una
Universidad. El sistema permite a alumnos acceder al sistema mediante la Internet para realizar
su inscripción a sus cursos. El sistema reside en una computadora servidora de web y la
información de los cursos es introducida por los profesores de la universidad.
77
3.4 Definición de los interesados en el sistema
Los interesados en el sistema (“stakeholders”) son personas, grupos de personas o organizaciones
que están involucradas activamente en el proyecto, que son afectadas por sus salidas, o que
proveen entradas al sistema. El proceso de Ingeniería de requerimientos está dominado por
distintos factores personales, sociales y organizacionales, debido a que involucra a distinto tipo
de personas, con distintos conocimientos o provenientes de distintas organizaciones. Así mismo,
las distintas personas involucradas en el proceso pueden tener o no conocimientos técnicos
relevantes al proyecto, y pueden venir de distintas disciplinas técnicas. Este contrasta con otras
etapas del desarrollo, como por ejemplo la etapa de pruebas, en donde el personal involucrado
por lo general comparte el mismo interés y conocimiento técnico, y comparten el objetivo de
demostrar que el sistema cumple con sus especificaciones.
1. Clientes: Estos normalmente son quienes contratan, financian o autorizan el desarrollo del
proyecto.
2. Usuarios: Estos son aquellos que terminarán operando el software requerido, después de que
el sistema esté completamente desarrollado.
4. Ingenieros del cliente. Son todos aquellos especialistas que asesoran o trabajan dentro de la
organización del cliente y que ayudan a especificar los detalles técnicos de la aplicación a
desarrollar.
5. Administradores o jefes del proyecto de software: Son aquellos que dirigen y/o
administran el proyecto de software.
6. Contratistas externos. Son aquellos desarrolladores externos a quienes se les contrata para
realizar una parte del sistema.
7. Reguladores externos: es todo aquel personal que indirectamente verifica que todo
reglamento o ley que aplique al desarrollo del proyecto se cumpla.
78
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.
1. El valor o beneficio que recibirá el interesado del producto o del sistema y la forma en que el
producto satisfacerá al interesado. Los beneficios que podría obtener el interesado podrían
ser:
b. Mejoras en su productividad.
d. Ahorro de costos.
Además de clasificar a los interesados en el sistema, es necesario proveer detalles acerca de los
tipos de usuarios que utilizaran directamente el sistema. A los usuarios de sistema de software se
les puede clasificar de acuerdo a los siguientes aspectos:
• Sus privilegios de acceso o niveles de seguridad (tales como usuario invitado, administrador o
usuario de nivel interno).
• Tipo de usuarios necesario para operar el sistema (persona, grupo de personas, robot, o otra
computadora).
Algunos usuarios del sistema no llegan a utilizar el sistema, 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 los integradores ó los
ingenieros de producto, los cuales se encargan de usar 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 otro lado, los usuarios no necesariamente tienen que ser personas. Algunos sistemas se
operan de forma automática, mediante otros sistemas de cómputo, 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.
80
3.4.1 Roles y Actividades
En general, los interesados involucrados en el proceso de Ingeniería de requerimientos son
personas afectadas por este proceso a quienes se les puede identificar por sus roles en la
organización. Usualmente es útil cuando se modela un proceso, asociar las actividades del
proceso con los roles del personal que está involucrado en el proceso.
Los roles del personal y sus correspondientes actividades dentro del proceso de Ingeniería de
Requerimientos se describen en la Figura 3.3.
Rol Actividades
Analista de Requerimientos, Experto del Este personal estará a cargo de entender el
dominio, usuario problema y su definición.
Usuario, experto del dominio, analista de Estarán a cargo de evaluar el sistema final o
requerimiento e Ingeniero de Desarrollo prototipo.
81
3.5 Recolección de Requerimientos
Después de la descripción del problema por el cliente, el analista de requerimientos debe escribir
en un documento inicial (DDR), una lista de requerimientos específicos, que describen a detalle
el problema planteado por el cliente. Este documento debe ser analizado para darle consistencia
durante la fase de análisis de requerimientos. De forma general los requerimientos provienen de
las siguientes fuentes:
Los requerimientos obtenidos deben de estar de acuerdo con los objetivos y planes de la
organización y aquellos requerimientos que no ayuden a lograr estos objetivos no deben ser
incluidos. Las fuentes de donde se obtienen los requerimientos dependen de la naturaleza del
producto a desarrollar y del ambiente de desarrollo. La necesidad de obtener los requerimientos
de múltiples fuentes implica que siempre debe existir una comunicación fluida e intensa entre
cliente/usuarios y desarrolladores.
• Análisis de los escenarios de las tareas del usuario. La identificación de las tareas que el
usuario necesita llevar a cabo con el sistema, permitirá al analista de requerimientos obtener
83
algunos de los requerimientos funcionales. De esta identificación debe también obtenerse
toda la información consumida y generada por la tarea y sobre las fuentes de la información.
• Análisis de Eventos y Respuestas. Este análisis permitirá identificar los eventos externos a
los cuales el sistema debe reaccionar y sus respuestas correspondientes. Este análisis es
especialmente útil en sistemas que deben responder a eventos externos y que requieren de
respuestas en plazos de tiempo cortos o en tiempos bien definidos.
Requerimientos
del negocio
Ideas y Casos de
soluciones y escenarios
Restricciones Requerimientos
funcionales
Requerimientos Atributos de y no-funcionales
de interfaces Calidad
externas
84
En capítulos anteriores hemos dado distintas clasificaciones de los requerimiento, sin embargo
aquí daremos una clasificación general que permita distinguir los requerimientos capturados. La
Figura 3.4, muestra 9 de éstas posibles categorías.
La información que no se encuentre dentro de esta clasificación no debe considerarse, y puede ser
lo siguiente:
• Una restricción del proyecto de desarrollo, por ejemplo el costo o el plan de ejecución (que no
se trate de restricciones de diseño e implementación).
• Una suposición.
• Un requerimiento de datos, el cual puede ser asociado con la funcionalidad del sistema, por
ejemplo que los datos deben ser almacenados en la computadora.
2. Casos de uso y escenarios: Los casos de uso son descripciones generales de metas del cliente
o tareas del negocio que los usuarios deben realizar. Un patrón único del caso de uso se
conoce como escenario. Es necesario trabajar con los clientes y usuarios para extraer los
escenarios, y de aquí conceptualizar los casos de uso. Los casos de uso se pueden obtener
mediante la descripción de los flujos de trabajo de los procesos de negocio del cliente. Otra
forma de obtener los casos de uso es preguntando a los usuario sobre la descripción de sus
tareas o funciones. Un usuario que dice: “Tengo que <hacer algo>” esta probablemente
describiendo un caso de uso. Algunos ejemplos de casos de uso son los siguientes:
85
• Yo necesito imprimir una etiqueta de correo para el paquete.
• Yo necesito administrar una cola de reactivos químicos que esperan ser analizados.
Mas detalles de los casos de uso y los escenarios se describen mas adelante en la sección de
técnicas de obtención de requerimientos.
3. Reglas del negocio: Cuando un cliente dice que solo algunas clases de usuarios realizan
alguna actividad bajo condiciones especificas, podría estar describiendo una regla del
negocio. Se podrían derivar algunos requerimientos funcionales mediante estas reglas, pero es
importante considerar que éstas reglas no definen requerimientos no funcionales. De hecho
las reglas de negocio definen hechos, restricciones, acciones que habilitan funciones,
formulas de cómputo o inferencias. Las siguientes son algunas de las frases que sugieren
reglas del negocio:
Algunos de los requerimientos funcionales podrían ser opcionales. Es decir que podrían
implementarse solo en el caso de que el tiempo o el presupuesto asignado lo permitiera. Los
requerimientos opcionales suelen presentarse con frecuencia, ya que es difícil predecir los
tiempos y los costos de desarrollo. Podrían considerarse también, a un precio por separado o
ser ignorados.
86
5. Atributos de calidad: Los atributos de calidad son requerimientos no-funcionales, los cuales
indican la forma en que el sistema debe realizar alguna actividad. Estos atributos se obtienen
de escuchar algunas frases o palabras que describen el comportamiento del sistema, tales
como: rápido, robusto, seguro, confiable, o eficiente. El analista de requerimiento tendrá que
estar de acuerdo con el cliente sobre el significado de estos términos de forma que se eviten
ambigüedades o descripciones subjetivas.
87
Las siguientes son ejemplos de algunas restricciones descritas por el cliente o el usuario:
Otras frases que describen restricciones al diseño podrían ser las siguientes:
8. Definiciones de datos: Las definiciones de datos permiten identificar formato de los datos o
archivos, rango de valores permitidos, valores por defecto, o estructura la base de datos.
Estas definiciones las puede proveer el cliente o pueden ser abstraídas por el analista (o por
cualquier desarrollador). Algunos ejemplos de definiciones de datos pueden ser las siguientes:
9. Ideas de solución: Mucho de lo que los clientes presentan como requerimientos podría
considerarse mas bien como ideas de solución. Algún cliente que describe como debería
comportase el sistema ante el operador, tal vez solo está describiendo sus ideas sobre posibles
soluciones. Las ideas de solución podrían derivar en requerimientos, si estas son validadas y
son factibles de implementar, pero en otras ocasiones estas solo podrían ser alternativas de
diseño. Por ejemplo, un cliente podría indicar que para proporcionar seguridad al sistema ante
ataques externos, este debe pedir un pasword, o podría construirse un “firewall” o hacer que
los datos usen encriptación. En este caso, el cliente esta dando ideas sobre posibles soluciones
al problema de añadir seguridad al sistema.
88
3.6.1 Identificación de los Elementos del Sistema
Otra clasificación de los requerimientos del sistema puede darse mediante la identificación de los
elementos que la componen. Una vez ubicados los limites del sistema mediante su diagrama de
contexto, es importante identificar cada elemento que compone al sistema y sus características.
Los elementos del sistema son los siguientes:
2. Salidas del sistema: describen los dispositivos de salida, que pueden ser dispositivos de
video o audio, así como la funcionalidad de los mismos.
3. Funciones del sistema: describen el mapeo de las entradas a las salidas, y sus distintas
combinaciones. Así mismo describen, los comandos que requiere cada función del sistema.
4. Atributos del sistema: describen los requerimientos no-funcionales necesarios para que el
sistema opere correctamente, como la confiabilidad, la usabilidad, la disponibilidad, la
mantenibilidad o el desempeño.
5. Atributos del ambiente del sistema: describe otros atributos requeridos del sistema, tales
como la máxima carga permitida, máxima temperatura permitida, restricciones de operación,
o compatibilidad.
89
3.7 Características de calidad de los requerimientos
Muchas de las características de calidad de los requerimientos han sido conocidas desde hace
muchos años, sin embargo aun hoy muchos proyectos carecen de algunas de éstas características
por lo cual producen productos de software con poca calidad. Para mejorar las características de
calidad de los requerimientos es necesario detallar los conceptos que permiten mejorar la calidad
de los requerimientos de software.
La calidad de los requerimientos está dada de acuerdo a sus características. Dicha calidad
permitirá garantizar a los desarrolladores y clientes su entendimiento y utilización. Estas
características son:
90
requiere dedicar tiempo, presupuesto y esfuerzo adicional, lo cual no siempre está
disponible en todo proyecto.
6. Verificable. Es verificable cuando puede ser cuantificado de manera que nos permita
hacer uso de métodos de verificación (tales como inspección, análisis, demostración o
pruebas) para garantizar que cumple sus propósitos. Los requerimientos deben cumplir
con las necesidades de los interesados. Para asegurar que un requerimiento es verificable
es útil asegurar que cada requerimiento es lo que los clientes y usuarios realmente
necesitan.
7. Correctos. Los requerimientos son correctos si estos describen lo que el cliente o usuario
indican. Estos deben ser revisados por el cliente y el desarrollador, para asegurar que no
tienen errores. Los defectos en los requerimientos naturalmente llevarán a producir
defectos en el diseño y en la implementación. Para asegurar que algún requerimiento es
correcto es necesario verificar que es semánticamente correcto, que cumple con alguna de
las necesidades de los interesados, y que está correctamente escrito.
8. Reales. Todos los requerimientos deben ser revisados para asegurar que su
implementación es posible en el sistema. Esta característica también define si un
requerimiento es factible. Los requerimientos no tienen valor si no pueden ser
implementados. Si no existe a tecnología, el personal, la experiencia o el presupuesto para
implementarlo no será factible.
9. Rastreables. Los requerimientos pueden ser rastreables hacia atrás y hacia delante.
Rastreable hacia atrás significa que para cada requerimiento se conoce su origen.
Rastreable hacia delante significa que todo requerimiento está escrito de tal forma que
facilita la referencia a los requerimientos con los que se relaciona.
91
10. Modificable. Un requerimiento es modificable si permite realizar cambios de manera
fácil, completa y consistentemente.
11. No redundantes. No deben existir dos requerimientos que definan funciones iguales o
similares, de otra forma estaríamos observando un requerimiento redundante.
2. Evolución del conocimiento del sistema del cliente/usuario o del analista. A medida que
los requerimientos se desarrollan, los clientes/usuarios o los analistas pueden entender mejor
el sistema y por lo tanto solicitar cambios en los requerimientos.
4. Cambios en las prioridades. Las prioridades del cliente pueden cambiar durante el
desarrollo del proyecto y pedir cambios. Esto puede deberse a cambios en la organización,
cambios en el ambiente operacional del producto, o cambios en el personal.
Es importante mencionar también que existen otros factores que contribuyen a que los procesos y
los requerimientos en si observen cierta variabilidad.
93
3.9 Dificultades para definir los requerimientos de software
Para conseguir un sistema de software de calidad se debe iniciar con la elaboración de
requerimientos correctos y precisos. La Ingeniería de Requerimientos es un proceso muy
complejo debido a la naturaleza y a la diversidad de ambientes de los sistemas. Existen una gran
variedad de dificultades a que se enfrentan los clientes y los analistas para lograr la obtención y
especificación de los requerimientos del sistema.
94
cliente es definitivo y completo. Sin embargo esta suposición puede ser muy riesgosa. Es
necesario verificar que esto se lleva a cabo. El ultimo síntoma que lleva a determinar que los
requerimientos son vagos, se presenta cuando los desarrolladores hacen frecuentes preguntas
a los analistas sobre la forma de implementar los requerimientos y de su significado. En
algunos casos, en realidad los diseñadores o quienes programan el sistema hacen suposiciones
o tienen que adivinar que es lo que un requerimiento realmente define. Las implicaciones de
estas suposiciones o adivinanzas puede no notarse hasta que el sistema es probado, o peor aun
cuando este es puesto en operación. En este punto, se requerirá regresar varias etapas hacia
atrás en el desarrollo para reparar los requerimientos mal interpretados. Muchas de estas
anomalías se resuelven mediante el análisis de los requerimientos y su correspondiente
validación (los cuales serán descritos en los próximos capítulos).
2. Poca familiaridad con los términos técnicos. La descripción de las necesidades del cliente
pueden estar expresadas utilizando sus propios términos y suposiciones con las cuales los
desarrolladores pueden no estar familiarizados. Por otro lado, los desarrolladores tienen
también su propio lenguaje, y en la mayoría de las veces creen estar hablando en los mismos
términos con el cliente, cuando en realidad proveen significados diferentes al mismo término.
Este fenómeno, ocasiona que los requerimientos no sean claros y que incluso lleguen a ser
definidos de forma incorrecta, muy alejada de lo que el cliente realmente requiere. En este
punto, es recomendable que el cliente se auxilie de sus ingenieros para la definición de los
requerimientos y también con el fin de lograr una mejor comunicación con el analista de
requerimientos.
5. Demandas poco realistas. Los usuarios con frecuencia no conocen realmente lo que desean
del sistema, y piden demandas irreales debido a que ignoran el costo de sus requerimientos.
95
Esto puede deberse a diversos factores. Por ejemplo, las demandas poco realista pueden
derivarse del hecho de que los clientes encargados de hablar con los analistas o con los
desarrolladores pueden no tener experiencia directa en hacer el trabajo que hacen los usuarios
del sistema actual. Así mismo, esto puede deberse también a que los desarrolladores conocen
soluciones al sistema, pero no siempre saben como afectarán las estas soluciones a las
actividades de negocio de los clientes. Finalmente, si la comunicación no se da de forma
fluida o si no está cuidadosamente organizada y fomentada entre el equipo de desarrollo y los
clientes, puede suceder que los requerimientos sean mal entendidos, que terminen
incompletos o que sean poco realista.
96
actualidad es de millones de dólares, y no invertir en mantenimiento y evolución puede llevar
a la organización a desechar continuamente el software que tantos esfuerzos costó desarrollar.
De hecho distintos estudios indican , que el 90 % del costo del software se dedica a el
mantenimiento y la evolución de los sistemas de software.
Como consecuencia de las dificultades antes descritas, el sistema de software a entregar podría
presentar los siguientes problemas:
• Los requerimientos no reflejan las necesidades reales de los usuarios o de los clientes. El
cliente y los usuarios podrían no estar satisfechos con el sistema o con algunas de sus
funciones. En consecuencia, podrían no usar (o utilizar con muchas dificultades) algunas
funciones del sistema.
• Es caro realizar cambios en los requerimientos después de que estos han sido implementados.
• Si el sistema continua en uso, los costos del mantenimiento y de la evolución del sistema
podrían ser bastante altos.
97
3.10 El costo de los requerimientos
En general, el costo de la Ingeniería de los requerimientos depende del tamaño y tipo del sistema
por desarrollar, y también de las actividades que implican los requerimientos en el desarrollo. En
algunos casos los requerimientos no están suficientemente claros y detallarlos lleva bastante
tiempo. En otros casos, los requerimientos cambian o tienden a evolucionar, y esto también
implica costos y tiempos de desarrollo extra. Los estudios llevados a cabo en la actualidad
indican que el costo económico de los requerimientos es del 10 al 15 por ciento del costo total del
desarrollo (referencia). Estas cifras corresponden a un proyecto que es llevado a cabo e
implementado con éxito. Sin embargo, muchos proyectos fallan o no cumplen con las
necesidades del usuario.
El costo de reparar un error en los requerimientos se ilustra en la Figura 3.5. Los costos de
desarrollo cuando los requerimientos son erróneos es bastante mayor que cuando estos no
requieren ninguna reparación. Además, entre mas avanzada este el desarrollo, el costo de reparar
los requerimientos es más alto. Reparar errores en los requerimientos puede requerir trabajar
nuevamente en el diseño, la implementación y las pruebas. Es mucho más económico reparar un
error o requerimiento ambiguo en la etapa de requerimientos, que hacerlo en la etapa de
programación. El problema es que si se detecta durante la fase de programación que existe un
error en los requerimientos será necesario regresar hacia todas las etapas anteriores a corregirlo y
de nuevo validar los requerimientos.
100
80
60
40
20
0
R equerim ientos D iseno C odificación P ruebas O peración
Fases del D esarrollo
Figura 3.5. Costos relativos de corregir los requerimientos.
98
3.11 Técnicas de Obtención de Requerimientos
Las técnicas de obtención de requerimientos son aquellas que nos permiten comprender el
dominio del sistema, buscar y recolectar información para definir sus límites y restricciones, e
identificar a las personas interesadas en el sistema. El resultado permite obtener una colección y
clasificación de los requerimientos del sistema, mediante la participación de los clientes y
usuarios.
3.11.1 Entrevistas
La entrevista es una técnica para obtener información mediante una conversación dirigida por los
analistas a clientes y usuarios, con el objetivo de entender el dominio del problema y sus
necesidades. Se basa en un formato de preguntas y respuestas. El desarrollador buscará obtener
las opiniones de los clientes o usuarios entrevistados, sus opiniones del sistema, sus metas
personales, de la organización y de los procedimientos informales.
Existen cinco puntos que deben tomarse en cuenta para preparar una entrevista [10]
• Selección de los entrevistados. Se entrevista a gente clave de todos los niveles del sistema.
• Selección del tipo y la estructura de las preguntas. Escribir las preguntas que cubran los
aspectos fundamentales del objetivo de la entrevista, eligiendo el tipo y la estructura adecuada
de las preguntas de la entrevista.
Las preguntas tienen ciertas estructuras básicas que se deben conocer. Los dos tipos básicos de
preguntas son abiertas y cerradas.
99
• Las preguntas abiertas permiten al entrevistado expresar de manera flexible y en
consideración de su experiencia responder a lo que se le pregunta.
• Las preguntas cerradas limitan las respuestas disponibles de los entrevistados mediante una
lista de opciones o alternativas de respuestas.
• Estructura de pirámide. En este caso, el entrevistador inicia con preguntas detalladas, del
tipo de preguntas cerradas, y luego realiza preguntas abiertas, de respuestas más
generalizadas.
Las entrevistas deben registrarse ya sea por un cuaderno de notas o utilizando una grabación. Es
importante que al final de la entrevista se escriba un informe con el fin de asegurar la calidad de
los datos de la entrevista.
3.11.2 Cuestionarios
Es una técnica para obtener información que permite a los desarrolladores del sistema recopilar
opiniones, posturas, conductas y características de los diversos usuarios que son encuestados y
que se encuentran involucrados en la operación del sistema actual o en la implantación de un
sistema nuevo. Los cuestionarios son eficaces si la gente de la organización se encuentra dispersa
o si mucha gente está involucrada en el proyecto de sistema [10]. Al igual que en la entrevista, un
cuestionario puede redactarse usando preguntas abiertas o preguntas cerradas y es importante
usar un vocabulario que refleje el lenguaje de los involucrados en la organización. El uso de
preguntas cerradas en los cuestionarios permite a los analistas medir los resultados mediante
gráficas. Esta técnica suele combinarse con las entrevistas para mejorar la obtención de
información del sistema.
100
3.11.3 Puntos de Vista
En cualquier sistema existen varios tipos de usuarios que tienen diferentes intereses en los
requerimientos del sistema, es decir, existen diferentes puntos de vista para un problema. El
enfoque orientado a puntos de vista toma en cuenta estos diferentes puntos de vista y los utiliza
para organizar y estructurar tanto el proceso de obtención como los requerimientos [2]. Se toma
en cuenta la existencia de diferentes perspectivas y proporciona un esquema para descubrir
problemas con los requerimientos propuestos por diferentes usuarios.
Las lluvias de ideas y los puntos de vista orientados a eventos son técnicas que utilizan este
enfoque.
a) Lluvias de ideas
En esta técnica se identifican los servicios potenciales y las entidades que interactúan con el
sistema. Se lleva a cabo mediante una reunión entre el equipo de desarrollo y la empresa que
solicita el software. Las personas involucradas generalmente son los usuarios del sistema y los
administradores. En esta reunión todos expresan sus ideas sobre el problema y la posible
solución. Cada persona participa sin ser interrumpida, las ideas son anotadas dentro de un
diagrama de burbuja en un pizarrón, y no pueden ser criticadas por los demás participantes. La
figura 3.6 demuestra como son capturadas las ideas dentro de los diagramas de burbujas del
sistema SIV. Al finalizar la sesión, se realiza una recolección de ideas sin duplicidad [2].
101
3.11.4 Observación
En la mayoría de las organizaciones se realiza algún trabajo en el cual se involucran distintos
grupos de personas que cooperan para llevar a cabo distintas tareas. La naturaleza de esta
cooperación es a menudo compleja y varía dependiendo de las usuarios involucradas, del
ambiente físico y de la organización en donde se realiza el trabajo. Los usuarios con frecuencia
encuentran dificultades para expresar la forma en como realizan sus tareas en la organización y la
forma en como cooperan con otras personas, por lo cual son necesarias técnicas y herramientas
para describir las actividades de los usuarios en la organización.
102
a) Etnografía
Generalmente los sistemas de información se encuentran dentro de un contexto social y
organizacional en donde los requerimientos del sistema se derivan y se restringen conforme a este
contexto. La etnografía es una técnica que se utiliza para entender estos tipos de requerimientos
sociales y organizacionales. El desarrollador se involucra en el entorno laboral donde se instalará
el sistema para observar y anotar las tareas reales que se llevan a cabo. Esta técnica descubre
requerimientos implícitos que reflejan los procesos reales más que los formales en donde la gente
está involucrada, y permite descubrir los factores sociales y organizacionales que puedan afectar
al sistema [2].
Es difícil detallar la forma de llevar a cabo un estudio etnográfico, sin embargo existen algunas
guías para el uso de esta técnica (referencia libro kotonya y somerville).
1. Asumir que la gente que se está estudiando son buenas en su trabajo y busca formas no
estándares de realizar el mismo trabajo (o la misma actividad). Esa observación permitirá
encontrar la eficiencia desarrollada por los usuarios la cual se debe a su experiencia.
2. Es importante dedicar tiempo a conocer a los usuarios y desarrollar una relación de confianza.
Si los usuarios no confían en quienes los observan, pueden llegar a realizar sus actividades de
forma que oculten sus habilidades o alguna información relacionada con el sistema actual.
Los usuarios pueden desconfiar de los observadores si detectan que el sistema en uso será
transformado o cambiado por otro sistema y que tal vez ellos no serán capaces de seguirlo
usando. A fin de desarrollar confianza entre los usuario y los observadores, en principio los
usuarios deben conocer los objetivos del nuevo sistema y las razones por las que están siendo
observados.
3. Se deben escribir notas detalladas acerca de las actividades de los usuarios y verificadas en
distintos días de trabajo. El observador (etnógrafo) debe sacar conclusiones de su observación
a fin de analizarlas. Esto permitirá conocer a detalle el sistema actual y los requerimientos
que solicita el cliente.
4. Podría ser necesario también entrevistar a los usuarios o sacar video de sus actividades para
complementar las notas.
103
3.11.5 Escenarios
Los escenarios son parte básica de algunos métodos de análisis orientados a objetos, y son
representaciones de la forma en que el usuario interactúa con el sistema. En este esquema se
representan gráficamente las entradas, la salidas, el flujo de datos y el comportamiento del
sistema [11]. Los escenarios pueden agregar detalles a alguna acción mediante el diseño de
ejemplos de interacción entre el usuario y el sistema. Existen dos esquemas para esta
representación: mediante escenarios de eventos ó casos de uso.
a) Escenarios de eventos
Este enfoque se utiliza para documentar el comportamiento del sistema ante eventos específicos.
Los escenarios de eventos incluyen una descripción del flujo de datos y las acciones del sistema,
y documenta las excepciones que pueden ocurrir. Un escenario de evento es una instancia de un
caso de uso, es decir, nos representa una secuencia de sucesos que podrían ocurrir en una
situación dada [2].
104
Figura 3.7 Escenario de eventos para transacciones de un cajero automático.
De la figura 3.7 se puede observar que los escenarios deben contener la siguiente información
(referencia Libro Kotonya y somerville):
1. Una descripción del estado del sistema antes de entrar al escenario. En este estado el sistema
esta en espera de obtener información sobre la tarjeta de crédito y el PIN.
3. Las excepciones al flujo normal de los eventos. Por ejemplo, interrupción, tarjeta invalida,
tarjeta robada o PIN incorrecto (y las correspondientes acciones de manejo de excepciones).
4. Información sobre otras actividades que pueden estar ocurriendo al mismo tiempo. Como son,
comunicaciones con la computadora del banco, manejo de motores para aceptar o rechazar
tarjetas de crédito, etc.
5. Una descripción del estado del sistema después de terminar el escenario. Al final, el sistema
podrá aceptar la selección de servicios del cajero automático.
La aplicación de esta técnica requiere del analista de requerimientos así como de los usuarios
finales. Ambos interesados deben trabajar junto con los ingenieros del cliente para definir cada
105
escenario, tomando nota de los comentarios, problemas y sugerencias. Una vez terminado el
diseño de algún escenario, el usuario debe simularlo para verificar que partes del escenario son
incorrectas, incompletas o poco factibles de implementar. El analista debe preguntar al usuario
sobre las acciones que se llevan a cabo actualmente, la forma en como se realizan las tareas,
quienes están involucrados en las tareas, y que sucede si las tareas se llevan a cabo de distinta
forma.
El tiempo de desarrollo de los escenarios puede ser largo ya que involucra de interacción con los
usuario y de entender las actividades y tareas del sistema.
b) Casos de uso
Los casos de uso son una técnica que se basa en escenarios para la obtención de requerimientos
[2]. En los casos de uso se especifican una secuencia de acciones, incluyendo variantes que el
sistema puede llevar a cabo y que producen resultados observables de valor para un actor
determinado [5]. En un modelo de caso de uso se puede identificar a un conjunto de actores
involucrados y su relación con varios casos de uso. Un conjunto de casos de uso representan
todas las posibles interacciones que ocurrirán en los requerimientos del sistema. Los actores
pueden tener las siguientes representaciones: personas, sistemas o hardware y cualquier de las
tres representaciones puede estar relacionada con un caso de uso.
Los requerimientos funcionales pueden estar representados mediante casos de uso y muchos de
los requerimientos no funcionales pueden estar asociados a ellos. En la notación gráfica de UML
(referencia), se representa a un actor con un símbolo de una persona. Un caso de uso se
representa mediante una elipse y la relación entre ellos se representa mediante una línea que
puede indicar el sentido de la relación. La Figura 3.8 representa un modelo de casos de uso para
una biblioteca.
Algunos analistas describen los casos de uso añadiendo texto a los diagramas, anotando todos los
detalles que ocurren en cada escenario. Para detallar más a los casos de uso, en UML se utilizan
los diagramas de secuencia, diagramas de actividad, diagramas de colaboración y diagramas de
estados (referencia).
106
Figura 3.8 Representación de casos de uso para una biblioteca.
3.11.6 Prototipos
Un prototipo es un versión inicial de un sistema de software que se utiliza para demostrar los
conceptos, probar las opciones de diseño y de forma general enterarse más acerca del problema y
sus posibles soluciones. La Figura 5.20 muestra los dos tipos de prototipos existentes.
107
Figura 5.20 Construcción de prototipos evolutivos y desechables.
3.11.8 Maestro/Aprendiz
Es una técnica en donde el papel del aprendiz es representado por los analistas o desarrolladores
y los usuarios representan al maestro. Los desarrolladores participan en un entrenamiento con los
usuarios finales del sistema. El aprendiz hace uso de la observación y podrá cuestionar sobre el
origen y significado de las tareas que realice. También, el aprendiz podrá realizar algunos
trabajos bajo la supervisión del maestro con el fin de proponer ideas o alternativas de solución. El
principal objetivo es proporcionar detalles al aprendiz sobre tareas específicas del usuario final
[18].
108
3.11.9 Despliegue de la Función de Calidad
Esta técnica (también conocida como “Quality Function Deployment”) fue propuesta por los
japoneses para determinar los requerimientos de calidad en la industria automotriz, se concentra
en maximizar la satisfacción del cliente [3]. El enfoque principal de QFD es la Función de
Calidad, en la cual se muestran las relaciones entre los requerimientos del cliente y las
características del producto mediante una matriz, en donde las filas representa los requerimientos
y las columnas representan los casos de uso (Tabla 3.1).
En la función de calidad se marca la intersección que existe entre un requerimiento y los casos de
uso que lo implementan, verificando que todo requerimiento sea implementado por algún caso de
uso y que todo caso de uso represente algún requerimiento. Además se deben revisar que no
existan elementos repetidos (redactadas de diferentes maneras) o contradictorias tanto en la lista
de requerimientos como en los casos de uso.
Hay varias maneras de obtener esta información, puede obtenerse mediante una reunión grupal,
donde todos los interesados conocidos estén representados ó pueden citarse grupos pequeños de
interesados a reuniones. En caso de que esto fallara, puede entrevistarse a uno por uno del grupo
de interesados identificados.
111
clientes del sistema. En general, lo que se desea lograr es determinar el contexto y la información
detallada del sistema en la que los requerimientos están basados [15].
112
INDICE DE CONTENIDO
3. Obtención de Requerimientos
3.1.Comprensión del Problema
3.1.1.Comprensión del dominio de la aplicación.
3.1.2.Comprensión de las necesidades de los clientes y usuarios.
3.1.3.Requerimientos del negocio
3.2.Búsqueda y Recolección de Información
3.3.Definición de Límites y Restricciones
3.4.Definición de los interesados en el sistema
3.4.1 Roles y Actividades
3.5.Recolección y Clasificación de Requerimientos
3.6.Clasificación de Requerimientos
3.6.1 Identificación de los Elementos del Sistema
3.7 Características de calidad de los requerimientos
3.8 Factores que llevan a realizar cambios en los requerimientos
3.9 Dificultades para definir los requerimientos de software
3.10 El costo de los requerimientos
3.11.Técnicas de Obtención de Requerimientos
3.11.1.Entrevistas
3.11.2.Cuestionarios
3.11.3.Puntos de Vista
3.11.4.Observación
3.11.5.Escenarios
3.11.6.Análisis de Protocolos
3.11.7.Maestro/Aprendiz
3.11.8.Despliegue de la Función de Calidad (Quality Function Deployment)
3.11.9.Talleres de Trabajo basados en Casos de Uso (Run Use Case WorkShop)
3.11.10.Análisis de Usuarios Interesados (Stakeholder)
3.7.11.Demostración de Tareas
3.11.12.Enfoque Grupal (Focus Groups)
3.11.13.Talleres Futuros (Future Workshops)
3.11.14.Estudio de Documentos/Datos
113
Verificar:
1. Directores de proyecto.
Que es facilitadores ?
4. Explicar mejor y con mas detalle algunas de las técnicas de la seccion 3.11.
7. Algunas de las técnicas de obtención son muy cortas o muy escuetas o tienen poco detalle,
pero que tanto detalle debe dárseles ?
114